إعادة كتابة الروابط وملف .htaccess: الفروقات والنصائح عند الانتقال من NGINX وApache إلى Caddy في ServBay

معلومات خلفية

إعادة كتابة الروابط (URL Rewrite)، أو ما يُعرف بـ "الروابط الجميلة" (الروابط الصديقة لمحركات البحث)، هي تقنية لتغيير عنوان URL الذي يطلبه المستخدم أو محرك البحث بشكل ديناميكي من خلال خادم الويب. تسمح هذه التقنية بإعادة توجيه URL الأصلي (مثل /?page=123) داخليًا إلى عنوان آخر (مثل /posts/123/)، بينما يرى المستخدم العنوان النهائي فقط في شريط المتصفح.

يتم استخدام تقنية إعادة كتابة الروابط عادةً من أجل:

• تحسين بنية الروابط: إنشاء روابط سهلة القراءة والحفظ والمشاركة.
• تعزيز السيو (SEO): تحبذ محركات البحث الروابط التي تحتوي على كلمات وصفية وتكون منظمة.
• إخفاء التفاصيل الداخلية: عدم الكشف عن مسارات الملفات والمعاملات لأغراض الأمان.
• توحيد الروابط: فرض استخدام بنية محددة للروابط (مثل استخدام www أو عدمه، أو إجبار استخدام HTTPS).
• توجيه الطلبات: تستخدم معظم إطارات عمل الويب الحديثة قواعد إعادة كتابة الروابط لتوجيه كل الطلبات إلى ملف دخول واحد (مثل index.php)، كي يعالجها الإطار البرمجي.

فهم وضبط قواعد إعادة كتابة الروابط مهارة أساسية في تطوير الويب.

دعم NGINX وApache في ServBay

يحتوي ServBay على دعم كامل ومُدمج لكل من NGINX وApache كخوادم ويب، ويمكن للمستخدمين التبديل بينهما بحرية حسب متطلبات المشروع أو التفضيلات الشخصية.

للتعرف على كيفية تغيير خادم الويب الافتراضي، راجع الوثيقة: كيفية ضبط خادم الويب الافتراضي

يمنح ServBay المطورين عدة اختيارات من أشهر خوادم الويب، مثل Caddy وNGINX وApache. لتسهيل إعداد بيئة التطوير المحلية، قام ServBay بتجهيز قواعد إعادة كتابة الروابط الأساسية مسبقًا لكل من Caddy وNGINX بحيث تغطي معظم احتياجات أطر العمل الحديثة وأنظمة إدارة المحتوى المشهورة. هذا يعني أنك تستطيع تشغيل تطبيقات شائعة مثل ووردبريس، لارافيل، سيمفوني وغيرها دون الحاجة غالبًا لأي إعداد إضافي لملفات إعادة كتابة الروابط، مما يجعل تجربة الاستخدام سهلة وسريعة.

مع ذلك، إذا كنت معتادًا على العمل مع Apache أو NGINX وتخطط للهجرة بموقعك أو مشروعك إلى Caddy المُدمج ضمن ServBay، من المهم فهم فروقات إعدادات إعادة الكتابة بين هذه الخوادم. تشرح هذه المقالة أهم الفروق في قواعد إعادة كتابة الروابط بين Apache وNGINX وCaddy، مع نصائح مهمة لعملية الانتقال.

قواعد إعادة الكتابة الجاهزة: ميزة ServBay

تنبيه مهم

واحدة من فلسفات تصميم ServBay هي تبسيط إعداد وتكوين بيئة التطوير المحلية. لأغلب تطبيقات الويب وإطارات العمل الشائعة، أعدّ ServBay مسبقًا قواعد إعادة كتابة الروابط، وهذا يعني أنك غالبًا لن تحتاج إلى كتابة أو تعديل قواعد إعادة الكتابة بنفسك عند عملك على هذه الأنظمة في ServBay.

إذا كنت تنتقل بموقع من بيئة Apache أو NGINX إلى Caddy ضمن ServBay، وتحتاج للتعامل مع قواعد إعادة كتابة مخصصة ومعقدة، يمكنك مراجعة أدلة الهجرة التالية لمزيد من التفاصيل:

• الهجرة من NGINX إلى ServBay (Caddy)
• الهجرة من Apache إلى ServBay (Caddy)

لمحة عن قواعد إعادة كتابة الروابط في خوادم الويب

تستخدم خوادم الويب المختلفة صيغًا وملفات مختلفة لضبط قواعد إعادة كتابة الروابط. فهم هذه الفروق ضروري عند الانتقال بين الخوادم. تعرض هذه الفقرة لمحة سريعة عن كيفية إعداد Apache، وNGINX، وCaddy لهذه القواعد.

ملف .htaccess في Apache

يستخدم Apache ملف .htaccess لضبط قواعد إعادة كتابة الروابط. هذا الملف تهيئة موزعة عادةً ما يوضع في جذر الموقع أو مجلدات فرعية، ويُطبق على هذا المجلد وكافة ما تحته (إلا إذا كان هناك ملف .htaccess مخصص للمجلد الفرعي). في Apache، تتم معالجة القواعد عبر وحدة mod_rewrite.

مثال أساسي على الاستخدام

في ما يلي مثال شائع لملف .htaccess يعيد جميع الطلبات التي لا تتوافق مع ملف أو مجلد موجود إلى index.php، كما هو معمول به في العديد من أطر العمل وأنظمة إدارة المحتوى المبنية على PHP:

# تفعيل محرك إعادة كتابة الروابط
RewriteEngine On

# إذا كان الملف أو المجلد المطلوب غير موجود، نفذ قاعدة إعادة الكتابة
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# إعادة كتابة كل الطلبات إلى index.php مع الاحتفاظ بسلسلة الاستعلام
RewriteRule ^(.*)$ index.php [L,QSA]

الشرح:

• RewriteEngine On: تفعيل إمكانية إعادة كتابة الروابط في هذا المجلد.
• RewriteCond %{REQUEST_FILENAME} !-f: شرط يتحقق إذا كان المسار المطلوب ليس ملفًا موجودًا.
• RewriteCond %{REQUEST_FILENAME} !-d: شرط إضافي يتحقق إذا كان المسار المطلوب ليس مجلدًا موجودًا.
• RewriteRule ^(.*)$ index.php [L,QSA]: القاعدة الفعلية لإعادة الكتابة.
  • ^(.*)$: تطابق أي مسار طلب.
  • index.php: إعادة توجيه كل الطلبات إلى index.php.
  • [L]: تعني أن هذه آخر قاعدة يجب تنفيذها ولن يتم تنفيذ قواعد تالية.
  • [QSA]: تعني ضم سلسلة الاستعلام الأصلية للعنوان الجديد.

قواعد إعادة الكتابة في NGINX

يستخدم NGINX ملف الضبط الرئيسي (nginx.conf) أو ملفات إعداد المواقع (غالبًا في conf.d أو sites-available/sites-enabled) لضبط قواعد إعادة كتابة الروابط. عادةً ما تُضبط هذه القواعد داخل كتلة server (تعريف المضيف الافتراضي) أو داخل كتلة location (تطابق مسار محدد). تدعم وحدة إعادة الكتابة في NGINX (ngx_http_rewrite_module) إمكانيات قوية، لكن الصياغة تختلف جذريًا عن Apache.

مثال أساسي على الاستخدام

في ما يلي مثال لجزء من ملف إعداد NGINX ينفذ منطق إعادة الطلبات إلى index.php:

server {
    listen 80;
    server_name servbay.demo; # مثال على دومين ServBay

    root /Applications/ServBay/www/demo; # مثال على جذر الموقع

    # حاول البحث بالتسلسل: ملف، مجلد، ثم إعادة إلى index.php
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # معالجة طلبات ملفات php وتحويلها إلى PHP-FPM/FastCGI
    location ~ \.php$ {
        # التحقق من أن الملف موجود لمنع تنفيذ أي ملف عشوائي
        try_files $uri =404;
        include fastcgi_params;
        # المسار الافتراضي لـ PHP FastCGI في ServBay
        fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

الشرح:

• location /: تطابق جميع الطلبات الجذرية للموقع.
• try_files $uri $uri/ /index.php?$query_string;: هذه تعليمات شائعة في NGINX، وتجرب بالترتيب:
  1. هل يوجد ملف مطابق لمسار الطلب ($uri)؟
  2. هل يوجد مجلد مطابق ($uri/)؟
  3. إذا لم يوجد شيء منهما، يعيد الطلب داخليًا إلى /index.php مع سلسلة الاستعلام.
• location ~ \.php$: يطابق كل الطلبات المنتهية بـ .php.
• fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;: يرسل طلبات php إلى معالج FastCGI الافتراضي في ServBay.

قواعد إعادة الكتابة في Caddy

يعتمد Caddy على ملف الإعداد المسمى Caddyfile، وقد صُممت صيغته كي تكون مبسطة وواضحة وقوية أيضًا. تختلف صياغة إعداداته بشكل كبير عن Apache وNGINX، وعادةً ما تكون أكثر مباشرة. يوفر Caddy الإعادة عبر تعليمة rewrite مع "matchers" (مطابقات) مرنة.

مثال أساسي على الاستخدام

في ما يلي مثال على جزء من ملف Caddyfile ينفذ منطق إعادة الطلبات إلى index.php:

servbay.demo { # مثال على دومين ServBay
    root * /Applications/ServBay/www/demo # مثال على جذر الموقع

    # تحويل طلبات PHP إلى PHP FastCGI الافتراضي في ServBay
    php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock

    # تقديم ملفات ثابتة
    file_server

    # تحديد مطابقة @notStatic: إذا لم يوجد ملف أو مجلد
    @notStatic {
        not {
            file {
                # محاولة العثور على ملف {path} أو مجلد {path}/
                # إذا لم يوجد، يتم تفعيل المطابقة (@notStatic)
                try_files {path} {path}/
            }
        }
    }

    # إذا تم تفعيل @notStatic، يعيد الطلب إلى /index.php
    rewrite @notStatic /index.php
}

الشرح:

• servbay.demo { ... }: كتلة تعريف لموقع (domain) معيّن.
• root * /Applications/ServBay/www/demo: ضبط جذر الملفات للموقع.
• php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock: يوجه تلقائيًا طلبات php لمعالج PHP FastCGI المحدد.
• file_server: تعليمية بسيطة لتقديم الملفات الثابتة.
• @notStatic { ... }: تعريف مطابقة باسم notStatic.
• not { file { try_files {path} {path}/ } }: تتحقق إذا طلب المستخدم ملفًا أو مجلدًا غير موجودين.
• rewrite @notStatic /index.php: يعيد الطلب داخليًا إلى index.php إذا تحققت المطابقة.

في إعداد ServBay الافتراضي، تعليمة php_fastcgi تدمج سلوك try_files تلقائيًا، كما أن ServBay يضبط Caddyfile تلقائيًا لأي موقع جديد ليوفر التجربة دون إعدادات إضافية. المثال أعلاه لأغراض التوضيح فقط.

نصائح مهمة عند الانتقال من Apache أو NGINX إلى Caddy في ServBay

عند نقل موقعك من بيئة Apache أو NGINX إلى استخدام خادم Caddy ضمن ServBay، تعتبر عملية تحويل قواعد إعادة كتابة الروابط خطوة حرجة. مع أن ServBay يجهز معظم القواعد المطلوبة مسبقًا، إلا أنه بالنسبة للمشاريع التي تحتوي على كثير من القواعد المخصصة ستحتاج لفهم وتحويل هذه القواعد يدويًا.

يرجى مراجعة أدلة الهجرة التفصيلية:

• الهجرة من Apache إلى ServBay (Caddy)
• الهجرة من NGINX إلى ServBay (Caddy)

أهم الفروق التي يجب مراعاتها أثناء الهجرة:

1. صياغة قواعد الإعادة ومكان ضبطها:

   • Apache: يستخدم ملفات .htaccess (موزعة على مستوى المجلدات) أو ملفات الإعداد الرئيسية (httpd.conf). تعتمد القواعد أساسًا على تعليمات RewriteRule وRewriteCond بصياغة مبنية على التعابير النمطية.
   • NGINX: يستخدم ملف إعداد مركزي (nginx.conf) أو ملفات المواقع. تُضبط القواعد داخل كتل location وserver وتستفيد من تعليمات rewrite، if، وtry_files.
   • Caddy: يستخدم Caddyfile كملف إعداد مركزي. تعتمد القواعد على تعليمة rewrite مع نظام مطابقة قوي (مثل file وpath وheader وغيرها) وصياغة مبسطة.
   • التحويل: يجب تحويل قواعد .htaccess أو إعدادات location/rewrite/try_files في NGINX يدويًا إلى صيغة Caddyfile، حيث تختلف الطريقة والتعبير بينهما بشكل كبير. يوصى بقراءة التوثيق الرسمي لـ Caddy لفهم آلية المطابقات وتعليمات إعادة الكتابة.

2. هيكلية ملفات الإعداد:

   • Apache: يمكن امتلاك إعدادات مختلفة لكل مجلد عبر .htaccess أو عبر تهيئة المركزي للمضيفات الافتراضية.
   • NGINX: الإعداد غالبًا مركزي في ملفات محددة، منظم باستخدام كتل server وlocation.
   • Caddy: تنظيم أقرب للبساطة بواسطة كتل الموقع في Caddyfile وتوزيع الأوامر داخل كل كتلة.

3. مقابلة التعليمات والوحدات:

   • يوجد عدد كبير من التعليمات والوحدات في Apache وNGINX. يوفر Caddy إمكانات واسعة ولكن مع اختلاف في الأسماء والصياغة. على سبيل المثال، يمكن تنفيذ منطق mod_rewrite بـ Caddy عبر تعليمة rewrite والمطابقات. بينما تعليمة try_files في NGINX تقابلها منطقيًا في Caddy عبر مطابقة file أو عبر php_fastcgi.
   • يجب عند الانتقال البحث عن المقابلات الصحيحة في توثيق Caddy وفهم استخدامها جيدًا.

4. السلوك الافتراضي وترتيب الأولويات:

   • لكل خادم طريقة خاصة في ترتيب أولوية تنفيذ الأوامر والقواعد الافتراضية، مثل كيفية معالجة Apache لملفات .htaccess، ترتيب كتل location في NGINX، وترتيب الأوامر في Caddy (حيث تكون الأوامر مُنفذة ترتيبًا).
   • بعد الهجرة، من الضروري اختبار جميع مسارات الروابط ضمن الموقع والتأكد من أن كل القواعد تعمل كما هو متوقع؛ خصوصًا التصادم بين الإعدادات الجاهزة في Caddy وبين إعداداتك المخصصة.

الخلاصة

يوفر ServBay بيئة تطوير محلية تضم Caddy وNGINX وApache كخوادم ويب. وبفضل ضبط إعدادات قواعد إعادة كتابة الروابط مسبقًا لـ Caddy وNGINX، يمكنك غالبًا تشغيل معظم المشاريع الحديثة دون مجهود إضافي. أما إذا كنت معتادًا على إعدادات Apache أو NGINX المخصصة وتود الانتقال إلى Caddy، فستحتاج لفهم الفروقات في آليات كتابة القواعد.

يميل Apache إلى استخدام إعدادات موزعة عبر ملفات .htaccess وتعليمات Rewrite، بينما يعتمد NGINX على إعداد مركزي وتعليمات location/try_files/rewrite، أما Caddy فيعتمد على Caddyfile البسيط مع أوامر rewrite والمطابقات القوية.

تتمثل الخطوة الأهم في عملية الهجرة بتحويل قواعد إعادة الكتابة الخاصة بك بدقة إلى صيغة Caddyfile. مع أن ذلك يتطلب بعض التعلم والتحويل، إلا أن البنية المبسطة لـ Caddy، إلى جانب الإعدادات الجاهزة والأدلة التفصيلية من ServBay، ستجعلك تستفيد بمرونة وكفاءة من بيئة التطوير المحلية الحديثة. نأمل أن تساعدك هذه المقالة على فهم الفروق والتنقل بأمان واحترافية بين أنظمة إعادة كتابة الروابط في ServBay.