Why Scroll To Find WYSIWYG Editor Toolbar

Thanks for the improvement to the WYSIWYG CKEditor, floating the link buttons. But they are only available if you have a link. Why not float the whole toolbar at the top of the page. I spend way too much time scrolling between the two right scroll bars and resizing the page just to get to the toolbar to click something.

I started about five months ago switching my incredibly old era 2012 MindTouch Core (10.1.4) personal website over to XWiki. That CMS platform was hard to beat. I just could not find a comparable product with its features and ease of use. That was 7 years ago and their CKEditor toolbar was always on the screen no matter where you was when editing; even if you had “headings” within a table, within a column and you started the editor for that heading section it resized to that column and stayed on the screen. Yeah, I chose XWiki but it still can’t do a lot I could effortlessly do in MindTouch Core; such as indent a paragraph without having to switch to source mode, then try an remember a long HTML margin style code (now I’m just venting).

I’m new to XWiki and my first newbie post, but not to CMS. Experience implementing and providing Documentum server support and evaluating Stellent for an aerospace company I once worked for. I’m not a programmer but provide data center support, an integrator, and requirements guy. So be kind.

What version of XWiki are you using? Because starting with XWiki 12.3 there is in-place edit of wiki pages and the WYSIWYG editor toolbar is floating. I guess you are referring to the stand-alone WYSIWYG edit mode (with the edit panels on the right) where the editing area height is fixed and there is a vertical scroll bar. Am I right?

Indenting is possible. We disabled it because:

  • it’s not common on the web
  • we want the users to focus on the content (rather than on styling)
  • we don’t want to have a cluttered toolbar so we tried to keep the essential features

Check the WYSIWYG Editor administration section.

GREAT!!! But oh no . I will be looking forward to using it. BTW I am using LTS 11.10.5 which I just upgraded last weekend because of CVE-2020-11057. Humm, do I want to spend another weekend upgrading, checking, and restoring changes and modifications after doing another upgrade.

And Thanks. I did see that reference somewhere about why XWiki limited the editing items on the toolbar. I had found and appreciate having a way to enable the disabled items and had enabled the ones I needed. But with the way indent is currently implemented when enabled, you can only do so with a leading bullet or an alphanumeric. You cannot just click and indent an item as needed without them.
IMHO a good web page is about styling and presentation, if it wasn’t we wouldn’t need color, graphics, parallax scrolling, etc…and just use command line terminals. Remember I said, “I am not a programmer” and either are my users. :blush: Oh yeah programmers indent too.
I am glad I found XWiki, and you folks are doing a great job. Keep making it better and don’t go cloud only and all corporate on us that’s what MindTouch did and it “had” a great open development community but kill it.

Actually the plugin to indent blocks (like paragraphs) is not bundled. See https://github.com/xwiki-contrib/application-ckeditor/blob/master/webjar/src/main/config/build-config.js#L84 . I guess I just thought it’s not that important.

Consistency is also very important. Most of the time there are multiple users editing the wiki content so it’s important that they follow the same styling (same alignment, same fonts, same colors). If each user uses the font or color they prefer then the result is a mess. That’s why we think it’s important to let the user focus on the content and let the styling in the hands of a designer that is responsible for the skin / color theme. So instead of aligning paragraphs individually maybe it’s cleaner to do it from the skin. And if you don’t want to align all paragraphs but just some of them then adding a custom paragraph style to the Styles drop down is probably cleaner:

  • the users don’t have to care about how many tabs they need to press or what other styles they need to add to match the expected display (they just select the style from the drop down)
  • you can change the styles (alignment) later without changing the content
  • it’s semantic

Hope this helps,
Marius