Support

Kickstart is developed on PHP 7.4. Moreover, all of my development environments are using PHP 7.4 by default. Your problem is not the PHP version (which would be something for us to fix).

Trying to help you on an issue that you self-misdiagnosed is really not possible since all I have is your wrong diagnosis :( If I had an exact error message and a screenshot from your issue I could help you identify the real issue and work around or fix it.

Thanks for the sarcasm, but it's both unwarranted and not conducive to me being able to help you. I am not disputing the fact that you have an issue, I am only disputing your diagnosis.

I have to work with 4 data points.

0. (this is something I JUST found out) The problem is that you see the extraction page with the progress bar but nothing seems to be obviously moving along and no error message is sent back.

1. I am developing and using Kickstart on a plethora of different local, staging and live servers using PHP 7.4. This spans every major operating system and web server software, not to mention a very representative real world mix of server environments. Therefore if there was a problem with something as fundamental as initiating the backup extraction -- an operation that literally EVERY use case of Akeeba Kickstart relies on -- I'd have certainly noticed given the fact that between developing, managing my sites and helping clients I am doing at least a dozen backup archive restorations a day.

2. The other reason that tells me that you have misdiagnosed the issue is that nearly 5% of our users are already on PHP 7.4. Based on my 13 years of experience, if there is a fundamental issue that affects at least 0.5% of our users we receive a plethora of tickets about it within the first 8 hours. It's been a quiet two days. The likelihood that you bumped into a PHP version incompatibility that nobody else could reproduce is infinitesimal.

3. You say that switching to PHP 7.4 stops the extraction dead but switching back to 7.3 fixes it.

The first thing that comes to my mind is "how exactly did he change the PHP version". If you used something that made a change to your .htaccess file or edited your .htaccess file directly we may have something there. The very first thing Kickstart does before the progress bar starts moving is rename .htaccess to htaccess.bak. If you see that file suddenly appearing then your problem is that your web server defaults to a PHP version earlier than 5.3.3 (the minimum PHP version Kickstart supports) which explains why you see nothing happening.

If the PHP version changes without touching any file under your site's root the answer might be in the different ways each PHP version is configured. Is one an Apache module and the other one implemented through FastCGI? That would imply there's a web server misconfiguration e.g. the wrong thread safety binary being used. Do both PHP versions have the same PHP extensions enabled? If not, maybe PHP 7.4 is missing something we are using such as JSON.

However, in both cases I'd expect to see an error message -- at the very least an AJAX Error after 30 seconds of nothing happening. Have you let it run that long?

If you have let it run for more than 3 minutes and literally nothing is happening I am suspecting a browser issue, possibly in combination with another server issue. However I cannot magically diagnose this; I would need to have access to an affected server.

So the information I need is:

1. How do you change the PHP version?
2. Is the .htaccess file in the site's root modified when you change the PHP version? If so, what are its contents for PHP 7.3 and PHP 7.4.
3. Have you confirmed that the PHP binary setup and php.ini configuration are identical in both PHP versions? If not, what are the differences?
4. How long have you let it run before deciding it's stuck?
5. Just to make sure, if you let it on the extract page for at least 180 seconds do you get ANY error message at all? If so, what is its exact content?

1. I changed the PHP-Version by means of the hoster's panel.

2.: .htaccess is not availble when doing an new install of theWebsite.

This is basically what I said before. When you use the hosting control panel what typically happens is that they add a line in the .htaccess file which changes your current PHP version. For example, you might see something like this at the bottom of your .htaccess file:

AddHandler application/x-httpd-php74 .php

However, when you click the Start button the .htaccess is renamed to htaccess.bak, therefore it is no longer applied. This means that your server falls back to its default PHP version.

Remember, at this time the Kickstart page is loaded on your browser and doesn't reload. But the JavaScript on that page still runs and tries to execute the next step by doing an XMLHttpRequest (AJAX) call to your server, i.e. it tries to load kickstart.php again.

If the server's default PHP version is too old for Kickstart that AJAX call will fail and you won't see the progress bar moving. I would expect to see an error BUT it may take up to 3 minutes for that to happen. That's why I had asked about how long you waited.

I still need to know what happens when you switch your site from PHP 7.3 to 7.4. Do you see a change or addition of an AddHandler or SetHandler line in your .htaccess?

There's a very good reason I am asking this, really. One of the items in my to-do list for this Spring is trying to modify Kickstart to preserve these AddHandler / SetHandler lines which set a specific PHP version instead of completely obliterating the .htaccess file prior to restoration. What I'm interested in is understanding if this would be something that would help in your case so I can better design this new feature. I really do care about making things easy for you guys. I've always said that Akeeba Backup doesn't make backing up, restoring or moving sites possible; it's only meant to do it easier. This means I get to contemplate on the challenges you have during those operations and try to provide as much automated features as possible to overcome them without too much effort.

Thank you in advance for your feedback!

Thank you. That removes an entire branch of possibilities (one that didn't quite match my expectations – as I said, I'd expect an AJAX error).

This leaves me with a few possibilities regarding the server configuration.

Now that you have restored your site, if you switch it to PHP 7.4 do you observe anything being broken? If not, can you take a backup? If the backup fails can you please ZIP and attach the backup log file? The answers to these questions will give me a pretty good idea about the nature of the problem (missing PHP extension, wrong PHP binary, PHP-FPM / FastCGI misconfiguration or a process memory limit).

Sorry for all these questions. Typically these issues are far faster troubleshooting with direct access to the affected site but since this is not an option (we don't want to bring your site down) I have to resort to much slower, indirect information collection.

Alternatively, you can set up a subdomain for me to run a few tests and give me FTP access to it. If you decide to do that please let me know first so I can convert your ticket to private. Right now it's public and it's not safe to share connection information with me – everyone could read them.

Akeeba Backup IS ABSOLUTELY AND MOST DEFINITELY compatible with PHP 7.4.2 on the grounds that this very site where we're haiving this conversation and all of my development sites, plus several thousands of client sites, all run on it perfectly.

Not only that, but if your host actually knew how his servers work and what is the connotation of the idiotic things they spout they'd be fully aware that if there was a PHP version compatibility issue they would have of course seen a PHP error log entry (and most likely an Apache error log entry) describing the PHP Fatal Error that would have occurred.

Unfortunately for your host, I have been testing Akeeba Backup with PHP 7.4 since PHP 7.4 was in beta! I know that they only compatibility issues it had were non-fatal: a few continue statements that should have been continue 2 and some legacy code that was using curly braces string array access instead of square braces. By the time PHP 7.4 was in Release Candidate 1 we had already converted all our commercially available software to be fully compatible with PHP 7.4. Because, unlike your host, we actually know what we are doing.

Now, let's see something very important that came out of the test I asked you to run. We have a smoking gun! Lo and behold:

HTTP Status: 503 (Service Unavailable)

This proves beyond any shred of doubt that the problem is none other than your host. This is the error you get when mod_fcgid or mod_proxy_fcgi sees the PHP FastCGI binary / PHP-FPM server crash or cannot connect to it at all (I suspect the former over the latter since your site DOES run under PHP 7.4). This is what you see when the server administrator has screwed up the configuration of the server.

Unfortunately for your host I happen to not only develop PHP software but also know how to set up server. I mean my macOS server setup (which is easily adaptable to Windows and Linux) is not exactly secret. A sort walk through my blog will be proof enough of how much I've learned about server setup the last ten years. But I digress.

If your host is using PHP-FPM I'd suggest that they take a closer look at its pool setup.

If your host is using plain old FastCGI with mod_fcgid I'd suggest that they check whether they are accidentally using the wrong thread-safety binary (which one they should be using depends on their Apache MPM).

As for why this issue is happening during extraction and not during backup, I have some theories but without the full server setup they will only be speculation. Let's just say that my experience on where to look can be found above.

In the meantime you can try to work around your broken server environment by adjusting the Kickstart / integrated restoration timing parameters. Maximum 3 seconds / minimum 1 if my first hunch is right, maximum 2 / minimum 5 (yes max is less than min on purpose) if my second hunch of what is going on is right.