اذهب إلى المحتوى

البحث في الموقع

المحتوى عن 'htaccess'.

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المحتوى


التصنيفات

  • الإدارة والقيادة
  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • السلوك التنظيمي في المؤسسات
  • عالم الأعمال
  • التجارة والتجارة الإلكترونية
  • نصائح وإرشادات
  • مقالات ريادة أعمال عامة

التصنيفات

  • مقالات برمجة عامة
  • مقالات برمجة متقدمة
  • PHP
    • Laravel
    • ووردبريس
  • جافاسكربت
    • لغة TypeScript
    • Node.js
    • React
    • Vue.js
    • Angular
    • jQuery
    • Cordova
  • HTML
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • لغة C#‎
    • ‎.NET
    • منصة Xamarin
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • لغة Rust
  • برمجة أندرويد
  • لغة R
  • الذكاء الاصطناعي
  • صناعة الألعاب
  • سير العمل
    • Git
  • الأنظمة والأنظمة المدمجة

التصنيفات

  • تصميم تجربة المستخدم UX
  • تصميم واجهة المستخدم UI
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب GIMP
    • كريتا Krita
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • مقالات DevOps عامة
  • خوادم
    • الويب HTTP
    • البريد الإلكتروني
    • قواعد البيانات
    • DNS
    • Samba
  • الحوسبة السحابية
    • Docker
  • إدارة الإعدادات والنشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
    • ريدهات (Red Hat)
  • خواديم ويندوز
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • شبكات
    • سيسكو (Cisco)

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • مقالات عمل حر عامة
  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • العمل الحر المهني
    • العمل بالترجمة
    • العمل كمساعد افتراضي
    • العمل بكتابة المحتوى

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
    • بريستاشوب
    • أوبن كارت
    • دروبال
  • الترجمة بمساعدة الحاسوب
    • omegaT
    • memoQ
    • Trados
    • Memsource
  • برامج تخطيط موارد المؤسسات ERP
    • تطبيقات أودو odoo
  • أنظمة تشغيل الحواسيب والهواتف
    • ويندوز
    • لينكس
  • مقالات عامة

التصنيفات

  • آخر التحديثات

أسئلة وأجوبة

  • الأقسام
    • أسئلة البرمجة
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات

التصنيفات

  • كتب ريادة الأعمال
  • كتب العمل الحر
  • كتب تسويق ومبيعات
  • كتب برمجة
  • كتب تصميم
  • كتب DevOps

ابحث في

ابحث عن


تاريخ الإنشاء

  • بداية

    نهاية


آخر تحديث

  • بداية

    نهاية


رشح النتائج حسب

تاريخ الانضمام

  • بداية

    نهاية


المجموعة


النبذة الشخصية

تم العثور على 6 نتائج

  1. يريد الكثير من الأشخاص تشغيل ووردبريس على جذر موقعهم، ليصبح عنوان مدونتهم، (http://example.com) على سبيل المثال، لكنهم لا يرغبون بأن يزدحم مسار خادمهم الرئيسي بالكثير من ملفات ووردبريس البرمجية. لحسن الحظ يسمح ووردبريس بتثبيت النظام داخل مجلدات فرعية والوصول إلى الموقع من نفس العنوان الرئيسي. بات بإمكان مستخدمي ووردبريس منذ إصدار ووردبريس 3.5 استعمال جميع المزايا المُدرجة في هذا المقال. لذا إن كنت تستخدم إصدارًا أقدم من 3.5، قم بتحديثه قبل تثبيت مواقع ووردبريس متعددة في المجلدات الفرعية. ملاحظة إلى مطوري القوالب، والإضافات: لن يؤثر هذا على توافق برمجياتك مع ووردبريس، إذ ستظل القوالب، والإضافات موجودةً في مجلد wp-content كما هو معتاد. نقل النظام المثبت على الجذر إلى مسار مخصص لنفترض أنك ثبتَّ ووردبريس على جذر عنوان example.com، يمكنك اختيار إحدى الطريقتين لنقل نظام ووردبريس إلى مجلد فرعي: بدون تغيير عنوان الموقع، أي سيظل عنوان مدونتك example.com عبر تغيير عنوان الموقع، ستُعيد هذه الطريقة توجيه عنوان الموقع إلى example.com/، اسم المجلد الفرعي. الطريقة الأولى: بدون تغيير عنوان الموقع بعد تثبيت ووردبريس على مجلد الجذر، بخادم موقعك، انقل جميع الملفات من مجلد الجذر إلى مجلد فرعي. أنشئ ملف htaccess.، على مجلد الجذر، وضع المحتوى، أدناه، داخل ذلك الملف (تذكر تغيير العنوان example.com، واسم المجلد الفرعي my_subdir): <IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTP_HOST} ^(www.)?example.com$ RewriteCond %{REQUEST_URI} !^/my_subdir/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ /my_subdir/$1 RewriteCond %{HTTP_HOST} ^(www.)?example.com$ RewriteRule ^(/)?$ my_subdir/index.php [L] </IfModule> هذا كل ما عليك القيام به. الطريقة الثانية: عبر تغيير عنوان الموقع عملية النقل ملاحظة: إذ ثبتَّ ووردبريس مسبقًا على مجلد فرعي، فبعض الخطوات التالية قد أُنجزت تلقائيًا بالفعل. أنشئ مجلدًا جديدًا لتخزين ملفات ووردبريس الرئيسية (سنستخدم wordpress/ كاسم المجلد الفرعي في مثالنا هذا). في حالة استخدام سطر أوامر لينكس، استخدم أمر mkdir من على مجلد الجذر، لإنشاء مجلد جديد؛ كما قد ترغب بمنح Apache صلاحيات الوصول اللازمة للمجلد الفرعي الذي أنشأته عبر أوامر chown apache. انتقل إلى صفحة الإعدادات العامة، داخل قسم الإعدادات، في لوحة التحكم بووردبريس. عدّل قيمة حقل عنوان ووردبريس (URL)، إلى عنوان المجلد الفرعي الذي يحتوي على ملفات ووردبريس الرئيسية (أي http://example.com/wordpress في مثالنا). غيّر رابط عنوان الموقع (URL)، إلى عنوان مجلد الجذر (أي http://example.com في مثالنا) انقر على زر حفظ التغييرات، ولا تقلق بشأن رسائل الخطأ التي ستظهر، واستمر باتباع الخطوات التالية. انقل ملفات ووردبريس الرئيسية من مجلد الجذر، إلى المجلد الفرعي. انسخ (لا تنقل) ملفي index.php، وhtaccess.، من المجلد الذي يحتوي على ملفات ووردبريس، إلى مجلد الجذر الخاص بموقعك. عادةً ما يكون ملف htaccess. سابق الذكر مخفيًا، لذا يجدر بك إعداد برنامج FTP الذي تستخدمه ليعرض الملفات المخفية في خادمك. إذا لم تكن تستخدم ميزة تجميل الروابط، فقد لا تملك ملف htaccess.، وإذا كنت تستضيف ووردبريس على خادم ويندوز، وتستخدم ميزة تجميل الروابط، فستجد ملف web.config عوضًا عن htaccess. في مجلد ووردبريس الخاص بك. فيما يتعلق بملف index.php فإن الإرشادات تبقى كما هي، انسخ، ولا تنقل ملف index.php إلى مجلد الجذر؛ من ناحية أخرى، فإن التعامل مع ملف web.config يختلف عن htaccess.، فهنا يجب عليك نقل الملف (وليس نسخه) إلى مجلد الجذر. افتح ملف index.php الموجود في مجلد الجذر باستخدام محرر نصّي. غيّر القيم التالية قبل حفظ الملف. غيّر السطر الذي يحتوي على ما يلي: (require( dirname( __FILE__ ) . '/wp-blog-header.php' )) إلى التالي، مستخدمًا اسم مجلد ووردبريس، الذي يحتوي على ملفات ووردبريس الرئيسية: (require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' )) سجّل الدخول إلى العنوان الجديد، والذي قد يكون (http://example.com/wordpress/wp-admin/). إذا أعددت ميزة تجميل روابط ووردبريس، انتقل إلى صفحة إعدادات الروابط لتحديث هيكل الروابط الجديد. سيُحدِّث ووردبريس تلقائيًا ملف htaccess.، طالما امتلك صلاحيات الوصول اللازمة. إذا لم يستطع ووردبريس الكتابة إلى ملف htaccess. الخاص بك، فسيعرض لك صلاحيات الوصول الجديدة التي يطلبها، وسيكون عليك نسخها يدويًا إلى ملف htaccess.، والموجود في نفس المجلد الذي يحتوي على ملف index.php الرئيسي. تعديل ملف htaccess. قد يرغب بعض المستخدمين في تثبيت إصدارات ووردبريس مختلفة، على مجلدات فرعية، مع مراعاة استخدام موقعهم لآخر الإصدارات بشكل افتراضي؛ في تلك الحالة ثبِّت ووردبريس في مجلد فرعي، وأضف التعليمات التالية إلى ملف htaccess.، الموجود بمجلد الجذر، مع تعديل الأجزاء المتعلقة باسم الموقع، والمجلد الفرعي حسب الحاجة: RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?example.com$ RewriteRule ^(/)?$ my_subdir[L] الآن سيتوجّه المستخدمين تلقائيًا إلى المجلد الفرعي الذي حددته، عندما يرغبون بالذهاب إلى عنوان موقعك الرئيسي (example.com). ملاحظة: أتت التعليمات البرمجية السابقة من دليل شركة Site 5 بعنوان: كيف تعيد توجيه عنوان موقعك إلى مجلد فرعي باستخدام ملف htaccess. نقل مجلدات ووردبريس محددة تشرح الروابط التالية كيفية تغيير مجلدات محددة، ضمن نظام ووردبريس: نقل مجلد wp-content نقل مجلد الإضافات نقل مجلد القوالب نقل مجلد التحميلات وبهذا نكون قد ذكرنا كيفية القيام بمنح ووردبريس لمجلد خاص به، من خلال نقل النظام المثبت على الجذر إلى مسار مخصص، وذلك بطريقتين؛ إلى جانب كيفية نقل مجلدات الووردبريس المحددة وتغييرها. ترجمة -وبتصرف- للمقال Giving WordPress Its Own Directory من موقع WordPress.org
  2. سواءً تَعلق الأمر بنقل ووردبريس إلى خادم جديد أو إلى مجلّد آخر على نفس الخادم، فلن تحتاج إلى إعادة تثبيته مجددًا لإكمال هذه العملية، فووردبريس يُعَدّ مرنًا كفايةً للتعامل مع أوضاع مشابهة لهذه، وفيما يلي سنشرح كيفية القيام بذلك، مع التعرف على طريقة التعامل مع صفحة اعدادت الروابط الثابتة. نقل ووردبريس إلى خادم جديد إذا رغبت في نقل ووردبريس من خادم لآخر فابدأ أولًا بإنشاء نُسخة احتياطية لكامل مُجلد ووردبريس وصورِهِ وإضافاته، وبقية الملفّات التي يتضمّنها موقعك، بالإضافة إلى قاعدة بياناتك. راجع دليل نَسخ ووردبريس احتياطيًا، ودليل النَسخ الاحتياطي لقاعدة البيانات. الاحتفاظ باسم نطاق موقعك وروابطه يمكنك نقل اسم النطاق (الدومين) الخاص بموقع ووردبريس دون تغيير عنوانه وروابطه بسهولة، فقد لا يتطلب سوى نقل بعض الملفّات في معظم الحالات. إذا بقى عنوان موقعك وقاعدة بياناته من دون تغيير، فيمكنك نقل ووردبريس عبر نسخ ملفّاتك وقاعدة البيانات فقط. إذا كان هناك تغيير على اسم قاعدة البيانات أو اسم المستخدم، فعليك تعديل ملف wp-config.php وتصحيح المعلومات المتعلّقة. إذا أردت تجربة الموقع قبل نقله، فعليك تغيير قِيم حَقلَي siteurl وhome على جدول البيانات wp_options مؤقتًا عبر استخدام برنامج phpMyAdmin أو غيره. إذا كنت تستخدم بِنيَة روابط دائمة مخصصة، فيجب عليك تعطيل ملف htaccess. وإعادة ضبط إعدادات الروابط الدائمة عند إطلاق موقعك. تغيير عنوان موقعك وروابطه يتطلّب نقل موقعك مع مراعاة تغيير عنوانه من http://example.com/site إلى http://example.com، أو من http://example.com إلى http://example.net على سبيل المثال، إجراء الخطوات التالية تِباعًا: نزّل ملفّات موقعك الحالي. صدِّر قاعدة بياناتك: انتقل إلى برنامج MySQL ونزّل نسخةً احتياطية من قاعدة البيانات. انقل ملفّات النسخة الاحتياطية إلى مجلّد جديد آمن. سجّل الدخول إلى الموقع الذي ترغب في نقله وانتقل إلى الإعدادات، ثم قسّم الإعدادات العامة وعدّل رابط الموقع (على سبيل المثال من http://example.com/‎ إلى http://example.net). إحفظ هذه التغييرات وسترى صفحة خطأ 404 بمجرّد إكمال هذه الخطوة. نزّل ملفات موقعك مجددًا. صدِّر قاعدة بياناتك مرةً أخرى. عدّل ملف wp-config.php مستخدمًا اسم قاعدة بيانات MySQL الخاصة بالخادم الجديد واسم المستخدم وكلمة مروره. ارفع هذه الملفّات إلى خادمك الجديد. استورد قاعدة البيانات إلى خادمك الجديد. هناك تدابير إضافية ستحتاج إلى إجرائها عند تغيّر اسم نطاق موقعك وروابطه، حيث يمكنك نقل الموقع وقواعد البيانات ببساطة، لكن ستظل هناك إشارات تؤدي إلى عنوان موقعك القديم أو مساره داخل قاعدة البيانات، حيث يمكنها التسبب بمشاكل مع الروابط أو تنسيقات القالب. إذا أجريت عملية البحث والاستبدال في كامل قاعدة البيانات لتغيير الروابط القديمة، فقد تُسبب مشاكل تتعلق بتسلسل البيانات، وذلك لأنّ بعض القوالب والودجات تخزّن قِيَم طُول روابطك، مما يجعلها تتعطّل عند تغيير تلك الروابط. ولتفادي هذه المشكلة يمكنك استخدام إحدى الطرق الثلاث التالية: إذا كنت تستطيع الوصول إلى لوحة التحكم بالووردبريس استخدام الإضافة Velvet Blues Update URLs، والإضافة Better Search Replace. إذا كانت شركة الاستضافة تتيح ميزة استخدام واجهة سطر أوامر ووردبريس (WP-CLI)، فاستخدم تعليمات سطر أوامر WP-CLI لاستبدال النصوص. إذا كنت تمتلك بعض المهارات في إدارة قواعد البيانات فاستخدم سكربت Search and Replace for WordPress Databases لاستبدال جميع الإشارات إلى عنوانك القديم بنظيرتها الجديدة. ملاحظة: استخدم طريقة البحث والاستبدال على جدول بيانات wp_posts فقط. ملاحظة: يُعِدّ سكربت Interconnectit برمجية طرف ثالث وقد يتعارض استخدامها مع شروط بعض خدمات الاستضافة. نقل ووردبريس إلى مجلد آخر على نفس الخادم يتطلب نقل ملفّات ووردبريس من مكان إلى آخر على خادمك انتباهك الكامل، ولذلك فإذا أردت نقل ملفّات ووردبريس إلى مجلّد خاص به مع مراعاة إمكانية تشغيله من على جذر خادمك، فربما يجدر بك قراءة صفحة امنح ووردبريس مجلّده الخاص للحصول على مزيد من الإرشادات المُفصّلة عن هذه العملية. تحتوي النقاط التالية إرشادات مُرتبة لكيفية نقل موقع ووردبريس الخاص بك إلى مكان جديد على نفس الخادم: أنشئ المجلد الجديد عبر استخدام إحدى الطريقتين أدناه: إذا كنت ترغب في نقل ملفّات ووردبريس الأساسية إلى مجلّد جديد فأنشئ المسار الجديد أولًا. إذا كنت ترغب في نقل ووردبريس إلى جذر خادمك، فتأكد من النسخ احتياطيًّا لجميع الملفّات التي ستحتاج إلى استبدالها مثل index.php و htaccess. وتأكّد أيضًا من جاهزيّة المسار الجديد لنقل ملفّات ووردبريس. سجّل الدخول إلى موقعك. انتقل إلى قسم الإعدادات في لوحة التحكم بالووردبريس، ثم إلى تبويب الإعدادات العامة. غيّر عنوان موقعك (URL) في حقل الإدخال المجاور إلى مسار ملفّات ووردبريس الرئيسية. غيّر عنوان موقع ووردبريس (URL) في حقل الإدخال إلى مسار ووردبريس الجديد والذي يجب أن يُطابق عنوان موقعك (URL). انقر على زرّ حفظ التغييرات لا تحاول تصفّح موقعك الآن. انقل ملفّات ووردبريس الرئيسية إلى المجلّد الجديد، ويتضمن هذا نقل جميع الملفّات الموجودة بداخل المسار القديم مثل http://example.com/wordpress، بالإضافة إلى المجلّدات الفرعية إلى المجلّد الجديد. تصفّح موقعك الآن عبر التوجّه إلى yourdomain.com/wp-admin، ويُرجى ملاحظة إمكانية حاجتك إلى التوجّه إلى yourdomain.com/wp-login.php عوضًا عن ذلك. إذا كنت تستخدم ميزة الروابط الدائمة فعليك الانتقال إلى لوحة التحكم، ثم قسّم الإعدادات، ثم تبويب الروابط الدائمة، لتحديث بِنيَة روابطك وحفظها إلى ملف htaccess.، والذي يتواجد على نفس مسار ملف index.php الرئيسي. لا تزال روابط موقعك ووسائطه تُشير إلى مسار ووردبريس القديم، لذا فعليك تحديثها عبر استخدام إضافات Better Search Replace، أو Velvet Blues Update URLs، أو يمكنك استخدام استعلام سطر أوامر ووردبريس (WP-CLI) لاستبدال النصوص سابقة الذكر (search-replace)، في حال دَعم هذه الميزة من قِبَل مزوّد الاستضافة المستخدم، أو يمكنك تحديث معلومات قاعدة البيانات يدويًا، أو عبر استخدام أداة طرف ثالث لاستبدال نصوص قاعدة البيانات. ويُرجى هنا ملاحظة أنّ استخدام هذه الأداة يتطلّب خلفيةً ومهارات برمجيّة. في حال تغيّر صلاحيات الوصول الخاصة بك بسبب مزوّد خدمة الإنترنت، فعدّل على صلاحيات وصول أي ملف من "0000" إلى "0644". إذا كان قالبك المستخدم يدعم ميزة القوائم فقد تكون تلك الروابط ماتزال تُشير إلى المسار القديم، ولهذا انتقل إلى قسم المظهر في لوحة التحكم، ثم إلى تبويب القوائم وحدّث معلوماتها. قد يتطلّب الأمر إعادة تشغيل خادمك وإلّا فستحصل على رسائل خطأ منه، ويحدث هذا عادةً في خوادم MAMP التي تعمل على أجهزة ماك من آبل. من المهم إعداد مسارات URI قبل البدء بنقل ملفّات ووردبريس الخاصة بموقعك. ماذا لو نسيت تغيير مسارات URI؟ إذا نسيت تغيير عناوين URI قبل نقل ملفّات ووردبريس فلديك طريقتين لحل هذه المشكلة: لنفترض أنّ مجلّد الملفّات القديم هو path/to/old وقد نقلتها إلى مجلّد path/to/new قبل تغيير عناوين URI. لحل هذه المشكلة ستحتاج إلى إعادة التوجيه عبر استخدام أمر symlink إلى مجلّد ووردبريس الجديد path/to/new كالتالي: ln -s /path/to/new /path/to/old ثم استمر باتباع الخطوات الموضّحة أعلاه ويمكنك حذف ملف symlink بعد إنهاء العملية إذا رغبت في ذلك. إذا نسيت تغيير عنوان ووردبريس وعنوان الموقع قبل نقل الملفاّت، فلن تستطيع تغييرها عبر استخدام واجهة لوحة التحكم، وعِوضًا عن ذلك يمكنك تعديلها عبر الوصول إلى جدول wp_options في قاعدة بيانات ووردبريس، إذ يُخزن هذا الجدول جميع الإعدادات التي يمكنك إيجادها على لوحة التحكم، وستجد معلومات عنوان ووردبريس وعنوان الموقع مخزّنةً في حقلي home وsiteurl، بحيث لن تحتاج إلّا لتغيير قيَِم تلك الحقول باستخدام المعلومات الجديدة. DELETE FROM `wp_options` WHERE option_name LIKE '%\_transient\_%' إذا أدخلت عنوان ووردبريس URL خاطئ لنفترض تغييرك لعنوان ووردبريس عن طريق الخطأ إلى مسار لا يمكنك نقل الملفّات إليه لكنك لا تزال تستطيع الوصول إلى صفحة تسجيل الدخول، في هذه الحالة يمكنك إعادة ضبط عنوان ووردبريس وعنوان الموقع عبر استخدام ملف wp-login.php بالبحث عن السطر البرمجيّ أدناه: require( dirname(__FILE__) . '/wp-load.php' ); ثم إدخال التعليمات التالية أسفل السطر السابق: //FIXME: do comment/remove these hack lines. (once the database is updated) update_option('siteurl', 'http://your.domain.name/the/path' ); update_option('home', 'http://your.domain.name/the/path' ); هذا هو كل ما عليك فعله، والآن تفقّد موقعك للتأكد من عمله على النحو المطلوب، وأَشْعِر زوارك بعنوان موقعك الجديد إذا قُمت بتغييره، وإذا احتجت إلى إضافة بعض تعليمات إعادة التوجيه إلى ملف htaccess لإرشاد زوارك إلى مسار موقعك الجديد، فراجع دليل تغيير عنوان موقعك URL للحصول على مزيد من التفاصيل حول هذه العملية. إدارة موقعك القديم إغلاق الموقع القديم نزّل نسخةً احتياطيةً من ملفّات ووردبريس الرئيسية الخاصة بموقعك القديم إلى حاسوبك، وعدّل المعلومات المُخزّنة في ملف wp-config.php لتناسب بيانات الخادم الجديد. توجّه إلى لوحة التحكم في موقعك القديم، ثم انتقل إلى تبويب الإعدادات العامة في قسم الإعدادات، وغيّر كلًّا من عنوان ووردبريس وعنوان الموقع مستخدِمًا معلومات الموقع الجديد. سجّل الدخول إلى لوحة التحكم في استضافتك وانتقل إلى برنامج phpMyAdmin، بعدها صدّر قاعدة البيانات في شكل ملف واحتفظ بها على حاسوبك، ثم ارفع قاعدة البيانات الجديدة هذه وملفّات ووردبريس الرئيسية مع ملف wp-config.php الذي عدّلته مسبقًا إلى خادمك الجديد. إبقاء الموقع القديم يعمل الخطوة الأولى: فعِّل موقعك الجديد نزّل نسخةً احتياطيةً مكتملةً من نظام ووردبريس من خادمك القديم إلى حاسوبك وتأكّد من تسمية المجلّد الذي يُخزّنها باسم يدُل على أنّ هذه هي النسخة الاحتياطية هي للموقع القديم. نزّل نسخةً احتياطيةً من قاعدة بيانات الموقع القديم. عُد إلى لوحة التحكم بموقعك القديم وتوجّه إلى الإعدادات لتغيير عناوين url الخاصة بووردبريس وموقعك إلى عنوان موقعك الجديد. أعد تنزيل نسخة احتياطية لكامل النظام إلى مجلّد جديد في حاسوبك وتأكد من تسميته باسم يدلّ على احتوائه على النسخة الاحتياطية لموقعك الجديد. نزّل نسخةً احتياطيةً أخرى من قاعدة بيانات موقعك مع الاحتفاظ بالنسخة الاحتياطية القديمة، ثم ارفع هذه النسخة إلى خادمك الجديد، ويجدر بك استخدام نفس اسم قاعدة البيانات وإنشاء حساب مستخدم بنفس تفاصيل الدخول إلى الخادم الجديد، لتسهيل عملية النقل وتفادي إجراء الخطوة التالية. إذا استخدمت اسمًا مختلفًا لقاعدة البيانات أو حساب المستخدم، فعليك تعديل ملف wp-config.php الموجود على خادمك واستبدال المعلومات القديمة. حمّل النسخة الاحتياطية لموقعك الجديد إلى خادمك وتفقّد إذا ما كان موقعك يعمل جيّدًا. الخطوة الثانية: استعادة موقعك القديم اِحذف قاعدة البيانات من خادمك القديم لكن تأكد من امتلاكك لنُسخة احتياطية منها على حاسوبك كما ذكرنا سابقًا. حمّل النسخة الاحتياطية لموقعك القديم إلى خادمك القديم واستبدل جميع الملفّات الموجودة هناك، أو يمكنك حذف مجلّد ووردبريس بالكامل ورفع النسخة الاحتياطية مكانه. حمّل النسخة الاحتياطية لقاعدة البيانات القديمة من حاسوبك إلى خادمك القديم، ثم تفقد إذا ما كان موقعك القديم يعمل. هناك طريقة أخرى أكثر سهولة لإجراء تلك العملية وإنشاء نُسخة من مقالاتك وصفحاتك وتصنيفاتك، بالإضافة إلى التعليقات والحقول الشخصية الأخرى، وهنا عليك باتباع الخطوات التالية: ثبّت نظام ووردبريس على خادمك الجديد. انتقل إلى لوحة التحكم في موقعك القديم وتوجّه إلى تبويب التصدير في قسم الأدوات واختر "تصدير كلّ المحتوى". انقر على زرّ تنزيل ملف التصدير (xml.). انتقل إلى لوحة التحكم في موقعك الجديد وتوجّه إلى تبويب الاستيراد في قسم الأدوات، بعدها ثبّت مستورد ووردبريس ثم استخدمه لاستيراد الملف الذي صدّرته للتو. انقر على زرّ اختيار الملف وحدّد ملف (xml.) الذي صدّرته سابقًا، ثم انقر على زرّ "ارفع الملف واستورده". ستنتقل إلى صفحة جديدة لتعيين كاتب المحتوى المستورد، ويمكنك استيراد الكاتب الأصلي أو إنشاء حساب كاتب جديد أو اختيار أحد الكتّاب الموجودين في موقعك الجديد، فقط حدّد صندوق تنزيل واستيراد الملفّات المرفَقة ثم انقر على زرّ إرسال لإكمال عملية الاستيراد. نقل نظام ووردبريس متعدد المواقع تُعَدّ عملية نقل شبكة ووردبريس متعدّدة المواقع (multisite network) أكثر صعوبةً وتعقيدًا بالموازنة مع نقل موقع ووردبريس اعتيادي، ويُعزى ذلك إلى وجود إشارات متعدّدة إلى اسم الخادم ومسار مجلّد النظام في قاعدة البيانات. لكن إذا كنت ترغب في نقل موقعك إلى خادم جديد مع الاحتفاظ باسم النطاق القديم، فيمكنك نسخ ملفّات ووردبريس وقاعدة بياناته ونقلها إلى الخادم الجديد كما لو كنت تثبّت نظام ووردبريس جديد. أمّا إذا أردت تغيير اسم نطاق موقعك فأفضل خياراتك هي نقل ملفّات ووردبريس وتعديل بيانات ملف htaccess. وwp-config.php أيضًا، وإذا كان هناك تغيير في اسم المجلّد الذي يضمّ نظام ووردبريس متعدّد المواقع، فستحتاج أيضًا إلى تعديل قاعدة البيانات يدويًا وتضمين المعلومات الجديدة حسب الحاجة، لكن للأسف لا يمكن أتْمَتَة هذه العملية حاليًا، فرغم قدرتك على إجراء عملية بحث واستبدال على مدخلات جدول wp_x_posts بأمان نسبيّ، إلا أننا ننصح بتفادي إجراء عمليات بحث واستبدال واسعة النطاق بدون الاستعانة بإحدى البرمجيات المخصَّصة لذلك، مثل: سكربت interconnectit. إذا كنت ترغب في نقل نظام ووردبريس متعدّد المواقع من مجلّد إلى آخر، فعليك التأكد من تغيير اسم المجلّد عبر تعديل مُدخلات جدول wp_blogs في قاعدة بيانات ووردبريس، كما يجب عليك مراجعة جدولَيّ wp_site وwp_blogs للتأكد من تصحيح معلومات جميع المواقع، كما عليك تفقّد جميع مُدخلات جداول wp_x_options إضافةً إلى ذلك، مع البحث عن الحقول التالية لتصحيح معلوماتها: home siteurl fileupload_url أمّا إذا كنت ترغب في نقل موقعك من اسم نطاق فرعي إلى مجلّد فرعي أو العكس، فتذكر تعديل ملف htaccess.، وقيمة متغيِر SUBDOMAIN_INSTALL الموجود في ملف wp-config.php باستخدام معلومات المسار الجديدة. صفحة إعدادات الروابط الثابتة يُقصد بالروابط الثابتة (Permalinks) عناوين URL الدائمة التي تشير إلى صفحات ومقالات موقعك، بالإضافة إلى صفحات التصنيفات والوسوم المؤرشَفة، إذ تُستخدم تلك العناوين لربط زوّارك بمحتوى الموقع، لذا فلابدّ من بقاء كلّ رابط منها ثابتًا بدون تغيير وهو سبب تسميتها بالروابط الثابتة. تسمح لك صفحة إعدادات الروابط الثابتة (Settings → Permalinks) باختيار بِِنيَة الروابط الافتراضية لموقعك، ويمكنك تحديد إحدى الخيارات الشائعة الظاهرة في هذه الصفحة أو تصميم بِنيَة روابط مُخَصصة، لكن لا تنسَ النقر على زرّ حفظ التغييرات أسفل هذه الصفحة لتطبيق وحفظ الإعدادات الجديدة. تستخدم إعدادات ووردبريس الافتراضية روابط ويب تتضمّن الاسم والتاريخ لكنها تُتيح لك إنشاء بِِنيَة مخصصة لروابطك الدائمة وصفحات الأرشيف، والتي يمكنها مساعدتك في جعل روابطك الدائمة عمليةً ومباشرةً وأكثر تناسقًا. راجع دليل استخدام الروابط الدائمة لمزيد من التفاصيل عن كيفية إعداد هذه البِنيَة، كما يجدر بك أيضًا قراءة قسم الروابط الدائمة والموجودة في صفحة دليلك إلى التدوين. تخصيص بِنية الروابط الدائمة تحتوي هذه الصفحة على مجموعة من الوسوم لمساعدتك في إعداد بِنية روابطك الدائمة، وستُبين النقاط التالية بعض الأمثلة على ذلك. الإعدادات الشائعة حدِّد أحد صناديق الاختيار الذي يُمثل بِنيَة الروابط الدائمة المناسبة لمدونتك من بين الخيارات التالية: عادي (Plain): تُشبه بِنيَة الروابط العادية النمط التالية: http://www.sample.com/?p=123. اليوم وعنوان المقال: مثال على هذه البِنيَة http://www.sample.com/2008/03/31/sample-post/‎. الشهر وعنوان المقال: تُشابه هذه البِنيَة سابقتها مع حذف اليوم من الرابط الدائم لتُصبح على هيئة http://www.sample.com/2008/03/sample-post/‎. رقمي: في مثال على هيكل الروابط الدائمة الرقمي لدينا ما يلي: http://www.sample.com/archives/123. عنوان المقال: تتضمن هذه البِنيَة عنوان المقال فقط بجانب رابط الموقع لتبدو بِنيَة الروابط الدائمة هكذا: http://www.sample.com/sample-post/‎. تركيبة مُخصصة: يمكنك تحديد بِنيَة روابطك الدائمة بنفسك عبر استخدام صندوق الإدخال المجاور، وفي مثال على ذلك نجد: /archives/%year%/%monthnum%/%day%/%postname%/. راجع صفحة وسوم بِنيَة الروابط الدائمة لمزيد من المعلومات عن هذه النقطة. الإعدادات الاختيارية يمكنك إدخال سابقة مخصَّصة لروابط التصنيفات والوسوم هنا. فعلى سبيل المثال، إذا استخدمت /topics/ مثل سابقةٍ لروابط تصنيفاتك، فستصبح روابط تصنيفاتك على هيئة http://example.org/topics/uncategorized/‎؛ أمّا إذا تركت هذه الحقول فارغةً، فسيستخدِم ووردبريس الإعدادات الافتراضية. راجع صفحة وسوم بِنيَة الروابط لمزيد من التفاصيل عن هذه النقطة. تركيبة التصنيف: أدخل سابقةً خاصة بروابط تصنيفاتك هنا. تركيبة الوسم: أدخل سابقةً خاصة بروابط الوسوم هنا. حفظ التغييرات انقر على زر حفظ التغييرات للتأكُّد من حفظ جميع الإعدادات التي قمت بتغييرها في قاعدة البيانات. سيَظهر صندوق نصّي أعلى الصفحة، وعند نقرك على هذا الزر يُعلمك بحفظ تعديلاتك، كما ستستقبل إحدى الرسالتين التاليتين عند نقرك على زر حفظ التغييرات اعتمادًا على صلاحية الكتابة التي تمتلكها على ملف htaccess. راجع دليل تغيير صلاحيات الوصول إلى الملفات لمزيد من المعلومات عن كيفية جعل ملف htaccess. قابلًا للكتابة. إذا كان ملف htaccess. قابلًا للكتابة فستحصل على رسالة تعلمك بنجاح تحديث بِنيَة الروابط الدائمة، وفي هذه الحالة فقد تولّى ووردبريس بقية مهمة تخصيص بِنيَة الروابط الدائمة تلقائيًا. إذا لم يكن ملف htaccess. قابلًا للكتابة فستحصل على رسالة تطلب منك تحديث ملف htaccess. وفقًا لبنيَة الروابط الجديدة، كما ستحصل على رسالة تُخبرك بأن ووردبريس كان ليتولى هذه المهمة تلقائيًا لو كان ملف htaccess. قابلًا للكتابة. وبما أن الأمر ليس كذلك، فهذه هي إعدادات mod_rewrite التي يجب عليك إدخالها في ملف htaccess. انسخ الحقل التالي عبر النقر على زرّي CTRL وa معًا لتحديد النص كاملًا. يعني ذلك حاجتك إلى إجراء هذه الخطوة بنفسك عبر نسخ النص الظاهر في حقل الإدخال أسفل شاشة الروابط الدائمة، والذي يُمثل إعدادات الروابط الدائمة التي قمت بتخصيصها أعلى هذه الصفحة، ثم إدراجه في ملف htaccess. الخاص بموقعك لتطبيق التغييرات الجديدة. ترجمة -وبتصرف- للمقال Settings Permalinks Screen، والمقال Moving WordPress من موقع WordPress.org. مصادر خارجية يمكنك الاطلاع على المصادر الأجنبية التالية لمزيد من التفاصيل: دليل نقل مدوّنة ووردبريس من wordpress.com إلى خادمك الخاص. دليل نقل ووردبريس إلى اسم نطاق أو خادم جديد. كيفيّة نقل مدونة أو موقع ووردبريس. دليل البحث والاستبدال لقاعدة بيانات ووردبريس سكربت PHP لاستبدال عنوان موقعك في نسخة قاعدة البيانات الاحتياطيّة حتى في حالة مواقع ووردبريس متعدّدة اللغات. إضافة Duplicator والتي ستساعدك في إدارة عمليّة نقل موقعك من مكان إلى آخر. دليل تقني عن نقل مدونة ووردبريس إلى خادم AWS من أمازون. اقرأ أيضًا مقدمة إلى تطوير قوالب ووردبريس: تحويل صفحة HTML إلى قالب ووردبريس كيف تدخل تعديلات على ووردبريس دون المساس بملفات البنية الأساسية
  3. تعرفنا في درس سابق على كيفية تفعيل وحدة mod_rewrite وضبطها لإعادة كتابة عناوين URL في خادوم Apache.ا سنعتمد في هذا الشرح على ما تعلمناه سابقًا ونتوسّع - مع مثاليْن عمليّيْن - في شرحٍ بعض من أكثر التّعليمات استخداما في ضبط mod_rewrite. المثال الأول – تبسيط نصوص الاستعلام Query strings باستخدام RewriteRule تستعمل تطبيقات الوِب في العادة نصوص الاستعلام التي يُمكن إضافتها إلى عنوان URL باستخدام علامة استفهام (?) بعد العنوان. تُمرَّر المُعاملات المُختلفة باستخدام علامة &. يُمكن استخدام نصوص الاستعلام لتمرير معلومات إضافيّة بين صفحات تطبيق الوِب. على سبيل المثال، يُمكن لصفحة نتائج بحث مكتوبة بلغة PHP أن تستعمل عنوانا مثل http://example.com/results.php?item=shirt&season=summer. في هذا المثال، هناك مُعاملان إضافيّان، المُعامل item مع القيمة shirt، والمُعامل season ذو القيمة summer. سيستعمل التّطبيق هذه المعلومات لتقديم أكثر نتيجة مناسبة للمُستخدم. تُكتب قواعد إعادة الكتابة في Apache عادة لتبسيط روابط طويلة مثل التي أعلاه إلى عناوين URL بسيطة سهلة القراءة والفهم. في هذا المثال، نريد تبسيط ما سبق ليكون على شكل http://example.com/shirt/summer. كما تُلاحظ، فالقيمتان shirt و summer لا تزالان مُتواجدتيْن داخل العنوان، لكن دون نصّ استعلام واسم ملفّ PHP. إليك قاعدة لتحقيق مُرادنا: RewriteRule ^shirt/summer$ results.php?item=shirt&season=summer [QSA] المقطع shirt/summer واضح وقد أخبرنا Apache بتوجيه أي طلبات مطابقة إلى العنوان results.php?item=shirt&season=summer. تُستخدم الخيارات [QSA] عادة في قواعد إعادة الكتابة. وتُخبر Apache بإضافة أي نصّ استعلام إضافي إلى عنوان URL المُقدَّم، لذا لو كتب زائر http://example.com/shirt/summer?page=2 فسيجيب الخادوم بـ results.php?item=shirt&season=summer&page=2. إن لم تُضف هذه الخيارات فسيُتجاهل نصّ الاستعلام الإضافي. رغم أنّ هذه الطّريقة تُحقّق هدفنا، إلّا أنّنا كتبنا القيمتين بصراحة داخل الملفّ. لذا فالقاعدة لن تعمل لأي قيم أخرى مثل pants وwinter. لجعل القاعدة عامّة أكثر، يُمكننا استخدام التّعابير النّمطيّة لمُطابقة أجزاء من العنوان الأصلي واستعمالها في مقطع بدل نمطي. بحيث تكون القاعدة المُعدّلة كما يلي: RewriteRule ^([A-Za-z0-9]+)/(summer|winter|fall|spring) results.php?item=$1&season=$2 [QSA] التّعبير النمطي الأول داخل القوسين يُطابق أي مقطع نصّ مكوّن من أحرف وأرقام مثل shirt و pants ويحفظ المقطع المُطابق في المُتغيّر $1. التّعبير النمطي الذي يتبعه يُطابق حرفيًّا كلّا من summer، winter، fall و spring، ويحفظ أي مُطابق في المُتغيّر $2. تُستعمل المقاطع المُطابقة بعدها في عنوان URL النّاتج لتمريرها إلى كل من المُعاملين item وseason عوضا عن كتابة القيمتين على نحو صريح كما فعلنا سابقا. القاعدة أعلاه ستستبدل على سبيل المثال العنوان http://example.com/pants/summer إلى http://example.com/results.php?item=pants&season=summer. هذا المثال قابل للتماشي مع التّطويرات المُستقبليّة كذلك، بحيث يُمكن إعادة كتابة العناوين لعدّة قيم باستخدام قاعدة واحدة فقط. المثال الثّاني – إضافة شروط منطقيّة باستخدام RewriteConds قواعد إعادة الكتابة ليست محصورة في قواعد تُترجم واحدة تلو الأخرى دون أية قيود. تُمكّننا تعليمة RewriteCond من إضافة شروط لقواعد إعادة الكتابة للتحكم في وقت ترجمة القواعد. تتّبع RewriteCond التّنسيق التّالي: RewriteCond TestString Condition [Flags] RewriteCond: تعليمة الشرط. TestString النّص الذي سيُجرى عليه الاختبار. Condition نمط أو شرط للاختبار به. Flags عبارة عن مُعاملات إضافيّة يُمكن لها تعديل الشّرط وقواعد التّحويل. إذا أرجع شرط في RewriteCond القيمة المنطقيّة true (أي أنّ الشرط قد تحقّق)، فستُنفَّذ قاعدة RewriteRule التي تلي الشرط مُباشرة. إن لم يتحقّق الشّرط فتُتجاهل القاعدة. يُمكن استخدام أكثر من شرط. يجب مبدئيًّا على جميع الشّروط أن تتحقّق لتطبيق القاعدة التي تليها. على سبيل المثال، لنفترض بأنّك تريد إعادة توجيه جميع الطّلبات المُوجّهة إلى ملفّات أو مُجلّدات غير موجودة إلى الصّفحة الرّئيسيّة عوضا عن عرض صفحة الخطأ 404. يُمكن تحقيق هذا الهدف بالشّروط التّاليّة: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . / في المثال أعلاه: %{REQUEST_FILENAME} يُمثّل النصّ المُختبَر. في هذه الحالة، القيمة ستكون عبارة عن اسم الملفّ الذي طلبه المُستخدم وهو مُتغيّر نظام خاص يتوفّر في كل طلب. f- شرط متوفّر مُسبقا في وحدة mod_rewrite للتّحقّق من أنّ الاسم الذي طلبه المُستخدم مُتواجد على القرص وبأنّه ملفّ فعلا. أمّا ! فهي علامة نفي. بجمعهما، فـf-! تتحقّق من أنّ الاسم الذي طلبه الاستعلام غير مُتواجد أو أنّه ليس ملفّا. d-! يعمل بطريقة مُشابهة ولكن بالنسبة للمجلّدات، إذ يُساوي القيمة true فقط إن كان الاسم المطلوب غير موجود أو أنّه ليس مجلّدا. ستُنفَّذ قاعدة RewriteRule الموجودة في السطر الأخير فقط إن تلقى الخادوم طلبا لملفّ أو مُجلّد غير موجود. القاعدة بسيطة وكلّ ما تفعله هو إعادة توجيه الطّلب إلى موجّه الجذر / في الموقع (والذي يكون عادة صفحة رئيسيّة). خاتمة mod_rewrite وحدة مُفيدة جدّا في Apache يُمكن استخدامها لتوفير عناوين URL سهلة القراءة. في هذا الدّرس، تعلّمتَ كيفيّة استخدام تعليمة RewriteRule لإعادة توجيه المُستخدمين حتى ولو كانت تتضمّن نصوص استعلام. تعلّمت كذلك كيفيّة إعادة التّوجيه حسب شروط باستعمال التّعليمة RewriteCond. للتّعرف أكثر على mod_rewrite، ألق نظرة على هذه الصّفحة والتّوثيق الرّسمي لـmod_rewrite من Apache. ترجمة – بتصرّف - للمقال How To Rewrite URLs with mod_rewrite for Apache on Ubuntu 16.04 لكاتبه Mateusz Papiernik.
  4. مُقدّمة سنتعرّف في هذا الدّرس على كيفيّة إعادة كتابة عناوين URL باستخدام وحدة mod_rewrite الخاصّة بـApache 2. تمنحنا هذه الوحدة حريّة إعادة كتابة روابط URL لتكون أكثر نظافة وتنسيقا عبر ترجمة مسارات قابلة للقراءة إلى استعلامات مُوجّهة لتطبيق الوِب أو إعادة توجيه المُستخدم حسب شروط إضافيّة. هذا الدّرس مُقسّم إلى جزأين. بحيث نجهّز في الجزء الأول موقعا إلكترونيا بسيطا مع مثال بسيط لإعادة كتابة عنوان URL. يُغطّي الجزء الثّاني مثالين مُعمّقين لأكثر قواعد إعادة الكتابة شيوعا. المُتطلّبات لاتّباع هذا الدّرس، ستحتاج إلى: خادوم أوبونتو 16.04 مضبوط باتّباع الخطوات الواردة في درس الإعداد الابتدائي لخادوم أوبونتو، وذلك يشمل مُستخدما ذا صلاحيّات sudo مع ضبط مُسبق لتمكينه من تنفيذ مهام إداريّة، غير المستخدم الجذر root، بالإضافة إلى جدار ناري. Apache 2 مُنصّب على خادومك باتّباع الخطوة الأولى من درس تثبيت حزم LAMP على أوبونتو. الخطوة 1 – تفعيل mod_rewrite أولا، نحتاج إلى تفعيل mod_rewrite. مبدئيًّا، الوحدة متوفّرة لكنّها غير مُفعّلة عند تنصيب Apache 2. sudo a2enmod rewrite سيقوم هذا الأمر بتفعيل الوحدة أو إخبارك بأنّ الوحدة قد سبق تفعيلها. لتطبيق التّغييرات، أعد تشغيل Apache: sudo systemctl restart apache2 وحدة mod_rewrite مُفعّلة الآن. سنضبُط في الخطوة التّاليّة ملفّ .htaccess لاستخدامه لتحديد قواعد إعادة الكتابة لإعادات التّوجيه Redirects. الخطوة 2 – ضبط htaccess. يسمح لنا ملفّ .htaccessبتعديل قواعد إعادة الكتابة دون الحاجة إلى الوصول إلى ملفّات إعدادات الخادوم. لهذا السّبب، فملفّ .htaccess مُهمّ جدّا لحماية تطبيق الوِب الخاصّ بك. النّقطة في أول الاسم تُشير إلى أنّ الملفّ مخفي. مُلاحظة: يُمكن لأي قواعد تضعها داخل ملفّ .htaccess أن توضع كذلك داخل ملفّات إعدادات الخادوم، في الحقيقة، ينصح التوثيق الرّسمي لـApache ينصح باستعمال ملفات إعدادات الخادوم عوضا عن ملفّ .htaccess لقدرة Apache على مُعالجتها بسرعة أعلى. مع ذلك، في مثالنا البسيط، الفرق في الأداء لن يكون ملحوظا. بالإضافة إلى أنّ وضع القواعد داخل ملفّ .htaccess مُريح أكثر، خاصّة إن كان لديك الكثير من المواقع الإلكترونيّة في خادوم واحد. إذ لا تتطلّب التّغييرات إعادة تشغيل الخادوم ولا تحتاج إلى صلاحيّات المُستخدم الجذر Root لتعديل الملفّ، ما يُسهّل إجراء التّغييرات بحساب مُستخدم عاديّ. بعض البرمجيّات مفتوحة المصدر مثل جوملا ، ووردبريس ولارافل تعتمد على ملفّ .htaccess لإجراء التّعديلات وإضافة قواعد إضافيّة حسب الطّلب. سنحتاج إلى ضبط وتأمين بعض الإعدادات قبل أن نبدأ. يمنع Apache مبدئيًّا استخدام ملفّ .htaccess لقواعد إعادة كتابة روابط URL، لذا سيتوجّب عليك أولا تفعيل إمكانيّة استخدام الملفّ. افتح ملفّ إعدادات Apache المبدئية باستخدام nano أو مُحرّرك المفضّل. sudo nano /etc/apache2/sites-available/000-default.conf ستجد داخل هذا الملفّ الجزء <VirtualHost *:80> في أول سطر. داخل هذا الجزء، أضف الجزء التّالي مباشرة بعد السطر الذي يبدأ بـDocumentRoot: <Directory /var/www/html> Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted </Directory> ليُصبح ملفّ الإعدادات كما يلي (حذفنا - للاختصار - التعليقات، وهي الأسطر التي تبدأ بـ# من المُقتَطع أدناه). تأكّد من أنّ الإزاحة صحيحة: <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html <Directory /var/www/html> Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> احفظ وأغلق الملفّ. ملحوظة: يفترض هذا الدليل وجودَ موقع واحد على خادومك، في هذه الحالة يكفي التعديل على ملف المضيف الافتراضي Virtual host المبدئي (000-default.conf) بالطريقة أعلاه لتفعيل إمكانيّة إعادة التوجيه. إن كان لديك أكثر من موقع فستحتاج لإجراء التعديل أعلاه على ملفّ المضيف الافتراضي الخاصّ بالموقع الذي تريد. توجد ملفات المضيفات الافتراضية على المسار /etc/apache2/sites-available/. لتطبيق التّغييرات، أعد تشغيل خادوم Apache: sudo systemctl restart apache2 الآن، أنشئ ملفّ .htaccess داخل مجلّد الوب الجذر: sudo nano /var/www/html/.htaccess أضف السّطر التّالي إلى أعلى الملفّ لتفعيل مُحرّك إعادة الكتابة Rewrite engine: RewriteEngine on احفظ وأغلق الملفّ. يُمكنك الآن استعمال الملفّ .htaccess للتّحكم بقواعد المُوجّهات في تطبيق الوِب الخاصّ بك. الخطوة 3 – ضبط إعادات كتابة روابط URL سنعدّ في هذه الفقرة إعادة كتابة بسيطة لرابط URL، بحيث نستطيع تحويل عناوين URL جميلة إلى مسارات يُمكن للشفرة فهمها. سنسمح بالخصوص للمُستخدمين بالوصول إلى العنوان http://your_server_ip/about. لنبدأ بإنشاء ملفّ باسم about.php داخل مُجلّد الوب: sudo nano /var/www/html/about.php انسخ شفرة HTML التّاليّة إلى الملفّ واحفظه ثمّ أغلقه: <html> <head> <title>About Us</title> </head> <body> <h1>About Us</h1> </body> </html> ملحوظة: تأكّد من أن خادوم الوِب لديه صلاحيات الوصول إلى الملف الذي أنشأته للتو. مثلا، بإعطاء الأذون 755على مجلد الوِب: sudo chmod -R 755 /var/www يُمكنك الوصول إلى هذه الصّفحة على العنوان http://your_server_ip/about.html، لكن لو حاولت الوصول إلى العنوان http://your_server_ip/about، فستُلاحظ خطأ 404 Not Found، إن أردت تمكين مُستخدميك من استعمال هذا العنوان عوضا عن العنوان السّابق (أي دون الجزء .html) فقواعد إعادة الكتابة كفيلة بتوفير هذه الوظيفة. تتّبع جميع قواعد الكتابة التّنسيق التّالي: RewriteRule pattern substitution [flags] بحيثُ: RewriteRule يُحدّد التّعليمة. pattern تعبير نمطي Regular Expression يُحدّد عنوان URL المرغوب به، هذا هو ما سيكتبه المُستخدم في شريط عنوان URL. substitution: البدل، وهو مسار عنوان URL الأصلي، (مسار الملفّ الذي يقوم Apache بتقديمه). flags عبارة عن مُعاملات اختياريّة لتعديل آليّة عمل القاعدة. افتح ملفّ .htaccess: sudo nano /var/www/html/.htaccess بعد السّطر الأول، أضف السّطر الثّاني ممّا يلي: RewriteEngine on RewriteRule ^about$ about.html [NC] في هذه الحالة، المقطع ^about$ هو التّعبير النّمطي، about.html يُعبّر عن البدل، و [NC] هي المُعاملات. استخدمنا في هذا المثال عدّة محارف تحمل معان خاصّة: ^ يُشير إلى بداية العنوان بعد المقطع your_server_ip/. $ يُشير إلى نهاية عنوان URL. about المقطع الذي يجب على التّعبير النّمطي مُطابقته. about.html اسم الملفّ الأصلي الذي يصل إليه المُستخدم [NC] خيار لجعل القاعدة تتجاهل حالة الأحرف Case insensitive. ينبغي الآن أن تستطيع الوصول إلى العنوان http://your_server_ip/about في مُتصّفح الويب الخاصّ بك. في الحقيقة، بالقاعدة التي كتبناها أعلاه، فالعناوين التّاليّة ستؤدّي جميعها إلى الملفّ about.html: http://your_server_ip/about، بسبب تعريفنا للقاعدة. http://your_server_ip/About، لأنّ القاعدة تتجاهل حالة الأحرف. http://your_server_ip/about.html، لأنّ اسم الملفّ الأصلي سيعمل دائما. العناوين التّاليّة لن تعمل: http://your_server_ip/about/، لأنّ القاعدة تنصّ بوضوح بأنّه لا يجوز على أي شيء أن يكون بعد about باستخدام المحرف $. http://your_server_ip/contact، لأنّ العنوان لن يُطابق المقطع about. تمتلك الآن ملفّ .htaccess مع قاعدة بسيطة، يُمكنك الآن تعديله وتوسيعه حسب حاجاتك. سنتعرّف في الجزء الثاني من هذا الدرس على أمثلة إضافية لإعادة كتابة الروابط والتعليمات الأكثر استخداما مع mod_rewrite. ترجمة – بتصرّف - للمقال How To Rewrite URLs with mod_rewrite for Apache on Ubuntu 16.04 لكاتبه Mateusz Papiernik.
  5. رغم قيامك بكل شيء بالطريقة الصحيحة، قد تواجهك أحيانا بعض رسائل الخطأ (errors) على ووردبريس. لا تقلق فإلى جانب أنك قد لا تكون السبب في ذلك بتاتا فقد تجد حلّا سهلًا وبسيطًا له. يتوفر ووردبريس افتراضيا على قيمة قصوى محدودة لرفع الصور، مقاطع الفيديو والملفات الأخرى، نفس الأمر بالنسبة لمحدودية ذاكرة PHP التي تساعدك على تشغيل الملحقات والسكربتات (scripts). قد يصبح هذا الأمر مشكلة حقيقية خصوصا إن كنت تملك موقعا ضخما غنيا بالمحتوى، عند وصولك إلى هذه القيم القصوى فإنك تواجه رسالة خطأ كالتالي: The uploaded file exceeds the upload_max_filesize directive in php.ini عند وصولك إلى القيمة القصوى للذاكرة من المحتمل أن تواجه رسالة مشابهة لما يلي: Fatal error: Allowed memory size of 12345678 bytes exhausted (tried to allocate 2345678 bytes) in /home/your-username/public_html/wp-includes/plugin.php on line 1000 قد يكون إصلاح هذا المشكل أمرا صعبا بعض الشيء بناء على إعدادات الخادوم (server)، لذ سنخصص هذا المقال لتوضيح كيفية زيادة قيمة الرفع القصوى وفي سعة الذاكرة على خادومك حتى تستأنف عملك كالمعتاد. تحديث ملف php.ini إن كنت تستخدم cPanel، اذهب إلى قسم الملفات Files واضغط على زر File Manager. تأكد التأشير على خانة Show Hidden Files ثم اضغط على Go. قم بتحديد مجلد wp-admin، ابحث عن أحد الملفين php.ini أو php5.ini، إن لم تجد أيا منهما، أنشئ واحدا جديدًا بالنّقر على زر New File في الزاوية أعلى اليسار، اختر اسم php.ini للملف ثم اضغط على Create File في الشاشة المنبثقة. يمكنك اختيار Document Root من أجل ولوج أسرع، ستذهب مباشرة إلى ملفات موقعك بعد اختيارها من القائمة المنسدلة. إذا اتبعت هذه الخطوات ولم ينجح الأمر، جرب تغيير اسم الملف إلى php5.ini، بمجرد فتح الملف أضف أو قم بتعديل الأسطر التالية، احفظ التغييرات ثم غلق الملف. upload_max_filesize = 1000M post_max_size = 2000M memory_limit = 3000M file_uploads = On max_execution_time = 180 يدل حرف M على ميغابايت، قم بتغيير القيم القصوى 1000M ،2000M و 3000M إلى قيم أخرى من اختيارك والتي تراها مناسبة لك. يؤدي تغيير قيمة max_execution_time إلى الحد من الوقت المستغرق في تحميل السكربت (مقدّرًا بالثّواني). في العديد من الحالات تتصاعد القيم التي تدخلها أثناء نزولك في القائمة من السطر الأول إلى الثالث، يجب على قيمة upload_max_filesize أن تكون هي الصغرى في حين تكون قيمة memory_limitshould هي الكبرى أما قيمة post_max_size فتمثل الوسط بينهما. قبل التأكد من ذهاب رسالة الخطأ، تأكد من حذف التخزين المؤقت للمتصفح (browser’s cache). تعديل ملف htaccess. إن لم يفِ التعديل السابق بالغرض، جرب التعديل على ملف htaccess.، أضف أو عدّل على الكود التالي في أسفل الصفحة: php_value upload_max_filesize 1000M php_value post_max_size 2000M php_value memory_limit 3000M php_value max_execution_time 180 php_value max_input_time 180 يتم تعديل هذا الكود بنفس طريقة التعديل على ملف php.ini، قم بتغيير القيم إلى ما يناسب احتياجاتك، لا تنس حفظ التعديلات وحذف التخزين المؤقت لمتصفحك. تحسين ملف wp-config.php إن لم تفلح أي الطريقتين السابقتين، جرب التعديل على ملف wp-config.php من خلال إضافة ما يلي إلى أسفل الصفحة مباشرة قبل سطر "happy blogging": define('WP_MEMORY_LIMIT', '3000M'); احفظ التعديلات واحذف التخزين المؤقت للمتصفح (browser’s cache). تغيير القيم القصوى في WHM إن كنت تستضيف موقعك على خادوم مخصص (dedicated server) أو من نوع VPS، يمكنك أن تجرب تغيير القيم القصوى للتحميل والذاكرة في WHM الخاص بك. بعد تسجيل الدخول، اذهب إلى: Server Configuration > Tweak Settings > PHP استخدم نفس القيم التي استخدمتها أعلاه وذلك من أجل نتائج أفضل. أدخل القيم المناسبة لك ثم اضغط على Save أسفل الصفحة. بعد ذلك، اذهب إلى: Service Configuration > PHP Configuration Editor تصفح الصفحة نزولا حتى تجد الأقسام الرئيسية memory_limit و upload_max_filesize. يجب على القيم التي تدخلها هنا أن تكون مطابقة لتلك التي حاولت إدخالها سابقا في ملفي: php.ini و htaccess.. أدخل القيم المناسبة لإعدادك. أخيرًا في قسم Options & Information حدد مكان max_execution_time وقم بتحديثه إلى نفس القيم التي أدخلتها في ملفي: php.ini و htaccess.. اضغط على Save أسفل الصفحة واحذف التخزين المؤقت للمتصفح. خلاصة أنت الآن على أتم استعداد لحل مشكل رسائل الخطأ، استمتع برفع ملفات أكبر حجما واستمر في استخدام الملحقات كما تشاء على موقع ووردبريس الخاص بك. لن تأخذ هذه التغييرات أكثر من بضع دقائق ليظهر تأثيرها لتتمكن من استئناف عملك بسرعة. إذا احتجت إلى رفع ملفات بحجم أكبر مرة واحدة فقط، يمكنك أن تقوم أيضا برفعها من خلال FTP لتجنب هذا العناء. في حين لا يتم عادة عرض الملفات المرفوعة على /wp-content/uploads/ directory باستخدام FTP في مكتبة الميديا، يمكن للملحق Media from FTP أن يسجلها في المكتبة ببضع نقرات. يتم تحديث هذا الملحق بشكل دوري. إن لم تعمل أي من الخيارات المقترحة، لم تتمكن من الولوج إلى الأماكن المذكورة أو واجهت بعض المشاكل أثناء القيام بهذه التغييرات عليك بالاتصال بمزود الاستضافة الخاصة بك الذي يمتلك صلاحية الولوج من أجل القيام بالتغييرات المطلوبة، فمزودك هو الأنسب لهذه المهمة. هل استطعت تغيير القيم القصوى للرفع وذاكرة PHP باستخدام هذه الطرق؟ هل واجهت أي مشاكل في القيام بذلك سابقا؟ تفضل بمشاركتنا تجربتك في التعليقات أسفله. ترجمة بتصرف للمقال: How to Increase the Maximum Upload and PHP Memory Limit in WordPress لصاحبته: JENNI MCKINNON.
  6. عند إعداد خادوم ويب توجد غالبًا أقسام من الموقع نرغب بتقييد الوصول إليها، تُوفِّر تطبيقات الويب عادةً طرق التصريح authorization والاستيثاق authentication الخاصّة بها، ولكن يُمكِن استخدام خادوم الويب بذاته لتقييد الوصول إن كانت هذه الطّرق غير كافية أو غير متوفّرة. سنشرح في هذا الدّرس كيف نحمي الممتلكات assets باستخدام كلمة سر على خادوم ويب Apache يعمل على Ubuntu. المتطلبات الأساسيةنحتاج للوصول إلى بيئة خادوم Ubuntu لكي نبدأ، نحتاج أيضًا لمستخدم غير جذري non-root مع صلاحيّات sudo من أجل تنفيذ مهام إداريّة administrative، لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. تثبيت حزمة أدوات Apache المساعدةسنستخدم أداة مُساعِدة utility تُدعى htpasswd من أجل إنشاء الملف الذي يقوم بتخزين كلمات السّر التي نحتاجها للوصول إلى المحتوى المُقيَّد لدينا، تُوجَد هذه الأداة في الحِزمة apache2-utils داخل المستودعات repositories في Ubuntu. نُحدِّث الذاكرة المؤقتة cache للحِزَم المحليّة ونُثبِّت الحِزمَة بكتابة هذا الأمر، سننتهز الفرصة أيضًا لتثبيت خادوم Apache2 في حال لم يكن مُثبّتًا لديك: sudo apt-get update sudo apt-get install apache2 apache2-utilsإنشاء ملف كلمات السرنستطيع الآن الوصول للأمر htpasswd واستخدامه لإنشاء ملف كلمات السّر والذي يستعمله خادوم Apache لاستيثاق authenticate المستخدمين، سنقوم بإنشاء ملف مخفي لهذا الغرض يُدعى htpasswd. بداخل دليل الإعدادات etc/apache2/. عند استخدام هذه الأداة لأوّل مرّة نحتاج لإضافة الخيار c- لإنشاء الملف المُحدَّد، نقوم بتحديد اسم مستخدم (في هذا المثال sammy) في نهاية الأمر لإنشاء مُدخَل جديد بداخل الملف: sudo htpasswd -c /etc/apache2/.htpasswd sammyسيتم سؤالنا عن تزويد كلمة سر وتأكيدها للمستخدم. نترك الوسيط c- لأي مستخدمين آخرين نرغب في إضافتهم: sudo htpasswd /etc/apache2/.htpasswd another_userإن قمنا بمشاهدة محتويات الملف نستطيع رؤية اسم المستخدم وكلمة السّر المُشفّرة لكل تسجيل record: cat /etc/apache2/.htpasswdsammy:$apr1$lzxsIfXG$tmCvCfb49vpPFwKGVsuYz. another_user:$apr1$p1E9MeAf$kiAhneUwr.MhAE2kKGYHK.إعداد استيثاق كلمة السر لخادوم Apacheالآن وبعد أن أصبحنا نمتلك ملف لأسماء المستخدمين وكلمات السّر في صيغة يستطيع خادوم Apache قراءتها، نحتاج لإعداد Apache لكي يتفحّص هذا الملف قبل تخديم محتوانا المحمي، بإمكاننا فعل هذا بطريقتين مختلفتين. الخيار الأول هو تحرير edit إعدادات Apache وإضافة حماية كلمة السّر إلى ملف المضيف الافتراضي virtual host file. يُعطينا هذا الخيار أداء أفضل بشكل عام لأنّه يتجنّب تكلفة قراءة ملفات إعدادات مُوزَّعة، إن كنت تملك هذا الخيار فإنّنا ننصح بهذا الأسلوب. إن لم تكن لدينا القدرة على تعديل ملف المضيف الافتراضي (أو كنّنا نستخدم مُسبقًا ملفات htaccess. لأغراض أخرى) نستطيع تقييد النفاذ باستخدام ملف htaccess.، يستخدم Apache ملفّات htaccess. من أجل السّماح لتعيين بعض عناصر الإعدادات داخل ملف في دليل المحتوى. العيب في هذا هو أنّه يجب على Apache إعادة قراءة هذه الملفّات عند كل طلب يتضمّن هذا الدّليل ممّا قد يؤثر على الأداء. اختر الخيار الذي يُناسِب احتياجاتك أدناه. إعداد التحكم بالنفاذ Access Control داخل تعريف المضيف الافتراضينبدأ بفتح ملف المضيف الافتراضي الذي نرغب بإضافة تقييد له، سنستخدم في مثالنا الملف 000-default.conf الذي يحمل المضيف الظاهري الافتراضي والمُثبَّت عبر حزمة apache في Ubuntu: sudo nano /etc/apache2/sites-enabled/000-default.confينبغي أن يبدو المحتوى داخل الملف مُشابِهًا لما يلي بعد إزالة التّعليقات: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>يتم الاستيثاق على أساس كل دليل، سنحتاج لإعداد الاستيثاق إلى استهداف الدّليل الذي نرغب بتقييد الوصول إليه بواسطة كتلة <Directory ___>، في مثالنا سنقيّد الوصول إلى كامل جذر المستند document root ولكن نستطيع تعديل القائمة لاستهداف دليل مُحدَّد داخل مساحة الويب: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> </Directory> </VirtualHost>نُحدِّد داخل كتلة الدّليل أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: etc/apache2/sites-enabled/000-default.conf/ <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory "/var/www/html"> AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-user </Directory> </VirtualHost>عند الانتهاء نحفظ ونغلق الملف، نعيد تشغيل Apache لتنفيذ سياسة policy كلمات السّر: sudo service apache2 restartيجب الآن أن يكون الملف الذي حدّدناه محميًّا بكلمة سر. إعداد التحكم بالنفاذ Access Control باستخدام ملفات htaccess.إن كُنّا نرغب بإعداد حماية كلمة السّر باستخدام ملفّات htaccess. بدلًا من الطريقة السّابقة فينبغي أن نبدأ بتحرير ملف إعدادات Apache الرئيسي للسماح بملفّات htaccess.: sudo nano /etc/apache2/apache2.confنبحث عن الكتلة <Directory> من أجل الدّليل var/www/ الذي يحتوي جذر المستند، نقوم بتشغيل معالجة htaccess. بتغيير الأمر التّوجيهي AllowOverride داخل تلك الكتلة من “None” إلى “All”: etc/apache2/apache2.conf/ . . . <Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> . . .عند الانتهاء نحفظ ونغلق الملف. نحتاج بعد ذلك لإضافة ملف htaccess. إلى الدّليل الذي نرغب بتقييد الوصول إليه، في هذا المثال سنقيّد الوصول إلى كامل جذر المستند (كامل الموقع) والذي يتواجد في المسار var/www/html/، ولكن يُمكننا وضع هذا الملف في أي دليل نرغب بتقييد الوصول إليه: sudo nano /var/www/html/.htaccessنُحدِّد بداخل هذا الملف أنّنا نرغب بإعداد استيثاق أساسي Basic، نختار من أجل AuthName اسم حقل يتم عرضه عند السؤال عن الاعتمادات credentials، نستخدم الأمر التوجيهي AuthUserFile ليشير إلى Apache عن ملف كلمات السّر الذي أنشأناه، سنحتاج أخيرًا إلى valid-user للوصول إلى هذا المورد، وهذا يعني أنّه سيتم السماح بالدخول لكل من يثبت صحّة هويته بكلمة سر: var/www/html/.htaccess/ AuthType Basic AuthName "Restricted Content" AuthUserFile /etc/apache2/.htpasswd Require valid-userنحفظ ونغلق الملف، نعيد تشغيل خادوم الويب لنحمي بكلمة سر كل المحتوى الموجود في الدّليل بواسطة الملف htaccess.: sudo service apache2 restartتأكيد استيثاق كلمة السرللتأكّد من أنّ المحتوى محمي لدينا نُجرِّب النفاذ إلى المحتوى المُقيَّد من متصفّح إنترنت، يجب أن يتم عرض مُحث prompt لاسم المستخدم وكلمة السّر يُشبه ما يلي: إن أدخلنا الاعتمادات الصحيحة سيتم السماح لنا بالنفاذ إلى المحتوى، وإن أدخلنا الاعتمادات الخاطئة أو ضغطنا على إلغاء Cancel سنشاهد صفحة الخطأ "Authorization Required": الخاتمة يجب أن يكون لدينا الآن كل ما نحتاجه لإعداد استيثاق أساسي لموقعنا، فلنضع في اعتبارنا أنّ حماية كلمة السّر يجب أن تكون جنبًا إلى جنب مع تشفير SSL كي لا يتم إرسال اعتماداتنا إلى الخادوم في شكل نص مُجرَّد plain text، يمكنك الإطلاع أيضا على كيفيّة إنشاء شهادة SSL موقّعة ذاتيًّا لاستخدامها مع Apache. ترجمة -وبتصرّف- لـ How To Set Up Password Authentication with Apache on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.
×
×
  • أضف...