Rich Text Default Setting?

Is there a setting for making new pages rich text by default?

Quote from: debussy at Sep 23, 2009, 01:04 PM

Is there a setting for making new pages rich text by default?

Nope, but that would be a great suggestion for a Jira improvement ticket.

In my Revo install, new pages created in the Manager *are* rich text by default (whether the parent is rich text or not). I’d like to have a setting to make them *not* rich text.

It would also be nice to have three choices for both "published" and "rich text":

Yes
No
Match parent

(filed in Jira)

Quote from: BobRay at Sep 23, 2009, 11:29 PM

In my Revo install, new pages created in the Manager *are* rich text by default (whether the parent is rich text or not). I’d like to have a setting to make them *not* rich text.

It would also be nice to have three choices for both "published" and "rich text":

Yes
No
Match parent

(filed in Jira)

Great, thanks BobRay. FYI, settings can control default values but plugins should be used to "match parent" or determine values based on other calculations.

Quote from: OpenGeek at Sep 24, 2009, 08:33 AM

FYI, settings can control default values but plugins should be used to "match parent" or determine values based on other calculations.

Is that a speed issue? It certainly seems doable to have code in "create" that would check the system setting (which it will be doing anyway) and optionally set the richtext and published values to those of the parent. It wouldn’t take much time at all unless the "match parent" value was set and then I think it would be faster than a plugin.

Quote from: BobRay at Sep 24, 2009, 05:58 PM

Quote from: OpenGeek at Sep 24, 2009, 08:33 AM

FYI, settings can control default values but plugins should be used to "match parent" or determine values based on other calculations.

Is that a speed issue? It certainly seems doable to have code in "create" that would check the system setting (which it will be doing anyway) and optionally set the richtext and published values to those of the parent. It wouldn’t take much time at all unless the "match parent" value was set and then I think it would be faster than a plugin.

No it’s a choice issue; I don’t want that behavior unless I specifically ask for it (i.e. install a plugin), and there are a variety of other ways that could be done besides inheriting from the parent. The default behavior will be to use the settings of the current context (currently it just uses system settings or settings of the mgr context though).

Quote from: OpenGeek at Sep 25, 2009, 09:27 AM

Quote from: BobRay at Sep 24, 2009, 05:58 PM

Quote from: OpenGeek at Sep 24, 2009, 08:33 AM

FYI, settings can control default values but plugins should be used to "match parent" or determine values based on other calculations.

Is that a speed issue? It certainly seems doable to have code in "create" that would check the system setting (which it will be doing anyway) and optionally set the richtext and published values to those of the parent. It wouldn’t take much time at all unless the "match parent" value was set and then I think it would be faster than a plugin.

No it’s a choice issue; I don’t want that behavior unless I specifically ask for it (i.e. install a plugin), and there are a variety of other ways that could be done besides inheriting from the parent. The default behavior will be to use the settings of the current context (currently it just uses system settings or settings of the mgr context though).

But in my scenario, you wouldn’t get that behavior unless you specifically asked for it by re-setting system settings to "match parent" which wouldn’t have to be the default. It seems to me that the result would be the same, just easier and faster.

Also, my way would let you to easily control the editor and published status for subsections of the site which would be a pain with a plugin.

(Sorry for the delay ... no internet access for a while.)

Quote from: BobRay at Sep 29, 2009, 11:45 PM

But in my scenario, you wouldn’t get that behavior unless you specifically asked for it by re-setting system settings to "match parent" which wouldn’t have to be the default. It seems to me that the result would be the same, just easier and faster.

Also, my way would let you to easily control the editor and published status for subsections of the site which would be a pain with a plugin.

It may be easier, but it would change the whole way those system settings work to display that directly. I don’t want that to happen. Matching a parent or grandparent or ultimate parent is a calculation, not a setting. Thus, a plugin.

Quote from: OpenGeek at Sep 30, 2009, 08:15 AM

Quote from: BobRay at Sep 29, 2009, 11:45 PM

But in my scenario, you wouldn’t get that behavior unless you specifically asked for it by re-setting system settings to "match parent" which wouldn’t have to be the default. It seems to me that the result would be the same, just easier and faster.

Also, my way would let you to easily control the editor and published status for subsections of the site which would be a pain with a plugin.

It may be easier, but it would change the whole way those system settings work to display that directly. I don’t want that to happen. Matching a parent or grandparent or ultimate parent is a calculation, not a setting. Thus, a plugin.

Fair enough. But I realize that I’ve been unhappy with the way both published and Richtext are handled for some time. I’m constantly running into cases where the default behavior isn’t what I want and I’d need a complex plugin and some TVs to get what I want.

Consider the extremely commmon situation where you want documents in some parts of the site to be published by default and those in other parts unpublished by default and the same with rich text. The system settings won’t help you (and in fact, could get in your way). This kind of granular functionality should be easy to accomplish in MODx, IMO, without forcing the user to create or find a plugin, then configure it to deal with different parts of the site, possibly by creating and setting TVs.

I think my first choice would be to simply have every *new* page (however created) inherit the rich text and published values from its immediate parent. For me, this was the expected behavior for objects in a tree and it took me a while to realize that it wasn’t the case. I don’t see any down side to this although maybe I’m missing something. It would be great to be able to say, "Do you want new docs published by default in a section of the site? Put them in a published container document." This seems a lot better, IMO than trying to explain how to create and configure a plugin to do the same thing.

It shouldn’t interfere with any existing code that explicitly sets those values on save. The only issue I see would be whether to get rid of the system settings or keep them and decide how they would interact with the default behavior. It might be useful to have user settings that would override the default behavior (e.g. a user whose work is never published or a user who always wants the RTE).

ManagerManager can do this with the following rule...

Turn rich text off by default
mm_default(’richtext’, 0);

Turn rich text on by default
mm_default(’richtext’, 1);