daggerhart / lark Goto Github PK

Whenever there is a vendor/autoload.php file within the WP project root (which is common for my projects), Lark loads this file in certain cases instead of its own autoloader. This seems to be due to the way Lark uses a relative file path within the require statement that pulls in its autoloader; and it looks like a quick and reasonable fix would be to use the DIR constant within the require statement.

When in "normal" mode and viewing a project in a web browser, there is no noticeable issue. But when using xdebug to set breakpoints and debug certain pages, it does become an issue. My guess is that this happens because xdebug is operating in a PHP CLI environment, and so the relative require path for Lark's autoloader ends up pointing to the CLI environment's current working directory instead of the lark plugin directory.

There are several ways that I have experienced this either breaking or not breaking the site in question when developing locally. But using WP CLI is the most straightforward way I can find to reproduce the issue in a general context.

Steps to reproduce issue with WP CLI:

• Begin with any locally-installed WP project where the Lark plugin is installed and activated

• Make sure the master branch of the Lark plugin within the project is checked out

• Within a terminal window, change to the project's WP root directory

• Issue the command wp shell to enter WP CLI's interactive mode more info

• At the interactive prompt, type class_exists('Lark\Transaction') and then hit Enter. The response should say bool(true) which confirms that the WordPress installation does in fact recognize the class name. So far, the Lark autoloader is working fine.

• Next, type exit in order to leave interactive mode (important for reproducing the issue)

• Create a new file within the WP root directory named vendor/autoload.php. This can be a blank file, but the point is that it simulates a project which might have its own composer autoloader in the WP root.

• Re-enter interactive mode by again issuing the wp shell command; again from the WP project root directory

• Type the same PHP expression as before -- class_exists('Lark\Transaction') -- and confirm that WP no longer recognizes the class name and the response is now bool(false)

Note that if you enter interactive mode from inside the lark directory, the class in question exists in all cases, since the relative path within the require statement is now operating from the correct directory.

However, if we add the DIR constant before the require statement, things will always work no matter which directory we happen to be in.