Osticket: تحذيرات حول نموذج إعلان التخصيص ونموذج التحويل في php 7

هل هناك سبب لعدم تضمين التغييرات في طلب السحب؟

آسف ليس لدي git repo ، لقد قمت للتو بتحرير الملف على نظام Linux الخاص بي باستخدام vi ..

من: ntozier [email protected]
تاريخ الإرسال: الأربعاء ، 13 أبريل 2016 ، الساعة 10:52 صباحًا
إلى: osTicket / osTicket
نسخة إلى: بيل ريتشي
الموضوع: Re: [osTicket / osTicket] تحذيرات بشأن إعلان التنازل ونموذج التحويل في php 7 (# 3033)

هل هناك سبب لعدم تضمين التغييرات في طلب السحب؟

أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/osTicket/osTicket/issues/3033#issuecomment -209487139

يقولون أن الصورة تساوي 1000 كلمة.

أثناء استخدام osTicket 1.10 RC3 مع PHP7 ، لاحظت نفس الشيء.
نتطلع إلى الإصلاح في إصدار أحدث.

راجع # 3349 لإصلاح مختلف

لا يزال هذا التحذير يحدث في الإصدار المستقر v1.10: http://osticket.com/forum/discussion/89095/v1-10-php-7-warning

أعيد التأكيد اليوم: على موقع الاختبار 1.10 الخاص بي ، يتم تشغيل IIS 8.5 و PHP 7.0.14 الذي تمت ترقيته حديثًا.

نفس المشكلة على PHP 7.1 لذا يجب علي الرجوع إلى إصدار ليس PHP 7 لأن OsTicket به مشكلات. يتعذر أيضًا تسجيل الدخول في رسالة منطقة مشغل المسؤول: Token CSRF valido richiesto

لا تزال هذه المشكلة قائمة في الإصدار المستقر 1.10. الإصلاح الذي ذكره @ martin-rueegg ساعد.

أواجه هذه المشكلة أيضًا في إصدار OSTicket 1.10 المستقر الحالي. يمنع عرض مربعات الحوار "النقل والتعيين" على أنها أي شيء بخلاف المربع الأبيض ، كما أنه يمنع api/cron.php من فحص البريد الإلكتروني. عندما أقوم بتشغيل cron.php ، تظهر رسائل الخطأ هذه:

PHP Warning:  Declaration of AssignmentForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /var/www/helpdesk/include/class.forms.php on line 4150
PHP Warning:  Declaration of TransferForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /var/www/helpdesk/include/class.forms.php on line 4270

إليك معلومات الخادم من لوحة المسؤول:

osTicket Version     v1.10 (901e5ea) —  Up to date
Web Server Software  Apache/2.4.18 (Ubuntu)
MySQL Version        5.7.17
PHP Version          7.0.15-0ubuntu0.16.04.4

يقوم الخادم بتشغيل Ubuntu 16.04.2 LTS ويتم تحديثه بالكامل.

أدت التعديلات المقدمة في طلب السحب # 3349 إلى حل المشكلة بالنسبة لي.

@ peterson-dane هل يمكنك مشاركة الحل الخاص بك؟

لدي نفس المشكلة مع نفس configuraiton تقريبًا لديك.

PrajapatiChirag في الملف include / class.forms.php ، غيِّر:
function render($options) {
ل
function render($staff = true, $title = false, $options = Array()) {

يجب أن يكون هناك ثلاثة تكرارات.

solsticesurfer ، شكرًا ، أصلحت مشكلتي على debian Stretch (9.2) أيضًا.

ماذا يحصل هنا ؟ لدي هذا الخطأ أيضًا ، لكن التعليقات الأولى حوله عمرها عام ونصف؟

osTicket الأساسية ، v1.10.1
أحدث إصدار مستقر ، صدر في 14 سبتمبر 2017

هذا ما قمت بتثبيته. كيف يمكن ألا يتم إصلاح الخلل بعد عام ونصف؟ خاصة وأن الحل بسيط وقد كتب شخص آخر الإصلاح هنا بالفعل ...

كما قلتم: "أحدث إصدار مستقر ، صدر في 14 أيلول (سبتمبر) 2017"

تم نشر "الإصلاح" في:

شكرًا لك على القيام بذلك ، لذا لم أضطر إلى ترك هذا الموضوع للإجابة على السؤال.

تضمين التغريدة

تم نشر هذا الإصلاح بالفعل في عام 2016. أول تعليقات منذ عام ونصف حول هذا الخطأ. لقد وجدت إصلاحًا مكتوبًا في سبتمبر 2016 على https://github.com/osTicket/osTicket/pull/3349/commits/bde15e2acec29a26c73918ae17aa0774fb5048c4

"أحدث إصدار مستقر ، تم إصداره في 14 أيلول (سبتمبر) 2017"

بعد عام ونصف من اكتشاف الخطأ وبعد مرور عام على نشر الحل ، لا يزال "الإصدار المستقر" يحتوي على الخطأ.

وهي ليست حشرة يصعب العثور عليها. osTicket على PHP 7 (المعيار في الوقت الحاضر) ببساطة لا يعمل بدون هذا الإصلاح.

ربما كان من الأفضل ترك الموضوع للإجابة على السؤال.

ببساطة لم يكن هناك إصدار جديد. 1.10 ثم 1.10.1 (تحديث أمني) الآن. 1.11 لم يتم إصدارها بعد.

ليس هناك ما يضمن أن الإصلاح في هذا الموضوع سيكون هو الإصلاح الذي سيتم استخدامه عندما يخرج 1.11 ومن غير المحتمل أن يحدث ذلك نظرًا لوجود إصلاحات متعددة على هذا الموضوع وحده ولم يتم دمجه بعد.

تضمين التغريدة

مع كل رد منك ، أشعر بالقلق أكثر. وهذا أيضًا يتعلق بالموقف.

PHP 7 هو المعيار الآن.

هناك حشرة شوهدت منذ سنة ونصف ولأول مرة. يمنع نظام التشغيل Ticket من العمل على PHP 7.

وبعد سنة ونصف ما زالت غير ثابتة ؟؟؟

لهذا سألت في رسالتي الأولى "ماذا يحدث هنا؟"

هل من المقبول استثمار الوقت الآن لتثبيت هذا البرنامج وتشغيله وما إلى ذلك؟ هل من المقبول أن ننصح العملاء باستخدام هذا؟

PHP 7 هو المعيار الآن.

هذا البيان شخصي تمامًا. الأشخاص الذين أعرفهم ما زالوا يفضلون PHP 5.6 على PHP 7 ...

هناك حشرة شوهدت منذ سنة ونصف ولأول مرة. يمنع نظام التشغيل Ticket من العمل على PHP 7.

إنه لا يمنع osTicket من العمل لكل شخص كما أعرف الأشخاص الذين يعملون بشكل جيد مع PHP 7 في بيئة الإنتاج الخاصة بهم.

وبعد سنة ونصف ما زالت غير ثابتة ؟؟؟

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

هل من المقبول استثمار الوقت الآن لتثبيت هذا البرنامج وتشغيله وما إلى ذلك؟ هل من المقبول أن ننصح العملاء باستخدام هذا؟

بالطبع لا بأس! إذا كنت قلقًا أو إذا كان PHP 7 المترجم لا يمكنه التعامل مع الإصدار 1.10.1 ، فما عليك سوى الرجوع إلى إصدار PHP 5.6 حتى يصبح متوافقًا تمامًا. 👍

تضمين التغريدة

الأشخاص الذين أعرفهم ما زالوا يفضلون PHP 5.6 على PHP 7 ...

أعرف أيضًا أشخاصًا يمتطون الخيول. انتهى دعم PHP 5.6 في يناير ، وستنتهي التحديثات الأمنية العام المقبل.

لقد قمت بتطبيق التصحيحات ، ويبدو أن كل شيء يعمل الآن. لكنها تقلقني :)

لا داعي للقلق. الأمور تتحسن حقاً. لم يكن العامان الماضيان سهلين لمستخدمي osticket (وأعتقد أنه لا سيما بالنسبة للأشخاص الذين يستخدمون osticket). لقد ترك أحد المطورين الرئيسيين (greezybacon ، المبرمج الودود والمفيد والماهر!) المشروع واستغرق الأمر بعض الوقت للعثور على مطورين جدد يمكنهم دعم المشروع جيدًا وسد الفجوة الكبيرة التي تركها. وقد أدى ذلك إلى إبطاء عملية التطوير لبعض الوقت. لكنك ترى على جيثب عندما تنظر إلى الصورة الكبيرة أن سرعة التطوير تنمو. وستأتي تغييرات كبيرة (على سبيل المثال تجديد كامل لواجهة برمجة التطبيقات ، وميزة قوائم الانتظار المخصصة-> متوفرة كـ alpha).

كما ساهم أعضاء المجتمع الماهرون الجدد مثل clonemeagain https://github.com/clonemeagain أو Micke1101 https://github.com/Micke1101 في العديد من الأشياء الرائعة للمجتمع باستخدام المكونات الإضافية الخاصة بهم. كما أنهم يساعدون الكثير من المستخدمين في المنتدى بمعرفتهم الجيدة. ntozier المشرف على المنتدى ساعد (ويساعد) الكثير من الناس في كل السنوات. لكن الناس لا تجعل من السهل مساعدتهم. إنهم لا يقرؤون الإرشادات ، بل ينسون المعلومات المهمة ، وأحيانًا لا يكونون قادرين على التواصل بشكل جيد أو غير مهذبين.

ليس من السهل رؤية هذا إذا كنت تركز فقط على التفاصيل الصغيرة مثل تقرير مشكلة واحد. هناك الكثير من تقارير القضية. العديد منهم قديم وسيء الكتابة ومكرر وما إلى ذلك. من الصعب تتبع الأشياء في هذه الغابة.

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

جمعية البناء الخيرية ؛-)

إذا بدا شيء غريبًا ، فهل هذا هو عذري:
أنا لست متحدثًا أصليًا للغة الإنجليزية ، وأستخدم في الغالب أدوات ترجمة التعلم العميق مثل https://www.deepl.com/translator . تحياتي من كولونيا (نعم ، هذه هي المدينة الكبيرة في ألمانيا التي تضم جميع اللاجئين. معظمهم لطفاء ، لا تصدق رئيسك. إنه منشق).

عندما أقوم بإجراء التغييرات التي لاحظها الانقلاب الشتوي في 3 أكتوبر ، تصبح النافذة المنبثقة تعيين شريط / نافذة بيضاء فارغة. انظر الملف المرفق.

ديبيان باستر x64
4.13.13-1

jonshado هل عملوا من قبل؟ إذا كانت الإجابة بنعم ، فسأقول أنك لم تفعل ذلك بشكل صحيح. أقوم بتشغيل هذا التصحيح على نظام الإنتاج الخاص بي ولا أحصل على النتيجة. إذا كانت الإجابة `` لا '' ، فأنت تواجه مشكلة في AJAX لا علاقة لها بهذا التصحيح.

تضمين التغريدة
مثير للإعجاب. لقد عدت الآن ، حيث قمت بفحص مزدوج وقمت باستبدال الأسطر بشكل صحيح في المنشور السابق الذي يعرض الفرق. لقد قمت بتضمين الملفات هنا.

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

ليس لدي أي مشكلات أخرى مع النظام أعلم بها وظيفيًا. ومع ذلك ، بالنظر إلى معلومات نظامي ، لا أعتقد أنني قمت بضبط cgi.fix_pathinfo على 1 ، على الرغم من أنني فعلت ذلك في ملف php.ini.

لقد قمت بتضمين معلومات النظام و php.ini و Forms.php التي كنت أحاول تحريرها. ما زلت أبحث في سبب عدم إدراك ost لتغييرات php.ini.

معلومات الخادم

إصدار osTicket | الإصدار 1.10.1 (9ae093d) - مُحدَّث
برنامج خادم الويب | Apache / 2.4.29 (Debian)
إصدار MySQL | 10.1.29
إصدار PHP | 7.0.25-1

gdlib | تستخدم لمعالجة الصور وطباعة PDF
imap | تستخدم لجلب البريد الإلكتروني
xml | XML API
xml-dom | تستخدم لمعالجة البريد الإلكتروني بتنسيق HTML
json | يحسن أداء إنشاء ومعالجة JSON
mbstring | موصى به للغاية لمحتوى اللغات غير الأوروبية الغربية
فار | موصى به للغاية للمكونات الإضافية وحزم اللغات
دولي | موصى به للغاية لمحتوى اللغات غير الأوروبية الغربية
fileinfo | تستخدم لاكتشاف أنواع الملفات للتحميلات
APCu | يحسن الأداء العام
Zend Opcache | يحسن الأداء العام

cgi.fix_pathinfo |
date.timezone | أمريكا / نيويورك

المخطط | osticket_db (مضيف محلي)
المساحة المستخدمة | 5.14 ميجابايت
مساحة للمرفقات | 0.00 ميغا بايت
المنطقة الزمنية | EST (تُفسَّر باسم America / New_York)

Shared.zip

بعد إجراء التغييرات على ملف php.ini ، يجب إعادة تشغيل Apache. هل فعلت ذلك؟

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

يبدو أن بقية التثبيت وظيفية. ما يقلقني هو أن هذه الأخطاء تمنع عمل cron من العمل بشكل صحيح. لا يوجد شيء في سجل كرون الخاص بي. سأقوم بإيقاف تشغيل الجلب عبر لوحة الإدارة (لذلك يجب أن يتم فحص cron فقط للبريد) وآمل أن أرى رسائل البريد الإلكتروني يتم استيعابها.

نفس المشكلة هنا. لا يمكن معرفة ما هو عليه. لكن هذه هي الطريقة التي يمكنك بها العمل مع النظام مرة أخرى.

/var/www/html/include/class.forms. فب: 4339

 function render($staff=true, $title=false, $options=array()) {

//        switch(strtolower($options['template'])) {
//        case 'simple':
            $inc = STAFFINC_DIR . 'templates/dynamic-form-simple.tmpl.php';
//            break;
//        default:
//            throw new Exception(sprintf(__('%s: Unknown template style %s'),
//                        'FormUtils', $options['template']));
//        }

        $form = $this;
        include $inc;
    }

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

أتمنى ألا يكسر هذا أي شيء آخر!

تضمين / class.forms. فب: 4462

function render($staff = true, $title = false, $options = Array()) {

//        switch(strtolower($options['template'])) {
//        case 'simple':
            $inc = STAFFINC_DIR . 'templates/dynamic-form-simple.tmpl.php';
//            break;
//        default:
//            throw new Exception(sprintf(__('%s: Unknown template style %s'),
//                        'FormUtils', $options['template']));
//        }

        $form = $this;
        include $inc;

}

أي إصلاح نهائي لهذه التحذيرات؟ أو قد يكون شخص ما يمكن أن يشترك في رقعة العمل؟

تضمين التغريدة

يجب إصلاح المشكلة مع طلب السحب هذا ولكن فقط لسلسلة 1.11.x . نرحب بتجربته على 1.10.x لكنه _might_ يكسر شيئًا (لا أعرف ؛ لم تختبر).

هتافات.