No input file specified using PHP 7.3.5 or 7.4.1 ... 5.6.39 works

Support
66

I still have the same issue - can’t have local running with Apache → “No input file specified.”
I need PHP 7.4.1 since my PROD server does not serve 8.0 (yet).
This seems around pretty long - isn’t it possible to fix this?

67

It’s not possible without changing some very fundamental ways in which Local works. This will likely not be worked on soon and possible not worked on ever.

My recommendation would be to either:

  • Use nginx as opposed to Apache, since Nginx can handle being on a different partition
  • Move the sites to the same, C:\ drive as the User’s folder
68

Ben, I hope we can get some clarity on exactly what the issue is, and the position there about how to address it. I’ve researched this deeply down to the specific C code where this message originates, and I’m not getting the feeling that you folks have been down the same path.

  1. The issue is from PHP, not Apache. The text comes from sapi/cgi/cgi_main.c, in this block.
  2. Apache does “work” with DocumentRoot in another drive. In a new Local site in D:, strip out WordPress and HTML pages execute with no problem.
  3. We got a clue in the very first post to this thread, that PHP 5.6 works but 7.4 does not. OK, compare the Local-generated site.config files for a site running v7 and another with v5. The directives for fcgid_module are different, and so are the rewrite rules.
  4. The problem seems to be that Apache is passing a bad URI to the above code, either a bad path or a bad filename, we can’t tell yet. But apparently with the same version of Apache, something different is being passed to PHP when the PHP versions are different.
  5. What is the php_cgi.exe file under lightning-services? It seems the version for PHP 5 is working and the version for PHP v7 and v8 are not. Is that your (Local/Flywheel/WPEngine) code? OK, what changed in that code from the v5 version to the v7 version? Specifically at the point where a .php file URI is passed to PHP for processing?
  6. If that is not your code, nothing else changed for fcgid_module. Let’s look at mod_rewrite. That code didn’t change but the RewriteCond/Rule directives did significantly. Wouldn’t it be great if all we need to do is to figure out what bad URI is getting passed to PHP so that we can just rewrite it again to fix it?

Summary

Your quote above seems to indicate that you know what the problem is now, almost certainly that the issue is in a regression introduced in php_cgi.exe, and that you folks determined that you really don’t want to fix it. But it’s possible that you didn’t really find the problem, or that the problem might be in the rewrite directives. We don’t know. We’re in the dark out here. I’m hoping for more transparency in what’s happened here so that we understand what we might be able to do, collectively, to find a solution, or to agree to move on with a work-around.

I know you folks provide your own custom build of some underpinnings. That’s generally bad news, but of course we appreciate that it all works so well here, except for in cases like this. If you folks actually do compile PHP from source, and modify it in any way, I suggest that you can shim the php_fopen_primary_script() function to coerce whatever bad URI you’re sending to it into something that can actually be read! That does not involve any fundamental change to Local or your (?) php_cgi.exe.

As to the work-around - I’ve been using junctions with no issues whatsoever. I’ve documented how to use them with Local - I just haven’t published any notes. If that is the solution then let’s make it clear and point to some docs. Some people are concerned about performance over junctions. Granted, some sites could have such concerns - but at least for developers that shouldn’t be an issue. And in an all SSD environment that might not be an issue at all. The point here is - that solution should not be regarded as a poor option, as it seems to be in this thread.

C’mon now, speaking for myself, the last response here was greatly appreciated for its candor, but it left us in a limbo. Can we work just a little harder to nail this and move on? I’m happy to help.

Thanks!

2 Likes
69

I just created a new site to do some testing on WordPress 6.0, PHP 8, MySQL 8. I encountered this issue right from the start. Running Local 6.4.0. No response from developers or management? That’s sad. This could be managed so much better - this is no longer really a technical issue. :frowning:

I would hope that there could be a process implemented that tested a connection to see if it returns this error, so that the Local configuration page can display a message like “Local has detected a configuration issue that results in a ‘No input file specified error’. See this localwp.com page for tips to remedy this common condition.”

70

I also suffered the same but when I changed from my custom location e.g. D drive to default local path e.g. c:.…Local Sites\ it worked

2 Likes