Great stuff. However we cant completely drop the ugly buttons as they work
with non-wysiwyg editors

On 11 June 2015 at 22:12, Dimitris Grammatiko notifications@github.com
wrote:

Attempt to drop the editors-xtd buttons

This is the initial commit (two more to come)
This was @nikosdion https://github.com/nikosdion idea that we talked
about in #JAB15 @wilsonge https://github.com/wilsonge I hope i’ll have
all of them before 3.5 alpha!

So what is this all about?
Well Joomla has those 5 buttons bellow tinyMCE which are not so helpful
and also are tightly related to mootools. This is a native tinyMCE button
that does exactly what the page break below the editor. Once we have all of
them as native plugins we can drop the other buttons!

Here is a preview:
[image: screen shot 2015-06-12 at 12 02 46]
https://cloud.githubusercontent.com/assets/3889375/8118431/81ffa40a-1097-11e5-8f90-fe57c6718996.png

Comments suggestions are welcome!

You can view, comment on, or merge this pull request online at:

#7152
Commit Summary

• Page Break button as native tinyMCE plugin

File Changes

• M administrator/language/en-GB/en-GB.plg_editors_tinymce.ini
  https://github.com/joomla/joomla-cms/pull/7152/files#diff-0 (4)
• A media/editors/tinymce/plugins/joomlabreak/plugin.min.js
  https://github.com/joomla/joomla-cms/pull/7152/files#diff-1 (25)
• M plugins/editors/tinymce/tinymce.php
  https://github.com/joomla/joomla-cms/pull/7152/files#diff-2 (7)

Patch Links:

• https://github.com/joomla/joomla-cms/pull/7152.patch
• https://github.com/joomla/joomla-cms/pull/7152.diff

—
Reply to this email directly or view it on GitHub
#7152.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman The idea is to drop them in tinyMCE which is the default browser, so for new comers this will be a good thing. Actually @nikosdion had some pretty neat ideas for the editor that will improve vastly the UX but they require some code that is not yet ready for show time. Maybe 3.6

I was just pointing out that we will still need to keep the existing ugly plugins for the non-tinymce editors

Yah for sure - we were aware of that when we talked.

What I don't see is how 3rd party extensions could do the same thing. I don't think we should add stuff for com_content (pagebreak, readmore, article) which can't be done similar for 3rd party extensions. It just shows a flaw in our design then.

Also we duplicate our code here, as there is no way we can remove the existing xtd plugins. Other editors still need them as pointed out already and it would be a huge step back if those no longer work cross-editor.

So while it sure is better UX for tinyMCE and com_content, it also probably creates more (maintenance) issues in future. And especially threats core extensions different from other extensions, and TinyMCE from other editors which I think both is not a good thing to do from a design point of view.

@Bakual Thomas the duplicate code in this instance is very small, and also the code here is really simple some declarations all and all.
About 3rd party devs: there is a problem with all the editors and their plugins, themes, etc that they support but there is no clear path how to actually achieve that (other than copy pasting folders).
There is another PR that eliminates mootools on the xtd buttons and that one got a lot more lines of code (some of them ugly due to b/c) than these 4 plugins.

Actually my idea was a bit different and based on plugins :) It was difficult explaining it without an IDE open and after consuming a couple of beers.

The bulk of changes is pushing stuff inside the onInit() method. Can this stuff come from editor-xtd plugins? Basically, can we stuff all editor-xtd buttons inside toolbar5? That was my idea.

More clearly: The TinyMCE plugins's onInit() method could fire the onDisplay method of the editor-xtd plugins. These plugins return a JObject element. The name property gives us the icon class, onclick, link and options tell us what to do and modal tell us if we should open the link as a modal dialog. I presume we can render these buttons in a new toolbar row and just call the same Javascript we already do with editor-xtd plugins.

What we need is a way for the editor plugin to tell the JEditor class that it's handling editor-xtd plugins or, better yet, which editor-xtd plugins it has handled. Thus the getButtons method would only render editor-xtd buttons which did not get handled by the editor itself.

Does this make more sense?

@nikosdion That will not work for all these buttons that have a modal because they also have a little js script that takes the selected value from the modal and injects it to the editor window.
Actually doing this experiment I realize that the bottleneck with those xtd buttons is that we don’t have a way to override the script that each button is coupled with!
Same thing happen few months ago when I tried to freed those buttons from mootools.

@DGT41
I tested the insert article in a different language in an article on a multilanguage site and before 17e553f I got the same link when toggling editor. Therefore there was no issue for that.
FYI: it will not work though as we need first to merge this regression:
#7159

@DGT41 Yes, I understand that we have tight coupling. It's the side-effect of having buttons which must work with every WYSIWYG editor under the sun. It's still a good feature (putting these buttons inside the TInyMCE toolbar) as it makes Joomla! more useful for the large percentage of our users who don't (know how to) install a different editor. This way we have a good UX for newcomers (like WordPress) without forcing everyone to use just this one editor we are providing in the core no matter what (so, unlike WordPress). In essence what I am trying to get you to do is making the default editor as easy to use as WordPress without being as restrictive as WordPress. Make the users happy, make the developers happy and everybody wins!

@nikosdion Doing that and retain B/C needs one decision:
Can we drop the xtd buttons for tinyMCE?
If the answer is YES then I’ll figure out a nice workaround (already done most of it in my local env)!
If the answer is NO: it means that we DO HAVE too many xtd buttons and there will be a big disruption for many users. But that’s not the case: JED xtd. Some usage statistics will have been very helpful here! (Eg how many user use tinyMCE and also have an additional xtd button from JED installed)

Maybe a combination of this PR and #5652 is a bullet proof solution here OR creating a new entry level tinyMCE plugin?

I think there needs to be weighted if the UX improvement is more important than supporting an additional 150 lines of -simple- code.

Most editor-xtd buttons are "hidden". They don't exist as standalone items on JED, they are part of components. For example, I have an editor-xtd button for Akeeba Release System... in its package.

So let's look at this from a b/c point of view. Right now editor-xtd buttons are rendered below the editor, they call some Javascript to be displayed and some other Javascript to push back their results into the editor area. What exactly stops us to move the button (calling the same Javascript) from below the editor into an extra TinyMCE toolbar? This is the part I don't get. Why would that affect backwards compatibility in any way?

The TinyMCE plugins must be regular Joomla plugins of some sort. I don't care if they are a new sort or the existing ones, but it must be possible to install similar plugins for 3rd party extensions and also to disable the core ones (those introduced with this PR).
I like the idea from @nikosdion more than the current proposed approach.

Can we drop the xtd buttons for tinyMCE?

Only if you can guarantee that the 3rd party buttons still work. The JED category is highly inaccurate as most of those buttons just are part of a package for a component. They are not standalone plugins.

@Bakual @nikosdion Ok I get the idea, but how can we "hide" those button in the toolbar below the editor and let all the other buttons render as usual?
Is this your proposal, or I’ve got it wrong?

All editor-xtds plugins should be added to toolbar5 in TInyMCE. We can change JEditor to talk to each editor plugin and decide whether to show the buttons below the editor render area or not.

@nikosdion OK, There will be a take two on this one the!

@Bakual Question: Is it an acceptable option if a user has to click on a button in the tinyMCE plugin each time he installs a new xtd plugin? If so the solution is easy peasy

Question: Is it an acceptable option if a user has to click on a button in the tinyMCE plugin each time he installs a new xtd plugin? If so the solution is easy peasy

I don't think so. The random Joe Doe user doesn't even know about the plugin and will just complain that the xtd plugin doesn't work.

Closing this one.
Will come up with @nikosdion ’s approach

Imho, we should not distinguish between core extensions (com_content in particular) and 3rd party extensions. It's bad design if core can do something which 3rd party devs can't.

I agree with @Bakual that all editor-xtd plugins should be treated the same way. It's the consistent thing to do.

@Bakual @nikosdion There are two considerations here:

1. Do we want to drop mootools wherever we can?
2. Following @nikosdion's idea to grab the toolbar from bellow the editor and putting it under the last toolbar of tinymce is a process that has to be done with a plugin (onAfterRender) but the problem is that tinymce follows some strange name convention for the classes so also some strange wrapping needs to take place.

Here is a little video on how to grab the xtd and place them after the last tinymce toolbar done with moving html structure on the browser.
https://www.dropbox.com/s/14w7kw89tf51tnc/Jtoolbar.mp4?dl=0

Ant here is the native plugins:
simple

Advanced

Extended

About the consistency consideration:
how about the installer in case of xtd plugin search tor e.g. tinymce/plugin.min.js in the zip file
and then place it in media/editors/tinymce/plugins/NAME OF THE PLUGIN/ ?

This seems a nice and easy work around for the project and also for those that want to follow this path

What do you think?

idea is very good but approach is very limited ...

how about the installer in case of xtd plugin search tor e.g. tinymce/plugin.min.js in the zip file
and then place it in media/editors/tinymce/plugins/NAME OF THE PLUGIN/

this will be dirty trick 😉
actually it not important to have the script exactly in that folder ...
important to have tinymce.PluginManager.add('example', function(editor, url) { on the page before the editor initialisation and after tinymce.js

Here is my idea, similar to what was talked.
What is common between editor button, across different editors, and XTD buttons? right it is callback.

So, first suggestion:
Make extra event, called by Editor plugin, eg "onEditorInitToolbar" to XTD plugins, where XTD plugin should return array with button name, and callback (and any additional info eg icon, position):

// in XTD plugin file
function onEditorInitToolbar()
{
  //... here code for add button script eg:
 $doc->addscriptDeclaration('
   JoomlaXtdButton.blabla = function(){
     alert("Ta da!");
   }
 '); 

 // Some marker, that this button already in the toolbar 
 // and so, does not need to render it again under the editor
$this->asToolbar = true; 

 return array(
   'name' => 'blabla', // button name
   'title' => 'Blabla',
   'callback' => 'JoomlaXtdButton.blabla' // callback name
 );
}

Then the editor plugin add that result into own script, in way how editor need it.
Such approach allow to share the buttons across different editors, in theory 😄

Second suggestion, is move this event to the client side.
On editor initialisation, editor script do something like (JavaScript):

// part of the editor code, before init ( example for tinymce)
var stdButtons = [];
jQuery(editortextarea).trigger('onEditorInitToolbar', [stdButtons]);
stdButtons.each(function(i, val){
  tinymce.PluginManager.add(val.name,{
    onclick: val.callback
  })
});

// part of the STD button code
jQuery(editortextarea).on('onEditorInitToolbar', function(stdButtons){
 stdButtons.push({
    'name' => 'blabla', // button name
    'title' => 'Blabla',
    'callback' => 'JoomlaXtdButton.blabla' // callback name, or even whole callback method
 });
 // here some code that hide existin buttons under the editor
})

Or something like that...
Just theory, all code is fake and used just for demonstrate the idea 😄

@Fedik There are two types of buttons

1. those that execute some command (insert some predefined text, find and change etc on the editor content)
   2 The modals that can call an external resource or render a native tinymce modal

Therefore the second option is kinda hard.

The first one is not B/C. Kinda chicken-egg situation on this one! @nikosdion’s idea is the easier approach here some jquery

$('#editor-xtd-buttons').detach().appendTo($('mce-toolbar-grp.mce-container.mce-panel.mce-first.mce-stack-layout-item'));

But is not working for some strange reason and also we stay with the bloody mootools till v4...

hm, sad but true

but in case with the modal, we do not need to use "tinymce modal", because how then we should use XTD buttons when default editor is none 😉
I think in this case enough the bootstrap modal (that opens by callback on onclick event), similar as you already did with toolbar buttons.
I not very imagine the BC problem in this case, any example?

@Fedik see #7170

tricky 😉
well, ok I said nothing 🙊

Closing this one as it got too many negative comments. I will release a free version of a plugin more advanced than core tinyMCE, maybe also with group ACL

Sad face
On 13 Jun 2015 19:14, "Dimitris Grammatiko" notifications@github.com
wrote:

Closed #7152 #7152.

—
Reply to this email directly or view it on GitHub
#7152 (comment).

@Bakual I would appreciate a review for #7170

@DGT41 I'm the wrong one to review JavaScript and TinyMCE code.
As long as it threats 3rd party and core extensions the same and is backward compatible, then I don't see an issue.

@Bakual the only thing right now is that all 3rd PD buttons will default to the same predefines icon. If we enable the ability to have their own icon then they need to update their css to include one more class (the normal buttons follow the BS way but tiny uses other classes). I don’t know if that could count as B/C break. and honestly I hope it won’t 😃

I agree with @DGT41. Sort of rewriting TinyMCE's button handling (OMG, NO!!!) we can't push new button images for existing plugins. IMHO it's not a b/c break if:

• We make the integrated buttons an optional feature in 3.x and the default (or only) option in 4.0
• We write clear documentation that developers can follow to get their custom button icons ready for Joomla!'s built-in TinyMCE editor.

I think we can call this graceful degradation: if an editor-xtd plugin doesn't have a special icon class we can still display it using a default icon. Moreover it's an enhancement in that the 3PD plugins don't necessarily have to use one of our limited choice icons (remember, we've screwed up Bootstrap icons intentionally in Joomla!, removing most of them...), they can define their own.

Bonus: 3PD editors can use the same method implemented by the core TinyMCE editor to integrate 3PD buttons in their own toolbars / user interface if they so wish.

@nikosdion Totally agree to document this upcoming change the earliest possible and inform the 3PD through article and JED.

Nicholas I think the graceful degradation in case falls to rewriting tinyMCE’s button handling. Our options here are:

1. We predefine an icon for all the 3PD buttons (one class name e.g. copy will convert to mce-i-copy)
2. We pass the button name for all the 3PD buttons
   This will have two effects
   A. For the buttons that have a valid class defined in the css an icon will be displayed
   The impact for 3PD here is very small (adding a comma a space and i.mce-ico.mce-i-[button name] in their css of each button)
   B. For all the buttons that the class doesn’t exist no icon will be displayed at all

I guess this needs some consideration from the PLT, but I would like to state that i would go with option 2!

@DGT41 I agree with your approach.

I can sure live with it when it's only affecting the icons used. And even better we could edit our plugins to make them appear again.
As long as the buttons still work, I'm fine.