@infograf768 I still believe that the javascript should be on the layout file and not in the plugin. But that's another issue...
I will test later on

@dgt41
Concerning the js, we can, if desired, move it in later J! releases. For now, we just need to make sure someone is logged in and access to these xtd-editors is OK for authors.

@infograf768 I know, it just bothers me that although someone could (potentially) change the mark up on these views, they have to rewrite the plugins for some lines of js...
But this problem you are solving here, is way more important!

Now is ok, but is different from the admin panel procedure.
After set the Pagebreak by Author in frontend now show a iframe in the modal windows. Inside the iframe there is the website homepage.
Also for the module button.

@AlexRed
Not here on 3.6.3-dev

Please see the video test: http://www.alexred.com/joomla/page-break01.gif

@AlexRed
Maybe you should use staging + patch. Here is my video

I use today Nightly + patch

I get exactly the same behaviour as @alexred with current staging

I have tested this item 🔴 unsuccessfully on ffdfe68

@AlexRed can you try the following:

insert

$this->eName    = JFactory::getApplication()->input->get('e_name', '', 'cmd');

at line 11 on administrator/components/com_content/views/article/tmpl/pagebreak.php

and report if that fixes the problem?

@dgt41 no it doesnt fix it and the issue is in more than page break - it can also be seen with other exitor-xtd such as modules

I confirm the issue on a clean installation WHEN using using TinyMCE.

Please folks, test using Codemirror instead of tinyMCE.
@AlexRed @brianteeman

@dgt41
Looks like we do need a similar patch as the one you did for 3.7:
#12324

What would be the point of that. It needs to work with all the editors

The point is that we have an issue with TinyMCE, NOT with the xtd-editors buttons

I do confirm: clean install, NO patch, SuperAdmin logged in frontend, using the pagebreak or modules button: we get the same issue you folks noted when using TinyMCE

Thanks for wasting our time. When you have fixed this PR please let us know. No point at all testing if it works with a different editor

Please test what I said:
use staging and log in as admin, try to use the xtd-editors buttons WITHOUT this patch and logged as superadmin in frontend.
This PR is just showing another release blocker issue that was happening BEFORE it.
It has been solved in 3.7 with #12324

You should rather thank me for finding this out a few days before release...

yes, I can confirm same problem without this patch as superadmin in frontend.

Folks, first patch with #12372 (Thanks @dgt41 )
then you can test again with TinyMCE.

I have tested this item ✅ successfully on ffdfe68

I have tested this item ✅ successfully on ffdfe68

ok with #12372

RTC

This should be merged together with #12372

Remove the RTC tag

The ACL check on the component for displaying e.g. pagebreak is not proper (and for the XTD buttons)

https://github.com/joomla/joomla-cms/pull/12353/files#diff-58d7af9fe491285c0bec790cf59c6cc3R38

You can have create / edit / edit.own on a category and not have it at the component level,

thus this check is broken for all sites that do not give to their usergroups, these permissions to the component, but instead give them to specific categories (or even specific articles), i had describe this here:

#10653 (comment)

• if it is decided not to drop the ACL checks for the pagebreak, then one needs to pass and check a specific "current" record (article) asset

@ggppdk
Indeed, this patch was not aimed at solving fully the ACLs. Just to let author access these xtds with existing ACL (adding create and editown.

As a RC-3 has now been released, I suggest you propose a PR to implement it fully.

Please revert this PR. This effectively removes any access checks against the articles view in the backend. Everybody can now access the articles view, even with a guest user. You added checks to prevent a link from being displayed, but not opening the actual resource.

Simply open ?option=com_content&view=articles&layout=modal&tmpl=component&{formtoken}=1 on your site and you get a list of all articles that have public viewlevel.

This not only gives you a complete list of the public articles (some of which maybe should not be found yet), it also gives you a complete list of your sites categories, viewlevels, authors and more. A nice truckload of information to further construct attacks against your site.

@Hannes
using the link you provide above as a guest, registered or author, I just get un frontend:
The most recent request was denied because it contained an invalid security token. Please refresh the page and try again.

Now, an author can indeed use the xtd when creating an article, which was not possible before.

When using the same link when not logged in backend just displays the login page

Now, as I said, we can re-add the checks in
ROOT/components/com_content/content.php, but using instead of only core.edit, also core.create and core.editown

Sorry, github swallowed parts of my link. You need to replace {formtoken} with the token. You can get that token from for example the login or contact-form view. This is a serious security issue!

@Hackwar
I can re-add the checks in content.php but also including create an edit.own
Would that be OK for you? I mean: is it OK for you to let authors use these xtds (will be the same isssue for the 3.7 branch and its new xtds)

Taking into account your comment here:
#12321 (comment)

I will now make a PR towards staging

Re-adding that check is a good first step. From my perspective, we need to further check this and consider what we display to editors, etc. Should someone with frontend editing capabilities see all categories, viewlevels and articles in the modal? I'd say that we have to restrict all of this to only those elements that the user would have access to.

As we can't right now do all necessary checks, this #12435 will let authors access to the xtds while preventing guest or registered users.
It just changes the limitation from editor to author.