Should WordPress be modular?

[Elpie]

It seems there are a lot of us who spend more time removing things we don't want than adding new things to WordPress. It seems to me that, apart from improving on existing features, WordPress has pretty much filled the kitchen sink.

WordPress 3.0 was a major leap forward but it also seems to have left some people behind. I'm working with a company that won't move off 2.9.2 because they feel they have no need to do so. The main reasons for this are that they don't need or want any of the features in 3.x and are happy to maintain their own security fixes.

The other argument they used was that they believe that the more stuff that goes into WordPress the harder it is for them to safely remove the unwanted features.

On their site, they have hacked the core extensively. The media manager and editor have been replaced. They have a custom dashboard. Roles have been extended.

I got to thinking how much better WordPress would be if it consisted of a solid core and all the extras, like the media manager, editor, etc were addons. I know this is how some other CMS work and the simplicity of WordPress has benefited from not going that way. But WordPress is moving much closer to being a CMS now and is so feature-rich that maybe going to a modular design would be a good move. It's not a big stretch from the idea of core plugins.

What do you think?

[Ryan]

I think it's a great idea, but the core team seem quite disinterested in moving in that direction from what I can tell.

[Jeffro]

It's not a big stretch from the idea of core plugins.

I thought that the idea of core plugins was exactly this. Take chunks of WordPress functionality and turn them into core plugins that could be enabled or disabled providing users the opportunity to decide how fat or lean the core of WordPress would be. However, it seems like the activity and focus around the idea of core plugins has stagnated.

[Ryan]

I can't remember who or where, but I do recall one of the core developers explicitly state that core plugins were not intended to be for functionality removed from core, but for additional functionality on top of the existing code base.

[Jeffro]

I can't remember who or where, but I do recall one of the core developers explicitly state that core plugins were not intended to be for functionality removed from core, but for additional functionality on top of the existing code base.

From the outside looking in, that sure does seem stupid if that was the case. I'd have to ask what the point was if that was the plan.

[Otto]

The point was there was a lot of interest in features that were generally deemed not general enough for the core itself, but which were nevertheless useful ideas that a lot of people would use. So the core plugin concept was devised to describe plugins which would be supported by the core team (or at least some of them) and kept up to date with the core as needed. This sort of stagnated when nobody stepped up to make any core plugins to start with.

As it stands, there's a fair number of plugins that already sort of fall into this category, there's just not a lot of interest in tracking them along with the core development. Most of the plugins actually used by the core team (that I've seen at least) tend to be very simple type of adjustments for personal wants and such. I like to state that I run more plugins than anybody (I have 51 network activated plugins right now), but the reality is that like almost all of them are under 10 lines of code. Minor little tweaks here and there. I tend to put each adjustment I make into a new plugin so that I can disable or enable them individually.

[Ryan]

I like to state that I run more plugins than anybody (I have 51 network activated plugins right now), but the reality is that like almost all of them are under 10 lines of code. Minor little tweaks here and there. I tend to put each adjustment I make into a new plugin so that I can disable or enable them individually.

Me too. I only have about 30 network activated plugins though.