گیت در توسعه وردپرس راهنمای حرفه‌ای

اولین باری که یک پروژه وردپرسی را روی Git گذاشتم، همه پوشه wp-content را push کردم. مخزن بعد از دو ماه، بیست گیگابایت شد و هر clone اولیه نیم ساعت طول می‌کشید. آن روز یاد گرفتم که وردپرس، دام‌های خاص برای Git دارد که با پروژه‌های عادی متفاوت است. اگر با Git آشنا نیستید، آموزش Git از صفر نقطه شروع خوبی است و برای مرور پایه‌ها، Git در ویکی‌پدیا هم مفید است.

چرا وردپرس برای Git چالش‌های خاص دارد؟

وردپرس سه ویژگی دارد که Git را در آن متفاوت می‌کند. اول، هسته وردپرس، پوسته و افزونه‌های third-party توسط تیم‌های جدا نگهداری می‌شوند و شما فقط یک مصرف‌کننده هستید. push کردن آن‌ها در مخزن، فقط مخزن شما را سنگین می‌کند و به هیچ وجه تغییرات آن‌ها را نمی‌تواند ردیابی کند. دوم، وردپرس فایل‌های پویا مثل wp-config.php دارد که هر محیط، نسخه متفاوتی از آن نیاز دارد. سوم، پوشه wp-content/uploads به سرعت رشد می‌کند و پر از فایل‌های داینامیک است که نباید در Git باشند.

به همین دلیل، مدیریت Git در وردپرس نیاز به یک استراتژی دقیق دارد که سه بخش اساسی دارد: چه چیزی را در Git نگه داریم، چه چیزی را نگه نداریم و چطور استقرار را با Git هماهنگ کنیم. بدون این استراتژی، مخزن به سرعت شلوغ، سنگین و غیرقابل‌نگهداری می‌شود. برای درک ساختار وردپرس، وردپرس چیست و ساختار فایل‌های قالب استاندارد را ببینید.

مخزن Git یک آرشیو تاریخ نیست؛ یک بستر کد است. هر چیزی که کد نیست، جای دیگری دارد.

ساختار مخزن: کدام فایل‌ها باید باشند؟

ساختار پیشنهادی من برای مخزن وردپرسی، سه گروه فایل را شامل می‌شود. گروه اول، فایل‌های اختصاصی پروژه: پوسته چایلد، افزونه‌های اختصاصی، فایل‌های تنظیمات قالب و اسکریپت‌های سفارشی. گروه دوم، فایل‌های تنظیمات محیط: wp-config.php نمونه، فایل .env.example و اسکریپت‌های استقرار. گروه سوم، فایل‌های مستندات و تنظیمات: README.md، composer.json، package.json و فایل‌های CI/CD.

ساختاری که در پروژه‌ها به کار می‌برم، به این شکل است: پوشه اصلی، پوشه wp-content را در خود دارد. داخل wp-content، سه پوشه اصلی نگه داشته می‌شوند: themes، plugins و mu-plugins. پوشه uploads در Git نیست و روی سرور نگه داشته می‌شود. هسته وردپرس هم در Git نیست و با ابزارهایی مثل Composer یا WP-CLI در زمان استقرار نصب می‌شود.

در پروژه‌های حرفه‌ای، یک فایل composer.json در ریشه پروژه نگه داشته می‌شود که وابستگی‌ها را تعریف می‌کند. با Composer می‌توانید هسته وردپرس و افزونه‌های معتبر از مخازن را مدیریت کنید. این روش در پروژه‌های تیمی بزرگ، مدیریت نسخه را بسیار ساده‌تر می‌کند. برای اصول ساختاربندی پروژه، ساختاربندی پروژه توسعه وردپرس راهنمای کاملی دارد.

gitignore حرفه‌ای برای وردپرس

فایل .gitignore مهم‌ترین فایل مخزن است چون تعیین می‌کند چه چیزی نباید در Git باشد. برای پروژه وردپرسی، این فایل باید حداقل این موارد را نادیده بگیرد:

• wp-config.php، چون هر محیط نسخه متفاوتی دارد.
• wp-content/uploads، چون پر از فایل‌های داینامیک است.
• wp-content/cache، wp-content/backup*، wp-content/upgrade، چون فایل‌های موقت هستند.
• wp-content/plugins/*، اگر افزونه‌ها با Composer مدیریت می‌شوند. فقط افزونه‌های اختصاصی در Git نگه داشته می‌شوند.
• هسته وردپرس، یعنی تمام فایل‌های wp-admin، wp-includes و فایل‌های ریشه‌ای مثل wp-load.php.
• .env، .env.local و سایر فایل‌های محیطی که شامل secrets هستند.
• node_modules، vendor، dist و سایر پوشه‌های ساخت.

یک نکته ظریف: حتی اگر پروژه کوچک است و همه فایل‌ها در Git هستند، باید از روز اول .gitignore درست بسازید. تغییر .gitignore بعد از اضافه شدن فایل‌ها به Git، کار را پیچیده می‌کند چون باید تاریخچه را بازنویسی کنید. برای امنیت پروژه، قفل‌کردن فایل wp-config راهنمای کاربردی دارد و برای مدیریت secrets، اصول مدیریت رمز عبور امن را ببینید.

در مورد پوشه wp-content، یک الگوی که در پروژه‌های حرفه‌ای زیاد دیده‌ام: به جای اینکه کل پوشه را نادیده بگیرید و بعد استثنا اضافه کنید، برعکس عمل کنید. یعنی کل پوشه wp-content را نادیده بگیرید و سپس با ! پوشه‌های خاص را از نادیده‌گرفتن خارج کنید. مثلاً !wp-content/themes/my-theme. این روش، کنترل دقیق‌تری می‌دهد.

مدیریت پوسته و چایلد تم

پوسته وردپرس را به دو دسته تقسیم می‌کنم: پوسته third-party که از مخزن رسمی نصب می‌شود و پوسته اختصاصی که خودتان توسعه می‌دهید. پوسته third-party را در Git نگه ندارید چون نگهداری و آپدیتش با خود سازنده است. اما چایلد تم همیشه باید در Git باشد چون بخشی از کد اختصاصی شماست.

ساختار چایلد تم در Git باید شامل فایل style.css با هدر استاندارد، فایل functions.php، پوشه assets برای CSS و JS سفارشی، پوشه templates برای فایل‌های override شده و پوشه woocommerce اگر فروشگاهی است، باشد. برای آشنایی با چایلد تم، قالب چایلد وردپرس و برای ساخت امن آن، ساخت چایلد تم امن و قابل نگهداری راهنمای کاملی دارند.

یک نکته مهم: اگر پوسته اختصاصی دارید (نه چایلد)، ساختار آن شبیه چایلد است اما فایل‌های بیشتری دارد. پوسته اختصاصی، پروژه کامل توسعه است و در Git باید همه فایل‌هایش حضور داشته باشند. برای ساخت پوسته اختصاصی، توسعه قالب وردپرس از صفر و مراحل ساخت قالب اختصاصی راهنمای کاربردی دارند.

مدیریت افزونه‌ها در Git

افزونه‌ها هم مثل پوسته‌ها به سه دسته تقسیم می‌شوند. افزونه‌های مخزن رسمی: باید در Git باشند یا نه؟ پاسخ بستگی به رویکرد شما دارد. اگر از Composer برای مدیریت استفاده می‌کنید، نباید در Git باشند. اگر نه، می‌توانید همه را در Git نگه دارید اما مخزن سنگین‌تر می‌شود. تجربه شخصی من، استفاده از Composer است چون مدیریت نسخه را ساده‌تر می‌کند.

افزونه‌های اختصاصی و سفارشی: همیشه باید در Git باشند چون بخشی از کد اختصاصی شماست. اگر افزونه اختصاصی‌تان به شکل درستی ساختاربندی شده باشد، مخزن شما تمیز و سبک می‌ماند. برای ساختار استاندارد، ساختار فایل‌های افزونه استاندارد وردپرس راهنمای کاملی دارد و برای توسعه اصولی، توسعه افزونه وردپرس از صفر را ببینید.

افزونه‌های mu-plugins (Must-Use): این‌ها افزونه‌هایی هستند که به صورت خودکار فعال هستند و معمولاً برای قابلیت‌های زیرساختی استفاده می‌شوند. این‌ها باید در Git باشند چون بخشی از معماری پروژه هستند. یک الگوی رایج در پروژه‌های حرفه‌ای: زیرساخت‌های مشترک مثل مدیریت خطا، تنظیمات امنیتی یا لاگ‌گیری در mu-plugins قرار می‌گیرند.

برای پروژه‌هایی که چند افزونه پولی دارند، مدیریت لایسنس در Git چالش‌ساز است. راه‌حل: کلیدهای لایسنس را در متغیرهای محیطی نگه دارید و در زمان استقرار، از طریق اسکریپت تنظیم کنید. برای مدیریت افزونه‌ها به صورت کلی، افزونه وردپرس چیست و افزونه‌های ضروری وردپرس راهنمای کاربردی دارند.

استقرار خودکار با Git

یکی از مزایای بزرگ Git، امکان استقرار خودکار است. سه الگوی اصلی برای استقرار وردپرس با Git وجود دارد. اول، استقرار با hook در سرور: بعد از هر push، سرور به صورت خودکار تغییرات را pull می‌کند. دوم، استقرار با CI/CD: از GitHub Actions یا GitLab CI برای push تغییرات استفاده می‌شود. سوم، استقرار با ابزارهای اختصاصی مثل Deployer یا Capistrano.

برای پروژه‌های وردپرسی، الگوی CI/CD رایج‌ترین و قابل مدیریت‌ترین است. با یک workflow در GitHub Actions، می‌توانید هم تست اجرا کنید و هم کد را به سرور منتقل کنید. راهنمای کامل در GitHub Actions و برای پروژه‌های وردپرسی، CI/CD برای پروژه‌های وردپرسی آمده است.

یک نکته عملی که در پروژه‌ها به کارم آمده: همیشه یک محیط staging داشته باشید که همان چرخه استقرار production را روی آن اجرا کنید. این کار جلوی بسیاری از فاجعه‌ها را می‌گیرد چون هر خطای استقرار، ابتدا در staging دیده می‌شود. برای امنیت استقرار، نصب SSL و قفل‌کردن فایل wp-config را ببینید.

استقرار با Git یک قابلیت نیست؛ یک انضباط است. تا زمانی که کل تیم به آن پایبند نباشد، سود واقعی‌اش را نمی‌دهد.

خطاهای رایج در مدیریت Git پروژه وردپرسی

چند خطا که در پروژه‌های مختلف دیده‌ام:

• push کردن کل پوشه wp-content: مخزن را سنگین و کند می‌کند.
• نگه داشتن wp-config.php در Git: اطلاعات دیتابیس و کلیدها را لو می‌دهد.
• نگه داشتن پوشه uploads در Git: حجم مخزن بی‌دلیل بالا می‌رود و هر تصویر جدید، یک commit است.
• نگه داشتن پوسته third-party: با هر آپدیت، commit‌های اضافه و مخزن شلوغ می‌شود.
• نداشتن staging: هر استقرار روی production یک ریسک است.
• عدم مدیریت صحیح secrets: توکن‌ها و کلیدهای API در مخزن باقی می‌مانند.

اگر با خطاهای Git مواجه شدید، رفع خطاهای رایج Git راهنمای کاملی دارد. برای مدیریت بهتر مخزن، Pull Request در GitHub و برنچ در Git نکات ارزشمندی دارند.

یک نکته اضافی درباره امنیت: هرگز اطلاعات حساس مثل رمز دیتابیس، کلید API یا توکن SSH را در مخزن Git نگه ندارید. حتی اگر private repository باشد، هر کسی که دسترسی داشته باشد می‌تواند آن‌ها را ببیند. برای مدیریت secrets، از متغیرهای محیطی و سیستم secret management ابزار استقرار استفاده کنید. برای امنیت پروژه، امن‌سازی پروژه‌های توسعه وردپرس و راهنمای امنیت وردپرس برای مبتدیان را ببینید.

پرسش‌های پرتکرار درباره Git در وردپرس

آیا باید هسته وردپرس را در Git نگه دارم؟ خیر. هسته وردپرس توسط تیم اصلی نگهداری می‌شود و شما فقط مصرف‌کننده هستید. آن را با Composer یا WP-CLI در زمان استقرار نصب کنید.

پوشه wp-content/uploads را چطور مدیریت کنم؟ در Git نگه ندارید. برای بکاپ، از ابزارهای بکاپ سرور یا ابزارهای اختصاصی استفاده کنید. برای همگام‌سازی بین محیط‌ها، می‌توانید از rsync یا S3 استفاده کنید.

افزونه‌های third-party را چطور مدیریت کنم؟ با Composer. یک فایل composer.json بسازید و افزونه‌ها را از WPackagist یا مخازن مشابه نصب کنید. این روش، مدیریت نسخه را بسیار ساده‌تر می‌کند.

چگونه بین محیط development و production تفکیک کنم؟ با فایل‌های محیطی متفاوت. wp-config.php را در Git نگه ندارید و به جای آن، از یک فایل نمونه استفاده کنید که در هر محیط مقادیر متفاوتی دارد.

آیا می‌توانم از Git برای بکاپ استفاده کنم؟ Git برای مدیریت نسخه کد است، نه بکاپ دیتابیس و رسانه‌ها. برای بکاپ کامل، از ابزارهای اختصاصی بکاپ استفاده کنید. برای بکاپ وردپرس، چگونه از سایت وردپرسی بکاپ بگیریم و برای فروشگاه، بکاپ‌گیری از فروشگاه ووکامرس راهنمای کاملی دارند.

برای مدیریت مخزن، آموزش Git از صفر، دستورات ضروری Git و برنچ در Git را ببینید. برای ساختار پروژه، ساختاربندی پروژه توسعه وردپرس و اصول کدنویسی تمیز نکات کاربردی دارند. برای توسعه اصولی، توسعه وردپرس چیست و از کجا شروع کنیم و استفاده از استانداردهای کدنویسی وردپرس را ببینید. برای محیط توسعه، توسعه با محیط لوکال و توسعه با چایلد تم راهنمای کاربردی دارند.

آنچه از پروژه‌های واقعی یاد گرفتم

سه چیز بعد از سال‌ها کار با Git در پروژه‌های وردپرسی در ذهنم جا افتاده. اول، مخزن باید فقط کد باشد، نه فایل‌های داینامیک و third-party. دوم، استراتژی استقرار را از روز اول تعریف کنید، نه در میانه پروژه. سوم، امنیت secrets را جدی بگیرید؛ یک بار لو رفتن، می‌تواند هزینه‌های سنگین داشته باشد. برای امنیت پروژه، چگونه REST API امن بسازیم و هدرهای امنیتی HTTP راهنمای کاملی دارند. برای بکاپ داده‌ها، بکاپ وردپرس و افزونه‌های بکاپ را ببینید. برای استقرار حرفه‌ای، GitHub Actions و CI/CD برای پروژه‌های وردپرسی را مطالعه کنید.

اگر تجربه‌ای از یک پروژه وردپرسی که با Git به خوبی مدیریت شد یا برعکس، با مشکل مخزن مواجه شد دارید، در دیدگاه بنویسید. برای من جالب است بدانم چه استراتژی برای مدیریت مخزن در پروژه‌های شما جواب داده است. 🗂️