Prose Miror & medium Wisiwyg editor will be desabled via pref ?

sacripant · 2019-03-24 21:28:09

Hello core team,

I just notice in github dev repo that etc. activate a combo of prose mirror & medium to create a better write UX. Cool.
I understand the desire to render Textpattern more user friendly.
But just to reassure me,
these JS additions js will be easilly disabled via preferencies or counterpart for users who do not want or want to install something else instead? Ideally are implemented via a official core plugin ?

Sorry if you have already debate about that in another tread.

etc · 2019-03-24 22:08:31

Frankly, these are just experiments atm that should even be in a separate branch, but who tests anything else than dev?

Among wysiwig editors I’ve tried I’d say only ProseMirror has a chance to be part of official distribution, because actually it is not wysiwyg. What you see when editing is just a limited-HTML view of an object representing your structured document tree. The default ProseMirror editor just helps to visually transform this object that can ultimately be output in a variety of formats: html, textile, markdown, etc. Actually, you could even get rid of the editor and use ProseMirror to transform, say, html or markdown to textile. Looks useful, no?

We could even store this (JSON encoded) object in db and freely switch between textile/markdown/wysywig/html/etc views for its editing.

Anyway, it’s not for tomorrow, at least for me – too much to learn.

sacripant · 2019-03-25 08:45:33

Hi,

Prose mirror is certainly the most popular JS IDE since adobe choose it for bracket. I have no objection if you want to use or test it.

My question is how are you going to implement these new features.
The improvements of the admin interface start from a good feeling:

jquery-ui
Prism
autosize for Hive theme
fileupload.js

But these choices have been imposed without leaving the possibility to disable them, replace them or not to install them. No config file, no prefs, no plugins.

Will future solutions to improve the write panel also be imposed or will you leave the possibility to users to deactivate or choose/install a other UI?
It’s important for me to know.
Thanks

philwareham · 2019-03-25 09:16:00

etc wrote #317288:

Frankly, these are just experiments atm that should even be in a separate branch, but who tests anything else than dev?

Among wysiwig editors I’ve tried I’d say only ProseMirror has a chance to be part of official distribution, because actually it is not wysiwyg.

Agreed – I haven’t had time to test any of these experiments as yet but my general feeling is that a formatting helper toolbar is the correct solution for core (which ProseMirror seems to be along the lines of). Kind of like rah_textile_bar if you have tried that, but more comprehensive. I’m not keen on having previews in a dialog popup or new window either but I do see the value in having a side-by-side option of seeing what text looks like when formatted. For example roughly this, but with a toolbar on the Textile side (which can be used for other Textfilters with some extensibility).

Whatever we did has to fit comfortably into our write panel plans and can also be disabled for those users who don’t require it. Lots to think about.

Bloke · 2019-03-25 10:22:28

philwareham wrote #317292:

I do see the value in having a side-by-side option of seeing what text looks like when formatted.

That example is great, yes. Perhaps we offer the option of a “Distraction Free Full Screen Mode” (a bit like sacripant’s ‘ace for Txp’ thing) which hides everything except the textarea(s) on the left and the preview window on the right. With the CTRL+S shortcut still available, people don’t have to leave this mode to commit changes and can toggle back to the regular Write panel if they need to change other meta data?

Not sure. As you say, lots to think about.

If we do that, it would be nice (somehow) to be able to invoke the parser, if we can do it safely, so that <txp:*> tags can be processed in the preview. But I appreciate this might be a security stretch, so not essential.

etc · 2019-03-25 11:02:17

sacripant wrote #317291:

Will future solutions to improve the write panel also be imposed or will you leave the possibility to users to deactivate or choose/install a other UI?

Not sure for jquery-ui and fileupload atm, but for other helpers the plans are to make them optional, either as un(installable) core modules or as themes preferences. I agree that we should impose as little as possible, but features like file upload, image processing etc are too tightly integrated into core.

philwareham wrote #317292:

… my general feeling is that a formatting helper toolbar is the correct solution for core (which ProseMirror seems to be along the lines of). Kind of like rah_textile_bar if you have tried that, but more comprehensive.

Yes, I think we can create different kinds of configurable toolbars with ProseMirror, even mimic rah_textile_bar. But I’m not smart enough to grok it in few days.

I’m not keen on having previews in a dialog popup or new window either but I do see the value in having a side-by-side option of seeing what text looks like when formatted. For example roughly this, but with a toolbar on the Textile side (which can be used for other Textfilters with some extensibility).

Popups have the benefit of being draggable and closable, and we already use them for help and tagbuilder. But again, we are just experimenting atm.

Re live preview, textile-js is not up to date with the recent php-textile we use for HTML generation. And using php-textile for live previews would be too expensive in terms of network connection/server load. If Jukka or someone else could release a JS version of Textile…

sacripant · 2019-03-25 15:07:39

Whatever we did has to fit comfortably into our write panel plans and can also be disabled for those users who don’t require it. Lots to think about.

Not sure for jquery-ui and fileupload atm, but for other helpers the plans are to make them optional, either as un(installable) core modules or as themes preferences. I agree that we should impose as little as possible, but features like file upload, image processing etc are too tightly integrated into core.

Thank you for reassuring me on this point.

Don’t hesitate to propose in next release a clean user solution for non activated prism and autosize.
And think about trashing jquery ui. I do not see any valid justification for keeping it.

philwareham · 2019-03-25 15:38:18

sacripant wrote #317299:

And think about trashing jquery ui. I do not see any valid justification for keeping it.

Sorry, why? We use it throughout the user interface for such things as vertical tabs, dialog/modal popups, selectmenus, etc. I guess we could move to something like UIkit which has some of the same features but why break what isn’t broken?

Bloke · 2019-03-25 15:45:09

sacripant wrote #317299:

a clean user solution for non activated prism and autosize.

Autosize: I agree. For (very) longform copy it can be a pain to scroll back up to the remaining elements in the 2nd column. Making this optional is something I’m keen to explore.

And think about trashing jquery ui

What?! No. At least not yet. See Phil’s reply. If development ever ceases on jQueryUI and we’re forced to jump ship or lose browser support, we’ll worry about it then. But until that day, it’s staying.

etc · 2019-03-26 10:26:56

Back to OP: we actually have a hidden admin_textfilter_classes pref for enabling textfilters, that could suffice.

sacripant · 2019-03-26 10:55:25

Mea culpa, If you are happy with this obese grandmother, it’s ok.

I just proposed this because:

no release since 2016-09
no commit since same date (abandonware ?)
too big: (250 ko minified + specific CSS theme) and just a small part are really used by txp admin.
old codebase
some part can be easily replaced now by CSS (:target :checked appearance:none, …), and some es5 / es6 lines of codes for better a11y.

Now, it work and some part are useful, but a future day, you need to replace this old dependence (jQuery too, sorry).
It’s, my opinion, preferable to gradually reduce this dependencies whenever possible, rather than accentuate it.

etc · 2019-03-26 11:17:07

Everyone seems to agree on it, no worries, just an extra work for our small team. Please feel free to suggest any improvements you see.

Textpattern CMS

Textpattern CMS support forum

#1 2019-03-24 21:28:09