In fact, turning on those settings only had the effect of both the "SCRIPT_NAME" and "PHP_SELF" variables being set to "D:/index.php" instead of "/index.php" in all working PHP versions. (I've read in a lot of places that the fix path info settings should be "FcgidFixPathinfo=1" and "cgi.fix_pathinfo=1", but I tried this without success. usually causes an error unless done from the command prompt.) (In XP, creating files that begin with a period Default value for user_ini.filename is ".user.ini". default_charset must be set for PHP 7.1 onwards in this case you would only need to edit these two lines.Įrror_log="D:/www/APACHE/logs/php_XXXXX.txt" Paths at the top for ease of copying configurations, which
#Avrdudess 2.4 full
The full contents of the "php.ini" files are as follows (XXXXX = Version ID): I can't find anything that indicates that further changes are needed for 7.2 or 7.3. I found this solution for 7.1 (which also didn't work originally, but does now) thanks to the migration pages at php.net. # This forces unknown addresses to the default site.Īll PHP configurations are the same except that versions 7.1 onwards include the "default_charset" directive, which if not present, causes a 500 Internal Server Error. LoadModule fcgid_module modules/mod_fcgid.soįcgidInitialEnv TEMP "D:\www\PHP\$"įcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000įcgidWrapper "D:/AddHandler fcgid-script. LoadModule mime_module modules/mod_mime.so LoadModule authz_core_module modules/mod_authz_core.so LoadModule access_compat_module modules/mod_access_compat.so # Here I simply uncomment the PHP version I want to test and then restart Apache. The Apache configuration is as minimal as I think it can be: # Apache 2.4.38 Configuration
#Avrdudess 2.4 software
All binaries have been checked and there are no missing dependencies except for the usual culprits (PHP extensions that rely on 3rd party software that is not installed).All PHP versions have their own "php.ini" file in their own folder.To keep things simple, no PHP extensions are being loaded.All VC runtimes are installed and working (2008, 2012, 2017).PHP builds are all pre-built binaries from php.net.PHP =5.6 are all current builds (as at ).Apache is the current build from Apache Lounge (as at ).Everything is 32bit and all PHP versions are non-thread-safe (nts) versions.There is one test site "test2.local" which contains a single index file. Apache and all PHP builds are installed in a folder named according to their 5 digit Version ID. I have now scaled everything down to a bare bones working configuration which is all shown below if anyone wants to try it out for themselves. Despite this, they return a 404 error with the message "No input file specified". Versions 7.2 and 7.3 however, are only checking for "user.ini" and don't try to access the requested php file at all. Following this, all PHP versions up to 7.1 check for both "user.ini" and the requested php file. SysInternals Process Monitor shows that Apache's "httpd.exe" finds the php files no problem. The Apache logs, if I'm reading them correctly, show that php-cgi.exe is being called correctly and is responsible for returning this status even though the files exist. Everything works perfectly, except that PHP 7.2 and 7.3 return a 404 status for all php files with the message "No input file specified". I'm using this to test Apache 2.4.38 with multiple PHP versions.
#Avrdudess 2.4 Pc
I have an old PC running XP with the One Core API installed. Apologies for the long read, but I think it makes sense to include as much detail as I can upfront, rather than waiting for people to ask for the various configs, logs, etc.
0 kommentar(er)
