Make WordPress Core

Opened 13 years ago

Closed 11 years ago

Last modified 6 years ago

#19721 closed feature request (wontfix)

WordPress should support multiple or nested plugin directories

Reported by: scottnath's profile scottnath Owned by: scottnath's profile scottnath
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: Plugins Keywords:
Focuses: Cc:

Description

WordPress currently only looks one directory deep for the plugin files. This is a limitation in get_plugins. It should look at least two (or more).

Our setup: We have many sites on WordPress and would like to share a set of plugins across them. However, we also have a requirement where each site should have its own unique set of plugins as well. (I realize this seems like an easy job for Multisite or mu=plugins, but they're not something we can adopt currently for various reasons).

Ideally, we can create a symlink (or external/submodule) to our shared plugins folder from inside the core plugins folder and have WordPress recognize plugins within that folder:

  • plugins Folder
    • hello-dolly.php
    • akismet
      • akismet.php
    • shared-plugins (symlink)
  • shared-plugins folder
    • hello-dolly-enhanced
      • hello-dolly-enhanced.php
    • akismet-enhanced
      • akismet-enhanced.php

Currently, WordPress will ignore both hello-dolly-enhanced and akismet-enhanced.

Themes already support nested folder; plugins should too please!

Thanks,
Scott Nath

Change History (9)

#1 @nacin
13 years ago

Themes only support nested folders when you explicitly register a new theme root. This is designed for plugins that package themes (with BuddyPress in mind when it was implemented). It definitely can't be without explicit registration of a plugin root (for it would suddenly find files it shouldn't have in existing plugins, introducing a backwards compatibility issue).

I do understand why both multisite and mu-plugins do not fit what you are trying to do, but I'm still not convinced we'd need this.

FWIW, there's a way to hide a plugin from plugins.php using the all_plugins hook. That might help you.

#2 @scottnath
13 years ago

Our need is based on sites having multiple environments (dev/qa/stage/prod). We're trying to separate Wordpress Core/load-tested/universally-approved-and-tested plugins (ours and third-party plugins from the Codex) from site-specific files (theme, uploads, plugins folder with plugins only needed for that site.) This gives individual sites a site-specific repository separate from what becomes a network-wide common repository.

MU won't work for us because we need separate databases for each environment of each site as well as different environments required to live on different servers.

No need to hide plugins, as our clients typically don't have access to the plugins list or the ability add plugins on their own.

thanks,
Scott

#3 @alex-ye
12 years ago

  • Cc nashwan.doaqan@… added

#4 @johnbillion
11 years ago

  • Keywords close added; needs-patch removed

I think we should wontfix this. Reasoning:

  • This is very much an edge case, and it can be solved by using build tools or dependency management tools such as Composer.
  • Quite a few existing plugins bundle dropins inside subdirectories. If plugins in subdirectories were listed it would cause those dropins to become visible in the Plugins list. Definitely not desirable.
  • Ticket has had no traction in two years

#5 @SergeyBiryukov
11 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

#6 @ocean90
11 years ago

#28418 was marked as a duplicate.

#8 @ocean90
9 years ago

#36721 was marked as a duplicate.

#9 @KeironLowe
6 years ago

I think the landscape has changed a lot in the past 8 years, and the availability of tools such as composer make features like this more helpful. For example, having a register_plugin_directory method would help a lot when using composer as it would allow us to easily separate our third-party plugins from our first-party plugins and clean up our directory structure.

Note: See TracTickets for help on using tickets.