"learn mode" for ACF

[Alfonso Martínez de Lizarrondo]

Many people will disable ACF because it modifies whatever content exists upon initial load if the classes, attributes, styles... haven't been added to the allowedContent.

A simple example is the stylesheet parser: you have been forced to make it disable the ACF in order to have things work.

Instead, the ACF could have an optional "learn mode" that adds whatever exists in the initial source to the allowedContent for that instance (maybe even configurable to work only on elements/classes/attributes/styles)

So now the stylesheet parser doesn't need to completely disable ACF: the first run of ACF sees some classes that aren't included in the ACF, so it adds those classes. Then the stylesheet is loaded and adds all the desired classes for the content. Nothing has been lost. The user then tries to paste something from an external page and the ACF is run and cleans up removing anything undesired. If the user copies and pastes something inside the editor, then all that content now is allowed and no filtering happens. everyone is happy.

[Piotrek Koszuliński]

Quote from #10136:

On setData stylesheets are not ready yet. To parse them before data are loaded we would have to reinvent bootstrap logic of the wysiwygarea editable.

Lear mode could help us solve this issue, because the ACF could be learning from the beginning to the instanceReady, so it would also include stylesheets.

And this is very interesting idea in general - it solves the common problem when one wants to limit pasting, but he doesn't want to configure ACF.

Although:

• I'm not sure about the details - e.g. what with source mode? Would it be limited or ACF could learn each time editor is switched from source mode back to wysiwyg. Perhaps this could be configurable.
• At the beginning ACF can't only learn from existing content, but it also has to include loaded features' allowed content rules, so they could work.
• This implies some problems:
  • as it is not possible to extract rules in optimized format, rules db will grow up a lot, what can influence performance,
  • learning will not be lightweight too - first, ACF would have to extract which element's parts are not allowed and then add them (we cannot add all elements' parts because it would make rules db too big) - both things take some time.
• Of course the performance will not be a problem on browsers which have quick JS engines (this does not touch DOM at all, so FF is included :D). And the bigger document is and more it adds to the ACF, the slowest ACF becomes.

Anyway, thanks Alfonso for a great idea!

[Mike Slinn]

This would be very helpful to me - I have a web site that uses CKEditor. Surprised to hear that a one-year-old site would be considered 'legacy'! There is a lot of content in the site, and figuring out the ACF rules would be painful in the extreme. That is why I disabled ACF, however this also means lots of noise gets injected into the HTML, which makes our product look bad. A learn mode would be terrific.

If a plugin could be made that scanned the HTML stored in the currently displayed page, and then create very restrictive rules to allow only the HTML elements and attributes found in the page, it could then combine those rules with any existing allow/disallow rules via user assistance. The plugin would pop up a dialog that allows the the user accept, ignore or negate the changes, one by one or use checkboxes to perform operations on multiple rules, thereby moving each selected element/attribute between the Allowed and Disallowed statuses, or removing them from both statuses.

[Mike Slinn]

I neglected to say the user would then have to copy the generated JS to their ckeditor folder manually