Akeeba Backup for Joomla!

Tuesday, 12 June 2012 10:28 CDT

Le Pache

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (which pages?)? Yes "I get a blank page or Internal 500 error accessing Akeeba Backup or trying to backup"
Joomla! version: 2.5.4
PHP version: 5.2.17
MySQL version: 5.x
Host: OVH
Akeeba Backup version: 3.5.1

Description of my issue:
Updating Akeeba 3.5.1 from 3.5.0 works fine, the backups run without any problem. However, when I try to update JCE Editor from Joomla's update page, I now get a 500 Internal Server Error. Installing the new JCE over the previous one works.
Removing Akeeba or using 3.5.0 allows me to update JCE
Desactivating JRS does not change anything
I've tried going through the "I get a blank page or Internal 500 error accessing Akeeba Backup or trying to backup" procedure, without any improvement.
I don't have any other module using this way of updating, so I don't know if this is JCE specific.

Tuesday, 12 June 2012 10:33 CDT

nicholas

I have not seen anything like that and, as you might have guessed, I am using and updating both Akeeba Backup and JCE on all of my sites. You can try disabling the "System - System Restore Points" plugin. That's a feature I don't use on my sites and one which has the potential to cause a problem during component upgrades.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 12 June 2012 10:48 CDT

Le Pache

Actually, "Desactivating JRS does not change anything" should read "Desactivating SRP does not change anything", I got confused about the name of the plugin.
The plugin's name is PLG_SRP_TITLE here (French localization).

Tuesday, 12 June 2012 10:54 CDT

nicholas

OK, if that plugin is disabled then there is nothing related to Akeeba Backup being loaded while JCE performs its update. I think that you problem is completely unrelated to Akeeba Backup.

At this point I should probably mention that a white page or a page with a 500 Internal Server Error is a PHP fatal error in disguise.

First, check your server's error logs (not the access logs) immediately after visiting the page which throws the error. There should be an exact description of the PHP fatal error which occurred. Sometimes you can find the error messages in files called error_log or error.log inside the site's root and/or administrator directories. If unsure about the error log location, please consult your host. Most likely the error logs are available in your site's cPanel, Plesk control panel or similar hosting account management facility.

If your host does not give you access to the error logs and you have access to the Joomla! administrator area, please log in to your site's back-end, go to Global Configuration, click on the Server tab and set the Error Reporting to Maximum (Joomla! 1.5) or Development (Joomla! 2.x and later). Try visiting the problem page again.

If you still get a blank page, edit your configuration.php file and put the following code right after the final closing curly brace ( this is what a curly brace looks like --> } ) but before the closing PHP tag (it looks like ?> that is a question mark and a greater-than sign):

ini_set( 'display_errors', true );
error_reporting( E_ALL );

Try visiting the problem page again.

If you still get a white page, please remote the two lines from your configuration.php file. Edit the .htaccess file in your site's root. If you don't have a file named .htaccess create a new one. Beware that htaccess.txt is a DIFFERENT FILE and will NOT work! Add the following to the end of the file:

php_flag display_errors On
php_value error_reporting 32767

and retry loading the problem page.

If you still get a white page, remove the two lines from your .htaccess file. Now, create a file called php.ini with the following content:

display_errors=on
error_reporting=E_ALL

and upload it into your site's root and your site's administrator directory. Retry loading the problem page.

If you still get a white page, delete the php.ini files your created and choose a different host. If your host doesn't allow you to debug any PHP-related issues there is no point paying them.

Please note that if you can not understand what the PHP error message means, just copy and paste it here verbatim so that we can take a look and point you to the right direction.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 13 June 2012 11:01 CDT

Le Pache

I checked the logs available to me, but I only had the http and error logs available :

2a01:e35:8a8a:8c90:50c3:5693:3703:7b06 ***.fr -[12/Jun/2012:17:16:44 +0200] "POST /notredame/administrator/index.php?option=com_installer&view=update HTTP/1.1" 500 357 "http://***.fr/notredame/administrator/index.php?option=com_installer&view=update" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0"

[Tue Jun 12 17:17:00 2012] [error] [client 2a01:e35:8a8a:8c90:50c3:5693:3703:7b06] [host ***.fr] Premature end of script headers: index.php, referer: http://***.fr/notredame/administrator/index.php?option=com_installer&view=update

I was able to set Error Reporting to Development, but I only got those
"Strict Standard" errors on every page including the problmatic one, so those should be unrelated :

Strict Standards: Only variables should be assigned by reference in /homez.533/creationef/www/notredame/plugins/system/jat3/jat3.php on line 41

Strict Standards: Declaration of JParameter::loadSetupFile() should be compatible with that of JRegistry::loadSetupFile() in /homez.533/creationef/www/notredame/libraries/joomla/html/parameter.php on line 512

Strict Standards: Non-static method T3Common::get_active_template() should not be called statically in /homez.533/creationef/www/notredame/plugins/system/jat3/jat3/core/define.php on line 16

Strict Standards: Non-static method JAT3_AdminUtil::get_active_template() should not be called statically in /homez.533/creationef/www/notredame/plugins/system/jat3/jat3/core/common.php on line 66

Strict Standards: Non-static method JAT3_AdminUtil::checkPermission() should not be called statically, assuming $this from incompatible context in /homez.533/creationef/www/notredame/plugins/system/jat3/jat3.php on line 161

Strict Standards: Non-static method JAT3_AdminUtil::checkCondition_for_Menu() should not be called statically, assuming $this from incompatible context in /homez.533/creationef/www/notredame/plugins/system/jat3/jat3.php on line 163

Strict Standards: Non-static method T3Common::detect() should not be called statically, assuming $this from incompatible context in /homez.533/creationef/www/notredame/plugins/system/jat3/jat3.php on line 183

Strict Standards: Non-static method T3Path::path() should not be called statically, assuming $this from incompatible context in /homez.533/creationef/www/notredame/plugins/system/jat3/jat3/core/common.php on line 52

Using ini_set('display_errors', 1); error_reporting( E_ALL ); instead shows the very same errors (as expected, I guess all Joomla does is setting the error reporting level to E_ALL)

Wednesday, 13 June 2012 11:14 CDT

nicholas

When you used the latter approach, did the update go through? Did it halt with an error page? If it halted, scroll all the way down. It should have a fatal error listed beneath the long list of Strict Standards notices.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 13 June 2012 13:04 CDT

Le Pache

The update didn't go through, and the "Strict Standards" warnings were the only text on that page otherwise blank. I would indeed have expected a fatal error of some kind, but there was none.

Wednesday, 13 June 2012 14:02 CDT

nicholas

OK, let's confirm that this is not related to Akeeba Backup. First, turn off the error reporting. Then, remove all of the following folders:
- administrator/components/com_akeeba EXCEPT the administrator/components/com_akeeba/backup directory and the administrator/components/com_akeeba/akeeba/serverkey.php file. If you remove that directory and that file you will lose your existing backups and/or settings.
- components/com_akeeba
- administrator/modules/mod_akadmin
- media/com_akeeba
- plugins/system/plg_srp
- plugins/system/plg_akeebaupdatecheck
- plugins/system/plg_aklazy
- plugins/system/plg_oneclickaction

What you've now accomplished is remove all of Akeeba Backup's executable code. There is no Akeeba Backup any more on your site. Gone. Dead. Now, try the update again. Does it work?

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Thursday, 14 June 2012 11:00 CDT

Le Pache

I've removed everything you said, and I still can't update JCE. plugins/system/plg_srp was just called plugins/system/srp (same for the other plugins).
I guess that's a hint, but it doesn't explain why 3.5.0 was working and not 3.5.1.

I have tested the following things :
3.5.1 -> JCE Update NOK
3.5.1, having removed the executable files-> NOK
Installing 3.5.0 over that -> We get the following errors (roughly translated) :
JInstaller: :Install : can't find an init XML
JFolder: :files : the path is not a directory. Path : /homez.533/creationef/www/notredame/components/com_akeeba
JInstaller: :Install : can't find an init XML
Still NOK
Reinstalling 3.5.0 a second time : No error message, still NOK
Desinstalling Akeeba 3.5.0 -> NOK
Reinstalling JCE 2.0.21 -> Still NOK

I'm thus left with a system unable to update JCE. I'm going to restore a system with 3.5.0 working later, but I'm quite sure that I'm able to update JCE just before installing 3.5.1 from 3.5.0

Thursday, 14 June 2012 11:06 CDT

nicholas

Not a hint, I just realised I typed the folders wrong :) In any case, you've completely removed all Akeeba Backup code from your site and you still had this problem. As a result it is not a problem related to Akeeba Backup and I can't help you. Maybe it's an issue with JCE's updater? You can ask Ryan, JCE's author.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support