CONSIDERATION: Ignore BUEditor's Visibility Settings. [#1786686]

Currently BUEditor Plus takes on the visibility settings for each editor in a profile. This can lead to some confusion (see #1786508: BUEditor not appearing on user account fields... as an example). What I am thinking of doing is this:

Hide the visibility settings on the editor edit screen (this is from the BUEditor module, not plus) by hiding the access.
Create a new visibility settings section per BUEditor Plus profile. It would be the same, except the visibility settings would apply to only non-entity formatted text fields. The entity fields will assume the profile as set in the field settings page.

If you have any concerns or opinions for this, please discuss them here. I would like to decide on this before working on the 7.x-2.x release.

Thanks!

Comments

Comment #1

Jamie Holly CreditAttribution: Jamie Holly commented 17 September 2012 at 14:48

Thinking further on this, we have two scenarios:

1. Entities
2. Non-entities

On entities the visibility is set through the field settings screen. This should remain the same and ignore all visibility rules.

On non-entites, we need a selection method for which profile should exist. I'm thinking of going with ignore paths and weighted profiles. This would allow the module to cycle through the profiles in order and stop when a certain profile matches the visibility criteria. This would also remove the "global profile" setting.

Thoughts? Suggestions?

TIA
Jamie

Comment #2

JordanMagnuson CreditAttribution: JordanMagnuson commented 18 September 2012 at 09:00

My only concerns would be performance-related: i.e. I would just want to make sure that any changes being made with regards to visibility settings, etc. don't adversely affect performance.

I do think that relying on the BUEditor visibility settings leaves a bit of room for confusion, but once you pointed that out, it actually made pretty good sense to me. It seems like relying on default BUEditor settings where possible might leave less room for confusion when enabling/disabling BUEditor Plus. I don't know.

Maybe this should be another issue, but have you considered/requested merging right into the main BUEditor module? Your module adds such obvious functionality, and if the two were merged, these kinds of confusions could be dealt with in a unified fashion. We would also get the performance benefits of one less module, bugs, performance, etc could get more thorough attention, and we could avoid duplicating any efforts between the two modules...

Comment #3

Jamie Holly CreditAttribution: Jamie Holly commented 18 September 2012 at 11:53

Right now it picks the profile and then each editor has to have the visibility settings checked. This will be a single check on the profile, so this is actually a performance booster.

I debated about making this a patch for BUEditor, but decided against it since it does a rather big change to the way BUEditor works. Also a lot of sites out there don't need this functionality. Most actually have a single input format available for regular content creators. I seldom use this module in client sites, though that will probably change when I get the 2.x branch done and have better WYSIWYG integration. Of course with the Spark initiative, a lot of things could change on the editor front.

Comment #4

JordanMagnuson CreditAttribution: JordanMagnuson commented 22 September 2012 at 11:12

Sounds good to me.

Comment #5

shunting CreditAttribution: shunting commented 17 November 2012 at 19:00

On spark:

1. So far, I love the in place editing functionality but

2. I think there is going to be a place for a really efficient and quick HTML editor for the foreseeable future.

Fact is, entering text in a box with angle bracket tags and some logic that turns characters like carriage returns and tokens into full blown tags is SGML's original use case, and it's very, very fast at that. If you care about productivity, that use case is a very good scenario. As soon as I train my users, they don't want to do anything else.

Granted, some coaxing/training is needed, but I want productive long form authors, and so the WYSIYWG mind candy is less important for me. I will probably end up using the Spark tools for annotation, copy editing, and correction after the "real work" is done.