Make WordPress Core

Opened 18 years ago

Closed 12 years ago

Last modified 12 years ago

#2479 closed defect (bug) (wontfix)

theme functions.php should override pluggable-functions.php

Reported by: technosailor's profile technosailor Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.0.1
Component: Administration Keywords:
Focuses: Cc:


Doing some advanced WP manipulation and have discovered that functions that are declared in pluggable-functions.php are not overrode by theme-based functions.php. If pluggable-functions.php functions can be overrode by plugins, they should be overrode by functions.php as well.

Change History (7)

#1 @masquerade
18 years ago

-1, this goes back to the argument of themes acting too much as plugins.

There is nothing in pluggable functions that a theme should have to overwrite to achieve the full functionality of a theme, anything more should be left as a plugin, as it is a serious change.

#2 @davidhouse
18 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Skeltoac on wp-hackers:

"I don't think so. {theme}/functions.php is not a plugin. It should not
be treated as one.

There are many differences between a theme's functions file and a
plugin. Let's keep it that way."

I agree with masquerade and skeltoac, and as no-one's put forward a convincing argument for this, I'm closing. Reopen if you can provide such an argument.

#3 @tomauger
12 years ago

  • Cc tomaugerdotcom@… added
  • Keywords 2nd-opinion added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Okay, I'm reopening this sucker. Considering this ticket is in the 4-digit range and is from 6 years ago, I think it's worth re-opening the discussion because I think our collective understanding of the role of themeing and themes within the WordPress architecture has evolved considerably since those arguably 'purer' early days.

Consider this use-case:

I'm developing a one-off CMS solution for a customer, with a lot of custom metadata, customization of the Admin back-end, the login/authentication process, the works. And of course, there's the design component - that's where the theme part comes in. Fact is, these are simply not reusable components - they will never apply to another client, they will never be put under GPL and open sourced, and they are most certainly not to be distributed / installed on other WordPress deployments. At best there are some best practices I will leverage on future projects, but that will be strictly a reference / copy-paste job.

This does not sound like a use case for plugins to me. The theme is installed, maybe a child theme of Twenty Eleven, maybe a standalone, its functions.php calls in a boatload of includes, each handling a different aspect of the CMS in question. Then the theme template files use custom 'template tags' that are defined in the includes. I don't want to have theme files with dependencies on some plugin or other being activated, etc. It just doesn't make sense to build complexity into the system. Sure, I can put it in the must-use plugins folder, but that still feels like a hack - right now, _everything_ that has to do with the customizations made for this project are contained in wp-content/themes/my-theme/. I don't also want to have to consider searching for stuff in some plugins folders as well.

Don't get me wrong. I love plugins and I use them and write them. And I do use plugins in conjunction with this sort of highly customized theme development _when_ the plugin is third-party and represents best practices far beyond what I could possibly roll out in a reasonable timeframe. But when I need to modify core functionality for a one-off scenario, I turn to action hooks, filter hooks, and I'd like to be able to rely on pluggable functions for the user and authentication side of things too.

#4 @SergeyBiryukov
12 years ago

  • Keywords functions.php pluggable-functions removed
  • Milestone set to Awaiting Review

#5 @nacin
12 years ago

If you are building this for a single client, you should absolutely take advantage of mu-plugins.

There are a lot of things in WordPress that you can't do in functions.php. Pluggable functions is one of them, but more obvious, a number of hooks (both actions and filters) fire before functions.php. In some cases, these hooks even fire before regular plugins, which then requires you to use mu-plugins or a network-activated plugin. In still other cases, even a mu-plugin is too late. Perhaps you need something in sunrise.php. Or even something (a constant or otherwise) in wp-config.php.

I would rather add some hooks to pluggable functions, than to make it easier to override them. We are not likely to ever again have another pluggable function — they pre-date hooks and I've almost never seen a situation where there is advantage to them over a good old-fashioned (new-fashioned?) hook.

I still agree, six years later, with andy — "There are many differences between a theme's functions file and a plugin. Let's keep it that way."

That all aside, a change like this could never happen. It would break a lot of things. Countless themes call functions in the body of functions.php that would result in a fatal error if pluggable.php hadn't already loaded — like current_user_can(), or wp_create_nonce(). They'd all fail. And it'd break plugins, too, which normally could start calling these functions on plugins_loaded. (Just move pluggable.php lower in wp-settings.php and I bet half of core would break — or at the very least, the customizer would.)

Finally, there's the inevitable idea that a theme could include a separate file like pluggable.php that we could load as early as we load plugins, and therefore could override pluggable functions. Aside from this being a bad idea (see the first four paragraphs of this comment), it would still not be compatible, because up until the setup_theme hook, one could override which theme is to be loaded by filtering stylesheet and template values.

Unfortunately, this just isn't tenable given how WordPress is architected. The good thing is, there are countless (better) ways to do it.

#6 @nacin
12 years ago

  • Keywords 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

I normally wouldn't immediately re-close a ticket, but in this case, it's pretty clear that any change here would cause significant breakage and there is no workaround.

#7 @tomauger
12 years ago

Phew! Thanks for the detailed response @nacin. I totally see how making a change here could cause potential havoc. Let's forget I ever brought it (back) up.

Note: See TracTickets for help on using tickets.