Very true beans. Tests are the cherry of a good cake. But I don’t want to get lost in the cherry world before I fix the cake. A conscious choice aimed at simplicity.
I can understand, but maybe leaving tests failing is better that not having.
You work on avatars. Test on avatars is failig. Ok… let’ go on. But if the test failing is about filesystem probably you broke something else you don’t want to.
I understand your reasoning, but I can’t put energy into that. For each change I’ll also have to go and review the tests and fix them accordingly. If the current project was the international reference for good practices I would take tests seriously. But at the current state, tests are the less relevant thing. Let’s see where this all brings. It may lead to nowhere, but at least I will have spent time in doing something relatively “decent” or “joyful”. Goal → A working version of a potential CP Next.
It’s a shame you didn’t fork off of the branch with all the PHP 8 changes.
Seems awesome man!
I did a complete rewrite of the Avatars Core Plugin to avoid using such a crazy amount of globals. Also, I’m not a fan of creating Classes just for the sake of avoiding names collision. So I moved everything into namespaced functions.
I am very open to critics for how I rewrote the plugin. My goal with this plugin is to show an example of good practices. You can see the file changes here (or just open the plugin locally and compare it with the original).
@anon66243189 - I fixed the bug you noticed for deafult avatars in Settings → Discussion. Regarding the default email… it’s currently set that way, I don’t really care about that right now but if you think we should change that email to something else I will do it, because you always provide good reasons. It’s just a mere replace inside the wp_install_defaults() function.
Now my next steps are:
convert the plugin’s jQuery into Vanilla JS (already done), fix potential bugs that I didn’t notice (feel free to open an issue and I will get it fixed) and work on this suggestion (an option to autogenerate an SVG image with first letter in the user’s display name). (already done). I also created a Spanish translation to make sure internationalization is done right.
I finished removing the things I wanted to remove (and the plugins I installed are all working, if you have a plugin suggestion let me know here and I will test it). Even though the Plugin and Themes directory were on the list (because there is no way that the WordPress plugins will keep working for long on this side), I’ll wait on that because progress is being made on the API. It’s a good chance to start forking some of the most used plugins and have a clean and native CP version.
I’m now working on the Core Plugins step. The first thing will be either REST API or Comments System. Both are very spread in core but yeah, nothing is impossible.
Before doing that I wanted to have three Core Plugins added, which I consider are essential:
- Avatars: allow users to have local avatars. This is working.
- Clone Posts: allow users to clone posts for a faster workflow and requested by @viktor. This is working (you may want to try it and leave some feedback, if you want).
- Custom Posts: allow users to create custom post types from the admin area. In progress.
The reason I am adding before I take stuff away is because I’m still reading about singletons, functional, and … I want to come up with the most easy to understand and clean plugin structure before I work on those big Core Plugins.
2 things I would want to see here, which would help developers working with clients based on my experience working with CPTs:
There should be a filter that will disable this functionality completely. Some devs like to lock things up, so clients can’t break things.
Might be related to #1, there should be a filter that hides/disables UI but continues to generate CPTs saved in database. Similar to #1, we may create “team” CPT to manage team bios. But we don’t want clients to break things, so we’ll need to hide CPT.
Bonus: Might be good to have a custom capability for this. Admin can edit them, but another role can be granted this capability.
Will set aside time to test Next version. Exciting.
These are reasons why I’d put such functionality in a (core?) plugin.
I modified the plugin API calls to cut away from the WordPress Plugin Directory, because it makes no sense. Also, I was adding “Core Plugins” that aren’t actually “Core Plugins”. They are useful plugins, but they belong to the Plugin Directory.
So this is how it looks like:
I added a folder with JSON files where the info for the available plugins can be added (in separate files, to keep it clean) which emulates the WordPress API fields.
Something like this:
I actually like the JSON files approach because they can be commited to the repo and other devs can PR for plugin updates, and all the information is always public (and no one is tracking what plugins we have or not!).
The only problem I see here is about listening to plugin updates (when a new version is available), and it would be cool to handle this differently (for example, each plugin developer could provide an online txt file with the most recent version).
Also, I think that all the rating and active installs stuff is a bit of BS. Only good quality plugins should be added to the Directory (no point in having rating) and information about active installs is just irrelevant.
But yeah, this isn’t meant to be a Plugin Directory replacement, it’s just to have something that works and that shows that cutting from WordPress is possible (instead of just words).
If your idea (and my hope as well) is that someone will pick your changes from ClassicPress “Next”
please try to be very precise in your git workflow.
I’m following your progress and I’ve noticed that many plugins have i10n problems.
Tracking down the problem shows that in Update Avatar Core Plugin #5 (a PR that looks about avatars) you have removed a deprecation (
$deprecated var from
I’m not here to criticize your work, but if you go on investing a lot of time and it’s not possible to “cherry pick” your commits it’s not useful (my personal opinion) for the ClassicPress community.
Yes, second parameter for load_plugin_textdomain() is a deprecated parameter. It makes no sense to keep carrying that on. As I said here: “Thoughts on breaking changes and a native CP pre-Gutenberg plugins ecosystem”, the time to break from WordPress with a CP native Plugin (and themes) directory is now.
In the process of doing that, some subtle changes will have to be applied to those plugins, but nothing crazy. And removing a useless variable that has been sitting there for years is something that takes less than 15 seconds to do. It takes longer to write your message than to fork a pre-Gutenberg plugin and apply the two or three subtle changes… - Also, I offered to do that myself, for plugins requested by the community: “What are some of the most important open source plugins in the pre-Gutenberg WP ecosystem? I want to try to keep them compatible with the CP Next version I am working on” (with the idea that they can get into the potential new Plugin Directory)
I’m not removing anything crazy from core. And actually, I’ve already removed everything I wanted to. The next step is all about separating core stuff into plugins.
@alvarofranz the specific thing you removed messes up the i18n (internalization) of the core and plugins, and the needed steps to make i18n good again haven’t been taken. What this means is that in removing this specific thing you left a whole piece of the job hanging there.
And this is a problem because not only it can cause breaking changes, but creates a not so clear and choerent git history.
Why haven’t you responded to this instead of venting?
Sorry to be brutal but it’s a very good question.
You could have said that you were going to handle this at a later time, you could have thanked for the heads up about it or you could have just acknowledged that the issue needed to be solved.
I want to know what will you do about i18n. I am a translator and for some month I was translation team lead before COVID decided to strike… I could help with CP next but I want clear processes and directions.
My message was not about removing something deprecated (but check because you removed it from the function declaration but not in the function itself).
If I like your work on avatar and I want to take it to ClassicPress I’ll cherry-pick
ffce677cbfc7c5ab0f0c0aa804bca5e7d5e65ba8, but that commit is 99% about avatars and 1% about removing deprecated functions. A commit should be 100% on what is supposed to do in the description.
It takes longer to write your message than to fork a pre-Gutenberg plugin and apply the two or three subtle changes…
It took longer to clone wp-cms and test all my plugins, trust me
Nothing has been broken. If you look at the function definition: load_plugin_textdomain() | Function, you will see that the
$deprectaed param is not being used. It’s just used to detect if it exists and say: “Hey, this is deprecated, don’t use it”.
Also, I don’t know why you say I left hanging work to do. The only thing that had to be done in Core was to update the _get_plugin_data_markup_translate() function (which I did…).
The only required change to make i18n work is on plugins. Specifically, replace:
load_plugin_textdomain('whatever', false, 'plugin-path')
In any forked plugin. And I don’t think that’s a problem.
Forking pre-Gutenberg plugins and replacing
load_plugin_textdomain('whatever', false, 'plugin-path') with
load_plugin_textdomain('whatever', 'plugin-path') seems a pretty neat start to me. Not just to have that silly replacement, but to actually make the first step in having a WordPress independent list of plugins with their corresponding repos (which are Gutenberg fuss free and can have an independent evolution from there on!)
Fair point! I will make sure to follow this principle from now on!
Fact is that just forking/altering plugins and removing things isn’t secure.
Have you seen Elementor for example? It is a very actively developed plugin, they discovered a vulnerability affecting all the sites using it.
You fork a pre-gb thing, but you need to maintain it. And actively develop it to stay current with security standards.
The hanging job is making sure that plugin devs adopt your change to CP core.
You can’t just fork, alter and maintain a whole ecosystem on your own.
So instead of removing things just for the sake of it, why don’t you just try to call on dev to be aware you are removing things (giving them an ETA about that) and ask them if they are willing to adopt a theme or plugin and keep it current with CP next? There are devs already involved in developing for CP, you could have enlisted their help in building the ecosystem (this was already started and things like classicSEO, CC and others were born out of it - aside from people abandoning the projects they started this was and is a good idea, you need devs behind plugins and themes, to be sure no vulnerability comes up for luck of maintenance)
So do you expect Elementor to support ClassicPress or do you expect ClassicPress to both support Elementor and be something different than WordPress at the same time?
That’s an illusion. None of those two things will happen anytime soon. Elementor would consider supporting ClassicPress if it reaches a few million users… but… if ClassicPress is an old WordPress with no improvements, who is going to use it anyway?
I’m not removing things just for the sake of it. I removed a very specific set of things that are useless (like XML-RPC, Gravatar, the Links Manager that wasn’t even enabled by default or functions that have been deprecated for years) for the sake of performance and a clean codebase.
It’s not my intention. My intention is to fork, alter and mantain the core of WP and a few basic plugins (definitely not something as huge as Elementor!), because when I use WP to develop websites I always create very specific and custom functionality and I don’t want Elementor, Gutenmentor and nothing alike. I want a clean Core that I can extend. And when extending it, I don’t want to call a function and pass it random parameters that aren’t used, because I feel stupid doing so.
We can’t expect ClassicPress to have the same ecosystem than WordPress from day one. But we can expect it to be a great product if it stands for optimization: a lightweight clean codebase that can easily be extended.
I’m just sharing my progress here for the case that ClassicPress wants to do something to prevent it from being a useless old copy of WordPress (which it kind of already is). I’m just giving an example of what could be done. And having an independent plugins/themes directory with subtle changes is just part of that idea.
Good luck on maintaining AND developing a new core, with plugin ecosystem on your own then.
Plugin you will need to be considered by users:
- payment gateways
And this is just a very basic list.
Just very simple.
A CMS IMHO is not a one man show.
I am not a dev, just a translator with a bit of front end knowledge, maybe I am very wrong. But I really see this going nowhere.
I’m not talking about building a page builder where you just install two things and a theme and have a working site. People should use WordPress for that. I’m talking about building a clean Core that developers can extend. Of course, with some plugins that will help developers work faster.
Where do you see ClassicPress going? Follow everything WordPress does just a few versions under?
No… it does not solve. But I have to look why… Tomorrow i’ll open a PR…