Troubleshooting

YourSites is a new extension and it is possible you may encounter issues as you use it.  This article summarises the types of issues that may arise, what configuration options you can customise to avoid then and what diagnostic information is available to help us resolve unanticipated issues.

YourSites uses the core Joomla Updater and Installer on the client site to perform update checks, upgrades, installations etc.  It is therefore unlikely that your client sites will be damaged (any more so than they would be by applying an upgrade/update directly).  However, if you have used Joomla for a while you will know, of course, that  some extension upgrades and Joomla updates have caused site problems in the past and it may happen again in the future.  It is therefore ALWAYS a good idea to make sure that your backups are up to date.  Your use of YourSites is at your own risk.

1. Progress Box is Red and [+] Says 'Internal Server Error'

If you view your javascript console you can see the log information generated by the request - this will probably say there was a 500 error.  Most likely, this is caused by your client site being overloaded by too many requests at one. 

You should open the YourSites config and increase the Intervals between requests - if you have a lot of sites to manage a good base interval may be 5000 (5 seconds) as opposed to the default 1000 (1 second)

2. Paid Extension Update Fails

If you have a paid extension that uses the Joomla updater and you set a download ID in the component parameters its possible that is uses a field name that we have not checked against.  We currently check for dlid, downloadid and update_dlid, but its possible your extension uses a different field.  If it does please let us know

Another possible explanation is that your subscription has expired.

3. Backup Check Fails

Make sure you have enabled frontend backups and set a secret key in the Akeeba Backups component on the client site

If have done this and you get a backup check failed error with the detailed error message 92 : HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1) you can resolve this by editing the site in YourSites and on the backups tab and setting the config option "Call Akeeba using GET instead of POST" to "Yes"

4. Updates Succeed but Progress Window Shows Red Error Message

This could be caused by a couple of things:

• If you have error reporting enabled on a client site you may get a PHP notice/warning that causes the JSON message interaction between the client site and server to be interpreted as an error.  If this happens please view the Javascript console in your browser and expand the log message next to the failed result.  If you are able to find the PHP notice/warning in this text please let us know so we can investigate and hopefully avoid the problem from arising again.
• You may have a system plugin on the client site that has sent the PHP headers early or output some text before the YourSites client script can run.  Again please let us know if you encounter this problem

5. All Interaction With a Client Site Fails

You may get a message to say that a secure connection could not be made between the server and the client site.  If this happens it could be that the private tokens don't match up between YourSites and the client.

The resolution of this is usually straightforward and requires you to download a 'site specific client' from the list of sites (click the site in question and select this button) - then install on the relevant client site directly (you will not be able to do this via YourSites since the secure connection required to do this will not work). 

The most common cause of this is that you have installed the wrong client package on client site.  If you can recreate this problem then please let us know so that we can investigate the cause further.

If you are connecting to a WordPres/ClassicPress site then its possible you have a plugin on the client site that is blocking the JSON Rest interface. You can check this fairly easily with a dummy request to the client site. Simply open the following URL in a web browser:

http://YOURDOMAIN/wp-json/yoursites/v1/action?json={%22task%22:%22findjoomlaupdates%22}&t=1&st=1

This should give you output similar to this (screenshot is from Firefox) - the key thing to look for is the YourSites security check failure (since we have intentionally provide invalid security tokens).

6. SSL certificate Error - Unable to get local issuer certificate

This is a problem that arises from time to time for some users when connecting some client sites to their YourSites server. If you get a red connection error see this error message in the output summary for a specific site e.g. when checking if a site it up, then there is a problem with the way that the TLS/SSL certificate has been set up on the client site.

• YourSites/Joomla typically uses a communication library called CURL to communicate with the client site. This in turn uses openssl to perform the encryption/certificate validation. Openssl is more strict that many web browsers so a client site which appears to work correctly over a https:// connection in a web browser can still fail when using curl/openssl.
• If have are using linux/unix/MacOS based computer you can run a command from a terminal window to check the certificate:
  openssl s_client -host problemdomain.com -port 443
  If you do not have access to this tool then this online service may provide some insight. https://www.digicert.com/help/
• A common cause of the problem is that there is a bundle of certificates and one or more of these is invalid. A web browser may choose to ignore the invalid certificate(e) where openssl does not. You will need to discuss this problem with the hosting provider of your client site. In the meantime you could change the site connection to http:// within YourSites but this is not recommended for security reasons.

7. Unable to update Joomla because of htaccess based cookie checks

If your administrator is protected by a cookie check in your htaccess file where the cookie is set via a secret path (e.g. You need to access another url (e.g. http://mysite.de/mysecretfolder) first, where a cookie will be set and then you are being redirected to http://mysite.de/administrator where the cookie is checked) then Joomla updates won't work because of the way the Joomla restore.php script is called.

You can work around this with a simple change to your htaccess file so that it reads

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/administrator
RewriteCond %{REQUEST_URI} !(restore.php)
RewriteCond %{REQUEST_URI} !(restoration.php)
RewriteCond %{REQUEST_URI} !(restore_finalisation.php)
RewriteCond %{HTTP_COOKIE} !"cookie_to_check"
RewriteRule .* - [L,F]

This will allow the Joomla update to work correctly.

8. Diagnostic Information

If you get unexpected results from the interaction between your YourSites server and a client site then it may be possible to get more diagnostic information to help figure out what is going on from the JavaScript Console. In Firefox or Chrome you should right click in the progresss popup modal window and select 'Inspect Element' and then select the 'Console' tab.

You will then see some diagnostic output from the interaction between the server and client site - you can expand on this to get more useful information which may help you or us figure out what the problem is. This is what you may see initially in the console window.

If you expand the response data you will see something like this

9. Extension Updates Failing on Litespeed Servers

If you find some extension updates failing and your client site runs on a Litespeed Server then its possible that the connection is timing out due to a LiteSpeed server setting. Unfortunately this can cause the extension update to fail part way through and possibly lead to a partial or broken upgrade.

One way to resolve this issue is to set the connection timeout higher for requests from your YourSites server. You can do this by adding the following to the .htaccess file on your client site. This example assumes your YourSites server is running on the IP address 127.0.0.1

RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^127\.0\.0\.1$
RewriteRule .* - [E=noabort:1, E=noconntimeout:1]

If that doesn't workyou can set the connection timeout higher globally -see the yellow highlighted field in this image.

An article discussion this issue can be found on the LiteSpeed website at https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:php:run-without-timeouts.

10. Problems Restoring Backups of Your YourSites Server

If you find you are unable to restore a backup of your YourSites server (your management server not the client site backups) you may have encountered a bug in AkeebaBackup - please see this article for guidance on how to resolve this issue.

11. Problems Installing Extensions or Updating Client Plugin

If you find you are unable to install extensions via YourSites or to update the client plugin on your client sites please check the error messages. You may see a 400 error code or a 'missing request data' type message. If this is the case then its possible you are encountering a PHP bug on your YourSites server - see https://bugs.php.net/bug.php?id=79013. If you running PHP 7.4.x you must make sure it is versino 7.4.4 or higher otherwise you may encounter these problems.

12. Push Notifications throwing Akeeba AdminTools WAF Exceptions

If you find your web push notifications are triggering Akeeba AdminTools WAF Exceptions you will need to add a special redirect in your web server's .htaccess file since its not possible to configure WAF to avoid these. In the custom redirects section add the following rule (replacing XXXXXX with your admin keyword/keyword pair.

RewriteCond %{QUERY_STRING} !h6ztgruv5b(.*)
RewriteCond %{QUERY_STRING} (.*)option=com_yoursites&task=push.notification(.*)
RewriteRule administrator(.*) /administrator$1?XXXXXX&%1option=com_yoursites&task=push.notification%2 [R,END]
    

13. Database Has Gone Away Errors

If you find you are geting "Database Has Gone Away" errors in YourSites it could be that your database server has too low a value for the config option 'wait_timeout'. What this means is that when YourSites is undertaking a long/slow task e.g. cloning a website, upgrading Joomla or generating a backup the database server may give up waiting for a response and close the connection.

From YourSites version 1.11 onwards you can set a configuration option on the advanced tab to run a query to override database settings prior to YourSites making any database calls and thereby avoiding this issue.

14. Persistent Timeout Errors

If you find a client site is consistently giving you timeout errors but the site can be accessed directly then its possible your client site has a firewall e.g. Apache mod_security, that is blocking access to your YourSites server. You should ask the webhost what rule is being triggered or to whitelist your YourSites server's IP address in the firewall settings.

15. Incorrect SiteDown 500 errors

If you find a client site is being reported as down with a 500 error but its actually working perfectly then check if the client site is running through Cloudflare - it could be that you need to add your YourSites server's IP address in the Cloudflare whitelist.

16. Client site timeout errors during Joomla updates on Plesk based servers - 504 Gateway Timeout

Plesk is normally configured to pass PHP script requests to Apache via Nginx - for some longer actions, such as Joomla upgrades, this can lead to a gateway timeout error.

nginx 504 Gateway Time-out

The following error message may appear on the Logs page (Domains > example.com > Logs) or in the domain's nginx error logfile /var/www/vhosts/system/example.com/logs/proxy_error_log

[error] 1096#0: *25 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 203.0.113.2, server: example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:///var/www/vhosts/system/example.com/php-fpm.sock", host: "example.com"

Please see the relevant plesk support page for an explanation of the cause of this problem and a recommended solution. We would recommend that you change the Nginx timeout limit for the client site and the YourSites server.

You may need to ask your webhost to do this for you depending on your hosting account arrangements.

Alternative Approach

If you are unable to make these changes on your client site servers then you are recommended to enable javascript based backups on the "Akeeba Backups" tab of the site entry and also javascript based Joomla upgrades on the "Advanced Settings" tab of the site entry. This requires version 1.30.0 of YourSites at least.

17. Bad Gateway Error 502 on Plesk based YourSites Servers

Plesk is normally configured to pass PHP script requests to Apache via Nginx - in some situations this can lead to a bad gateway error on your YourSites server.

nginx 502 Bad Gateway

The following error message may appear on the Logs page (Domains > example.com > Logs) or in the domain's nginx error logfile /var/www/vhosts/system/example.com/logs/proxy_error_log

[error] 1295090#0: *1735252 upstream sent too big header while reading response header from upstream

If you encounter this problem please try adding the following to your "Additional nginx directives"

proxy_buffering on;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

18. HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1) for SiteGround Client Sites or CloudFlare Sites

If you have a Siteground client server or are using CloudFlare you may need to change the useragent that YourSites uses to communicate with the client site. You can change this on the advanced tab of the YourSites config.

You could use a value that matches your web browser (see https://webbrowsertools.com/useragent/?method=normal&verbose=false) e.g. "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0", something related to YourSites e.g. "YourSites Client Site Monitor" or a Joomla related value e.g. "Joomla Server v4.3.4".

A Joomla related value seems to work best for Siteground but has been known to cause a problem on some CloudFlare sites