Opened 5 years ago

Closed 5 years ago

#12082 closed Bug (invalid)

Mention about ACF in shipped config.js file

Reported by: Piotrek Koszuliński Owned by:
Priority: Normal Milestone:
Component: General Version: 4.1
Keywords: Cc:

Description

We need some short comment about:

Why CKEditor removes my classes/styles/elements? Read more in the .... guide.

Change History (5)

comment:2 Changed 5 years ago by Piotrek Koszuliński

Status: newconfirmed

comment:3 Changed 5 years ago by Wiktor Walc

Configuration file should not be used as FAQ or as a solution for unfriendly documentation.

If we want to solve issue with ACF here, let's do it in a way that at least keeps the meaning of configuration file, by providing commented out configuration option for ACF and then a short follow up afterwards.

// Define changes to default configuration here. For example:
// config.language = 'fr';
// config.uiColor = '#AADC6E';

// To disable Advanced Content Filter, uncomment the following line:
// config.allowedContent = true;
//
// If enabled, Advanced Content Filter might remove ..........
// ............... (two lines of description maximum, ideally)
// Read more in ........................

It looks like we don't have clear, short & simple explanation what ACF does and why and instructions on how to extend ACF rules without having to read an essay about it. Let's do something with this as well, that would be a perfect entry point, to which we could link users from here.

Last edited 5 years ago by Wiktor Walc (previous) (diff)

comment:4 Changed 5 years ago by Piotrek Koszuliński

Configuration file should not be used as FAQ or as a solution for unfriendly documentation.

I totally agree... but :D But, we're solving here a real issue. The problem is that developers don't even know about the problem. They learn about it late and I understand their irritation when they lost some content already.

So this is a special situation and special situations are worth special solutions. Smart and early alarm may significantly improve the situation and places developers often visit when installing CKEditor are IMO the best places to alarm them about possible problem.

Therefore I proposed at least three places:

  1. config.js - IMO there we should only include an alarm; I don't think that we necessarily need to have a solution there.
  2. CKEDITOR.config documentation - BTW. the current content of config.js could be moved there and we definitely should have a link to CKEDITOR.config plus docs in there!
  3. "Configuration" section in documentation - here we can have this short article about ACF's options. It should be focused on configuration, not architecture as the current one (http://docs.ckeditor.com/#!/guide/dev_advanced_content_filter) does.

comment:5 Changed 5 years ago by Piotrek Koszuliński

Milestone: CKEditor 4.4.2
Resolution: invalid
Status: confirmedclosed

After a bit of a discussion we decided no to add anything to config.js, because it's only a half measure and we should not implement such solutions even in special cases like this.

Though, docs must be improved and this will be handled in https://github.com/ckeditor/ckeditor-docs/issues/14

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy