Bug: Issue with `plugin_dir_url()` in mu-plugins installed from local path

rafaucau commented 1 year ago

Terms

[X] I have read the guidelines for Contributing to Roots Projects
[X] This request is not a duplicate of an existing issue
[X] I have read the docs and followed them (if applicable)
[X] I have seached the Roots Discourse for answers and followed them (if applicable)
[X] This is not a personal support request that should be posted on the Roots Discourse community

Description

When Composer installs mu-plugins from a local directory using symlinks, the plugin_dir_url( __FILE__ ) function returns an incorrect URL. This issue only occurs in mu-plugins and not in regular plugins. Instead of returning a URL like https://example.com/app/mu-plugins/my-plugin/, it returns https://example.com/app/plugins/var/www/domain/packages/plugins/my-plugin/.

Bedrock composer.json:

...
  "repositories": [
    ...
    {
      "type": "path",
      "url": "packages/plugins/*"
    },
    {
      "type": "path",
      "url": "packages/themes/*"
    },
    ...
  ],
...

Plugin composer.json

{
  "name": "my/plugin",
  "type": "wordpress-muplugin",
  "extra": {
    "installer-name": "my-plugin"
  }
}

Steps To Reproduce

Install a mu-plugin in from a local directory using Composer
Use the plugin_dir_url() function in the plugin file
Notice that the returned URL is incorrect

Expected Behavior

The plugin_dir_url() function should return the correct URL for mu-plugins installed via Composer symlink, just as it does for regular plugins.

Actual Behavior

The function returns an incorrect URL for mu-plugins installed via Composer symlink.

Relevant Log Output

No response

Versions

1.21.1

QWp6t commented 1 year ago

You need to configure your repository path strategy to mirror instead of symlink.

For community support, please post on Roots Discourse. https://discourse.roots.io/

rafaucau commented 1 year ago

@QWp6t Thanks for the suggestion, but this is not a support question. Configuring the repository path strategy to mirror instead of symlink won't work for local development since it would require running composer update after every change. Plus, the issue only occurs in mu-plugins, so it's likely a problem with the Bedrock autoloader.

I believe that this issue is a bug that should be fixed to ensure that plugin_dir_url works correctly for mu-plugins installed via Composer symlink. Therefore, I would like to request that the Issue be reopened.

QWp6t commented 1 year ago

Gotcha! If this is only happening with mu-plugins, then you're right, it could be related to Bedrock Autoloader.

I'll take a peek at this tomorrow.

QWp6t commented 1 year ago

I haven't tested this yet but looking at your code again, I would expect that this is really just a composer config issue. Using __FILE__ is going to point to the real path to the file, not the symlinked one. WordPress has no way of knowing that you're referencing a symlinked file inside of mu-plugins when the path you're passing to plugin_dir_url() is outside of mu-plugins.

I don't think this is a mu-plugins issue, and I don't think this is related to Bedrock or Bedrock Autoloader.

I think it just boils down to your specific environment and application code.

But again, I'll double check tomorrow. 👍

rafaucau commented 1 year ago

Here's an example. I created two identical plugins that display plugin_dir_url, with the only difference being that one is a regular plugin and the other is a mu-plugin

alwaysblank commented 1 year ago

Could this be connected to the path concatenation here, especially that my-plugins conditional (which may be failing oddly): https://developer.wordpress.org/reference/functions/plugins_url/#source

QWp6t commented 1 year ago

Yeah, @alwaysblank, that's exactly what I was suspecting might be going on. I'll test this theory later today by setting up a symlinked directory in mu-plugins and load it manually, with bedrock autoloader removed from the equation.

if we see this same behavior, then this isn't a bedrock or bedrock autoloader issue. it's a wordpress issue.

QWp6t commented 1 year ago

Yes, I can confirm that this issue persists on vanilla WordPress installation with symlinked mu-plugin without Bedrock or Bedrock Autloader.

I appreciate that you took the time to report this and pushed for a resolution, but unfortunately it's outside the scope of Bedrock and Bedrock Autloader as this is due to code in WordPress core. I would encourage you to file an upstream report with the WordPress folks.

roots / bedrock-autoloader