Does plugins_url work as we should expect?

  • I’m trying to make Migrate DB Pro a must-use plugin which is turning out to be quite the process. WP Migrate DB Pro uses plugins_url to find the URL it should use for some assets it has. It looks like plugins_url will only use WPMU_PLUGIN_URL if the name of the plugin passed (which WP Migrate DB Pro doesn’t currently) matches the beginning portion of $mu_plugin_dir. Can somebody explain this logic to me? Why not just check if the plugin name is a directory within $mu_plugin_dir?

    In my case, I end up with $plugin containing “wp-migrate-db-pro” (if I alter their code) and $mu_plugin_dir containing “/fullpath/wordpress/company/must-use-plugins”. The must-use-plugins directory has all the plugins I want as must-use separated by directory, so “wp-migrate-db-pro” will never be at the beginning of that path.

    I can work around this issue using the supplied “plugins_url” filter, but it feels like plugins_url doesn’t work as I would expect. Maybe my definition of must-use plugins is wrong…

Viewing 3 replies - 1 through 3 (of 3 total)
  • Moderator bcworkz

    (@bcworkz)

    This is my take own on the situation. I’ve no special knowledge that qualifies me to know the intent of WP core developers. I believe it’s related to the last caveat in Must_Use_Plugins#Caveats. Additionally, plugins don’t necessarily need to have a matching directory name, nor do they need to be in a sub-directory at all.

    The must use plugins feature was initially intended for multi-user network installs. In such cases the administrator is expected to be much more code/tech savvy than the usual WP admins, so little effort was made to make network quirks easy to deal with. If network admins needed something, they’ll figure it out as long as some hook is provided.

    plugins_url() works for most cases, unique situations for a formerly network only provision are still expected to be dealt with via the filter. Such special situations are rare and varied enough that it doesn’t warrant adding additional code in core to handle it. Instead, a filter is offered for those that need it.

    Thread Starter tubaguy50035

    (@tubaguy50035)

    I understand about the caveats associated with must use plugins. The last bullet point under caveats suggests adding a loader and loading all plugins separately.

    Even if I do that, the plugins_url that gets returned is not correct. It just seems odd that there is special behavior for must use plugins in the plugins_url() function at all if it doesn’t work by checking the folders under that directory.

    I respectfully disagree that this is a “special situation”. It seems to me that having multiple must use plugins would be a commonplace tactic if the functionality existed in WordPress to make that happen, but as of now, any plugins using plugins_url() cannot be used this way. I do not see the need to have plugins structured any differently under the must use plugins path versus the regular plugins path, but maybe that’s just me.

    Moderator bcworkz

    (@bcworkz)

    I do know where you’re coming from, and I don’t disagree. I was trying to represent a likely viewpoint of core developers without the benefit of being one. I’m not claiming it’s right or wrong, but I think it at least somewhat represents the situation.

    Since you believe an improved plugins_url() function would benefit a significant number of WP users, I’d encourage you to submit a enhancement request Trac ticket. While Trac is mainly intended for bug reports, enhancement and feature requests are accepted. Do pay attention to the guidelines on the linked page, especially about searching for related tickets. Your request will get more traction if you can provide a patch that provides the functionality you desire, or at least the suggested new code for the function.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Does plugins_url work as we should expect?’ is closed to new replies.