I guess we have to normalise drag and drop
We have already 2 ways
PLG_TINY_FIELD_DRAG_DROP_DESC="Enable drag and drop for uploading images"
PLG_TINY_FIELD_DRAG_DROP_LABEL="Images Drag & Drop"

You add a new way:
(drag&drop)

Looks like we could use drag and drop
Oxford Dictionnary:
https://en.oxforddictionaries.com/definition/drag_and_drop

@Fedik
Can you correct the new lang string and modify to fit the 2 others in this PR?

@infograf768 done ?

The label should have caps, i.e.
PLG_TINY_FIELD_DRAG_DROP_LABEL="Images Drag and Drop"

I have tested this item ✅ successfully on 96f39a6

@infograf768 I made one more change, based on @ggppdk idea:

I have tested this item ✅ successfully on 84ef965

OK. Remains to see if we can make the general UI (the tabs 0 1 2 vs the Presets) more user friendly. But this I guess is for another PR.

1. Some corrections for language strings

An existing sets of the TinyMCE panel, and options for each.

Should be: Existing sets of the TinyMCE panel, and options for each.

The list of available buttons

(Maybe) should be: The list of available menus and buttons

In each Set you can add new buttons from

(Maybe) should be**: In each "set" you can add new buttons from

2. About easier configuration: (i can make a PR too)

It would be most intuitive
-- to pad+border 2nd level TABsets (like i showed on picture above) and
-- use JS to update the TAB titles, onchange of the drop-down select "Assign this layout to" (and of course on form load), to be:
"Public", "Registered" (instead of "Set 2", "Set 1")

thus the user can easily both:

• understand what each TAB is about, (it is about configuration per VIEWing access level)
• find the editor configuration set, of the desired access VIEWing access level without clicking them all

3. About existing tinyMCE configuration there is a simple solution to avoid problems

The existing configuration continue to be usable until you save the plugin (@Fedik correct ??)
If the above is true, just detect that there is an old configuration and display a message:

You existing configuration of tinyMCE editor is same for all access levels: public, registered, etc
We have upgraded this tinyMCE editor plugin to support 1 configuration set per access level.

After you click save your old configuration will be discarded,
Please configure the sets below and then click save

@Fedik can you do this last one ?

1. Some corrections for language strings

I am not strong in English ?
@infograf768 what do you think about suggestions?

2. About easier configuration

Not bad idea, but it make it more complicated to use the sets list in other places.
Example, I had a plan to add the option to user profile to allow to select one of existing set, so the "Set X" can be assigned to the User Y.
So I would not do what you have suggested, for now.

3 The existing configuration continue to be usable until you save the plugin

Not really, the plugin ignore an old existing configuration when render the TinyMCE,
but tries to use them on the plugin configuration form.
I think I can try to make similar thing: use existing options (which in the form) while render the TinyMCE.

For the strings, I propose these changes
PLG_TINY_SET_TARGET_PANEL_DESCRIPTION="<strong>Existing sets of the TinyMCE panel, and options for each.</strong><br />In each set you can add new menus or buttons from <strong>the list of available menus and buttons</strong> or remove unneeded."
and
PLG_TINY_SET_SOURCE_PANEL_DESCRIPTION="<strong>The list of available menus and buttons.</strong><br />Use them (drag and drop) to edit or build your custom TinyMCE panel."

which will give:

ok, I will change the strings, this evening

@Fedik
Note unrelated to this PR:
Created set Set 3 for Registered using Medium Preset modified by adding the LTR and RTL buttons OR used the existing Medium Preset tagged to registered.
Logged as Author
Using the menu item Create an article in frontend.
It is always the Advanced Preset which is displayed.
So basically, this feature does not work for me here.

hm, that bad, need to check more

the feature is flawed. one should chose among groups and not among access which does not make sense...

The problem comes from the multiple access levels one may have set on one's site.
I really think this should be redone using Users Groups instead of Access levels, i.e. using type="usergrouplist"

Similar problem a user is a member of multiple usergroups

The way it is done forces to create new Access Levels AND new User Groups.
Example: most of Users menu items are set to Special.
Therefore if we let an author or an editor access these menu items, the user group they belong to has to be added to the Special Access. Even if we do not want them to use the "Special" set in TinyMCE, they will...

IN any case it does not work here, whatever I do:

Example:
Created a User Group: Author RTL as child of Author.
Created an Access Level: Author RTL with ONLY Author RTL group as viewing Access
In the editor plugin, created a new set assigned to AuthorRTL as described above

Logged in frontend as Author RTL user.

Instead of getting this

I get this

@Fedik
Talked with @ggppdk a lot.
We should try to use usergroups (multiple) with priority to Set # when necessary instead of Access levels which are reserved to View and not Use and make Tiny B/C as much as possible by cheking if mode exists in the db before updating its parameters after a 3.7.0 update.
We can create a skype chat if you like.

I have update the strings

We should try to use usergroups

well, the idea about use "usergroup" instead of "viewlevel", sounds better,
just need to find out how to
I have used "viewlevel", because old configuration also use "viewlevel" for some options, but seems it was a bad idea ?

maybe open new issue?
I will do PR tomorrow, if all will be fine

@Fedik
About B/C:
My idea is to check
if ($this->params->get('mode') !== null)
then use old tiny (3.6.5 code)
and display a message if in admin to tell users to change the Tiny Settings.

	if ($app->isClient('administrator'))
	{
			$app->enqueueMessage(JText::_('PLG_TINY_OLD_TINY'), 'warning');
	}

else use new code.

@Fedik
I tested successfully here modifying Tiny to be fully B/C and display a message both when using the editor in back-end (in tinymce.php) and when editing the plugin (in /layouts/plugins/editors/tinymce/field/tinymcebuilder.php)
I did it with brute force, i.e. I added the conditional in the onInit() method, then in onDisplay() method by adding in this last one the whole 3.6.5 code in one conditional, not using the conditional for each change.
It adds evidently a lot of lines into tinymce.php: 1987 versus 1122, but it is now B/C

@infograf768 but what you made? ? maybe add some comments to #13387
I tried to make it without the message, to not confuse user much ?

Posted proposal for B/C on #13387

I have tested this item ✅ successfully on acd9742

OK, may need update after #13387

now I need to fix the conflict ?

yep, eclipse did it for me ?

fixed ?

I have tested this item ✅ successfully on 5c6eed1

@ggppdk

Now you can test.

I have tested this item ✅ successfully on 5c6eed1

The language strings added by this PR appear in the intended places

I have tested this item ✅ successfully on 5c6eed1

RTC

Thanks @Fedik

@rdeutz @wilsonge
Please merge that one too