Fixed XF\ComposerAutoload issue on WSL

[Lukas W.]

Affected version

2.2.9

I haven't followed the issue down too deeply, but building a release on my local WSL crashed in XF\ComposerAutoload as the $pathPrefix came in postfixed with a windows directory separator, but the code only attempted to trim the Linux one. Without tracking it down any further, this was a quick-triage to alleviate the issue for me:

 

[PaulB]

We use WSL for our devkit, so I’d like to try to repro this, as I suspect it may be related to other issues we’ve encountered. A few questions, though:

1. WSL1 or WSL2?
2. Is the web/PHP server running in WSL or Windows?
3. Are the PHP files stored on Windows or within WSL’s filesystem?

Note that running PHP within WSL2 but using it to execute files stored within Windows’ filesystem (rather than WSL’s) isn’t supported by PHP and is expected to break in weird ways: https://xenforo.com/community/threa...count-for-faulty-9p-filesystem-driver.187154/

Microsoft doesn’t seem to interested in fixing it, sadly: https://github.com/microsoft/WSL/issues/5074#issuecomment-718919865

 

[K a M a L]

I just had the same issue

An exception occurred: [ErrorException] [E_WARNING] require(/var/www/xf229/src/addons/XFAws/_vendor/composer\/autoload_namespaces.php): failed to open stream: No such file or directory in src/XF/ComposerAutoload.php on line 47
#0 src/XF/ComposerAutoload.php(47): XF::handlePhpError(2, '[E_WARNING] req...', '...', 47, Array)
#1 src/XF/ComposerAutoload.php(47): require()
#2 src/XF.php(278): XF\ComposerAutoload->autoloadNamespaces(false)
#3 src/XF/App.php(2337): XF::registerComposerAutoloadData('...', Array)
#4 src/XF/App.php(1896): XF\App->setupAddOnComposerAutoload()
#5 src/XF/Cli/App.php(25): XF\App->setup()
#6 src/XF.php(497): XF\Cli\App->setup(Array)
#7 src/XF/Cli/Runner.php(54): XF::setupApp('XF\\Cli\\App')
#8 cmd.php(15): XF\Cli\Runner->run()
#9 {main}

 

[PaulB]

@K a M a L, any chance you could answer the questions in my previous post?

 

[K a M a L]

We use WSL for our devkit, so I’d like to try to repro this, as I suspect it may be related to other issues we’ve encountered. A few questions, though:

1. WSL1 or WSL2?
2. Is the web/PHP server running in WSL or Windows?
3. Are the PHP files stored on Windows or within WSL’s filesystem?

Note that running PHP within WSL2 but using it to execute files stored within Windows’ filesystem (rather than WSL’s) isn’t supported by PHP and is expected to break in weird ways: https://xenforo.com/community/threa...count-for-faulty-9p-filesystem-driver.187154/

Microsoft doesn’t seem to interested in fixing it, sadly: https://github.com/microsoft/WSL/issues/5074#issuecomment-718919865

@PaulB .. sure

1- WSL2
2- WSL
3- WSL's File System

 

[PaulB]

@K a M a L Did you allow Composer to run from Windows (or and IDE like PhpStorm) at any point?

 

[K a M a L]

@K a M a L Did you allow Composer to run from Windows (or and IDE like PhpStorm) at any point?

on Xenforo related directories ?
No, as you see from stack trace the error occurred with the official XFAws addon not something I created.

 

[PaulB]

No, as you see from stack trace the error occurred with the official XFAws addon not something I created.

It didn't really come from XFAws; it's just hitting the issue while trying to load that add-on. At some point, rebuildActiveAddOnCache ran from Windows. Once that's happened, you've corrupted your add-on cache.

You have to make absolutely certain you're only invoking PHP from within WSL, never from within Windows. That can be difficult because PhpStorm will prompt you to run Composer at times. In your case, at some point, some XenForo script--likely cmd.php--was run from Windows, and now your cache has Windows directory separators. Subsequent invocations from within WSL will result in the stack trace you're seeing.

 

[PaulB]

If you run the following SQL query:

select cast(data_value as char) from xf_data_registry where data_key = 'addOnsComposer'\G

you'll likely see something that looks like this:

a:1:{s:5:"XFAws";a:5:{s:13:"autoload_path";s:17:"_vendor/composer\";s:10:"namespaces";b:1;s:4:"psr4";b:1;s:8:"classmap";b:1;s:5:"files";b:1;}}

Notice that autoload_path has a backslash at the end. You need it to be a forward slash. You can clear that cache entry using the following query, but I haven't tested this, so don't do it on production.

delete from xf_data_registry where data_key in ('addOns', 'addOnsComposer');  -- DON'T RUN IN PRODUCTION

You may continue to encounter other issues. It's probably best to do a clean installation and completely remove PHP from the host so you don't accidentally run it from Windows.

 

[PaulB]

If someone like @Chris D wants to provide a better workaround, that'd be appreciated, as I suspect this is a common issue on Windows. Modern IDEs make it all too easy to fall into this trap. @Lukas W.'s ComposerAutoload.php fix will at least prevent further recurrences in the autoloader.

 

[K a M a L]

I don't usually use WSL .. I used it temporarily for some reason so I wasn't interested on spending time tracking the problem but the files and database there were copied from development setup originally running on windows so your conclusion about using rebuildActiveAddOnCache may be correct

 

[PaulB]

I don't usually use WSL .. I used it temporarily for some reason so I wasn't interested on spending time tracking the problem but the files and database there were copied from development setup originally running on windows so your conclusion about using rebuildActiveAddOnCache may be correct

That would definitely do it. The same applies if you copy the database from Windows to Linux or macOS in an attempt to migrate. This isn't specific to WSL.

 

[Chris D]

Notice that autoload_path has a backslash at the end. You need it to be a forward slash. You can clear that cache entry using the following query, but I haven't tested this, so don't do it on production.

delete from xf_data_registry where data_key in ('addOns', 'addOnsComposer'); -- DON'T RUN IN PRODUCTION

Clearing them in production should be okay as they'll be rebuilt the next time we try to access them.

Rebuilding the active add-on cache is also done in various places so disabling/enabling an add-on, upgrading XF, or anything else that triggers a core cache rebuild like upgrading XF, or rebuilding master data will also rebuild it.

If I've followed the bug report correctly, I think all we need to do is implement the changes recommended by @Lukas W. and that should sort it. Anyone running into issues can probably disable listeners in the short term.

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.12).

Change log:

Better support cross platform directory separator trimming in ComposerAutoload

There may be a delay before changes are rolled out to the XenForo Community.