با عرض سلام و وقت به خیر خدمت کاربران سایت پی وی لرن به ویژه کاربرانی که به سیستم مدیریت محتوای قدرتمند وردپرس علاقمند هستند.
به ” دوره متخصص وردپرس ” خوش آمدید!
در این دوره قرار است توسعه و ارتقاء پلاگین های وردپرس را به صورت جامع و کامل بیاموزیم.
فرقی نمی کند که در شرف نوشتن اولین پلاگین خود هستید و یا این که پنجاهمین پلاگین خود را می نویسید! امیدوارم این دوره برایتان مفید باشد.
در جلسه گذشته با متودهای حذف یک پلاگین و تفاوت آن با هوک غیر فعال سازی آشنا شدیم.
در این جلسه شما را با بهترین روش های سازماندهی کدهای پلاگین آشنا می نماییم.
در این جلسه با برخی بهترین روش های سازماندهی کدهای پلاگین که می توانند در کنار هسته وردپرس برای سایر پلاگین ها به کار رود آشنا می شویم.
Naming Collisions یا تصادم نام ها زمانی رخ می دهد که پلاگین شما از نام مشابهی با پلاگین دیگر برای یک متغیر، تابع یا کلاس استفاده نماید.
با استفاده از روش های زیر می توانید از تصادم نام ها جلوگیری نمایید.
اولین روش سازماندهی کدهای پلاگین روش Procedural است.
به طور پیش فرض، تمام متغیرها، توابع و کلاس ها در namespace سراسری تعریف شده اند.
این امر یعنی ممکن است متغیر، توابع و کلاس ها توسط پلاگین دیگری از بین برود و برعکس.
متغیرهایی که درون توابع یا کلاس تعریف شده اند از این قاعده تاثیر نمی پذیرند.
تمام متغیرها، توابع و کلاس ها باید با یک شناسه منحصر به فرد پیشوند شوند.
پیشوندها از بازنویسی متغیرهای دیگر پلاگین ها و فراخوانی تصادفی توبع و کلاس های شما جلوگیری می کند.
علاوه بر این اگر شما نیز این مسئله را از خاطز بردید؛ شما را نیز از انجام آن باز می دارد.
موارد در حال اجرای PHP تعدادی تابع فراهم می کند که وجود متغیرها، توابع، کلاس ها و constant ها را تایید می کند.
اگر این موارد تایید شوند آن گاه همگی بازگردانی می شوند.
1 2 3 4 5 6 7 8 9 10 11 12 13 | //Create a function called "wporg_init" if it doesn't already exist if ( !function_exists( 'wporg_init' ) ) { function wporg_init() { register_setting( 'wporg_settings', 'wporg_option_foo' ); } } //Create a function called "wporg_get_foo" if it doesn't already exist if ( !function_exists( 'wporg_get_foo' ) ) { function wporg_get_foo() { return get_option( 'wporg_option_foo' ); } } |
یکی دیگر از روش های سازماندهی کدهای پلاگین که از تصادم نام ها جلوگیری می کند روش OPP است.
این روش از یک کلاس برای کد پلاگین استفاده می نماید.
در این روش همچنان باید ببینید آیا نام کلاس تان تکراری است یا خیر اما بهتر است بدانید سایر کلاس ها توسط PHP بررسی خواند شد.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | if ( !class_exists( 'WPOrg_Plugin' ) ) { class WPOrg_Plugin { public static function init() { register_setting( 'wporg_settings', 'wporg_option_foo' ); } public static function get_foo() { return get_option( 'wporg_option_foo' ); } } WPOrg_Plugin::init(); WPOrg_Plugin::get_foo(); } |
سطح ریشه دایرکتوری پلاگین شما باید شامل فایل plugin-name.php و، optionally، فایل uninstall.php تان باشد.
هر فایل دیگری نیز باید در هر زمان که امکان دارد، در پوشه های زیر قرار گیرد.
یک ساختار پوشه ای به شما کمک می کند که علاوه بر کار روی پلاگین تان هم زمان روی فایل های دیگری نیز کار کنید.
در زیر نمونه ای از ساختار پوشه ای را ببه عنوان رفرنس مشاهده می کنید :
1 2 3 4 5 6 7 8 9 10 11 12 13 | /plugin-name plugin-name.php uninstall.php /languages /includes /admin /js /css /images /public /js /css /images |
معماری یا کد سازمانی که برای افزونه یا پلاگین تان انتخاب می کنید به احتمال زیاد به اندازه پلاگین تان بستگی دارد.
برای پلاگین های کوچک و منحصر به فرد که تعامل محدودی با هسته وردپرس، تم ها یا سایر پلاگین ها دارند، کلاس های engineering complex مفید اند.
البته اگر فکر می کنید که پلاگین تان در آینده گسترش خواهد یافت بهتر است از کلاس engineering complex استفاده نکنید.
برای پلاگین های بزرگ تر که کدهای بیشتری دارند؛ از start off with classes in mind استفاده نمایید.
فایل های استایل و اسکریپت و حتی فایل های build-related جدا کنید.
این امر به سازماندهی کدها و نگهداری طولانی مدت پلاگین تان کمک می کند.
یکی از روش های سازماندهی کدهای پلاگین که در جدا سازی کدهای عمومی و کدهای ادمین تان کمک می کند روش بارگیری مشروط است.
برای مثال :
1 2 3 4 | if ( is_admin() ) { // we are in admin mode require_once( dirname( __FILE__ ) . '/admin/plugin-name-admin.php' ); } |
به طور کلی می توان الگوهای طراحی پلاگین ها را در سه دسته قرار داد :
اجرا های خاص و پیچیده چندین کد سازمانی در حال حاضر در چندین آموزش و بخش نوشته شده اند.
به جای این که از اول بخواهید یک پلاگین را صفر تا صد خودتان بنویسید؛ چطور است این کار را با boilerplate شروع کنید.
یکی از مزیت های قابل توجه boilerplate این است که موجب هماهنگی میان پلاگین های شما می شود.
اگر از boilerplate استفاده نمایید دیگران نیز در استفاده از پلاگین شما راحت تر خواهند بود.
به این معنا که دیگران به سهولت و راحتی بیشتری می توانند کدهای شما را مورد استفاده قرار دهند.
پس اگر دیگران نیز از این ابزار در پلاگین خود استفاده نمایند شما نیز بعد ها در استفاده از آن دست باز تر و سهولت بیشتری خواهید داشت. یعنی هنگام بازنویسی و ویرایش کدهای یک پلاگین لازم نیست آن را از صفر بازنویسی نمایید.
در ادامه به برخی از ابزارهای دیگر که می تواند در طراحی پلاگین وردپرستان کمک کند اشاره می نماییم.
شما می توانید از میان این سه ابزار، ابزاری را که بیش از همه ممکن است به کارتان بیاید را انتخاب نمایید.
در این جلسه بیش هشت روش ارائه شد که همگی جزئی از بهترین روش های سازماندهی کدهای پلاگین هستند.
چهار مورد از این روش ها چون روش Procedural، روش پیشوند سازی، روش opp و … از تصادم نام ها جلوگیری می کردند.
حدود سه روش (روش پوشه Structure، روش بارگیری مشروط، روش معماری پلاگین) جز آن دسته از روش هایی بودند که سازماندهی فایل ها را هنگام ایجاد و طراحی پلاگین راحت تر می کنند.
در نهایت نیز boilerplate معرفی شد که در واقع اگر همه پلاگین نویس ها به استفاده از آن روی بیاورند پلاگین نویسی بسیار ساده تر خواهد شد و دیگر برای نوشتن یک پلاگین، دیگر به طراحی صفر تا صدی آن احتیاج نخواهد بود.
در پایان نیز با سه ابزار کاربردی اشنا دشیم که می توان بنا بر اقتضا از هر کدام و یا هر سه برای نوشتن پلاگین وردپرس استفاده کرد.
در جلسه بعدی با تعیین دایرکتوری پلاگین و محتوا همراه شما خواهیم بود.
با پی وی لرن همراه باشید.
حمید
با سلام و تشکر ویژه بابت مطالب مفید مقالات پلاگین نویسی. واقعا کارتون باارزش هست. با آرزوی موفقیت
پی وی لرن
ممنون نظر لطف شماست