Why I won't upgrade to Cockpit CMS v2 and might leave the project

[raffaelj]

Thanks @webcliq and @artur for your feedback. I think, I need to clarify a few things to make my concerns more understandable.

Especially new users might not know about v1 or my previous work and I went deep into technical details.

custom php frontend

I always was more interested in the PHP (and the CLI) api than in the REST api. On top of the headless Cockpit CMS v1 I wrote my own frontend (head) Multiplane. So my usage always was unusual or not like intended, but I tried to write all my addons to be compatible with the headless paradigm. When I started to port Multiplane to v2, I discovered all these issues, I mentioned in my initial post.

Because defining custom paths was dropped in favour of using the Cockpit::instance() pattern, it isn’t compatible anymore to be used as a foundation.

accessibility

During the last year I read a lot about inclusive web design. Before, I already cared about semantic HTML, which is a great starting point to avoid exclusive web design. So I did many things right without knowing about the impact for disabled people. I also did many things wrong (e. g. error messages after validating a form were undetectable for blind people).

I don’t see myself as a disabled person. Maybe I am. I can’t concentrate on reading a text when a single element in the viewport keeps moving. Also every now and then my typists’s cramp (RSI) comes back. I see myself more as a power user. These things are interconnected. I use the keyboard, because typing is faster, but it also supports my right wrist. I use script and ad blockers for privacy, political and security reasons, but also to be able to read text at all.

Opening the same issues twice thrice, after fixing them in v1 already, annoyed me, e. g.:

• clickable labels of boolean fields, my fix in v1
• keyboard navigation in search modal, my fix in v1

I skimmed my feedback post from one year ago again and I found both issues above, as well as most issues mentioned in this thread.

If you want to improve your accessibility skills, I recommend starting with Best practices for inclusive textual websites from Rohan Kumar. I found a good overview about screen readers and form elements from Russ Weakley. He also has some more resources, but I didn’t read them, yet. And I follow a few interesting people on Mastodon so I have daily input about accessible web design in my news feed. It’s a huge topic and it fundamentally changed my view on code.

disabling vs. enabling features

I chose v1 because I was tired of playing whack-a-mole with WordPress by disabling (new) features (mainly third party requests and Gutenberg CSS changes). With Cockpit I still had to disable a few things via my rljUtils addon (including a security patch, that was never fixed in v1 - after I reported it again, it was fixed in v2) but my modifications were stable for years.

To bend Cockpit to my needs, I would have to modify the core, which would lead to a very unstable foundation.

Also I have to disable the user ip logging now, which must be opt-in instead of opt-out.

spaces

I totally understand the mentioned use cases, but I don’t like the implementation. All use cases were possible with v1 by writing some code in defines.php, config/bootstrap.php and config/config.php and using a .env file.

Alternatively it was possible to load Cockpit as a library with some quick and dirty js fixes to correct paths in the admin ui (first proof of concept, old variant for Multiplane, latest implementation for Multiplane).

pro addons

It is possible to publish the Github repos without a permissive license.

If I could read the commit history, I could have a better understanding of some decisions about changed core code, that only makes sense e. g. with the Sync addon.

Now I would have to download the latest pro zip archive, extract it and run a manual diff on an addon folder to keep track of changes. This doesn’t feel transparent.

Because I have that deep insights (like the above mentioned security issue, that never got fixed) and because v1 never had a changelog, I lost some trust in published releases. Without reading (or at least skimming) the code, I wouldn’t install them. This also applies to other contexts like WordPress plugins, so it’s not just a Cockpit issue. But making the code open source (with commit history) helps gaining trust.

As I said, I didn’t have a look at the pro addons to avoid copyright problems. My Multiplane implementation would compete with the Pages addon.

And I planned to improve the BlockEditor prototype (probably with prosemirror/TipTap). It was based on the layout field, which is now a pro addon, too.

So this is another field where I can’t build on an existing foundation anymore.

specific answers

@artur

You say that the effort to port your existing addons is too high. What’s stopping you from setting a good example and creating an extension where the accessibility doesn’t suck? I’m sure there’s a lot I can learn from that as well.

1. If I can’t use v2 as a foundation for Multiplane, I’m not motivated to rewrite my addons.
2. Porting just the business logic in PHP is the simple part. Writing a user interface is hard and you did a great job with building an intuitive UI in most places. Most times I spend more time on writing the UI and thinking about UX than solving the actual problem with a few lines of PHP.
3. Accessibility doesn’t work well as an after-thought. If I can’t navigate to the addon settings, it doesn’t help much when the addon is accessible.
4. In the Babel addon I used an event listener on all text inputs and a CSS fix to address the fixed header/footer issue. Being able to use the Tab key while editing hundreds of form fields was worth the loss in performance and the increased RAM usage. The real fix would be to drop fixed and sticky elements or to go the hard way and build an accessible sticky header and fixed footer (I read somewhere, that it’s actually possible).
5. If I would start from scratch, I would fundamentally change things. With HTML5 and basic form fields you get most accessibility features for free. Add some CSS with pseudo elements to avoid div soup. Than JS follows as a progressive enhancement. In this regard Cockpit is actually a good base, because Lime is compatible with form data by design and I’m not forced to send json via ajax. So it could work even when JS is disabled. This concept is hard to achieve while developing with JS frameworks (vue, kiss). A PHP based templating engine would help here . Drupal does these things right. A few days ago I wondered, why CKEditor didn’t load while editing and saving the content field with plain html in a textarea. I didn’t notice, that I disabled Javascript on http://localhost a few days earlier for a different test and it just worked.
6. I don’t want to start from scratch. Instead of spending years on my ideal CMS I want to build on a strong foundation and improve things over time.

@artur

It looks like we don’t have the same idea of how to approach these challenges.

I agree

@webcliq

BUT at best Cockpit CMS is a great prototyping tool because it is not scalable

I agree, but for a different reason. With MongoDB and cloud storage support, Cockpit should scale well (I never needed scaling, so not tested). If I ignore my mentioned limitations, Cockpit is a great tool for prototyping. It just doesn’t match my needs for production anymore.

@webcliq

Cockpit has stood the test - why because it works and it is so blindlingly simple in concept. This is why I take my hat off to Artur.

Yes. Everytime I see some configuration in another CMS, I miss that simplicity.

@webcliq

and anyway, do we want that such a development purely belongs to Artur.

Actually no. I think, that Cockpit as a project is too big for one person.

@webcliq

I want to see the best product possible, put together by a remote team where everyone earns money, eventually, by rolling out enduser websites, providing paid support and creating sensibly priced extensions.

Raffael, is that not really what you want to achieve?

You nailed it. But as mentioned above, I don’t want to start from scratch.

@artur

Keep on growing and do exploration into new territories.

I do already. Right now I’m reading the docs of Neos. They have some great core concepts. I’m not sure about their state of accessibility, but it might be quite good. Unfortunately, it is the opposite of simplicity with a default footprint of 200MB, but they have inline-editing, which is simple for end users.