Osticket: Advertencias sobre Declaración de AssignmentForm y TransferForm en php 7

¿Hay alguna razón por la que no incluirías los cambios en una solicitud de extracción?

lo siento, no tengo un repositorio de git, acabo de editar el archivo en mi sistema Linux con vi ..

De: ntozier [email protected]
Enviado: miércoles 13 de abril de 2016 10:52 a.m.
Para: osTicket / osTicket
Cc: Bill Ritchie
Asunto: Re: [osTicket / osTicket] Advertencias sobre la Declaración de AssignmentForm y TransferForm en php 7 (# 3033)

¿Hay alguna razón por la que no incluirías los cambios en una solicitud de extracción?

Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente o véalo en Gi

Dicen que una imagen vale 1000 palabras.

Al usar osTicket 1.10 RC3 con PHP7, he notado lo mismo.
Esperamos la solución en una versión más reciente.

Vea # 3349 para una solución diferente

Esta advertencia sigue apareciendo en la versión estable v1.10: http://osticket.com/forum/discussion/89095/v1-10-php-7-warning

reconfirmado hoy: en mi sitio de prueba 1.10 que ejecuta IIS 8.5 y PHP 7.0.14 recientemente actualizado.

El mismo problema en PHP 7.1, así que tengo que degradar a la versión que no es PHP 7 porque OsTicket tiene problemas. Aòso no se puede iniciar sesión en el mensaje del área del operador de administración: Token CSRF valido richiesto

Este problema aún persiste en la versión estable 1.10. La solución mencionada por @ martin-rueegg ayudó.

También estoy experimentando este problema en la versión estable actual de osTicket 1.10. Evita que los cuadros de diálogo Transferir y Asignar se muestren como algo que no sea un cuadrado blanco, y también evita que api/cron.php revise el correo electrónico. Cuando ejecuto cron.php , produce estos mensajes de error:

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

Aquí está la información del servidor del Panel de administración:

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

El servidor ejecuta Ubuntu 16.04.2 LTS y está completamente actualizado.

Las modificaciones presentadas en la solicitud de extracción # 3349 resolvieron el problema.

@ peterson-dane ¿Puede compartir su solución?

Tengo el mismo problema con casi la misma configuración que tú.

@PrajapatiChirag En el archivo include / class.forms.php , cambie:
function render($options) {
a
function render($staff = true, $title = false, $options = Array()) {

Debería haber tres apariciones.

@solsticesurfer , Gracias, también solucionó mi problema en debian Stretch (9.2).

Que está sucediendo aquí ? Yo también tengo este error, pero los primeros comentarios al respecto tienen 1 año y medio.

osTicket Core, v1.10.1
Última versión estable, publicada el 14 de septiembre de 2017

Eso es lo que instalé. ¿Cómo es posible que los errores no se solucionen después de un año y medio? Especialmente porque la solución es simple y alguien más ya escribió la solución aquí ...

Como dijiste: "Última versión estable, publicada el 14 de septiembre de 2017"

"Arreglar" publicado en:

Gracias por hacerlo, así que no tuve que dejar este hilo para responder la pregunta.

@ntozier

Esa corrección ya se publicó en 2016. Primeros comentarios de hace 1 año y medio sobre este error. Encontré una solución escrita en septiembre de 2016 en https://github.com/osTicket/osTicket/pull/3349/commits/bde15e2acec29a26c73918ae17aa0774fb5048c4

"Última versión estable, publicada el 14 de septiembre de 2017"

1 año y medio después de que se encontró el error y 1 año después de que se publicó una solución, la "Versión estable" todavía contiene el error.

Y no es un error difícil de encontrar. osTicket en PHP 7 (el estándar hoy en día) simplemente no funciona sin esta solución.

Quizás hubiera sido mejor dejar el hilo para responder a la pregunta.

En pocas palabras, no ha habido un nuevo lanzamiento. 1.10 entonces, 1.10.1 (actualización de seguridad) ahora. 1.11 aún no se ha publicado.

No hay garantía de que la corrección en este hilo sea la que se utilizará cuando salga 1.11 y es poco probable que lo haga, ya que hay varias correcciones solo en este hilo y aún no se ha fusionado.

@ntozier

Con cada respuesta tuya, me preocupo más. Y esto también se trata de actitud.

PHP 7 es el estándar ahora.

Hay un error, visto hace 1 año y medio por primera vez. Impide que os Ticket funcione en PHP 7.

¿Y después de 1 año y medio todavía no está arreglado?

Por eso pregunté en mi primer post "¿Qué está pasando aquí?"

¿Está bien invertir tiempo ahora para instalar este programa, ponerlo en uso, etc.? ¿Está bien aconsejar a los clientes que utilicen esto?

PHP 7 es el estándar ahora.

Esta afirmación es completamente subjetiva. La gente que conozco todavía prefiere PHP 5.6 sobre PHP 7 ...

Hay un error, visto hace 1 año y medio por primera vez. Impide que os Ticket funcione en PHP 7.

No impide que osTicket funcione para _todos_, ya que conozco personas que lo tienen funcionando bien con PHP 7 en su entorno de producción.

¿Y después de 1 año y medio todavía no está arreglado?

Como dijo @ntozier , hay varias correcciones para este problema en este hilo y lleva tiempo

¿Está bien invertir tiempo ahora para instalar este programa, ponerlo en uso, etc.? ¿Está bien aconsejar a los clientes que utilicen esto?

¡Por supuesto que está bien! Si está tan preocupado o si su PHP 7 compilado no puede manejar v1.10.1, simplemente cambie a PHP 5.6 hasta que sea totalmente compatible. 👍

@JediKev

La gente que conozco todavía prefiere PHP 5.6 sobre PHP 7 ...

También conozco gente que monta a caballo. El soporte para PHP 5.6 finalizó en enero, las actualizaciones de seguridad finalizarán el próximo año.

Apliqué los parches, todo parece funcionar ahora. Pero me preocupa :)

No debes preocuparte. Las cosas están mejorando mucho. Los últimos dos años no fueron fáciles para los usuarios de osticket (y creo que especialmente para la gente de osticket). Uno de los desarrolladores principales (greezybacon, un codificador muy amable, siempre servicial y hábil) había dejado el proyecto y tomó algún tiempo encontrar nuevos desarrolladores que pudieran apoyar bien el proyecto y llenar el gran vacío que había dejado. Esto había ralentizado el desarrollo durante algún tiempo. Pero ves en github cuando miras el panorama general que la velocidad de desarrollo crece. Y se avecinan grandes cambios (por ejemplo, renovación completa de la API, función de colas personalizadas-> disponible como alfa).

También nuevos miembros hábiles de la comunidad como clonemeagain https://github.com/clonemeagain o Micke1101 https://github.com/Micke1101 han contribuido con muchas cosas interesantes para la comunidad con sus complementos. También están ayudando a muchos usuarios en el foro con sus buenos conocimientos. ntozier, el moderador del foro, había ayudado (y está ayudando) a mucha gente en todos los años. Pero la gente no facilita su ayuda. No leen las pautas, olvidan información importante, a veces no pueden comunicarse bien o son bastante descorteses.

No es fácil ver esto si solo se enfoca en pequeños detalles como un informe de un solo problema. Hay tantos informes de problemas. Muchos de ellos son antiguos, están mal escritos, están duplicados, etc. Es difícil hacer un seguimiento de las cosas en esta jungla.

Mucha gente tiene muchos deseos y no tanta gente está ayudando al proyecto. La mayoría de ellos solo ven su punto de vista y no están interesados ​​en ayudar a los demás. Pero esto hace que sea difícil para un equipo pequeño lograr todos los deseos en el tiempo esperado. ¡No conozco ningún proyecto de mesa de ayuda de código abierto que sea similar y en el que haya tanta gente buena trabajando junta!

Solo mis dos centavos ;-)

Si algo suena raro, entonces esta es mi excusa:
No soy un hablante nativo de inglés y principalmente uso herramientas de traducción de aprendizaje profundo como esta https://www.deepl.com/translator . Saludos desde Colonia.

Cuando hago los cambios señalados por solsticesurfer el 3 de octubre, la ventana emergente Assign se convierte en una barra / ventana blanca en blanco. Ver adjunto.

Debian Buster x64
4.13.13-1

@jonshado ¿Trabajaron antes? Si es así, diría que no lo hizo correctamente. Ejecuto este parche en mi sistema de producción y no tengo su resultado. Si no, entonces tiene un problema de AJAX que no tiene nada que ver con este parche.

@ntozier
Interesante. He revertido por ahora, ya que verifiqué dos veces y reemplacé correctamente las líneas según la publicación anterior que muestra la diferencia. He incluido los archivos aquí.

Salimos en vivo el viernes, por lo que muchos de estos elementos solo están apareciendo ahora, ya que mi equipo analiza el sistema.

No tengo ningún otro problema con el sistema que conozca funcionalmente. Sin embargo, al mirar la información de mi sistema, no creo que haya configurado cgi.fix_pathinfo en 1, aunque lo hice en php.ini.

He incluido información del sistema, php.ini y forms.php que he estado intentando editar. Todavía estoy investigando la razón por la que ost no reconoce los cambios de php.ini.

información del servidor

osTicket Version | v1.10.1 (9ae093d): actualizado
Software de servidor web | Apache / 2.4.29 (Debian)
Versión de MySQL | 10.1.29
Versión PHP | 7.0.25-1

gdlib | Se utiliza para la manipulación de imágenes y la impresión de PDF.
imap | Se utiliza para recuperar correo electrónico
xml | API XML
xml-dom | Utilizado para el procesamiento de correo electrónico HTML
json | Mejora el rendimiento creando y procesando JSON
mbstring | Muy recomendado para contenido en idiomas no europeos occidentales
phar | Muy recomendado para complementos y paquetes de idiomas
intl | Muy recomendado para contenido en idiomas no europeos occidentales
fileinfo | Se usa para detectar tipos de archivos para cargas
APCu | Mejora el rendimiento general
Zend Opcache | Mejora el rendimiento general

cgi.fix_pathinfo |
date.timezone | America / New_York

Esquema | osticket_db (localhost)
Espacio utilizado | 5,14 MiB
Espacio para archivos adjuntos | 0,00 MiB
Zona horaria | EST (interpretado como America / New_York)

shared.zip

después de realizar cambios en php.ini, debe reiniciar Apache. ¿Hiciste eso?

@ntozier Sí, lo tengo. También he reiniciado el sistema por completo. Parece, según otras publicaciones de la comunidad, que debido a que la instalación de php se ejecuta como un módulo apache, la advertencia en la sección de información no desaparecerá, por lo que no creo que eso tenga un impacto.

El resto de la instalación parece funcional. Mi preocupación es que estos errores impiden que el trabajo cron se ejecute correctamente. No hay nada en mi registro cron. Voy a desactivar la búsqueda a través del panel de administración (por lo que solo debería ser cron comprobando el correo) y, con suerte, veré que se ingieren los correos electrónicos.

El mismo problema aqui. No pude averiguar qué es. Pero así es como puede volver a trabajar con el sistema.

/var/www/html/include/class.forms. php: 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 para mí, la transferencia de departamento también tuvo el mismo problema que la ventana del agente en blanco. Parece que usó el mismo código que la ventana del agente, así que apliqué su corrección a la sección de transferencia y funcionó.

¡Solo espero que esto no rompa nada más!

incluir / class.forms. php: 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;

}

¿Alguna solución final para estas advertencias? ¿O puede ser que alguien pueda compartir un parche de trabajo?

@iprok

El problema debe solucionarse con esta solicitud de extracción, pero solo para la serie 1.11.x . Puedes probarlo en 1.10.x pero _ podría_ romper algo (no lo sé, no lo he probado).

Salud.