Warnings about of Declaration of AssignmentForm and TransferForm in php 7

[wnoisephx]

Using the latest development version on php 7 gives the following to warnings:
Warning: Declaration of AssignmentForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /opt/osticket/osTicket-develop/include/class.forms.php on line 4144

Warning: Declaration of TransferForm::render($options) should be compatible with Form::render($staff = true, $title = false, $options = Array) in /opt/osticket/osTicket-develop/include/class.forms.php on line 4264

These warnings interfere with the pop up dialog boxes as well as throw the spacing on the templates off

The attached patch diff fixes these warnings

class.forms.php.zip

[ntozier]

Is there some reason why you wouldn't included the changes in a pull request?

[wnoisephx]

sorry I don't have a git repo, I just edited the file on my linux system with vi..

---

From: ntozier notifications@github.com
Sent: Wednesday, April 13, 2016 10:52 AM
To: osTicket/osTicket
Cc: Bill Ritchie
Subject: Re: [osTicket/osTicket] Warnings about of Declaration of AssignmentForm and TransferForm in php 7 (#3033)

Is there some reason why you wouldn't included the changes in a pull request?

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/3033#issuecomment-209487139

[ntozier]

They say an image is worth 1000 words.

[ArthurBorsboom]

While using osTicket 1.10 RC3 with PHP7 I have noticed the same.
Looking forward for the fix in a newer version.

[martin-rueegg]

See #3349 for a different fix

[JMCA2]

This warning is still happening in the v1.10 stable release: http://osticket.com/forum/discussion/89095/v1-10-php-7-warning

[ntozier]

reconfirmed today: on my 1.10 test site running IIS 8.5 and newly upgraded PHP 7.0.14.

[PeopleInside]

Same issue on PHP 7.1 so I have to downgrade to not PHP 7 version because OsTicket has issues. Aòso unable to log in in admin operator area message: Token CSRF valido richiesto

[scroom]

This issue still persists in the 1.10 stable release. The fix mentioned by @martin-rueegg helped.

[peterson-dane]

I'm also experiencing this issue on the current osTicket 1.10 stable release. It prevents the Transfer and Assign dialog boxes from rendering as anything other than a white square, and it also prevents api/cron.php from checking email. When I run cron.php, it yields these error messages:

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

Here's the server information from the Admin Panel:

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

The server is running Ubuntu 16.04.2 LTS and is fully updated.

The modifications presented in the #3349 pull request resolved the issue for me.

[PrajapatiChirag]

@peterson-dane Can you share your solution?

I have same issue with almost same configuraiton as you have.

[solsticesurfer]

@PrajapatiChirag In the file include/class.forms.php, change:
function render($options) {
to
function render($staff = true, $title = false, $options = Array()) {

There should be three occurrences.

[thctlo]

@solsticesurfer , Thanks, fixed my problem on debian Stretch (9.2) also.

[dimitrivisser]

What is happening here ? I have this bug too, but first comments about it are 1 1/2 year old ?

osTicket Core, v1.10.1
Latest Stable Release, Released September, 14th, 2017

That is what I installed. How is it possible that bugs are not fixed after 1 1/2 year ? Especially because the solution is simple and someone else wrote the fix here already...

[ntozier]

As you said: "Latest Stable Release, Released September, 14th, 2017"

"Fix" posted on:

Thanks for making it so I didn't have to leave this thread to answer the question,.

[dimitrivisser]

@ntozier

That fix was posted already in 2016. First comments from 1 1/2 year ago about this bug. I found a fix written on sept 2016 on bde15e2

"Latest Stable Release, Released September, 14th, 2017"

1 1/2 year after the bug was found and 1 year after a solution was posted the "Stable Release" still contains the bug.

And it is not a bug which is difficult to find. osTicket on PHP 7 (the standard nowadays) simply doesn't work without this fix.

Maybe leaving the thread to answer the question would have been better.

[ntozier]

Simply put there hasn't been a new release. 1.10 then, 1.10.1 (security update) now. 1.11 has still not been released.

There is no guarantee that the fix in this thread is going to be the one to be used when 1.11 comes out and its unlikely that it will since there are multiple fixes on this thread alone and it hasn't been merged yet.

[dimitrivisser]

@ntozier

With every reply from you I am getting worried more. And this is also about attitude.

PHP 7 is the standard by now.

There is a bug, seen 1 1/2 years ago for the first time. It prevents os Ticket to work on PHP 7.

And after 1 1/2 years it is still not fixed ???

That is why I asked in my first post "What is happening here ?"

Is it ok to invest time now to install this program, put it into use etc ? Is it ok to advice clients to use this ?

[JediKev]

PHP 7 is the standard by now.

This statement is completely subjective. People I know still prefer PHP 5.6 over PHP 7...

There is a bug, seen 1 1/2 years ago for the first time. It prevents os Ticket to work on PHP 7.

It does not prevent osTicket from working for everyone as I know people who have it working just fine with PHP 7 in their production environment.

And after 1 1/2 years it is still not fixed ???

As @ntozier stated there are multiple fixes to this issue in this thread and it takes time to look through them and find the best one that doesn't break anything else and make sure it fits our coding style. Plus this isn't the only issue here on our Github page...there's 1,177. Gotta look through them all.

Is it ok to invest time now to install this program, put it into use etc ? Is it ok to advice clients to use this ?

Of course it's okay! If you're that worried or if your compiled PHP 7 can't handle v1.10.1 then just simply downgrade to PHP 5.6 until it is fully compatible. 👍

[dimitrivisser]

@JediKev

People I know still prefer PHP 5.6 over PHP 7...

I also know people who ride horses. Support for PHP 5.6 was finished in january, security updates will end next year.

I applied the patches, everything seems to work now. But it does worry me :)

[ghost]

You should not be worried. Things are getting real better. The last two years were not easy for osticket users (and I think especially for the osticket folks). One of the main developers (greezybacon, a very friendly, always helpful and skillful coder!) had left the project and it take some time to find new developers who could support the project well and fill the big gap he had left. This had slowed down the development for some time. But you see on github when you look at the big picture that the development speed grows. And big changes are coming (for example complete revamp of the api, custom queues feature->available as alpha).

Also new skillful community members like clonemeagain https://github.com/clonemeagain or Micke1101 https://github.com/Micke1101 have contributed many cool stuff for the community with their plugins. They also are helping a lots of users in the forum with their good knowledge. ntozier the moderator of the forum had helped (and is helping) so much people in all of the years. But people does not make it easy to help them. They don't read the guidelines, they forget important information, sometimes they aren't able to communicate well or quite impolite.

It is not easy to see this if you are only focused on small details like an single issue report. There are so many issue reports. Many of them are old, bad written, duplicated and so on. It is hard to keep track of the things in this jungle.

Many people have many wishes, and not so many people are helping the project. Most of them see only their point of view and are not interested in helping others. But this makes it hard for so a small team to accomplish all wishes in a timeline that they are expecting. I don't know any open source help desk project that is similar powerful and in which are so many good people are working together!

Just my two cents ;-)

If something sounds weird, then is this my excuse:
I'm not a native english speaker and mostly I am using deep learning translation tools like this https://www.deepl.com/translator . Greetings from Cologne (Yeah, that's the big city in germany with all the refugees. Most of them are nice, don't believe your president. He's a splitter).

[jonshado]

When I make the changes noted by solsticesurfer on Oct 3, the Assign pop-up becomes a white blank bar/window. See attached.

Debian Buster x64
4.13.13-1

[ntozier]

@jonshado Did they work before? If yes then i would say that you didn't do it correctly. I run this patch on my production system and do not have your result. If no then you are having an AJAX issue that has nothing to do with this patch.

[jonshado]

@ntozier
Interesting. I've reverted for right now, as I did double check and have properly replaced the lines per the previous post showing the diff. I've included the files here.

We went live on Friday, so a lot of these items are only coming up now as my team susses through the system.

I don't have any other issues with the system that I'm aware of functionally. However, looking at my system information, it does not believe that i have set the cgi.fix_pathinfo to 1, though I did so in the php.ini.

I've include system info, the php.ini and forms.php I've been trying to edit. I'm still looking into the reason why ost isn't recognizing the php.ini changes.

Server Information

osTicket Version | v1.10.1 (9ae093d) — Up to date
Web Server Software | Apache/2.4.29 (Debian)
MySQL Version | 10.1.29
PHP Version | 7.0.25-1

gdlib | Used for image manipulation and PDF printing
imap | Used for email fetching
xml | XML API
xml-dom | Used for HTML email processing
json | Improves performance creating and processing JSON
mbstring | Highly recommended for non western european language content
phar | Highly recommended for plugins and language packs
intl | Highly recommended for non western european language content
fileinfo | Used to detect file types for uploads
APCu | Improves overall performance
Zend Opcache | Improves overall performance

cgi.fix_pathinfo | "1" is recommended if AJAX is not working
date.timezone | America/New_York

Schema | osticket_db (localhost)
Space Used | 5.14 MiB
Space for Attachments | 0.00 MiB
Timezone | EST (Interpreted as America/New_York)

shared.zip

[ntozier]

after you make changes to the php.ini you need to restart Apache. Did you do that?

[jonshado]

@ntozier Yes, I have. I have also restarted the system completely. It seems, based on other community posting, that because php installation is running as an apache module, the warning in info section will not go away, so I don't think that is having an impact.

The rest of the install appears functional. My concern is that these errors are preventing the cron job from running correctly. There is nothing in my cron log. I am going to turn off the fetching via the admin panel (so it should only be cron checking for mail) and hopefully I'll see emails getting ingested.

[all-sd]

Same problem here. Couldn't figure out what it is. But that's how you can work with the system again.

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

[Anticept]

@OSSD for me, department transfer also had the same problem as the blank agent window. It looks like it used the same code as the agent window, so I applied your fix to the transfer section and it worked.

I just hope this doesn't break anything else!

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;

}

[iprok]

Any final fix for this warnings? Or may be somebody can share working patch?

[JediKev]

@iprok

The issue should be fixed with this pull request but only for the 1.11.x series. You're welcome to try it on 1.10.x but it might break something (don't know; haven't tested).

Cheers.