WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 months ago

#19721 closed feature request (wontfix)

WordPress should support multiple or nested plugin directories

Reported by: scottnath Owned by: 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 (5)

comment:1 nacin2 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.

comment:2 scottnath2 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

comment:3 alex-ye18 months ago

  • Cc nashwan.doaqan@… added

comment:4 johnbillion2 months 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

comment:5 SergeyBiryukov2 months ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.