Grav-plugin-admin: لماذا لا يمكن استخدام المكون الإضافي admin مع الخادم المدمج؟

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

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

هل هناك المزيد من الشرح المتعمق لما هي مشكلة خادم cli؟

المشكلة هي أنها لا تدعم وجود معلمات URL مثل site.com/param1:something والتي يتم استخدامها في المسؤول ، لقد وجدت مرجع هذه المشكلة https://github.com/getgrav/grav-plugin-admin/issues/167

مرحبًا ، أدرك أن هذه مشكلة مغلقة ، لكن جولتي الأولى لمدة 5 دقائق في getgrav كانت تسير على ما يرام حتى حاولت استخدام وحدة الإدارة هذه (الاختبار عبر خادم الويب المدمج). لقد أعطاني عدم العمل في تلك البيئة المتبقية وقفة لإلقاء نظرة أخرى عليها. في العادة لن أعود إلى المشروع ، لكنه بدا واعدًا في أول 5 دقائق حتى المسؤول.

ضع في اعتبارك هذا تصويتي الذي آمل أن تتمكن من تحديد أولوياته لجعله يعمل على خادم الويب المدمج. :)

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

هل أنت متأكد من أنها مشكلة أساسية في خادم الويب php؟

إذا قمت بإنشاء index.php بالمحتوى التالي:

<?php
echo $_SERVER['REQUEST_URI'];

ثم ابدأ تشغيل خادم عبر php -S localhost:9000 ثم قم بزيارة http://localhost:9000/foo:bar/hello:world

أحصل على /foo:bar/hello:world كناتج وهو ما أتوقعه.

(PHP 5.5.36 (CLI) (تم الإنشاء: 29 مايو 2016 01:15:42))

حسنًا ، أي إصدار من PHP؟ أحتاج إلى الاختبار مرة أخرى على ما أعتقد.

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

راجع الأمثلة الثلاثة الأخيرة: http://php.net/manual/en/features.commandline.webserver.php

آه نعم (السبب يعود إلي الآن) ، إنه هذا الخطأ: https://bugs.php.net/bug.php ؟

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

لا يرى فريق PHP أي سبب لإصلاح ذلك لأن خادم الويب المدمج مخصص للتطوير المحلي الخفيف فقط.

راجع للشغل جرب هذا:

http://localhost:8888/admin/pages/home.json/task:listmedia/nonce:jlk32393jklklj3

تقوم بإرجاع صفحة ثابتة 404 غير موجودة ، ولا تتم معالجة PHP حتى.

لا يزال يعمل إذا تم تشغيل الخادم عبر
php -S localhost:9000 index.php
بدلا من مجرد
php -S localhost:9000

حسنًا ، لدي المشرف يعمل من خلال القيام بذلك:

php -S localhost:9000 index.php

في index.php .. بعد إضافة namespace Grav; :

// Special router logic for built-in PHP webserver
if (php_sapi_name() == 'cli-server') {
    if (preg_match('/\.(?:png|jpe?g|gif|js|css|svg|otf|woff|woff2|ttf|eot)(\?|$|\/)/', $_SERVER["REQUEST_URI"])) {
        return false;    // serve the requested resource as-is.
    }
}

ثم قم بالتعليق على هذا الجزء في الملف user/plugins/admin/admin.php :

//            if (php_sapi_name() == 'cli-server') {
//                throw new \RuntimeException('The Admin Plugin cannot run on the PHP built-in webserver. It needs Apache, Nginx or another full-featured web server.',
//                    500);
//            }

مذكرة قانونية:

الآن هذا _ يبدو أنه يعمل من أجلي .. JSON الذي أوقفه دائمًا أصبح قادرًا الآن على المعالجة. القلق الذي يساورني هو هذا المطلب لإجبار بعض عناوين URL بقائمة مضمنة لأنواع الملفات ليتم عرضها بشكل ثابت.

سيؤدي هذا بالتأكيد إلى مشكلات مع الوسائط التي يتم تقديمها عبر طرق Grav. هذه ميزة قوية في Grav ولن تعمل مع هذا "الحل البديل". ستعمل خوادم الويب التقليدية الملفات بشكل ثابت إذا تم العثور على المسار في webroot ، وإلا فإنه يعود إلى PHP. هذه الوظيفة مهمة لأجزاء من كيفية قدرة Grav على تقديم ملفات الوسائط عبر مسارات Grav (وليس فقط المسارات المادية).

لا يمكن استبدال الاختيار preg_match بفحص file_exist؟ ثم يجب أن يعمل بشكل تناظري مع سلوك .htaccess.

جربها؟

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

أثناء تواجدك فيه ، فإن وجود قائمة أنواع الملفات هذه التي تم إنشاؤها من system.yaml و media.yaml سيجعلها أكثر موثوقية أيضًا.

يبدو أن preg_match يعمل بالنسبة لي. لا يعد file_exists انخفاضًا مثاليًا في الاستبدال لأن $_SERVER['REQUEST_URI'] سيتضمن معامِلات الاستعلام ، والتي قد تشك في أنها ستتخلص من فحص file_exists لبعض طلبات الأصول الثابتة (يجب تجريدها قبل file_exists check. على سبيل المثال:

/user/plugins/admin/themes/grav/fonts/fontawesome-webfont.woff2?v=4.5.0
/user/plugins/markdown-notices/assets/notices.css?555c60a537

ralphschindler يمكن للمرء قطع المسار بعد أول ? . سأحاول ذلك في الأيام القادمة.