Local Community

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

Commenting to keep this post alive as this issue has existed for a long time and previous tickets have been auto-closed.

Edit: thank you @ben.turner for moving the other topics and re-opening this ticket!

1 Like

Same issue here. Doesn’t work on my D:\ drive.

Local version 5.10.5+5403. PHP 7.4.1, Apache, MariaDB 10.4.10

My solution: create a symlink. The Quick Guide to Creating Symbolic Links (Symlinks) in Windows 10 (makeuseof.com)

It makes Windows/Local think that the file is in the C: drive when its actually in D:

It should still be fixed though by the devs…

Edit: After all of that, the site was EXCRUCIATINGLY slow, both on Apache and NGINX, so I uninstalled it and replaced with DesktopServer. Not as slick looking, but easy enough to set up and quite zippy. Given the amazingly poor support that I’ve seen in the forums here, I can only conclude Local is a joke.

Hey everyone, just wanted to give an update here. I am actively working on a resolution to this, but it is a surprisingly challenging issue. I’ll provide updates as I have them!

2 Likes

Another update: this should be resolved in Local 6.1.1! You can find the release notes here:

https://localwp.com/releases/6.1.1/

In order to get this fix, you’ll need to manually upgrade any PHP lightning services that have already been downloaded. We’re working on making the service update process better, but in the meantime, can you try the steps outlined in this FAQ:

Please let us know if you continue to run into issues after updating and performing these steps.

1 Like

Unfortunately still not working for me. I am on 6.1.1+5468 and I imported a new site after deleting the PHP version 7.4.1 and I’m still getting the error. The site will only run on 5.6.39.

Ohh no!

Can you please provide an updated version of the Local Log so we can see what’s going on? See this Community Forum post for instructions on how to do so:

local-lightning.log (895.4 KB)

Looking at that Local log, it seems like maybe there was an issue importing that site:

{"thread":"main","class":"ImporterGeneric","stack":"Error: ERROR 1050 (42S01) at line 11: Table 'wp_commentmeta' already exists\n    at %%appPath%%\\main\\_helpers\\importSQLFile.js:1:2105\n    at Generator.next (<anonymous>)\n    at a (%%appPath%%\\main\\_helpers\\importSQLFile.js:1:132)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (internal/process/task_queues.js:93:5)","level":"error","message":"Unable to import E:/Websites/_psc/Evidence Based Classroom Solutions/app/sql/20200813_evidencebasedclassroomsoluti_933f8057c2b07f956734_20200813145139_database.sql","timestamp":"2021-08-18T10:48:51.088Z"}

In particular, it seems like maybe the SQL dump isn’t correct and has multiple wp_commentmeta tables.

You might need to open up the sql file that’s trying to be imported and remove any sections that point to there being multiple tables.

As a test to see if this feature is resolved for you, can you try creating a new, plain WordPress site that is using Apache?

I can try to create a new site and see if that works but the issue with the table has something to do with the fact that I am using a remote database. In the previous version of Local I was able to just use the db name, user, password, and ip address but now for some reason in the latest version there is a port assigned and I have to include the port in the ip address. So for example, for all of my sites that use a remote database (staging) the format is xxx.xxx.xxx.xxx:1234, where 1234 is the port number of the remote server’s mysql application.

1 Like

Unfortunately, even when I try to create a new test site in Local I get the same issue “No input file specified.”. Attached is the updatedlocal-lightning.log (905.7 KB) log.

Any update Ben?

Very interesting!

Looking at the Local log, the only thing that comes to mind are these two lines:

{"thread":"main","class":"Process","process":"httpd","level":"warn","message":"AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using fe80::9560:c258:b9b4:f395. Set the 'ServerName' directive globally to suppress this message","timestamp":"2021-08-19T18:22:36.977Z"}
{"thread":"main","class":"HostsFileService","stdout":"Updating hosts file at  C:\\WINDOWS\\System32\\drivers\\etc\\hosts\nUpdated hosts file at  C:\\WINDOWS\\System32\\drivers\\etc\\hosts\n","stderr":"","level":"info","message":"Updated hosts.","timestamp":"2021-08-19T18:22:40.796Z"}

Note this part:

AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using fe80::9560:c258:b9b4:f395

Which is basically telling us that Apache is trying to use the IPv6 version as the server’s name. I don’t know for sure if that would cause issues, but looking over my Local log, all of the entries for when I’ve created Apache sites have used IPv4:

Do you know if you have any custom configuration within the computer’s Hosts file? I wouldn’t think it’s an issue, but do you have a VPN?

@ben I’m not using a VPN or anything customized in my hosts file. Attached Clipboard01 is the hosts section related to the test site that I set up using Apache.

What is the site name in Local, eg my-site.local

I can make out the attached graphic.

geez sorry about that not sure why it attached so lo-res. The site name is test-site.d4tw

::1 test-site.d4tw #Local Site
127.0.0.1 test-site.d4tw #Local Site
::1 www.test-site.d4tw #Local Site
127.0.0.1 www.test-site.d4tw #Local Site

I don’t know if the .d4tw Is an issue, can you change it to something like .local or .test to see if it makes a difference?

Didn’t make a difference changing to test-site.local

Try nginx instead of Apache, just for fun.

That works fine but I need Apache.

How was the domain changed? Did you change it only in the hosts file, or through the Local “Site Domain” field?

Alternatively, if you create a new apache site with the .local top-level-domain, does that work for you?

If you still have issues, I’d be interested in seeing a screencast so that I can better visualize where things are breaking down. Also, can you provide an updated version of the Local log for us to look at?