sonata-project / SonataFormatterBundle

Symfony SonataFormatterBundle
https://docs.sonata-project.org/projects/SonataFormatterBundle
MIT License
81 stars 117 forks source link

Add back the Ckeditor support on 5.x branch #647

Closed VincentLanglet closed 2 years ago

VincentLanglet commented 2 years ago

I created this issue to resume some discussion from

All the formatter was too quickly removed. We should add back some of them.

cc @jordisala1991 @lukepass @core23

core23 commented 2 years ago
  • The ckeditor should be added back with his doc. The dependency is still in the composer.json
  • The markdown won't be added back. The dependency was removed but there is still some "markdown" occurrences in the doc.
  • For others, it's like you want.

👍 We should only provide the CKEditor for now. The other editors type look very experimental.

We could use the new symfony/ux framework to initialise the CKEditor. This way we keep the DOM clean and can use more strict CSPs to increase security. This will also increase the loading speed for each page.

VincentLanglet commented 2 years ago

We could use the new symfony/ux framework to initialise the CKEditor.

Shouldn't we add back the code from 4.x instead ? it's quicker, introduce no BC-break, worked before and need less work.

jordisala1991 commented 2 years ago

As a first point yes.

Later we could introduce Webpack if needed (not sure if we have script associated with the ckeditor)

core23 commented 2 years ago

it's quicker, introduce no BC-break

We're talking about a new major release. We should use the time to clean some technical debts.

Using symfony ux is quite simple. There's also a POC for the CKEditor: https://github.com/xearts/symfony-ux-ckeditor5

VincentLanglet commented 2 years ago

it's quicker, introduce no BC-break

We're talking about a new major release. We should use the time to clean some technical debts.

But there is no time to take here IMHO.

The SonataFormatter doesn't support

There is already a lot of BC-break in the 5.x branch to me.

And since not a lot of people are working actively on Sonata bundles to release new majors (see how much time it took to release SonataAdmin 4, then how much was needed for Classification and Media 4), we should not add extra work/take extra time and delay the Sonata bundles major. The goal is to close https://github.com/sonata-project/dev-kit/issues/1715 as soon as possible IMHO.

Then, we can still work on a 6.x branch with webpack and stimulus. We can do major version more often if needed.

jordisala1991 commented 2 years ago

We should do our best to have a good quality code. But for now, having to learn/apply some Stimulus / UX when we don't have any bundle using it, will be hard.

We have other tasks like going to level 8 of phpstan and level 2/3 psalm that are higher in priority to me.

Also adding some functional test would be nice too.

Not saying that removing the inline js is not important but not having functional tests or good level of phpstan / psalm is more important to me. It helps building some trust when we change things.

Also there are other things that we know how to do like:

Removing bower and move to NPM (it was done on SonataAdminBundle already). (also more important than using inline scripts)