جلسه ۶۸ : آشنایی با قوانین دقیق ساخت پلاگین

• جزئیات
• نوع محتواآموزشی

مقدمه

با عرض سلام و وقت به خیر خدمت کاربران سایت پی وی لرن به ویژه کاربرانی که به سیستم مدیریت محتوای قدرتمند وردپرس علاقمند هستند.
به ” دوره متخصص وردپرس ” خوش آمدید!
در این دوره قرار است توسعه و ارتقاء پلاگین های وردپرس را به صورت جامع و کامل بیاموزیم.
فرقی نمی کند که در شرف نوشتن اولین پلاگین خود هستید و یا این که پنجاهمین پلاگین خود را می نویسید! امیدوارم این دوره برایتان مفید باشد.
در جلسه گذشته مختصراً با راهنمای افزونه WordPress.org آشنا شدیم.
در این جلسه وقت آن است که به  آشنایی با قوانین دقیق ساخت پلاگین پردازیم.

آشنایی با قوانین دقیق ساخت پلاگین

دایرکتوری پلاگین

هدف دایرکتوری پلاگین وردپرس فراهم کردن مکانی امن برای همه کاربران وردپرس است.
این کاربران باید از افزونه هایی استفاده کنند که با اهداف پروژه وردپرس سازگار است.
برای این منظور ، می خواهیم یک فرآیند ساده و شفاف را برای توسعه دهندگان ارائه کنیم که افزونه ها را برای دایرکتوری ارسال کنند.
در ادامه برای شفاف سازی بیشتر، فهرستی از افزونه ها و لیستی از دستورالعمل های توسعه دهنده را ارائه کرده ایم.

انتظارات توسعه دهنده

از برنامه نویسان، کلیه کاربران دارای دسترسی و کلیه کاربرانی که بطور رسمی از یک افزونه پشتیبانی می کنند؛ انتظارتی می رود.
از آن ها انتظار می رود که از دستورالعمل ها و قوانین دایرکتوری پیروی کنند.
وجود نقض ممکن است باعث شود پلاگین ها یا داده های افزونه (برای افزونه هایی که قبلاً تأیید شده اند) تا زمانی که مشکلات حل شوند از دایرکتوری حذف شوند.
داده های افزونه ، مانند بررسی های کاربر و کد ممکن است بسته به ماهیت تخلف و نتایج بررسی همسالانه از وضعیت ، بازیابی نشوند.
نقض هاو اشکالات مکرر ممکن است باعث شود همه افزونه های نویسنده از بین بروند و توسعه دهنده از میزبانی افزونه ها در WordPress.org محروم شود.
این مسئولیت توسعه دهنده افزونه است که اطمینان حاصل کند اطلاعات تماسش در WordPress.org به روز و دقیق است ، تا همه اعلان ها را از تیم افزونه ها دریافت کند.

از یک توسعه دهنده چه چیزی انتظار می رود؟

پاسخهای خودکار و ایمیلهایی که به سمت سیستم پشتیبانی ارسال می شوند مجاز نیستند.
زیرا از نظر تاریخی مانع از دسترسی به موقع افراد به ایمیل های ارسالی می شوند.
کلیه کدهای موجود در فهرست باید تا حد امکان ایمن باشد.
امنیت مسئولیت نهایی توسعه دهنده افزونه ها است ، و راهنمای افزونه ها این امکان را به بهترین وجه فراهم می کند.
اگر یک افزونه پیدا شود که دارای مشکلات امنیتی است ، تا زمانی که مشکل برطرف نشود؛ این پلاگین بسته خواهد شد.
در موارد شدید ، این افزونه ممکن است توسط تیم امنیتی WordPress به روز شود و برای امنیت عمومی مردم تبلیغ شود.

در ” آشنایی با قوانین دقیق ساخت پلاگین ” تلاش می کنیم که تا حد ممکن شما را با تمامی دستورالمعل های ساخت و انتشار پلاگین آشنا نماییم.
اما باز هم شرایطی هستند که ممکن است یک افزونه آن را نقض کند.
در آشنایی با قوانین دقیق ساخت پلاگین نه مورد اساسی که در ساخت پلاگین ارائه شده است.
این موارد را بررسی کرده و سعی کنید که رعایت نمایید.

۱) قواعد

افزونه ها باید با مجوز عمومی عمومی GNU سازگار باشند.
اگرچه هر مجوز سازگار با GPL نیز قابل قبول است.
اما استفاده از مجوز مشابه با وردپرس – “GPLv2 یا بالاتر” – اکیداً توصیه می شود.
هر چیزی که در فهرست افزونه ها در WordPress.org قرار داده شده است – باید با GPL یا مجوز سازگار با GPL باشد.
این موارد ممکن است شامل کتابخانه های شخص ثالث ، کد ، تصاویر یا موارد دیگر شود.
برای آشنایی بیشتر با این موارد لیست مجوزهای سازگار با GPL را در gnu.org بخوانید.

۲) مسئولیت توسعه دهندگان در قبال محتوا و کارکرد پلاگینی که ساخته اند

این وظیفه توسعه دهندگان افزونه است که اطمینان حاصل کنند کلیه پرونده های موجود در افزونه شان کاملاً با قوانین مطابقت دارند.
نوشتن کدی به طور عمدی برای دور زدن دستورالعمل ها یا بازیابی کدی که از آنها خواسته شده است حذف کنند ، ممنوع است.
(به شماره ۹ اقدامات غیرقانونی / نامشخص مراجعه کنید).

توسعه دهندگان باید قبل از بارگذاری افزونه خود در SVN یک مسئله را رعایت کنند.
این مسئله مجوز پرونده هاست.
توسعه دهندگان باید مجوز کلیه پرونده های موجود را از کد منبع اصلی گرفته تا تصاویر و کتابخانه ها تأیید کنند.
علاوه بر این، آنها باید شرایط استفاده را برای کلیه خدمات شخص ثالث و API های مورد استفاده در افزونه های خود مطابقت دهند.
آن ها باید به خاطر داشته باشند که :
اگر راهی برای اعتبارسنجی مجوزهای کتابخانه یا شرایط یک API وجود نداشته باشد ، پس نمی توان از آن استفاده نمود.

مورد بعدی که در آشنایی با قوانین دقیق ساخت پلاگین باید آن را رعایت کرد تهیه پلاگین از  لیست های معتبر است.

۳) نسخه پایدار یک افزونه باید از صفحه فهرست افزونه های WordPress در دسترس باشد

تنها نسخه افزونه ای که WordPress.org توزیع می کند نسخه معتبر افزونه محسوب می شود.
افراد می توانند کد پلاگین خود را در جایی دیگر توسعه دهند.
اما کاربران باید ان را از WordPress.org دریافت کنند و نه جای دیگری.
توزیع کد از طریق روشهای جایگزین، در حالی که کد میزبانی هنوز در WordPress.org به روز نشده است؛ ممکن است موجب جذف افزونه شما شود.

۴) کدهای افزونه باید نه تنها توسط ربات ها که توسط افراد هم قابل خواندن باشند

کدهایی که برای افزونه تان می نویسید نه تنها باید توسط ربات ها که توسط افراد انسانی نیز قابل خواندن باشند.
پنهان کردن آن با تکنیکها یا سیستمهای مشابه ویژگی pf، a، c، k، e، rfscate، mangle uglify یا نامگذاری های نامشخص مانند z12sdf813d$ در فهرست مجاز نیست.
ساختن کدی که برای انسان قابل خواند نباشد توسعه دهندگان آینده را مجبور می کند با یک مانع غیر ضروری روبرو شوند.
علاوه بر این یک وکتور مشترک برای کد مخفی و مخرب ایجاد می کند.

امروز به توسعه دهندگانی احتیاج است که دسترسی عمومی، دسترسی مداوم به کد منبع خود و هرگونه ابزار ساخت را به یکی از روشهای زیر ارائه دهند:

• مستقر کردن کد منبع در deployed پلاگین.
• ایجاد لینکی در قسمت readme در محل توسعه.

ما اکیداً توصیه می کنیم نحوه استفاده از ابزارهای توسعه را مستند کنید.

در ادامه آشنایی با قوانین دقیق ساخت پلاگین به مسئله عدم استفاده از Trialware می پردازیم.

۵) عدم استفاده از Trialware

پلاگین ها ممکن است دارای عملکرد محدود باشند.
اما ممکن است که یک قابلیت در یک افزونه برای کاربران قفل باشد.
و یا ممکن است کاربران با پرداخت وجهی و ردیافت اشتراک، اجازه استفاده از یک افزونه را پیدا کنند.
یا حتی ممکن است برخی از قابلیت های یک افزونه مدتی به صورت آزمایشی برای کاربران کار کند و بعد از بین برود.
علاوه بر این ، افزونه هایی که فقط sandbox را به API ها و خدمات دسترسی می دهند ، نیز آزمایشی هستند ، یا افزونه های آزمایشی دارند و مجاز نیستند.

قابلیت هایی که پولی اند و باید حق اشتراک برای آن ها پرداخت مجازند.
اما مشروط بر اینکه تمام کد های داخل یک افزونه کاملاً در دسترس باشد.
پیشنهاد می کنیم که از add-on plugins که خارج از WordPress.org هستند استفاده نمایید.
استفاده از آن سبب می شود که بتوانید کد حق بیمه را حذف کنید.

موقعیت هایی که یک افزونه فقط به عنوان یک ابزار توسعه دهنده در نظر گرفته شده است ، به صورت پرونده ای مورد بررسی قرار می گیرد.

۶) یک پلاگین به عنوان یک نرم افزار فقط باید نقش خدمات رسانی را داشته باشد

پلاگین هایی که به عنوان واسط برخی از سرویس های شخص ثالث خارجی (مانند سایت میزبانی ویدیو) عمل می کنند ، فقظ برای خدمات پرداخت شده مجاز در نظر گرفته می شوند.
این نوع سروریس ها باید عملکردی را که وعده آن را داده اند محقق کنند.
این سروس ها باید در فایل readme ارسال شده با افزونه ، ترجیحاً با پیوند به service’s Terms of Use ، کاملاً مستند باشد.

خدماتی یا کارکردهایی که برای یک پلاگین یا افزونه وردپرس ممنوع است:

• خدماتی که تنها با هدف اعتبارسنجی مجوزها ایجاد شده اند.
• ایجاد سرویس با جابجایی کد دلخواه از افزونه:
  این کار به گونه ای که به نظر میرسد که گویی این سرویس به اشتباه می تواند قابیلت های تکمیل شده را ممنوع کند.
• فروشگاه هایی که نقش خدمات رسانی ندارند.
  بنابرین افزونه ای که فقط به عنوان پیش زمینه برای خریداری محصولات از سیستم های خارجی عمل می کند ، پذیرفته نخواهد شد.

۷) افزونه هایی که کاربران را بدون اجازه آن ها ردیابی می کند

به دلیل محافظت از حریم شخصی کاربران ، پلاگین ها ممکن است بدون رضایت صریح و مجاز با سرورهای خارجی تماس نگیرند.
این کار معمولاً از طریق روش “opt in” انجام می شود.
و بعد نیاز به ثبت نام با یک سرویس یا کادر تأیید در تنظیمات افزونه دارد.
مستندات چگونگی جمع آوری و استفاده از داده های کاربر ، باید ترجیحاً با یک خط مشی رازداری به وضوح بیان شده و در فهرست privacy policy درج شود.

برخی از نمونه های ردیابی ممنوع توسط پلاگین ها عبارتند از:

• جمع آوری خودکار داده های کاربر بدون تأیید صریح از طرف کاربر.
• گمراه کردن کاربر برای ارسال اطلاعات به عنوان شرط استفاده از افزونه.
• ابزار های آفلود (از جمله تصاویر و اسکریپت ها) که به یک سرویس ارتباطی ندارند.
• استفاده غیرقابل مستند (یا ضعیف مستند) از داده های خارجی (مانند لیست های سیاه blocklists).
• ساز و کارهای تبلیغاتی شخص ثالث که دیدگاه ها را ردیابی می کند.

۸) افزونه ها باید از کتابخانه های پیش فرض وردپرس استفاده کنند.

وردپرس شامل تعدادی کتابخانه مفید مانند

• jQuery
• Atom Lib
• SimplePie
• PHPMailer
• PHPass
• و موارد دیگر می باشد.

به دلایل امنیتی و ثبات ممکن است افزونه ها آن کتابخانه ها را در کد خود نداشته باشند.
در عوض افزونه ها باید از نسخه های کتابخانه های بسته بندی شده با وردپرس استفاده کنند.

به عنوان آخرین مورد در آشنایی با قوانین دقیق ساخت پلاگین ، به مبحث زمان ارسال یک پلاگین می پردازیم.

۹) یک پلاگین کامل باید در زمان ارسال موجود باشد

تمام افزونه ها قبل از تأیید بررسی می شوند ، به همین دلیل باید از یک فایل زیپ استفادخ کنید.
اسامی را نمی توان برای استفاده های بعدی یا برای محافظت از مارک ها reserved “رزرو کرد”.
نام دایرکتوری پلاگین های مصوب که استفاده نشده ممکن است به سایر توسعه دهندگان ارائه شود.

کلام آخر

در این جلسه به آشنایی با قوانین دقیق ساخت پلاگین پرداختیم.
در جلسه بعدی شما را با Subversion آشنا می نماییم.
با پی وی لرن همراه باشید.