بهترین شیوه های سازماندهی کد پلاگین

بهترین شیوه ها

در اینجا برخی از بهترین شیوه ­های کمک به سازماندهی کد پلاگین شما ارائه می­ شود، بنابراین، در کنار هسته وردپرس و سایر پلاگین­ های وردپرس به خوبی کار می­ کند.

اجتناب از تصادم ­ها یا برخورد های نامگذاری

برخورد نامگذاری زمانی اتفاق می­ افتد که پلاگین شما از نامی یکسان برای یک متغیر، تابع یا کلاس به عنوان پلاگینی دیگر استفاده کند.

خوشبختانه، با استفاده از متدهای زیر می­ توانید از تصادم­ ها یا برخورد­های نامگذاری اجتناب کنید.

رویه ­ای

به طور پیش فرض، تمام متغیرها، توابع و کلاس ­ها در فضای نام سراسری تعریف می­ شوند، که بدان معنا است که باطل کردن متغیرها، توابع و کلاس­های تعیین شده توسط پلاگین دیگری برای پلاگین شما امکانپذیر
می­باشد، و بالعکس. متغیرهایی که درون توابع یا کلاس­ها تعریف می­شوند، تحت تأثیر این نیستند.

به همه چیز پیشوند اضافه کنید

تمام متغیرها، توابع و کلاس­ها باید با شناسه منحصر به فرد پیشونددهی شوند. پیشوندها از این مسئله جلوگیری می­کنند که سایر پلاگین­ها، متغیرهای را مجدداً بنویسند و به طور تصادفی توابع و کلاس­های شما را فراخوانی کنند. شما را هم از انجام چنین کاری منع خواهد کرد.

پیاده ­سازی­ های موجود را چک کنید

PHP تعدادی از توابع را برای تأیید وجود متغیرها، توابع، کلاس­ها و ثابت­ها فراهم می­کند. اگر موجودیتی وجود داشته باشد، همه اینها درست برمی­گردانند.

  • متغیرها: isset() (شامل آرایه­ها، اشیاء و غیره)
  • توابع: function_exists()
  • کلاس­ها: class_exists()
  • ثابت­ها: defined()

مثال

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
//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' );
    }
}

OOP

راه ساده­تر برای مقابله با مشکل برخورد نامگذاری، استفاده از یک کلاس برای کد پلاگین شما است.

شما هنوز هم باید مراقبت بررسی این مسئله باشید که آیا نام کلاسی که می­ خواهید قبلاً اتخاذ شده است یا خیر، اما بقیه توسط PHP بررسی خواهند شد.

مثال

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
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، و به صورت اختیاری، فایل uninstall.php شما باشد. همه فایل­های دیگر باید در هر زمان که ممکن است، در زیر پوشه­ ها سازماندهی شوند.

ساختار پوشه

یک ساختار پوشه روشن به شما و دیگران کمک می ­کند تا روی پلاگین خود کار کرده، فایل­ های مشابه را با هم نگه دارید.

در اینجا یک ساختار پوشه نمونه برای مرجع ارائه می­ شود:

/plugin-name
     plugin-name.php
     uninstall.php
     /languages
     /includes
     /admin
          /js
          /css
          /images
     /public
          /js
          /css
          /images

معماری پلاگین

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

برای پلاگین­های کوچک و تک منظوره، که تعامل محدودی با هسته وردپرس، تم­ها و سایر پلاگین­ها دارند، مزیت کمی در کلاس­های پیچیده مهندسی وجود دارد؛ مگر اینکه بدانید پلاگین در آینده عمدتاً توسعه خواهد یافت.

برای پلاگین­های بزرگ با کد زیاد، با کلاس­های موجود در ذهن آغاز کنید. فایل­های اسکریپت و سبک، و حتی فایل­های مرتبط با ساخت را جدا کنید. این به سازماندهی کد و نگهداری طولانی مدت این پلاگین کمک می­کند.

بارگذاری مشروط

جدا کردن کد ادمین شما از کد عمومی سودمند است. از عبارت شرطی is_admin() استفاده کنید.

به عنوان مثال:

1
2
3
4
5
<?php
if ( is_admin() ) {
    // we are in admin mode
    require_once( dirname( __FILE__ ) . '/admin/plugin-name-admin.php' );
}

الگوهای معماری

در حالی که تعدادی الگوی معماری ممکن وجود دارد، به طور گسترده به سه نوع قابل تقسیم هستند:

  • فایل تک پلاگین، حاوی توابع
  • فایل تک پلاگین، شامل یک کلاس، شیء نمونه­سازی شده و توابع به صورت اختیاری
  • فایل پلاگین اصلی، سپس یک یا چند فایل کلاس

الگو های معماری بیان شده

پیاده­ سازی­ های خاص موارد پیچیده­ تر سازماندهی­ های کد بالا، قبلاً به عنوان آموزش ­ها و اسلایدها به تفصیل نوشته شده ­اند:

  • Slash – یگانه­ها، بارکننده­ها، اعمال، اسکرین­ها، دسته­گذارها
  • پیاده­سازی الگوی MVC در پلاگین­های وردپرس

نقاط آغاز متن استاندارد

به جای آغاز از ابتدا برای هر پلاگین جدیدی که می­نویسید، ممکن است بخواهید با یک متن استاندار آغاز کنید. یکی از مزایای استفاده از متن استاندارد، وجود سازگاری و هماهنگی بین پلاگین­های شما است. اگر شما از متن استانداردی که سایر افراد با آن آشنا هستند، استفاده کنید، متون استاندارد، کمک به کد شما را برای سایرین راحت­تر می­کنند.

اینها به عنوان نمونه­ های بیشتر معماری­ های مختلف قابل مقایسه نیز عمل می­ کنند.

  • متن استاندارد پلاگین وردپرس: پایه و اساس برای توسعه وردپرس پلاگین، که هدف آن، ارائه راهنمای واضح و سازگار برای ساخت پلاگین­های شما است.
  • بوت استرپ پلاگین وردپرس: بوت استرپ پایه برای توسعه پلاگین­های وردپرس با استفاده از Grunt، Compass، GIT، و SVN.
  • پلاگین WP Skeleton: پلاگین Skeleton که بر تست واحد و استفاده از سازنده برای توسعه تمرکز دارد.
  • جستجوی کلی برای متوان استاندارد پلاگین وردپرس روی GitHub

البته، شما می­ توانید از جنبه­های مختلف اینها و موارد دیگر برای ایجاد متن استاندارد سفارشی خود بهره­ مند شوید.

خیلی مهم است بدانیم دیدگاه شما راجع به این مطلب چیست؟

avatar
  Subscribe  
Notify of