Osticket: Avisos sobre a declaração de AssignmentForm e TransferForm no php 7

Existe algum motivo pelo qual você não incluiu as alterações em uma solicitação pull?

desculpe, eu não tenho um repositório git, acabei de editar o arquivo no meu sistema linux com o vi ..

De: ntozier [email protected]
Enviado: quarta-feira, 13 de abril de 2016 10:52
Para: osTicket / osTicket
Cc: Bill Ritchie
Assunto: Re: [osTicket / osTicket] Avisos sobre a declaração de AssignmentForm e TransferForm no php 7 (# 3033)

Existe algum motivo pelo qual você não incluiu as alterações em uma solicitação pull?

Você está recebendo isto porque é o autor do tópico.
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/osTicket/osTicket/issues/3033#issuecomment -209487139

Dizem que uma imagem vale 1000 palavras.

Ao usar osTicket 1.10 RC3 com PHP7, notei o mesmo.
Ansioso pela correção de uma versão mais recente.

Veja # 3349 para uma correção diferente

Este aviso ainda está acontecendo na versão estável v1.10: http://osticket.com/forum/discussion/89095/v1-10-php-7-warning

reconfirmado hoje: no meu site de teste 1.10 executando o IIS 8.5 e o PHP 7.0.14 recém-atualizado.

O mesmo problema no PHP 7.1, então tenho que fazer o downgrade para uma versão diferente do PHP 7 porque OsTicket tem problemas. Também não foi possível fazer login na mensagem da área do operador administrativo: Token CSRF valido richiesto

Esse problema ainda persiste na versão estável 1.10. A correção mencionada por @martin-rueegg ajudou.

Também estou tendo esse problema na versão estável atual do osTicket 1.10. Impede que as caixas de diálogo Transferir e Atribuir sejam processadas como algo diferente de um quadrado branco e também evita que api/cron.php verifique o e-mail. Quando executo cron.php , ele produz as seguintes mensagens de erro:

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

Estas são as informações do servidor do painel de administração:

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

O servidor está executando o Ubuntu 16.04.2 LTS e está totalmente atualizado.

As modificações apresentadas na solicitação pull # 3349 resolveram o problema para mim.

@ peterson-dane Você pode compartilhar sua solução?

Tenho o mesmo problema com quase a mesma configuração que você.

@PrajapatiChirag No arquivo include / class.forms.php , altere:
function render($options) {
para
function render($staff = true, $title = false, $options = Array()) {

Deve haver três ocorrências.

@solsticesurfer , Obrigado, consertou meu problema no debian Stretch (9.2) também.

O que esta acontecendo aqui ? Eu também tenho esse bug, mas os primeiros comentários sobre ele são de 1 ano e meio?

osTicket Core, v1.10.1
Última versão estável, lançada em 14 de setembro de 2017

Isso é o que instalei. Como é possível que os bugs não sejam corrigidos após 1 ano e meio? Principalmente porque a solução é simples e outra pessoa já escreveu a correção aqui ...

Como você disse: "Última versão estável, lançada em 14 de setembro de 2017"

"Fix" postado em:

Obrigado por fazer com que eu não tivesse que deixar este tópico para responder à pergunta.

@ntozier

Essa correção foi postada já em 2016. Primeiros comentários de 1 ano e meio atrás sobre esse bug. Encontrei uma correção escrita em setembro de 2016 em https://github.com/osTicket/osTicket/pull/3349/commits/bde15e2acec29a26c73918ae17aa0774fb5048c4

"Última versão estável, lançada em 14 de setembro de 2017"

1 ano e meio depois que o bug foi encontrado e 1 ano depois que uma solução foi postada, o "Lançamento estável" ainda contém o bug.

E não é um bug difícil de encontrar. osTicket no PHP 7 (o padrão hoje em dia) simplesmente não funciona sem essa correção.

Talvez tivesse sido melhor deixar o tópico para responder à pergunta.

Simplificando, não houve um novo lançamento. 1.10 então, 1.10.1 (atualização de segurança) agora. 1.11 ainda não foi lançado.

Não há garantia de que a correção neste segmento será a única a ser usada quando o 1.11 for lançado e é improvável que o seja, pois há várias correções neste segmento sozinho e ele ainda não foi mesclado.

@ntozier

A cada resposta sua, fico mais preocupado. E isso também tem a ver com atitude.

PHP 7 é o padrão agora.

Existe um bug, visto 1 ano e meio atrás pela primeira vez. Impede que o OS Ticket funcione no PHP 7.

E depois de 1 ano e meio ainda não está consertado ???

É por isso que perguntei no meu primeiro post "O que está acontecendo aqui?"

Posso investir tempo agora para instalar este programa, colocá-lo em uso, etc? Posso aconselhar os clientes a usar isso?

PHP 7 é o padrão agora.

Esta afirmação é totalmente subjetiva. Pessoas que conheço ainda preferem PHP 5.6 em vez de PHP 7 ...

Existe um bug, visto 1 ano e meio atrás pela primeira vez. Impede que o OS Ticket funcione no PHP 7.

Isso não impede que o osTicket funcione para _todo mundo_, pois conheço pessoas que o têm funcionando perfeitamente com o PHP 7 em seu ambiente de produção.

E depois de 1 ano e meio ainda não está consertado ???

Como @ntozier afirmou, há várias correções para esse problema neste tópico e leva tempo para olhar através delas e encontrar a melhor que não quebra nada e certifique-se de que se encaixa em nosso estilo de codificação. Além disso, este não é o único problema aqui em nossa página do Github ... há 1.177. Tenho que dar uma olhada em todos eles.

Posso investir tempo agora para instalar este programa, colocá-lo em uso, etc? Posso aconselhar os clientes a usar isso?

Claro que está tudo bem! Se você está preocupado ou se o seu PHP 7 compilado não suporta a v1.10.1, simplesmente faça downgrade para o PHP 5.6 até que seja totalmente compatível. 👍

@JediKev

Pessoas que conheço ainda preferem PHP 5.6 em vez de PHP 7 ...

Também conheço pessoas que andam a cavalo. O suporte para PHP 5.6 foi finalizado em janeiro, as atualizações de segurança terminarão no próximo ano.

Apliquei os patches, tudo parece funcionar agora. Mas isso me preocupa :)

Você não deve se preocupar. As coisas estão ficando realmente melhores. Os últimos dois anos não foram fáceis para os usuários do osticket (e acho que especialmente para o pessoal do osticket). Um dos principais desenvolvedores (greezybacon, um programador muito amigável, sempre útil e habilidoso!) Havia deixado o projeto e demorou algum tempo para encontrar novos desenvolvedores que pudessem apoiar bem o projeto e preencher a grande lacuna que ele havia deixado. Isso retardou o desenvolvimento por algum tempo. Mas você vê no github quando olha o quadro geral que a velocidade de desenvolvimento cresce. E grandes mudanças estão chegando (por exemplo, renovação completa da API, recurso de filas personalizadas-> disponível como alfa).

Além disso, novos membros habilidosos da comunidade, como clonemeagain https://github.com/clonemeagain ou Micke1101 https://github.com/Micke1101 , contribuíram com muitas coisas legais para a comunidade com seus plug-ins. Eles também estão ajudando muitos usuários no fórum com seus bons conhecimentos. ntozier o moderador do fórum ajudou (e está ajudando) muitas pessoas em todos os anos. Mas as pessoas não facilitam ajudá-las. Eles não lêem as orientações, esquecem informações importantes, às vezes não conseguem se comunicar bem ou são muito indelicados.

Não é fácil ver isso se você estiver focado apenas em pequenos detalhes, como um único relatório de problema. Existem tantos relatórios de problemas. Muitos deles são antigos, mal escritos, duplicados e assim por diante. É difícil acompanhar as coisas nesta selva.

Muitas pessoas têm muitos desejos e nem tantas pessoas estão ajudando o projeto. A maioria deles vê apenas seu ponto de vista e não está interessada em ajudar os outros. Mas isso torna difícil para uma equipe tão pequena realizar todos os desejos em um cronograma que eles estão esperando. Não conheço nenhum projeto de help desk de código aberto que seja igualmente poderoso e no qual tantas pessoas boas estejam trabalhando juntas!

Apenas meus dois centavos ;-)

Se algo parece estranho, esta é a minha desculpa:
Não sou um falante nativo de inglês e, principalmente, estou usando ferramentas de tradução de aprendizagem profunda como esta https://www.deepl.com/translator . Saudações de Colônia (Sim, essa é a grande cidade da Alemanha com todos os refugiados. A maioria deles são legais, não acredite no seu presidente. Ele é um divisor).

Quando eu faço as alterações observadas por solsticesurfer em 3 de outubro, o pop-up Atribuir se torna uma barra / janela em branco. Ver anexo.

Debian Buster x64
4.13.13-1

@jonshado Já funcionaram antes? Se sim, então eu diria que você não fez isso corretamente. Eu executo este patch no meu sistema de produção e não tenho o seu resultado. Se não, você está tendo um problema de AJAX que não tem nada a ver com este patch.

@ntozier
Interessante. Eu reverti para agora, como eu verifiquei duas vezes e substituí corretamente as linhas do post anterior mostrando a diferença. Eu incluí os arquivos aqui.

Entramos ao vivo na sexta-feira, então muitos desses itens estão chegando agora, enquanto minha equipe analisa o sistema.

Não tenho nenhum outro problema funcional com o sistema que conheça. No entanto, olhando para as informações do meu sistema, não acredito que eu tenha definido o cgi.fix_pathinfo como 1, embora o tenha feito no php.ini.

Incluí as informações do sistema, o php.ini e o forms.php que estou tentando editar. Ainda estou procurando a razão pela qual ost não reconhece as alterações do php.ini.

informação do servidor

osTicket Version | v1.10.1 (9ae093d) - atualizado
Software de servidor web | Apache / 2.4.29 (Debian)
Versão MySQL | 10.1.29
Versão PHP | 7.0.25-1

gdlib | Usado para manipulação de imagens e impressão de PDF
imap | Usado para obtenção de e-mail
xml | API XML
xml-dom | Usado para processamento de e-mail HTML
json | Melhora o desempenho ao criar e processar JSON
mbstring | Altamente recomendado para conteúdo em idiomas não europeus ocidentais
phar | Altamente recomendado para plug-ins e pacotes de idiomas
intl | Altamente recomendado para conteúdo em idiomas não europeus ocidentais
fileinfo | Usado para detectar tipos de arquivo para uploads
APCu | Melhora o desempenho geral
Zend Opcache | Melhora o desempenho geral

cgi.fix_pathinfo |
date.timezone | America / New_York

Schema | osticket_db (localhost)
Espaço Usado | 5,14 MiB
Espaço para anexos | 0,00 MiB
Fuso horário | EST (interpretado como América / New_York)

shared.zip

depois de fazer alterações no php.ini, você precisa reiniciar o Apache. Você fez isso?

@ntozier Sim, tenho. Eu também reiniciei o sistema completamente. Parece, com base em outra postagem da comunidade, que, como a instalação do php está sendo executada como um módulo apache, o aviso na seção de informações não irá embora, então não acho que isso esteja tendo um impacto.

O resto da instalação parece funcional. Minha preocupação é que esses erros estão impedindo o cron job de funcionar corretamente. Não há nada em meu log do cron. Vou desligar a busca através do painel de administração (portanto, deve ser apenas checando o cron por e-mail) e espero ver e-mails sendo ingeridos.

Mesmo problema aqui. Não consegui descobrir o que é. Mas é assim que você pode trabalhar com o sistema novamente.

/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 mim, a transferência de departamento também teve o mesmo problema que a janela do agente em branco. Parece que usou o mesmo código da janela do agente, então apliquei sua correção à seção de transferência e funcionou.

Só espero que isso não estrague mais nada!

include / 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;

}

Alguma correção final para esses avisos? Ou alguém pode compartilhar um patch de trabalho?

@iprok

O problema deve ser corrigido com esta solicitação pull, mas apenas para a série 1.11.x . Sinta-se à vontade para experimentá-lo em 1.10.x mas _pode_ quebrar algo (não sei; não testei).

Saúde.