Getting error about PHP version but it is installed

Greetings,

After configuring Windows Server 2016 with IIS 10 and PHP 7.4.1 I am getting the following error:

Error: Ask your hosting provider to use PHP 7.2.5 or higher for both HTTP and CLI.

I've checked and PHP 7.4.1 is the ONLY one installed on my system. What could be wrong?

my PHP info top panel is copied below, notice PHP version
System Windows NT WIN-MFD-LLC 10.0 build 14393 (Windows Server 2016) AMD64
Build Date Dec 17 2019 19:17:08
Compiler Visual C++ 2017
Architecture x64
Configure Command cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--disable-zts" "--with-pdo-oci=c:\php-snap-build\deps_aux\oracle\x64\instantclient_12_1\sdk,shared" "--with-oci8-12c=c:\php-snap-build\deps_aux\oracle\x64\instantclient_12_1\sdk,shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet=shared" "--without-analyzer" "--with-pgo"
Server API CGI/FastCGI
Virtual Directory Support disabled
Configuration File (php.ini) Path C:\Windows
Loaded Configuration File C:\Program Files\PHP\v7.4\php.ini
Scan this dir for additional .ini files (none)
Additional .ini files parsed (none)
PHP API 20190902
PHP Extension 20190902
Zend Extension 320190902
Zend Extension Build API320190902,NTS,VC15
PHP Extension Build API20190902,NTS,VC15
Debug Build no
Thread Safety disabled
Zend Signal Handling disabled
Zend Memory Manager enabled
Zend Multibyte Support provided by mbstring
IPv6 Support enabled
DTrace Support disabled
Registered PHP Streams php, file, glob, data, http, ftp, zip, compress.zlib, https, ftps, phar
Registered Stream Socket Transports tcp, udp, ssl, tls, tlsv1.0, tlsv1.1, tlsv1.2, tlsv1.3
Registered Stream Filters convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk, zlib.*

Folks, if you are getting this error and your PHP is installed correctly (as it shows it is for me) don't go crazy trying to figure out what is wrong with your installation of PHP like the folks at Akaunting keep telling folks. I resolved this by just deleting the senseless and useless check for PHP version in the installation script. My problem is now solved and I am successfully using the software on my own private server running Windows Server 2016 and IIS 10.

Hi Freddy, I have hit the same wall and could not locate the PHP module causing the PHP version check error that you identified for deletion. I have php version 7.4.9 configured in IIS (Windows 10). I have looked in the bootstrap folder which has the version check and error message but slightly different from what is being displayed. (???).
If you can point me to the module that you changed, I'd appreciate that...

Greetings Aibo,

From what I can see the check is being performed in the Installer script which is located in C:\\app\Utilities\Installer.php

There at around line 119 you'll see the following code snippet:

/* if (Console::run('help') !== true) {
$requirements[] = trans('install.error.php_version', ['php_version' => AKAUNTING_PHP]);
}
*/

After commenting this out it is my belief that the senseless check for version will be bypassed. It would be great if you could confirm this. For me, it did the trick so I expect that it will work for you as well. Let me know!

hmm, I used "<>" greater than symbols to depict where your akaunting root is, but I guess the system takes the greater than symbols out (rightfully so!) :)

The full path is: C:\akaunting_directory\app\Utilities\Installer.php

Greetings Freddy,
I can confirm that your suggestion did fix the error.

I got through that okay but ended up being hit with an "Internal server error 500".
I am using IIS on Windows 10 same as your setup.
Alas, my limited understanding of web based systems and servers is challenging for me.
Did you encounter a similar problem with your setup?
I have Mysql, PHP 7.4 and IIS running in Windows 10.
I am wondering whether the low RAM capacity and CPU speed might be a contributing factor.

I also did the same thing, and I was able to get Akaunting installed on my Windows 2019 server.
The web installer was totally busted, and I could not get the artisan installer to connect to a mySQL database, so I used a PostgreSQL one.

However, I noticed later that various operations throughout the site simply do not work.
I cannot create a bill, I cannot add a new vendor with an email from scratch, and many other issues.

Did you have these issues on the database you connected to?

Hi Freddy, Scion and Aibo, the main reason I've decided to join "Akaunting" is my hope it WILL fully work, asap, under PostgreSQL latest versions. Thank you, Freddy, for posting your installation workaround. Could all of you, please, also update this discussion topic about how far did you go in terms or real work already accomplished? Wouldn't be a good idea to learn the list of user names really interested in help Akaunting to get this strategic job done sooner rater than later? I would gladly offer a 100$ financial reward to anyone really able to make it happen under the powerful PostgreSQL version 13 + Laravel 8. Any suggestion? Perhaps through the Akaunting Collaboration Hub (PostgreSQL chat group open to all)?

Greetings folks,

While I did not experience any of the issues after bypassing the installer option I wrote about here on my 2016 server with MySQL, I did give up on Akaunting because, quite frankly, it was too manual for our needs. That is, in order to have any type of automation (linking accounts, etc) its a separate effort.

Then, reading through the forum I found out about Wave Accounting, which is a SaaS with a free tier that fits all of our needs including the most vital one for us: linking of bank accounts for automatic transaction synchronization.

Perhaps we'll visit Akaunting again when it has these features available as well as the issues fixed in the installation. We view these as show stoppers and a no go.

Thanks and hope that helps.

I figured out this issue for myself after some trial and error. I tried setting the PHP_BINARY (https://stackoverflow.com/questions/64046112/how-to-fix-this-error-ask-your-hosting-provider-to-use-php-7-2-5-or-higher-for). That did not work.

I was installing on a plesk server, and made sure to set the php cli version as suggested here for the user (https://support.plesk.com/hc/en-us/articles/115003766853-How-to-configure-a-specific-command-line-PHP-version-for-an-SSH-user-on-a-Plesk-for-Linux-server-). Did not work, again.

What I ended up having to do was log into my server as root and create a symlink to the php executable in a folder that the web user had access to. The alias would not work, the environmental variable would not work. I had to rely on the executable being in one of the paths of the user (I chose to symlink into /usr/local/sbin/php). I hope this helps someone in the future.