I still haven’t been able to meet up with my co-worker about his issue.
However, this morning I went to pull a site again and the issue popped up again. There were no other sites running when I pulled. Like before it seems to fail during the search/replace.
I’ve attached a screen shot of the error, a copy of the logs and a screenshot of what appears when I try to open the site after a failure. I’m not sure if that last one is relevant. In case it is there are about 5 files that are required in the wp-settings.php that I can disable in the Local copy of the file that will then allow me to log in. Since the search/replace failed it does take me to the remote site but the local wp-settings is a bit wonky after a failure.
The fatal error message seems to be saying that WordPress is trying to include a file (class-wp-token-map.php) that it cannot find. This might mean the file is missing, corrupted, or has incorrect permissions.
Do any of your sites on WPE have customized WordPress Core files? That could be causing a problem with the imports. If the sites shouldn’t have any kind of Core file customizations, then you could try resetting them with a default Core file set to refresh.
Another thing you could try is resetting file permissions to make sure that isn’t the issue either:
I’m not sure why the first pull attempt fails and the second works, unless something is getting reset just in the process of reattempting.
No, these are all stock installs. Various theme’s too. All sites are at least 6.5.5 and match the remote servers WP version and PHP versions.
I’ve been running into this issue still but I have a system that seems to be working 100% now.
After an unsuccessful pull I noticed that when I’d start the Local site I’d get the fatal error like the one I posted the screenshot of showing the “failed to open stream” error. I opened the wp-settings.php and commented out all lines that would come up. Then the site would start but since the search/replace failed it would take me to the remote URL instead of Local. However, after doing that I can now successfully pull and the process will work as expected. I’ve been able to repeat this a number of times and unless I comment out the files the site will fail to pull correctly.
Here is a list of the lines that I’m having to comment out:
I went back up and looked at your last Local log, and the most recent errors were referencing that the site was using PHP 7.4, but when I look at the site on WPE now, it’s using PHP 8.2. Just to double check what you said about the versions matching. Was that the case for for that site or something you’ve updated since?
Which site was showing 7.4? It’s possible that it’s an older site that might have been in there. There are two sites that we are doing heavy development on currently and I did verify that PHP versions match, at least as close as possible since most of the WPE sites are 8.2 and the Local options are usually a point release or two off.
I did test the PHP versions on one site that’s been problematic. Tried 8.1.29, 8.10, 8.20 locally and the site on WPE shows 8.2.
I did get a moment to troubleshoot with my co-worker and I did confirm that his issue is the same as mine. We were even able to get a successful pull after removing the 5 lines in wp-settings.php.
I have no idea what those files have to do with anything other than deleting / commenting them out guarantees that the import and search/replace will work as expected.
This should ensure that any missing WP files are restored locally. Then you could then try the pull again.
Local would normally sync those missing files, but something (we aren’t sure what) seems to be causing unexpected issues during the pull. There have been some SSH Gateway issues and platform maintenance on the WPE side that could be related, but these only impacted certain specific instances, so I’m unsure off-hand if your installs were impacted. If we need to check that I can sync with WPE support. We’ve also been seeing issues with users who are utilizing the MacOS 15 Beta release that came out this summer which hasn’t been functioning normally with Local Connect. The public release isn’t due until this fall, so we haven’t been able to dig into that yet to get a patch done.
I am currently running 14.6.1 and this issue has followed me through 14.5 and 14.6.
My Coworker is running 14.4.
I did as you requested and ran into the same issue. Failed on search/replace with errors regarding the missing files. I’ve attached the most recent logs just in case.
Applying the same wp core download --version=latest --skip-content --force correction locally if it’s an existing site stored locally.
Whenever you use “select files”, please could you and your coworker be sure to untick the wp-admin and wp-includes folders before pushing/pulling?
I suspect the Failed to open stream: No such file or directory for missing or deleted files such as class-wp-token-map.php come from modifications to core files during push/pull. As it causes a fatal error the issue manifests as a failure when the WP-CLI find-replace command runs.
By preventing Local from modifying wp-admin or wp-includes on pull/push when using “select files”, it should better ensure a stable WP state locally and prevent the errors about missing files.
Do you want me to try the first suggestion before a pull or after?
Also, to be clear we are never pushing to these sites, we only pull. This is part of the frustration since we normally would be pulling often to keep up with any work that is outside of the theme’s files.
Here are a few things that are on my mind;
If the sites and the local environments are showing the same WP version, how/why do they seem to become mismatched? I compared the WPE site’s wp-settings to the Local version and the Local version is the only one that has the extra lines that are causing the error. I also checked a few other sites on WPE and none had the lines requiring the missing files.What is odd to me is that even after I comment them out they are somehow restored. It seems that wp-settings with the extra require lines is being installed/created/modified on the Local side of things. I used the cli check the WP version in my Local site and it shows as 6.5.5 but yet is has some 6.6 code in it.
The lines that are causing the error’s weren’t in WP until 6.6 (WP_Token_Map – Class | Developer.WordPress.org). According to the the git commits in the wp repo all of the files in question were added at the same time, 3 months ago, around the time that we started experiencing this issue.
I did have to do a pull and neither wp-admin nor wp-includes were options to pull in either “only newer files” or “all modified files”.
Thanks for your response and patience with this, @clerick.
Do you want me to try the first suggestion before a pull or after?
Before: it’s intended to ensure that the local WP install is in a known-good state before pulling.
I did have to do a pull and neither wp-admin nor wp-includes were options to pull in either “only newer files” or “all modified files”.
Did you still end up with a broken state on pull that time? I would only expect WP core files to be missing if you pulled while modifying wp-admin or wp-includes files.
If Local were to change its push/pull behaviour to never push/pull wp-admin or wp-includes and only modify wp-content, would that cause issues for you? It seems that modifying these files is the source of push/pull errors for many, but I wasn’t sure if your workflow expects Local to modify core WP files.
In the last week or so I’ve been paying close attention to the before and after.
Verify using wp-cli the WP version of both the host and Local installs. They both reported as 6.5.5
I tried ‘core download --version=latest --skip-content --force’ with no positive effect.
PHP versions were within a point release or two. I tried setting Local to older and newer versions with no change in failure.
At no time did I see the wp-settings file as part of the pull from the host.
The wp-settings file was being changed somehow. After a time, with no obvious signs as to why, the lines that I had removed/commented out to get WP to start would be back and I’d have to do it all over again.
I went to the WP git repo and found that all of the files wp-settings was trying to include were released in 6.6. So why were they in a version 6.5.5 install?
Based on that I upgraded the WP version on both the host and Local and have been problem free on that site and I will be trying on more.
I don’t know for certain but it feels like my Local was running a different version of WP than was being reported. The biggest one being that wp-settings file. The version that I was seeing wasn’t merged in WP until 6.6, so why did I have it and what kept overwriting it?
For now it seems like upgrading WP in both locations works and that for whatever reason version 6.5.5 is just acting up in Local for us.
Thanks for sharing your findings, @clerick, and sorry this was harder than it should be! I’m glad that upgrading to 6.6 on both sides helped in the end.
From the thread here I don’t see any stand-out cause of those local WP core files being deleted. But one thing you could try if you encounter this again is to delete Local’s cache of WP core, just in case that happened to be corrupt.
