Thank you @rastapopoulos and @nicod for your great comments!
Yes indeed the amazing porte-plume plugin that allows editing field’s contents in the frontend, has inspired me to make a WYSWYG editor for the frontent based on the same approach.
Adding a WYSIWYG layer in the frontend, users can edit the site directly. And see exactly what things look like.
Quick Screencast
I wasn’t able to embed the screencast video in my original post, it’s here: Spediteur: WYSIWYG Editor for SPIP - Urs Riggenbach
Markdown - Textwheel / Backend - Frontend
This will be a frontent-editor. The idea is to make the best WYSIWYG experience. And WYSIWYG is best when it’s in the frontend: When the container size matches the template’s, when all the CSS of the frontend is available, when the H1 tags and everything is rendered in the correct font, sizes, etc according to the actual CSS of the website.
(It could be used on the backend maybe and that’s something to consider in the future. It would require bringing the CSS into the backend, I’m not sure it’s wise).
About data storage: I have no opinion about markdown vs textwheel. As long as we can store modeles and also enter custom html when needed, I’m happy.
But for WYSWYG, whatever the backend storage format, something has to parse that source data, and create HTML for the editor. That HTML needs to wrap modeles and custom syntax with metadata so the editor can understand that these elements need to edited differently (e.g. open a dialog to configure a modele). All the rest can be edited normally in HTML, and upon save this HTML is parsed back into the original format (Textwheel or Markdown).
@rastapopoulos I will have a look at how you did that, no need to duplicate the works. My support for Textwheel is non-existant, I’ve just for now have modeles/documents working. Also no configuration dialog for that. So I will gladly take a look at your work.
* but also manage internal spip links (« article123 », « myobject456 »)
* fully manage SPIP modeles in WYSIWYG : viewing, inserting and modification of existing, by using the YAML description of the modeles inspired by the plugin « Insérer modèles » (totally integrated inside the editor)
*
@nicod I agree with 1 and 2, this I was able to do direclty in the plugin:
For questions 1 and 2, I think you can overload in your plugin.
Your other points:
For question 3, could you publish a diff here, to understand what changes you need ?
Please see the code block in my original post.
The simplest will be to pass an $option[« spediteur »] = true; into the existing function:
public function traiter(string $texte, array $options) {
and add an if statement to wrap the html with the correct metadata (this would then be the pull request):
//Spediteur: add contenteditable wrapper.
//Wraps a modele with metadata needed for Spediteur editor
if( $options["spediteur"] ){
$modele = "<div class='contenteditable_modele' data-modele=" . json_encode(htmlspecialchars($m['raw'])) . ">" . $modele . "</div>";
}
For question 4, why do you need such big values ?
The porte plume plugin has limited the max size of the editor to 700 px, but when editing a website where #TEXTE is wider than that, the editor is limited to that 700px max and it should be increased. I think there is no reason to limit the size, is there? I think 10000px would be fine, but it may be better to remove the limit: I don’t see what purpose it serves.
Have a great day,
Urs