سير عمل تطوير WordPress الحديث باستخدام Roots Stack

كان WordPress موجودًا منذ العصور ، على الأقل وفقًا لمعايير الإنترنت ، وكانت فلسفته دائمًا هي الحفاظ على التوافق مع الإصدارات السابقة. هذا التركيز على التوافق مفهوم نظرًا للكم الهائل من مواقع WordPress عبر الإنترنت اليوم. ومع ذلك ، في حين أن هذا يمكن أن يساعد أولئك الذين لا يزالون يستخدمون البيئات القديمة مع إصدارات PHP و MySQL القديمة (وهي مخاطرة أمنية في حد ذاتها ، ولكن هذا ليس موضوع مقال اليوم) ، فقد تسبب أيضًا في عدم استخدام إصدارات WordPress الأحدث بشكل كامل أحدث إمكانيات PHP.

وقد تسبب هذا أيضًا في أن العديد من مطوري WordPress يعيشون في فقاعة WordPress ، ولا يتم تحفيزهم لتعلم تقنيات تطوير جديدة وحديثة للواجهة الأمامية ، وأحيانًا يتعثرون في "الطريقة الجيدة" للقيام بالأشياء.

هل يمكنك اعتماد سير عمل تطوير حديث لـ WordPress؟

يمكنك بالتأكيد ، ومكدس WordPress Roots موجود هنا لمساعدتك على التطور مثل 2019 ، مع ثلاث أدوات مذهلة:

• سيج كموضوع البداية الخاص بك ،
• Bedrock كنموذج معياري حديث لـ WordPress ،
• الشبكة لإدارة النشر والتوفير في بيئات مختلفة.

لدى فريق Roots أيضًا أداتان إضافيتان قيد التطوير: Acorn ، وهو إطار عمل لبناء المكونات الإضافية ، و Clover ، وهو أداة مرجعية للمكوِّن الإضافي. نظرًا لحقيقة أن كلاهما في ألفا ، لم يتم تضمينهما في هذه المقالة ، ولكن يجب عليك بالتأكيد مراقبتهما.

ما هو مكدس الجذور بالضبط

كان يُعرف في الأصل باسم Roots theme ، وكان سمة بداية HTML5 صلبة للغاية تهدف إلى توفير نقطة انطلاق أكثر نظافة لمواقع WordPress الجديدة. بمرور الوقت ، تطورت إلى مجموعة كاملة من الأدوات ، مروراً بجميع تقنيات ومعايير الويب الحديثة الرئيسية (من Grunt إلى Gulp و Webpack و LESS و SCSS و NPM و Yarn و Bootstrap و PSR-2 ومعايير الترميز ومبدأ DRY) ، وبالتالي إجبار مطوري WordPress الذين تبنوه على التعلم المستمر والبقاء على اطلاع دائم بما تقدمه تقنيات تطوير الواجهة الأمامية الحديثة.

اليوم ، نمت Roots إلى مجموعة كاملة من الأدوات في التوسع المستمر ، تهدف إلى مساعدتك في إنشاء مواقع WordPress أفضل من خلال اتباع الدورة بأكملها ، من التطوير إلى التدريج والإنتاج ، وجعلك مطورًا أفضل من خلال إجبارك على الخروج من الراحة المنطقة التي يوفرها ما يسمى بفقاعة WordPress.

لكن دعونا نلقي نظرة على الأدوات الرئيسية الثلاث التي يقدمونها ، وما هي ، ولماذا يجب أن تفكر في استخدامها.

جذور حكيم 9

Roots Sage 9 هو التكرار الأخير لموضوع بدء تشغيل WordPress الذي تم الحفاظ عليه بشكل احترافي ، والذي تم إصداره في الأصل كـ Roots فقط في عام 2011. خلال حياته ، مر بالعديد من التغييرات والتحسينات وإعادة النظر في أفضل الممارسات ، ليصبح أخيرًا ما اليوم هو نقطة انطلاق رائعة لتقديم سير عمل تطوير الواجهة الأمامية الحديثة لتطوير WordPress.

ما تحاول Sage القيام به هو اعتماد نمط MVC (Model-View-Controller) حيث يتم فصل المشاهدات ووحدة التحكم تمامًا ؛ يمكّننا هذا من إعادة استخدام طرق العرض ، والتي لا تحتاج بالضرورة إلى "معرفة" مصدر البيانات ، لكنها تنتظر ببساطة حتى تقوم وحدة التحكم بتزويدها ببعض البيانات لعرضها.

وحدة التحكم المضمنة في Sage 9 ليست وحدة التحكم الفعلية التي قد تكون معتادًا عليها بالفعل في أطر أخرى مثل Laravel ، والفرق الرئيسي هو أن Sage 9 Controller يستخدم توجيهًا قائمًا على القالب بدلاً من التوجيه المستند إلى URL. بشكل أساسي ، تسمح لـ WordPress بمعالجة توجيه URL وتكتب وحدات تحكم لملفات القوالب.

من خلال إضافة بضع درجات من التعقيد إلى عملية التطوير بأكملها ، قد لا يكون Sage 9 هو الخيار الأفضل للبدء به للمبتدئين ، حيث سيكون لديك قدر كبير من التعلم لإتقانه في النهاية وتكون قادرًا على استخدامه في الإنتاج: مناسب التبعية وإدارة الأصول ، وإصدار الكود ، وهيكل مشروع جديد ، ومحرك نموذج جديد مشتق من Laravel ، ومبدأ DRY (لا تكرر نفسك) ، وسيتعين عليك الالتزام بمعايير تشفير صارمة تختلف قليلاً عن ما يوصي WordPress ؛ ولكن إذا كنت مطورًا متمرسًا ، فيمكن أن تكون بداية رائعة.

إذا كنت تريد أن تتكامل مع Sage ، فقط ضع في اعتبارك هذه النصيحة من Ben Word ، أحد مطوري فريق Roots:

Sage ليس إطار عمل ، إنه سمة بداية. نادرًا ما تحتاج إلى تحديثه ، وعادةً لا يجب عليك إنشاء سمات فرعية منه. نظرًا لكونه موضوعًا مبتدئًا ، فمن المفترض أن يتم استخدام Sage كنقطة انطلاق في مشروع جديد.

ولكن أيضا:

إذا كانت النقاط السفلية بداية مبكرة لمدة 1000 ساعة ، فإن Sage هي بداية مبكرة بمقدار 10000 ساعة.

بنية الملف والمجلد مع سيج

يختلف هيكل الملفات والمجلدات في Sage قليلاً عما اعتدنا على رؤيته في سمات بداية أخرى مثل Underscores ، أو حتى في الإصدار الرئيسي السابق من Sage 8.

هذا ما ستجده بعد تثبيت Sage مباشرة:

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

بالإضافة إلى بعض الملفات الأخرى المستخدمة بواسطة محرري التعليمات البرمجية و IDEs ، مثل .editorconfig و .eslintrc.js و .stylelintrc.js و phpcs.xml وما إلى ذلك.

فيما يلي نظرة عامة سريعة على متطلبات Sage 9 الأساسية:

• ووردبريس> = 4.7
• PHP> = 7.1.3 (مع تمكين php-mbstring)
• ملحن
• Node.js> = 8.0.0
• غزل

بيدروك

Bedrock مثل WordPress على المنشطات!

إذا قام Sage بتحسين تطوير المظهر الخاص بك ، فإن Bedrock يحسن تثبيت WordPress بالكامل. يقوم بذلك من خلال توفير مشروع معياري حديث ، مع بنية مجلد محسّنة وأمان (على سبيل المثال من خلال عدم وجود ملفات التكوين الخاصة بك في جذر موقع الويب) ، والتكوين وملفات ENV ، وإدارة التبعية المناسبة (نعم ، بما في ذلك المكونات الإضافية والسمات في WordPress) .

لوصفه في عبارة واحدة ، يمكننا القول أن Bedrock هو مشروع WordPress قائم بذاته يقوم بأتمتة تثبيت الملفات الأساسية والمكونات الإضافية المطلوبة.

بنية الملف والمجلد

إذا نظرت إلى تثبيت Bedrock الأساسي ، فقد تشعر بالضياع في البداية. يفصل Bedrock ملفات الويب والتكوين والتبعية في مجلداتهم الخاصة. إليك ما يبدو عليه هيكل العظم العاري:

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

بالإضافة إلى بعض الملفات الأخرى الأقل أهمية.

متطلبات حجر الأساس هي:

• PHP> = 7.1
• ملحن

تعريشة

Trellis عبارة عن مكدس LEMP حديث لإدارة خوادم التطوير والتركيب والإنتاج الخاصة بك بسلاسة ، تهدف إلى إبقائها متشابهة مع بعضها البعض قدر الإمكان ("تكافؤ التطوير والإنتاج"). هذا يعني أنه إذا كان موقع WordPress المخصص الخاص بك يعمل في بيئة التطوير الخاصة بك ، فمن الآمن افتراض أنه سيعمل أيضًا في الإنتاج ويمكنك النشر بثقة.

من أجل التنمية المحلية ، يستخدم Trellis Vagrant ، مع vagrant up بسيط سيكون لديك آلة افتراضية تعمل في بيئة حديثة مناسبة.

تتم إدارة التزويد والنشر في بيئات التدريج والإنتاج الخاصة بك باستخدام Ansible playbooks ، وهي ملفات YAML تخبر Ansible بما يجب القيام به.

اقترح الشبكة بنية المجلد

يحتوي Trellis على هيكل مجلد مقترح يتكون من مجلدين فرعيين فقط:

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

أوصي بتركه كما هو ، ولكن يمكن تخصيصه حسب رغبتك واحتياجاتك.

متطلبات الشبكة

• ملحن
• فيرتوال بوكس> = 4.3.10
• المتشرد> = 2.1.0

لماذا يجب عليك استخدامه

إذا كان WordPress يعمل بالفعل كما هو ، فلماذا يجب عليك التبديل إلى مكدس أكثر تعقيدًا وقضاء قدرًا كبيرًا من الوقت لإتقانه؟ لأن هناك مزايا واضحة ، وبعضها أقل وضوحًا. دعنا نحاول أن نرى ما هم.

موضوع كاتب ملحد لإطار العمل

تجبرك العديد من سمات المبتدئين في WordPress على استخدام إطار عمل CSS محدد قد يعجبك أو لا تعرفه أو حتى تعرفه ، ولكن Sage هو إطار محايد تمامًا. أثناء التثبيت ، سيكون لديك خيار تضمين Bootstrap 4 أو Bulma أو Foundation أو Tachyons أو Tailwind CSS أو بدون إطار على الإطلاق إذا كنت تريد البدء من نقطة الصفر أو استخدام شيء آخر (تلميح: بدأت مؤخرًا في الإعجاب بـ Tailwind CSS كثيرًا).

نصيحة PRO: على جهاز يعمل بنظام Windows ، قد تتلقى الرسالة "وضع TTY غير مدعوم على نظام Windows الأساسي" أثناء التثبيت ولن تتمكن من اختيار إطار عمل أو تكوين Sage. سيتعين عليك تشغيل هذه الأوامر الثلاثة يدويًا من داخل مجلد السمة إذا كنت تريد الاستفادة من التكوين التلقائي:

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

عملية بناء حديثة

مع Webpack ، المضمن في Sage ، لن تضطر بعد الآن إلى التفكير في تجميع الأصول ، وسلسلة وتصغير JavaScript و CSS code ، وتحسين الصور ، والتحقق من أخطاء JavaScript والنمط ، وإدارة المكتبات الخارجية. ستهتم عملية البناء بكل ذلك من خلال بنية yarn build بسيطة (أو yarn build:production إذا كنت تريد تحسين أصولك لاستخدام الإنتاج) ، مما ينتج عنه جميع الملفات الثابتة في السمة /dist/ المجلد.

متطلبات و PHP الحديثة

الحد الأدنى لإصدار PHP الذي يمكنك تشغيل WordPress عليه هو PHP 5.2.4 ، وهذا سيضمن التوافق مع الإصدارات السابقة لجميع المستخدمين الذين يشغلون مواقعهم على الويب في بيئة قديمة ، لكن الإصدارات القديمة من PHP (<= 7.0) وصلت رسميًا إلى نهاية الحياة ، لذلك لم تعد مدعومة وقد تعرض موقعك لثغرات أمنية ومشكلات في الأداء.

يتطلب كل من Sage و Bedrock إصدارًا سليمًا من PHP 7.1 (على الرغم من أنه إذا كان لديك خيار اختيار 7.3 ، فيرجى القيام بذلك).

تتبنى Sage 9 أيضًا معايير تشفير PSR-2 بالكامل (الترميز الأكثر استخدامًا والمقبولة

المعايير المستخدمة في مجتمع PHP) ، والتي تختلف قليلاً عن معايير ترميز WordPress ، لكنها تسمح لك بالحصول على كود أكثر نظافة وقابلية للصيانة ، خاصة إذا كنت تعمل في فريق أو كان عليك مشاركة الكود الخاص بك مع الآخرين.

أفضل التبعيات وإدارة الحزم

تستفيد Roots stack بشكل كبير من Composer لإدارة جميع التبعيات والحزم ، بما في ذلك WordPress core والإضافات والقوالب. قد تكون هذه مشكلة إذا كنت تستخدم أدوات الجهات الخارجية لإدارة تحديثات WordPress (مثل ManageWP أو MainWP أو InfiniteWP) ، ولكن قد يجادل شخص ما بأن وجود كل شيء تحت التحكم في الإصدار يمنحك مزيدًا من التحكم ويسهل الرجوع إلى عمل سابق الإصدار إذا حدث خطأ ما.

بالإضافة إلى ذلك ، تستخدم Sage Yarn كحزمة ومدير تبعية لكود التطبيق ولإطلاق عملية الإنشاء.

أفضل ملفات القوالب

يفتقر WordPress إلى محرك قوالب حقيقي ، لذلك لتعويض ذلك ، اعتمدت Sage شفرة Laravel وتتبع مبدأ DRY: لا تكرر نفسك.

هذا ما يبدو عليه ملف قالب single.blade.php الافتراضي ، 6 أسطر فقط من التعليمات البرمجية:

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

يفصل محرك قالب Blade تمامًا بين طرق العرض وأدوات التحكم ، كما أن تركيبته أكثر أناقة وإيجازًا وقابلية للقراءة وأسهل في الكتابة من مجرد علامات PHP. القاعدة الأساسية هنا هي ترك جميع أكواد PHP خارج ملفات القالب (أو على الأقل محاولة ذلك).

فائدة أخرى لاستخدام Blade هي وراثة القالب: قالب التخطيط الأساسي (الافتراضي هو /resources/views/layouts/app.blade.php ) يحدد الكتل التي تحتوي على عناصر موقع الويب الشائعة ، والتي يتم توارثها بعد ذلك بواسطة القوالب الفرعية الخاصة به. يعتبر توريث القوالب أمرًا رائعًا لإزالة العلامات المتكررة من القوالب الفردية والحفاظ على الأشياء جافة.

Browsersync

من خلال تشغيل yarn start جلسة Browsersync. Browsersync عبارة عن وحدة نمطية لاختبار المتصفح المتزامن أثناء التطوير. سيراقب التغييرات التي تم إجراؤها على أصول الواجهة الأمامية ، وبالعمل مع Webpack ، يقوم تلقائيًا بإدخال التغييرات في جلسة المتصفح.

نشر ووردبريس سريع وسهل وآمن

يقدم Trellis عمليات نشر WordPress بدون توقف. عند بدء نشر ، سيقوم Trellis باستنساخ مستودعك وتشغيل تثبيت composer ثم تحديث الارتباط الرمزي إلى الإصدار الحالي حتى لا يقوم أبدًا بتحرير الملفات التي يتم عرضها حاليًا في الإنتاج مباشرةً.

عند استخدام Bedrock ، يحتاج Trellis أيضًا إلى القليل جدًا من التكوين.

عيوب

العيب الوحيد لاستخدام مكدس الجذور الكامل (بصرف النظر عن تعلم أشياء جديدة ، والتي لا ينبغي اعتبارها مشكلة على الإطلاق) هو أنه يتعين عليك استخدام مزود استضافة متوافق مع Trellis مثل Kinsta ، أو DigitalOcean droplet أو أي مضيف آخر دعم SSH و Composer و WP-CLI على الأقل ، إلى جانب خيار تحديث مسار جذر الويب.

هذا يترك معظم الاستضافة المشتركة الرخيصة (ish) خارج اللعبة وهو شيء يجب أن تضعه أنت و / أو عميلك في الاعتبار قبل بدء مشروع جديد.

كيف تبدأ

يمكن اعتبار ذلك بمثابة تجربة جديدة لبرنامج "WordPress 5-Minute Installation" الشهير ولكن لمطوري الواجهة الأمامية الحديثين. إنه يضيف بضع درجات من التعقيد للتطوير اللاحق ، ولكن في النهاية ، الفوائد التي يمكنك الحصول عليها تستحق العناء بالتأكيد.

سنركز على تبني المجموعة الكاملة (Sage و Bedrock و Trellis) ، ولكن يمكنك فقط استخدام مجموعة واحدة أو أي مجموعة منها. يمكن استخدام Sage كنقطة بداية لموضوع مستقل على أي تثبيت WordPress ؛ يمكن استخدام Bedrock مع أي سمة WordPress تريدها ؛ ويتم تكوين عمليات نشر Trellis للمواقع المستندة إلى Bedrock وتهتم بكل ما هو مطلوب ، ولكن مع القليل من الترقيع ، يمكن تخصيصها لأي احتياج تقريبًا.

كيفية إنشاء مشروع جديد

يعد إعداد مشروع WordPress جديد باستخدام Trellis و Bedrock و Sage أمرًا سهلاً للغاية ، على بعد بضعة أسطر أوامر.

قم بتثبيت Trellis في المجلد الذي تريده (على سبيل المثال ، example.com ):

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

قم بتثبيت Bedrock في /site/ المجلد الفرعي:

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

تثبيت وبناء Sage:

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

النشر

يعد النشر في التدريج أو الإنتاج أسهل إذا قمت بتكوين كل شيء بشكل صحيح وفقًا للوثائق الرسمية. إنه سطر أوامر واحد فقط (يتم تشغيله من المجلد example.com/trellis/ ):

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

يمكنك أيضًا التراجع عن النشر بسهولة ، ما عليك سوى تشغيل:

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

تلميحات حول إعداد بيئة التطوير الخاصة بك على Windows

إذا كنت تبحث في google حول كيفية تثبيت واستخدام Roots stack ، وخاصة Trellis ، فستجد الكثير من البرامج التعليمية التي تركز على Linux أو MacOS ، ولكن القليل جدًا من المعلومات متاح لنظام Windows حيث ستجد مشكلتين رئيسيتين: Ansible غير متوفر لنظام التشغيل Windows ، وعادة ما يكون Vagrant بطيئًا للغاية على أجهزة Windows.

عندما فكرت في الأصل في هذه المقالة ، كانت وثائق Trellis الرسمية لنظام التشغيل Windows تقترح تشغيل Ansible داخل الجهاز الظاهري Vagrant ، ولكن كانت هذه طريقة مخترقة للقيام بالأشياء ولم تكن موثوقة للغاية.

منذ ذلك الحين قاموا بتحديث الوثائق بإرشادات مناسبة حول إعداد كل شيء باستخدام WSL (نظام Windows الفرعي لنظام Linux) ، لذلك ليست هناك حاجة لإعادة اختراع العجلة وكتابة برنامج تعليمي عنها. من الجيد معرفة أن هناك ثلاث صفحات تستحق الإرشادات التفصيلية خطوة بخطوة التي يمكنك اتباعها قبل تثبيت Trellis: إعداد Windows ، وإعداد Windows: Sage و Windows Setup: Trellis.

ترميز سعيد!