I was just at GitHub posting to you that I’d got it sorted… and you were over here posting to me that you liked how I got it sorted. Seems like a win!
That’s why I’m here. Got notified, got it tested and gotta tell others.
We’ve added templates to the repository to help users include all the needed information when opening issues.
So, when you report issues, you’ll find something like this:
Note: the yellow highlighted parts (sections) should remain in your issue and under each section you can add the relevant details, as shown. If a particular section is not needed for the issue, you can remove that section (and the dummy data under it.) The highlighting is only used here for reference; it’s not in the actual templates.
Thanks for helping to keep the effort organized!
did look, but it is not a priority right now, more important things first. But the general plan is to just ignore plugins, anything important enough can be in core or in a core plugin. You can not ensure backward compatibility forever without it holding you back forever. This is basically why WP do not upgrade tiny, ozz is very capable of doing the upgrade and fix whatever needed from core side, he just don’t feel like doing the effort of coordinating with the plugins community when his boss always say that gutenberg is the only editor WP needs.
Thanks for commenting Mark. You’re right. The general community consensus is to move ClassicPress in its own direction and focus on building our own plugins, which is what will start happening with version 2.0. It will have some breaking changes. But we will continue to support version 1.x as a drop-in replacement for WordPress 4.9 for as long as community needs it.
@joyously - Where are you working on this right now? I went through the Github issues but I am a bit lost on where to start doing anything to help here. I wanted to do something while I wait on feedback about the Plugin Directory API.
The thing is, I installed the plugin but the editor doesn’t load. What is the most direct useful thing that we can do so that the editor can be used for new CP projects?
If you installed the plugin, you know it is at GitHub - ClassicPress-research/ClassicPress-Editor as stated, and it shows the recent commits I have made.
If you have a problem, please open an issue.
I am working my way through the existing issues.
Perfect, I just asked because since you have been working on it, you may already have a mental map of what the next most important step is, to at least make it work for a clean CP installation
Since it works for me, what is important is to make sure everything works the best it can, meaning the plugins that start with wp
should be very solid, but those are the least solid right now.
The toolbar needs to be revisited, since I put a temporary way for it to work and it’s not as reliable as before.
I was previously lamenting the fact that in the 5.x TinyMCE, you can’t specify a class on your toolbar button like you could in 4.x. Since there were several that are added by custom code and are then manipulated in some way (JS or CSS), I didn’t quite know how to proceed. Reading the issues for something else, I came across one where people were asking for the class parameter (as if it had never been there), and the response in 2019 was that they removed it intentionally so the UI is more consistent. It sounds as if it was a problem with their cloud version since they have to support whatever people do, so they limit what they can do.
One person commented with some code to add your class when you create the button, by doing a find
on a temp class you put in the text
parameter and then call closest
to get the button and add the class, and remove the temp text node. It’s pretty hacky, but something I was considering before this. Then I noticed that the function they used tinymce.dom.DomQuery
was deprecated in 5.10, to be removed in 6.0. It can still be done with vanilla JS, but really I wonder if 5.x is better in any way than 4.x.
About the same time I was reading the issues, someone commented on the WP ticket for the 5.x update, saying that 5.10 fixed a security issue present in all prior versions. But it’s only present while editing, so it likely doesn’t really affect the admin page. Also, it affects the link
and image
plugins. We don’t use link
(there is wplink
) and the image
plugin is loaded, but there are custom interfaces being used. So I think it isn’t super important.
This wouldn’t apply to plugins that bundle TinyMCE (there are a lot!) or use the editor on the front end.
Wow! You also seem to have found quite a few problems before this with version 5, so it’s beginning to sound a bit of a nightmare. Have you seen anything of version 6, or read anything about when that is likely to appear? It would be nice to think that version 6 would be designed to address the problems found with version 5.
I haven’t read much concerning 6.0 except where it’s referenced that things will be removed. Most of those are because they are making them into premium plugins in 6.0. Coders gotta make some bucks somehow.
Honestly I have seen much worse than this. Not ideal, but it should work reliably, and it will be even shorter and cleaner if done with vanilla JS.
@joyously are you still working on the TinyMCE upgrade? Haven’t seen any updates, just wanted to check what the status is. Thanks.
Hey, thanks for asking! No, I haven’t been working on it since I needed input and testing and got none. I brought the code to the point where some compromises need to be made and I don’t have the info or right to decide by myself. Also, I have not seen any improvement in the newer version over the older version, but a lot of detriment. The trend for TinyMCE is to remove features and offer paid plugins instead.
Assuming you got help with the testing and decisions were made, and editor was finished. Would it be an improvement over current editor? Anything we would lose?
Those are big assumptions. The decisions needed are about what to lose, as I don’t see how to go forward trying to keep all the same stuff as before.
v5 changed the interface for buttons and menus and toolbar, and removed the flexibility. v4 has custom code to handle floating toolbars and dialogs, but those are done differently in v5. The admin Screen Options for making the editor full height rely on some of that which changed.
As I said, I don’t see any visual improvements. I removed one plugin for textpatterns since the v5 one did everything we had.
If we continue to push this project along, at the end, do you think we would have a better editor than v4?
If we’re not getting a better editor in the end, there’s no reason to continue this project. If the end product will be an improvement over v4, then we can figure out the details to get this moving.
I don’t want this project to die simply because we didn’t make the decisions that needed to be made.
Frankly, you’re probably the only person who can make an informed decision on this project. So if you think this will not end with an improved editor, we should put a stop to it and move on.
Tiny v5 is way better than v4. Tiny is a huge company, they wouldn’t go and release a new version with less quality. Only looking at the design, you can feel the difference between 2004 and 2022:
Btw, it has a dark theme too:
Yes, they added some premium features which are not required for it to function, and I don’t see anything in the current CP editor that would require a premium feature.
It doesn’t have to be Tiny though, and if we decide to follow a roadmap anywhere close to what I proposed here, this could still wait.
Anyway, I’m leaving here an amazing updated and curated list of open source WYSIWYG editors:
JefMari/awesome-wysiwyg: A curated list of awesome WYSIWYG editors. (github.com)
I like this one: ContentTools. Simple, original, practical, 100% free and easy to extend. But yeah, saying it just for reference and inspiration.
No, I don’t. Despite what alvaro says, the changes I’ve seen are just rewrites, not improvements. And looking at the list of issues, they made a lot of mistakes doing it.
The change in the design is minor, but also obnoxious because they renamed everything. Both v4 and v5 use skins, so you could already make it look like whatever you wanted. But v5 doesn’t allow you to add a custom class name to your custom button, so you can’t even style it like in v4. I already opened issues that I found with their dark skin, although the one I have in the plugin fixes those.
I said this in the beginning.
Not true, and I don’t want the responsibility. I have documented my thinking and research on all the issues. There are some code details I didn’t write down, but other folks can follow along and figure out what to do. I mentioned it on the WP ticket for the upgrade and got one person looking, but that was it.