Roadmap idea

Projects Core Development
1

I generally don’t play on github or slack - so if you think this idea is worth it, someone else make it over there if appropriate…

And yes, this is my first post, I created an account just for this. Now the idea…

In the 3D world, when designing a plant or control system you don’t care about what goes on inside any component (a pump is a pump, regardless of complexity or whiz-bangs - that’s the manufacturer’s headache). You only need to know how to talk to it.

In the case of CP, this is kinda like a plugin. So…as CP is developed going forward, why not make everything a plugin?

Essentially the “core” become nothing more than a plugin architecture. Editors, comment sections, database, admin pages, it’s all a plugin. And thus becomes a self contained “black box” insofar as the core is concerned.

– What’s the default editor? It’s just a blank text input box like this without any formatting or anything else. You just type (or paste) raw html or javascript. Want a fancier editor? Install the plugin. And even that “default” editor is a plugin.

– What database do you want? Flat file? MySQL, something else? It’s a plugin.

– Want your custom theme to use that (horrible) "customizer? It’s a plugin (that you list as a dependency in your theme). Don’t care about it? Your theme doesn’t have to use it (or even install it).

– Want comments? Load a plugin.

– Want to create a blog network at any time (subdir or subdomains)? Load a plugin.

You could even select (during install) what your default plugins are.

Yes this would be a MAJOR redesign of the core. But it would free up the core team from having to deal with any of the other issues. And a plugin architecture (almost inherently) can remain backwards compatible.

Just an idea to make things (maybe) more manageable.

JS

6 Likes
2

I like the way you think, and I’d love this model too. But it’s a bit idealistic: too complicated and ambicious for a fork. The next logical step is to leave WP behind and develop a visual clone based on a proper framework :smile:

But I think you are totally right in your basic statements. Less is more. WP increases excessive functionality, and CP could make a great contrast throwing away all stuff useless for commercial projects and solving some legacy problems.

I support many sites based on WP. And here are some most common questions asked by all clients:

  • How do I change nav menu items? (They can’t imagine why menus belong to ‘Appearance’).
  • What’s the difference between Posts and Pages? (As 90% sites use hierarchical custom posts - catalogs etc.- this difference becomes too abstract and artificial for them. In addition words Page and Post loose some context via localization, so new people are confused).

My clients do not use:

  • dashboard (current data doesn’t match their real daily interests),
  • REST API,
  • comments,
  • RSS,
  • theme customizer (the most useless, since they pay for a custom theme development),
  • password protection (as they manage access by roles and don’t keep real secrets in public area),
  • publication via email (no need and poor flexibility),
  • pings,
  • manual import/export (as it depends on lower level tools for managing backups and deploys).

I don’t mean that my situation is typical for all cases. Just giving information for statistics and illustrating the difference between business goals and current WP priorities. I think that CP should keep focusing on business goals. So moving useless ‘user-can-do-it-himself’ stuff to plugins is the right way and the key benefit. WP tends to please mass users, CP could be a solution for developers. In that aspect I agree with johnstrasser’s idea.

5 Likes
3

We have the petitions for that…
It’s a “good” idea to strip the unnecessary… But… I think there’s the risk to strip too much.
Moving things into core plugin however is the direction CP is taking. Who knows what it will be like in 10 years.

2 Likes
4

As @ElisabettaCarrara says, there are moves in this area already. I think REST and Emoticons are two on the agenda for moving to core plugins. Others in future would be guided by the petitions process.

2 Likes
5

We are already moving this direction with V2: ClassicPress | Stable. Lightweight. Instantly Familiar.

But I do agree, I like the idea on principle but trying to rework the foundation to support it is a big task that would probably span multiple ‘major’ versions. I think the roadmap for v2 is a great start in that direction though :slight_smile:

6 Likes
6

I like @johnstrasser thinking too. Not sure if it is possible in theory but a neat idea. I played with Perch CMS for a while and it does a bit of that… separates the theme completely, so the CMS is just handling content via a very simple admin backend. You insert editable areas into the page.

And @norske I agree with all of your “unnecessary” components. My clients don’t use any of those either.

Interesting discussion. :clap:

6 Likes
7

Thanks folks (sorry for my absence - life). At least I know I’m NOT crazy (on this front at least…).

I’ll take a look at the petitions stuff

JS

3 Likes
9

Splitting stuff out into plugins will make it clear to users that the sort of things that give you nightmares exist. I think we’ll be defaulting to leaving them on for existing sites, in case it breaks things. But we could default to having them off for new sites.

1 Like
10

Our work on v2 will be much more limited in scope than this. We will be building our own plugin directory and using it to split out a few less-used features into plugins. You can see the likely candidates here - Issues · ClassicPress/ClassicPress · GitHub - but it’s unlikely that we will be able to remove all of these in time for v2.

Please go to petitions.classicpress.net and start a new entry for removing/disabling the Post by Email feature. Personally I think this is a good candidate but we need to make these decisions democratically, and right now this is the tool we use to enable this process.

3 Likes