Support

Akeeba Backup for Joomla!

#9145 – Conflict between CLI and ArtioSEF - JSON decoding error

Posted in ‘Akeeba Backup for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Wednesday, 09 November 2011 20:40 CST
Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? No articles suggested
Have I searched the forum before posting? Yes
Have I read the documentation before posting (which pages?)? Yes - CLI info, Quick Start guide, Backup guide
Joomla! version: 1.5.18; 1.5.15; 1.5.8
PHP version: 5.2.16; 5.2.4;
MySQL version: (unknown)
Host: Salsa Internet (Melbourne, Australia)
Akeeba Backup version: 3.3.6

EXTREMELY IMPORTANT: Please attach your Akeeba Backup log file in order for us to help you with any backup or restoration issue.

Description of my issue:
Hi Akeeba staff!

This is a bit complex as there are 3 sites under management, but I will try and make this as simple as possible.

We are having issues getting Akeeba CLI to work correctly with 2 out of the 3 sites. We are 99% certain this is related to the ArtioSEF module installed on all sites. Versions of both Joomla and ArtioSEF vary between these sites (out of our control, unfortunately - controlled by host), Akeeba is the same version throughout.

Manual backup works without any issues on all sites.

I will break these down for you as clearly as possible:

Site 1:
Joomla 1.5.8
ArtioSEF 3.2.0
Manual backup: Works fine
CLI backup: Works fine
CLI upgrade: Works fine

Site 2:
Joomla 1.5.15
ArtioSEF 3.3.5
Manual backup: Works fine
CLI backup:
Command: php remote.phar --action=backup --host="http://[masked]" --secret=[masked]
Reports: Error 500 - JSON decoding error
CLI upgrade:
Command: php remote.phar --action=update --host="http://[masked]" --secret=[masked]
Reports: Error 500 - JSON decoding error

Site 3:
Joomla 1.5.18
ArtioSEF 3.8.1
Manual backup: Works fine
CLI backup:
Command: php remote.phar --action=backup --host="http://[masked]" --secret=[masked]
Reports: Error 500 - JSON decoding error
CLI upgrade:
Command: php remote.phar --action=update --host="http://[masked]" --secret=[masked]
Reports: Error 500 - JSON decoding error

Troubleshooting steps taken:
- Akeeba forum/documentation research - initial research suggested the SEF module could be interferring.
References found:
https://www.akeebabackup.com/support/forum/desktop-apps-support/remote-cli-on-15-sites/52878.html#p52878
https://www.akeebabackup.com/support/forum/support-for-akeeba-backup-core/solved-almost-instant-backup-didnt-work/26090.html#p26090
- Configuration changes - On Site 3 I was able to extensively test configurations of ArtioSEF for troubleshooting. While I was unable to find any configuration that allowed backups to take place (included explicitely excluding the Akeeba directory and module areas from SEF processing), turning off the ArtioSEF module completely allowed CLI based backups to process without error.
- ArtioSEF forum/documentation research - nothing relating to Akeeba was found in ArtioSEF documentation.

I'm sure the setting is somewhere within Artio but I can't find it anywhere - perhaps it's something else, really stuck here.

If you guys are able to help in any way, please let me know! I'm happy to send through admin credentials if you require them.

Thanks,

- Andrew
user50236
Thursday, 10 November 2011 01:38 CST
Hello Andrew,

The problem is on the ArtioSEF side. FWIW, the same problem also happens with AceSEF. Both of them unilaterally decided that it's a good idea to modify incoming request parameters. What happens is that Remote CLI has to access a special URL with a query parameter called JSON. In it we place the JSON-encoded data structure which tells Akeeba Backup what action we need it to execute. All SEF components (except sh404SEF, after a fix one year ago) intercept the json query parameter and corrupt its content, effectively disabling Akeeba Backup's remote API. Unfortunately, I can't really do anything about that :( SEF components are not supposed to modify incoming parameters and, even if they do, they OUGHT to give a workaround!

So, once again, I will have to restate my form belief on SEF components: they suck. They do too much, they cause a lot of trouble and, in the end of the day, search engines don't care about your URLs anymore. Content is king, not URLs. It's much better for SEO focusing on page metadata and quality, frequently updated content.



Nicholas K. Dionysopoulos

Lead Developer and Director



Greek: native

English: excellent

French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



nicholas
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.