it-swarm.asia

يطلب WordPress بيانات اعتماد FTP الخاصة بي لتثبيت المكونات الإضافية

لقد قمت بتثبيت مدونة WordPress في نظامي المحلي. ولكن عندما أحاول إضافة مكونات إضافية من المشرف ، فإنه يطلب الوصول إلى FTP. ما الذي أحتاجه لتهيئة برنامج WordPress ليكون قادرًا على التحميل بدون FTP؟

98
sasi kanth

حاول إضافة الكود في wp-config.php:

define('FS_METHOD', 'direct');
266
nickle

إذا كنت تستخدم أوبونتو.

Sudo chown -R www-data:www-data PATH_TO_YOUR_WORDPRESS_FOLDER
32
Nanhe Kumar

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

قبل إجراء أي تغييرات ، يتحقق WordPress أولاً لمعرفة ما إذا كان لديه حق الوصول إلى نظام الملفات أم لا.

إذا لم يكن لدى WordPress الأذونات اللازمة لتعديل نظام الملفات مباشرةً ، فستتم مطالبتك ببيانات اعتماد FTP حتى يتمكن WordPress من محاولة القيام بما يحتاج إليه عبر FTP. "

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

<?php echo(exec("whoami")); ?>

بالنسبة لي ، كان الخفي وليس شبكة الاتصالات العالمية البيانات. ثم ، قم بإصلاح الإذن من خلال:

Sudo chown -R daemon /path/to/your/local/www/folder
16
Aboozar Rajabi

على OSX ، استخدمت ما يلي ، وقد نجحت:

Sudo chown -R _www:_www {path to wordpress folder}

_www هو المستخدم الذي يعمل PHP ضمنه على جهاز Mac.

(قد تحتاج أيضًا إلى تغيير بعض المجلدات أيضًا. لقد قمت بذلك أولاً ولم يتم إصلاحه. لم يكن الأمر كذلك حتى قمت بتنفيذ الأمر chown ، لذلك لست متأكدًا مما إذا كان الأمر chown وحده ، أو مزيج من chmod و chown.)

10
Kenny

لقد غيرت ملكية مجلد Wordpress إلى www-data بشكل متكرر وأعدت تشغيل Apache.

Sudo chown -R www-data:www-data <folderpath>

هذا يعمل كالسحر!

9
KawaiKx

من أول ضربة على Google :

يطلب WordPress بيانات اعتماد FTP الخاصة بك عندما لا يستطيع الوصول إلى الملفات مباشرة. يحدث هذا عادة بسبب PHP التشغيل كمستخدم Apache (mod_php أو CGI) بدلاً من المستخدم الذي يملك ملفات WordPress الخاصة بك.

هذا أمر طبيعي إلى حد ما في معظم بيئات الاستضافة المشتركة - يتم تخزين الملفات كمستخدم ، ويعمل Apache كمستخدم Apache أو httpd. يعد هذا في الواقع إجراءً احتياطياً جيداً للأمان ، لذا لا يمكن للاستغلال والخارقة تعديل الملفات المستضافة. يمكنك التحايل على هذا من خلال تعيين جميع WP الملفات على 777 أمان ، ولكن هذا يعني لا الأمن ، لذلك أنصح بشدة بعدم ذلك. ما عليك سوى استخدام بروتوكول نقل الملفات ، إنه الحل الذي ينصح به تلقائيًا لسبب وجيه.

7
Niels Keurentjes

أولاً ، انتقل إلى مجلد التثبيت الخاص بك (على سبيل المثال)

cd /Applications/XAMPP/xamppfiles/

سنقوم الآن بتعديل دليل htdocs الخاص بك:

Sudo chown -R daemon htdocs

أدخل كلمة مرور الجذر عند المطالبة ، ثم قم بإنهائها باستخدام مكالمة chmod:

Sudo chmod -R g+w htdocs
3
Benja Garrido

قمت بإجراء تثبيت محلي لبرنامج WordPress على Ubuntu 14.04 باتباع الخطوات الموضحة هنا وتشغيلها ببساطة:

Sudo chown -R www-data:www-data {path_to_your_project_directory}

حل مشكلتي مع تنزيل الإضافات. السبب الوحيد الذي يجعلني أترك هذا المنشور هنا هو أنه عندما غوغل مشكلتي ، كانت هذه واحدة من النتائج الأولى التي أدت بي إلى حل لمشكلتي.

آمل أن يكون هذا واحد يساعد على أي شخص!

3
Hiren Gohel

كانت لدينا نفس المشكلة كجزء من مشكلة أكبر. الحل المقترح لل

define('FS_METHOD', 'direct');

يخفي تلك النافذة ولكن بعد ذلك ما زلنا نواجه مشكلات في تحميل السمات والترقيات وما إلى ذلك. إنه مرتبط بالأذونات ، ولكن في حالتنا ، قمنا بإصلاح المشكلة من خلال الانتقال من php OS vendor mod_php إلى بائع نظام التشغيل الأكثر أمانًا php OS FastCGI الوضعية .

3
malta

أسهل طريقة لحل هذه المشكلة هي إضافة معلومات FTP التالية إلى wp-config.php

define('FS_METHOD', 'direct');
define('FTP_BASE', '/usr/home/username/public_html/my-site.example.com/wordpress/');
define('FTP_CONTENT_DIR', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/');
define('FTP_PLUGIN_DIR ', '/usr/home/username/public_html/my-site.example.com/wordpress/wp-content/plugins/');

FTP_BASE هو المسار الكامل إلى المجلد "الأساسي" (ABSPATH) الخاص بتثبيت WordPress FTP_CONTENT_DIR هو المسار الكامل إلى مجلد wp-content لتثبيت WordPress. FTP_PLUGIN_DIR هو المسار الكامل إلى مجلد الإضافات لتثبيت WordPress.

2
Purvik Dhorajiya

كما ذكر نيلز ، يحدث هذا لأن مستخدم عملية الخادم لا يمكنه الكتابة إلى مجلد Wordpress.

ولكن هذا هو الشيء الذي لا تفسره الكثير من المقالات. إنه مالك عملية php ، وليس عملية nginx. إذا حاولت تغيير مالك nginx ، فلن يحل هذا.

لحلها ، حاول تشغيل ps aux لمعرفة المستخدم الذي يملك عملية php-fpm. ثم تحقق من أن المستخدم هو نفس مستخدم مالك مجلد Wordpress ، أو يمكنه على الأقل الكتابة إليه. إذا لم يتمكن المستخدم من الكتابة إليه ، فستحتاج إلى تغيير أذونات و/أو ملكية المجلد ؛ أو ضع المستخدمين (مالك الخادم ومالك مجلد WordPress) في مجموعة مشتركة يمكنها الكتابة إلى المجلد ؛ أو تغيير خاصية "المستخدم" php.ini إلى مستخدم يمكنه الكتابة إلى المجلد.

1
mahemoff

كنت أواجه نفس المشكلة! لقد أضفت الكود أدناه في ملف wp-config.php (في أي سطر) وهو يعمل الآن!

define('FS_METHOD', 'direct');
1
erovere

هناك الكثير من الإجابات المتشابهة على هذا السؤال ، لكن لا أحد منها يتطرق بالكامل إلى السبب الجذري. سيباستيان شميد تعليق على المشاركة الأصلية يمسها ولكن ليس بشكل كامل. ها هي لقطة لي اعتبارًا من 2018-11-06:

السبب الجذري

عند محاولة تحميل مكون إضافي من خلال واجهة مسؤول WordPress ، سيقوم WordPress بإجراء مكالمة إلى وظيفة تسمى "get_filesystem_method ()" (ref: /wp-admin/includes/file.php:1549 ). سيحاول هذا الروتين كتابة ملف إلى الموقع المعني (في هذه الحالة دليل البرنامج المساعد). بالطبع يمكن أن تفشل هنا على الفور إذا لم يتم إعداد أذونات الملفات بشكل صحيح للسماح لمستخدم WordPress (اعتقد هوية المستخدم التي تنفذ ملف php) بكتابة الملف إلى الموقع المعني.

إذا كان يمكن إنشاء الملف ، فستكتشف هذه الوظيفة بعد ذلك مالك الملف الخاص بالملف المؤقت ، إلى جانب مالك الملف لملف الوظيفة الحالي (المرجع: /wp-admin/includes/file.php:1572 ) و يقارن اثنين. إذا كانت تتطابق مع ذلك ، وفقًا لكلمات WordPress ، "يقوم WordPress بإنشاء ملفات بنفس مالك ملفات WordPress ، وهذا يعني أنه من الآمن تعديل وإنشاء ملفات جديدة عبر PHP" ويتم تحميل المكون الإضافي بنجاح دون مطالبة بيانات اعتماد FTP. إذا لم تتطابق ، فستحصل على مطالبة بيانات اعتماد FTP.

الإصلاحات

  1. تأكد من أن دليل البرنامج المساعد قابل للكتابة بواسطة الهوية التي تدير عملية php الخاصة بك.
  2. تأكد من أن الهوية التي تقوم بتشغيل عملية php هي مالك الملف لأي من:

    أ) جميع ملفات تطبيق WordPress ، أو ...
    ب) على الأقل /wp-admin/includes/file.php الملف

التعليقات النهائية

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

0
Matt Woodward