? ? Success
Referenced as Related to: # 7170

User tests: Successful: Unsuccessful:

avatar dgt41
dgt41
11 Jun 2015

Attempt to drop the editors-xtd buttons

This is the initial commit (two more to come)
This was @nikosdion idea that we talked about in #JAB15 @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 (at least for tinyMCE)!

Here is a preview:
screen shot 2015-06-12 at 12 02 46

Comments suggestions are welcome!

avatar dgt41 dgt41 - open - 11 Jun 2015
avatar joomla-cms-bot joomla-cms-bot - change - 11 Jun 2015
Labels Added: ? ?
avatar joomla-cms-bot joomla-cms-bot - change - 11 Jun 2015
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - change - 11 Jun 2015
Labels Added: ?
avatar zero-24 zero-24 - change - 11 Jun 2015
Labels Removed: ?
avatar zero-24 zero-24 - change - 11 Jun 2015
Labels Removed: ?
avatar joomla-cms-bot joomla-cms-bot - change - 11 Jun 2015
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - change - 11 Jun 2015
Labels Added: ?
avatar zero-24 zero-24 - change - 11 Jun 2015
Category JavaScript Plugins
avatar zero-24 zero-24 - change - 11 Jun 2015
Status New Pending
Easy No Yes
avatar brianteeman
brianteeman - comment - 11 Jun 2015

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

Patch Links:


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

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

avatar dgt41
dgt41 - comment - 11 Jun 2015

@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

avatar brianteeman
brianteeman - comment - 11 Jun 2015

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

avatar dgt41 dgt41 - change - 11 Jun 2015
The description was changed
avatar wilsonge
wilsonge - comment - 11 Jun 2015

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

avatar Bakual
Bakual - comment - 12 Jun 2015

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.

avatar dgt41
dgt41 - comment - 12 Jun 2015

@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.

avatar nikosdion
nikosdion - comment - 12 Jun 2015

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?

avatar dgt41
dgt41 - comment - 12 Jun 2015

@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.

avatar infograf768
infograf768 - comment - 12 Jun 2015

@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

avatar nikosdion
nikosdion - comment - 12 Jun 2015

@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!

avatar dgt41
dgt41 - comment - 12 Jun 2015

@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.

avatar nikosdion
nikosdion - comment - 12 Jun 2015

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?

avatar Bakual
Bakual - comment - 12 Jun 2015

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.

avatar dgt41
dgt41 - comment - 12 Jun 2015

@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?

avatar nikosdion
nikosdion - comment - 12 Jun 2015

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.

avatar dgt41
dgt41 - comment - 12 Jun 2015

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

avatar dgt41
dgt41 - comment - 12 Jun 2015

@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

avatar Bakual
Bakual - comment - 12 Jun 2015

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.

avatar dgt41
dgt41 - comment - 12 Jun 2015

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

avatar dgt41 dgt41 - change - 12 Jun 2015
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2015-06-12 17:23:39
Closed_By dgt41
avatar dgt41 dgt41 - close - 12 Jun 2015
avatar dgt41 dgt41 - close - 12 Jun 2015
avatar dgt41 dgt41 - change - 12 Jun 2015
Status Closed New
Closed_Date 2015-06-12 17:23:39
Closed_By dgt41
avatar dgt41 dgt41 - reopen - 12 Jun 2015
avatar dgt41 dgt41 - reopen - 12 Jun 2015
avatar dgt41
dgt41 - comment - 12 Jun 2015

@Bakual @nikosdion How about this way: we do respect and render only the buttons from the 3rd party devs, but for tiny we use the native editor plugins?
https://github.com/dgt41/joomla-cms/blob/__tiny_btns/plugins/editors/tinymce/tinymce.php#L980-L1009

avatar dgt41 dgt41 - change - 13 Jun 2015
Title
Page Break button as native tinyMCE plugin
Editor xtd buttons as native tinyMCE plugins
avatar dgt41 dgt41 - change - 13 Jun 2015
Title
Page Break button as native tinyMCE plugin
Editor xtd buttons as native tinyMCE plugins
c640fbd 13 Jun 2015 avatar dgt41 CS
avatar Bakual
Bakual - comment - 13 Jun 2015

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.

avatar nikosdion
nikosdion - comment - 13 Jun 2015

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

avatar dgt41
dgt41 - comment - 13 Jun 2015

@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
screenshot 2015-06-13 12 37 05

Advanced
screenshot 2015-06-13 12 36 15

Extended
screenshot 2015-06-13 12 35 01

avatar dgt41
dgt41 - comment - 13 Jun 2015

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?

avatar Fedik
Fedik - comment - 13 Jun 2015

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 :wink:
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 :smile:

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 :smile:

avatar dgt41
dgt41 - comment - 13 Jun 2015

@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...

avatar Fedik
Fedik - comment - 13 Jun 2015

hm, sad but true :neckbeard:

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 :wink:
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?

avatar dgt41
dgt41 - comment - 13 Jun 2015
avatar Fedik
Fedik - comment - 13 Jun 2015

tricky :wink:
well, ok I said nothing :speak_no_evil:

avatar dgt41
dgt41 - comment - 13 Jun 2015

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

avatar dgt41 dgt41 - change - 13 Jun 2015
Status New Closed
Closed_Date 0000-00-00 00:00:00 2015-06-13 18:14:06
Closed_By dgt41
avatar dgt41 dgt41 - close - 13 Jun 2015
avatar dgt41 dgt41 - close - 13 Jun 2015
avatar brianteeman
brianteeman - comment - 13 Jun 2015

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).

avatar dgt41
dgt41 - comment - 18 Jun 2015

@Bakual I would appreciate a review for #7170

avatar Bakual
Bakual - comment - 18 Jun 2015

@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.

avatar dgt41
dgt41 - comment - 18 Jun 2015

@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 ????

avatar nikosdion
nikosdion - comment - 18 Jun 2015

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.

avatar dgt41
dgt41 - comment - 18 Jun 2015

@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!

avatar nikosdion
nikosdion - comment - 18 Jun 2015

@dgt41 I agree with your approach.

avatar Bakual
Bakual - comment - 18 Jun 2015

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.

Add a Comment

Login with GitHub to post a comment