Another 4.2.2 upgrade test

[da_judge]

You suggested hide errors... how is that good.. just asking

http://www.vbulletin.com/forum/forum...-been-released

its bad to hide errors... not saying your fault... and as im from London... its what we say.. its mental... nothing personal.. but Nginx craps out big time with update

No offence intended Paul

[Paul M]

I suggested "Where possible, you should fix the plugin code".

Thats not always practical or possible, so hiding them is the only alternative.

vBulletin has been hiding them for a long while due to the fact the old error handler (which dates from php 4 days) didnt do anything with them. All 4.2.2 does is expose them.

[da_judge]

question is then m8... why hide errors.. it be better to show rather than hide

and your fixes fails on nginx.. plugins which i know are not yor fault.....

[Paul M]

Originally Posted by da_judge

question is then m8... why hide errors.. it be better to show rather than hide

You are free to show them on your forum if you wish, most admins however would prefer not to display them.

On a production site, display_errors should be turned off at source (php.ini).

As noted in the standard php.ini file

;;;;;;;;;;;;;;;;;;;
; Quick Reference ;
;;;;;;;;;;;;;;;;;;;
; The following are all the settings which are different in either the production
; or development versions of the INIs with respect to PHP's default behavior.
; Please see the actual settings later in the document for more details as to why
; we recommend these changes in PHP's behavior.

; allow_call_time_pass_reference
;   Default Value: On
;   Development Value: Off
;   Production Value: Off

; display_errors
;   Default Value: On
;   Development Value: On
;   Production Value: Off

[CarlitoBrigante]

Paul, there is no reason to be so dismissive. I have a problem on many servers with display_errors set to off and errors still being shown by vBulletin 4.2.2 through its new error handler. Why this is happening, I did not have time to look into, as I have so many forums to upgrade I do not have time to submit a bug report. I am not paid to look into vBulletin's core code, but I might take some time to do so.

For the others: those warnings, as I said in my previous post, should not be ignored. The reality is that many plugins you could have downloaded also from vBulletin.org will cause those warnings in many vBulletin installations - just, up to this moment, you might have not noticed them. This is because many plugins are using old code or are coded following old PHP standards.

When you set display_errors to off, you should always have log_errors set to on and check routinely for errors popping up there, including warnings, and fix plugins when possible.

On production websites, you should basically NEVER show this kind of error information to the public, as it might expose vulnerabilities or other information about your server you do not want to disclose (like path structure).

Sorry for the fast post, I did not have time to re-read it for spelling errors as I have still 4 forums piled up for an upgrade today.

[meaters]

Thanks for the info Carlito.

Broken templates are also a big problem after this upgrade.

[da_judge]

Yer i understand that m8.. but im running Nginx.. php.ini doesn't work the same with nginx

i managed to fix anyway

cheers

--------------- Added [DATE]1381433711[/DATE] at [TIME]1381433711[/TIME] ---------------

Originally Posted by meaters

Thanks for the info Carlito.

Broken templates are also a big problem after this upgrade.

you tried rebuilding templates in maintenance

Admincp > Maintenance > Rebuild Styles