The problem with relying on WP Software while running CP

This is bogus. There are thousands of plugins and themes that do not interface with the new changes in WP, so they continue to work. Some might need updates for PHP version though.

2 Likes

I think in time CP will differentiate enough for that not to work. For example considering the fact we will ship libraries so plugins/themes won’t need to include them. This means having basically two versions of the plugin. One using WP standards and one that uses CP’s and doesn’t ship libraries to avoid conflicts. Also, the more CP develops, the more it can get something different from what WP 4.9 was. Just continuing to tell people that they can use WP ecosystem to win them over won’t work in the long run, they will be frustrated when they’ll see their theme doesn’t render images alignment or custom CSS as did mine, or that a famous plugin causes errors. And they will leave for something else entirely not wanting to wait for us to develop a stable and working ecosystem of our own. That is why we should ship the infrastructure and a set of vetted plugins and at least a theme for V2 IMHO. To show people we are getting there. And retain their trust in what CP can be in the future.

Plugins and themes already fail now if they simply use one tiny function not in cp (and that’s not just blocks stuff, there’s a whole more).

Read this thread here to see at least one person even experienced security issues due to plugins dropping support for older wp versions.

Definitely it’s not bogus seeing the future coming which is already here:
Plugins, and themes will not work smooth anymore with WordPress 4.9 very soon and most big ones of them already don’t anymore, this is just a fact.

Toolset, elementor, yoast, astra, kadence, those are names come to mind of big, actively developed plugins and themes and they all won’t work with cp.
Metabox is officially compatible but stated “as long it works”. Big lol on that. If someone’s going to develop a process website or use cp in a professional environment then they won’t be able to use any of that stuff, because not working means not working and “as long it works” is like almost the same.

There are literally thousands of people who’d love nothing more than old traditional editor as cp has it and do also use it thru the disable gb plugin but also want those themes or plug-ins.

As said prior, wp 4.9 has nothing to do with Gutenberg deactivated on updated wp install. Those installs keep working with all and every most modern theme or plug because the code is there, just the scripts aren’t loaded and legacy editor is instantiated.

I’m member in several big communities and those are the major softwares these people use, even if disabling gb.

This problem has nothing to do with cp evolving.
It has everything to do with those plugins and themes also not sleeping and evolving with WordPress.

If you’re asking a plugin or theme dev to keep compatible it means to keep compatible with a 3+ years old code. And as said no major plugin even thinks about doing that.
It’s not “not happening in the future”. It’s “already” happening.

Relying on a plugin or theme not updating and thus not breaking on cp, or not evolving ever and thus not breaking on cp is plain simple unpredictable and is not what I’d want to tell or recommend a person who pays me for doing some work for them.

3 Likes

… it really doesn’t have to be though :slight_smile:

https://wordpress.org/plugins/query-monitor/ is a good example: it is working with all WP versions since 3.7 (released in 2013!)

It has some features related to blocks. They are optional, and only enabled if the plugin detects a running block editor. The code is cleanly separated between “classic” WP-backend-stuff and “new” block-editor-related stuff.

I expect this plugin will continue working with CP for a long, long time.

Of course, most plugin authors won’t or can’t write their plugins this way. Which brings me to agree with this:

The main drawback is that migration from WP sites becomes harder and harder over time. I cannot think of a way to avoid this.

3 Likes

I think we need the CP versions of the newer features that have been added to WP, like Recovery mode, error handling for image uploads, some of the REST API stuff, maybe Site Health, admin email verification, custom fields on menu items, jQuery update, lazy load images, App passwords?, https migration, Robots API, plugin Update URI header.
But these things would be in v2+, is that right?

If all of these features are backported from WP, then major version would not change since no breaking changes were introduced. Or we decided to include these changes in 2.0 along with a breaking change that necessitates major version increase.

1 Like

Not everything that @joyously mentioned would be a non-breaking change, even if backported. Moving to jQuery 3, for example, could break themes or plugins.

I think we can conclude that we need more Plugins and Themes in CP, apart of also pushing forward CP, and that it is allover a dangerous, and on the long term unreliable approach to rely on WP Theme or plugins just “keeping to work with 4.9”

The problem intended to be discussed here, touching the possibly catastrophical effects it can have on a website when using a mix of things and especially the main-stream recommendation being to drive users towards such approach, I think received enough consensus.

As well I think we all seem to agree that relying too much on another ecosystem from which we did distance ourselves (WP), is not only a potential danger for users, but an issue for the project itself.

Thus I think we can resolve this issue here by:

  1. Update our instances where we say “contact other devs and ask them to ensure compatibility” to mention that the best approach would be to choose if available, or even develop, a CP solution.
    For example, there is this DOC entry: Whatever the case may be, we recommend contacting the plugin developers and asking them to make their plugin compatible with WordPress 4.9.x (and therefore ClassicPress).
    I think the whole section there needs an update reminding users that yes, Software labelled with 4.9 will work, but - recommended - would be to use these (list here) plugins or themes as substitutes for XY.
    We already have some replacements, like CC and CSEO.
    Even just mentioning this there, can contribute to the change.
    Please if anyone knows of other instances where we recommend to simply contact dev’s and ask them to make things compatible (again) share here so we can enhance those.

  2. Much more important, since words are nice but do not change a thing, everyone interested in this project with the capacity and knowledge to do so, should be if possible focusing towards working on CP, or Themes and Plugins for CP. For starters, it is clear that Themes are 100% missing. I know there is one person working on a new starter theme based on Susty, and I myself am creating a widgetized theme for those people who want a more backend-ish experience but still could get their hands dirty on some code. So that would make 2 Themes being ready in the coming up weeks.
    So for the theme dev’s amongst us, now would be a good time to think about creating some amazing new theme, working solely for CP (nice if it works also with WP but it shouldn’t be the gaol).
    If anything is stopping you from developing such theme - even if a simple one - we should immediately try to resolve the blocking issue. I think however there is nothing blocking us, other than motivation.
    Related to Plugins, we have some 90 plugins already, but none of the major “wow” features that WP users have in the major PRO Plugins
    Thus, I made a ShortCodes plugin now that allows you to display almost anything on a CP site https://github.com/TukuToi/tukutoi-shortcodes.
    For those amongst you who know Toolset or even Visual Composer from back in the days, this is very similar. You can display a bunch of information using ShortCodes that you usually can only display with PHP. You can nest, and use ShortCodes as attributes inside themselves, allowing you to build pretty powerful templates and dynamic content. I assume you do know that most “templating” plugins who switched to blocks, under the hood do nothing else but parse old shortcodes. Thus, one could say, shortcodes are Blocks without the user interface to choose fancy borders :slight_smile: with more control over the surrounding HTML.
    Following in this same project, a Forms and a Search/Filter Plugin. Again here I am heavily inspired by Toolset, because it just wins everything out there.
    Help is greatly appreciated on this rather massive project.
    These plugins will be always free, open source, but powerful like PRO paid stuff.
    Project on Github is here. https://github.com/users/TukuToi/projects/1
    As said - the Shortcodes plugin is mostly done, it needs a thorough QC, and probably then will need to go back into a dev cycle to fix the things found. Forms and Search & Filter was done a while ago but likely needs a total rewamp, on which I am now, because not really user-ready nor full functional.

  3. I also think each and everyone of us developers/freelancers needs to take a more responsible approach and NOT deliver a CP site with WP stuff running on it where we are not sure if it will continue to work. Let’s assume the worst, like when sanitising and escaping, and not the best. I think the general consensus should be “You may, but if possible should not use WP Software. Be sure the Developer did not just forget to bump the version, and is actively and planned maintaining the older versions”.

  4. I think this is the most important point. It is fine to not have time or motivation to create something for CP or with CP. However lets not take down the ones who want to create, and are full steam believing in this project, with unfounded assumptions 'bout some dark future where ClassicPress has no chance because “not ready”. Instead, if we do not believe in the project, lets stick with other CMS and leave the ones who do believe in it, do their thing. Negativity has never helped someone. However they say that by believe you may move mountains. And I for one, believe very much in CP being the next big CMS of the years to come, unless we screw it up in a endless discussion related to how crippled CP is, or how many things should be done (but then no one takes a finger up to do). Lets bring that trust out in us that convinces those “clients” to trust CP, and let’s try to do what we ask to be done ourselves, or at least help with it.

4 Likes

You really have a problem here, because CP 1.x has the WP repo built in, with nothing for the CP directory. We are still in the transition phase to CP v2, but supposedly 1.x will remain as WP 4.9 was and still supported. So how do you split the few contributors you have to handle both? And what kind of mixed messages are you sending if you say CP 1.x is supported, but don’t use all of its features (WP plugins)?

Not nothing, but around a 100 plugins officially tagged with ClassicPress
Officially tagged means those authors commit to the idea of supporting, not like a plugin that by accident is still working with 4.9 or by accident hasn’t yet bumped version.

That is something, not nothing
Ans as James and others have shown in other threads, it is actually more about communicating the confidence and just “doing” it instead of letting the “client” do us.

I think my point there was clear:
NOT deliver a CP site with WP stuff running on it where we are not sure if it will continue to work.

I never said “split the few contributors you have to handle both” - which btw we clearly already do, we openly state and ask people to ask developers to please support WP 4.9.
So I do not understand this statement at all how it would differ so much from what we do already, other than making things clearer and actually inciting the motivation to truly support ClassicPress.

Other than we developers being more conscious, I do not ask to force actual theme and plugin devs to chose either or.
I am also not sending any mixed message about supporting CP1 but not using “its features”. Of course we use its features. But we need to be conscious about what we use. Not just because something is still working, assume blindly it is going to work like that for the years to come, which is what was assumed throughout the discussion.

I am not sure how this is a problem other than we may need to put in a little effort instead of blindly using things that accidentally work with a CMS of choice.
I can also use python in WP, it is possible, but is it a wise choice? Similarly it might not be a wise choice to use Toolset and hack a bit around with shims, to make a client site work on CP. It’s fine for a short term transition, not for a new project or long term.

Instead, we perhaps should develop a targeted solution, in those cases.

I really think instead of picking out the things that are in progress (Plugin API for example just go released today) we could invest that time into for example developing the first theme for CP. Then the issue already became a tad smaller.

1 Like

Point one that emerged from this discussion - to update instances where we just diverge the responsibility to the Devs (“ask them to be compatible”) has been done in the instance of FAQ here

Screenshot below is what was prior, doc features updated content.

Again, if someone knows of more content where we do not motivate users to actually really move towards CP please list it here so we can act upon.
Also of course if above FAQ contains error or such please let me know.


As of point 2, where we should motivate and make it as easy as possible for people to develop for CP, I also put online https://www.generateplugins.com, a service to quickly spin up a (CP Compatible) Plugin.
I am wondering if we also should create a “code snippets repo” where users can share code snippets, perhaps a kind of “vetted” library. I was thinking of something like this example (that os from Toolset, it is a semi-public site, just as example) where snips are available for consultation. We could also use Gist of course, and link if somewhere useful. I think this could be helpful to address some tiny features that usually need a plugin but could just be a tiny Must use plugin file, for example.

This could speed up development process as the avid devs do not need to deploy a full theme each time or plugin, but could just gist their tiny bit of code that addresses one issue. Of course we’d need some sort of vetting process, just like we do have for Plugin directory.
And gist might be suboptimal for this as it is not a closed system (anyone can gist)

Thus a section in “developer guides” on our doc might be better.

1 Like

There’s a great list of ~75 commonly asked/searched WP tasks that can be accomplished with quick snippets instead of plugins. These snippets should make it into a CP snippet repo if one comes to fruition. Obviously, the descriptions would have to be rewritten for CP/copyright, but, it’s a nice reference nonetheless.

4 Likes

Nice, I think the only question is where to put it - under a Developer Guides section or else.

I think the developer Guides would not be the wrong place, perhaps one main page with inside all sub-pages listed, or, one big long page with all snippets (although that gets long with the time I think.

Perhaps:

Developer Guides

  • [other menu items]
  • Code Snippets

Then on the code snippets page a simple menu (links) to each a sub page, each page one snippet.
That gives room to search for snips but also room for displaying them nicely.

:eyes:

3 Likes

Snippet repo, I like it.

1 Like

I have called for a repo of gists before. Glad to see it getting traction now!

2 Likes

Does everyone agree with the structure?

If so - it needs no new CPT and can be implemented immediately. We can then also think about some submission process of new snippets.
I can do this quickly, while adding a New CPT takes a tad more time (not much thou)

Perhaps a new CPT is better after all because snippets aren’t necessarily only for devs. If this where a code section I’d seay “it is used both in public and admin and thus goes to the includes folder” :smiley:
Hence a standalone CPT?

Definitely a new CPT. Keep different things separate. It will make things much easier to manage.

1 Like

…and with a CPT, you also have access to core import/export. :+1:

1 Like

Indeed, good point!

1 Like

Hi guys. New convert here. I’m not a developer, just a regular WordPress user, and so all I can do is encourage you all.

I believe in the vision of ClassicPress, and I really hope that this project will succeed. And as a sign of my faith, I’m building my first-ever self-hosted dynamic website using ClassicPress :slight_smile:

9 Likes