Successful major upgrade !

[WebDork]

Was sweating bullets over this one - so thought I would post this here in case anyone else is worried about upgrading.

I just went from 3.3.1 to 4.8c and not a single hiccup as far as I can see. Whole process took less than 5 mins - including d/l latest version from here and re-uploading.

I deleted close to 100,000 images first just to make it easier for the script - but in hindsite probably didnt need to.

Thanks photopost !

[WebDork]

Previous version was *much* faster at checking for missing thumbs / images ...

[WebDork]

Spoke too soon

Checking photo #81951: done.
Checking photo #81952: done.
Checking photo #81953:
Fatal error: Maximum execution time of 30 seconds exceeded in forums/photopost.php on line 27

[WebDork]

Under the line:

$disableforadmin=1;

add:

set_time_limit(5000);
ini_set("memory_limit",-1);

in adm-db fixes it for anyone interested.

[Chuck S]

Thats a PHP error techically not Photopost

Your processing of that image took longer than 30 seconds

[WebDork]

Originally Posted by omegatron

Thats a PHP error techically not Photopost

Your processing of that image took longer than 30 seconds

Id argue it was a scalability issue within photopost. After all an edit to the script rather than an edit to php.ini is what fixed it

[Chuck S]

Actually way incorrect if you call it a photopost issue. We could never put a php_override in our scripts nor can anyone else as a standard.

Just cause your server setup or mine etc accepts overriding defaults does not mean everybodies does. There are many many server setups where overrides DO NOT WORK.

So glad you did that to correct your issue but the correct answer from a support standpoint is still you need to edit your php.ini as that is a php error not a photopost error.

[WebDork]

I stand corrected then

What would users with big sites then do ? Not many hosts would change their php.ini just for a user. The script timed out when it was checking for missing thumbs, not when it was processing any images.

[Chuck S]

All I am saying from a script perspective is that you can not just simply add code to override the server php.ini if people can not use it. Say 25% of our user's can accept that override what about the other 75% of users. Just an example you see. We right script that has to be runable on many many servers.

PHP errors are just that php errors not script errors. There are ways around things as you know by editing the php.ini or applying overrides if the server accepts them. This is outside a script perspective and is a server thing. You did a short cut that works for you which is good.