Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Add the ability to control the default format at the field level with the full control and options BF provides in other format default screens.
A simple field level default that piggy backs on D7 Fields' default value is already committed. This allows the admin to set the default format of a field without having to also enter a value into the field if they wish. This is very simplistic and does not provide full power but is simple enough for many people. The option is not turned on by default as that would change the way the fields work in core without the users' knowledge.
Comment | File | Size | Author |
---|---|---|---|
#21 | field-formats-112311-21.patch | 5.51 KB | emarchak |
#16 | field-formats-1275266-16.patch | 5.51 KB | Jamie Holly |
#12 | field-formats-1275266-11.patch | 5.56 KB | Jamie Holly |
#7 | field-formats-1275266-7.patch | 18.01 KB | Jamie Holly |
#3 | field-formats-1275266-3.patch | 10.85 KB | Jamie Holly |
Comments
Comment #1
webchickTagging.
Comment #2
Jamie Holly CreditAttribution: Jamie Holly commentedPatch attached. Adds per field configurations plus a per entity default format. Patch moved from http://drupal.org/node/1231272#comment-5025998
Comment #3
Jamie Holly CreditAttribution: Jamie Holly commentedAttaching a new patch. Added some comments on what's happening, plus setting the default_value for the format select to the top format in the list.
Comment #4
miro_dietikerReferring correctly to the related
#1231272: Set preferred format per content type
Great progress!
Comment #5
Cyberwolf CreditAttribution: Cyberwolf commentedSubscribing.
Comment #6
Cray Flatline CreditAttribution: Cray Flatline commentedHollyIT, thanks a lot for your great patches. All of us need this functionality. Little review from me.
I tried to apply your patches.
Patch #2 was applied successfully but it gets error that better_formats.theme.inc file is missing.
Patch #3 was failed to apply.
Comment #7
Jamie Holly CreditAttribution: Jamie Holly commentedTry this one out. One of those weird Git things.
Comment #8
miro_dietikerNow we have another issue with a similar suggestion containing:
#1295248: Allow per-field-instance configuration of allowed formats
Comment #9
Crell CreditAttribution: Crell commentedIMO, shoving the field settings into the variables table makes no sense. As a field instance setting they're already saved smartly by the system with the field, so it's not loaded if we don't need. Way too many modules abuse the variables table already, and it's causing a memory problem for Drupal. Let's not do that.
That also makes this patch considerably larger than I think it needs to be.
(And yeah, I totally didn't see this issue before posting. Bah.)
Comment #10
Jamie Holly CreditAttribution: Jamie Holly commented@Crell -
This patch actually stores the per field settings with the field system. The variable table is only used for entity type defaults, should a user decide to use them:
And I totally agree about the abuses of the variable tables. There are a ton of modules that abuse the system and if you have a Drupal site that's been around for awhile and seen modules come and go in the installation, that table becomes a lead anchor on the whole site.
The default format settings could be stored in their own table, but I don't think that would reduce the code size any. If anything it would increase it with having to deal with CRUD on the new system.
Comment #11
Crell CreditAttribution: Crell commentedAh, I see. I must have misunderstood that in the patch.
I'm not sure there's a need for the node type defaults, though. If that's what accounts for the 15k difference in patch size, I don't think it's worth it. In the "default" case, we'd just edit the settings on the one body field anyway and be done with it.
Comment #12
Jamie Holly CreditAttribution: Jamie Holly commentedHere's a patch with the default stuff removed. That could possibly be put into another module, with the addition of a hook_alter on the settings in better_formats_filter_process_format(). Most of the code added is for the drag and drop table to order filters on the field settings ui.
Comment #13
felixSchl CreditAttribution: felixSchl commentedSubscribing.
Comment #14
j0rd CreditAttribution: j0rd commentedIs this the same work as #1295248: Allow per-field-instance configuration of allowed formats ?
Comment #15
miro_dietikerHollyIT, nor after applying #7 or #12 ... i'm unable to find the location to limit the input format per field / field-instance.
Am i missing something?
BTW: It seems to me that this issue and the referred #1295248 is now almost similar after the discussion thread. (Thus, the #1295248 would be duplicate.) Am i wrong?
Comment #16
Jamie Holly CreditAttribution: Jamie Holly commentedYou have to go to admin/config/content/formats/settings and check the "Use field default" box and then the customizers will appear in the field settings pages under content types. Not really sure what that checkbox is for, but I left it acting as that depending upon what it's intention is by dragonwize.
Also, here's a new patch that removes references to the better_formats.theme.inc file I had before.
Comment #17
miro_dietikerThank you HollyIT. Patch applies cleanly.
Found the checkbox. But afterwards i still cannot change anything. What should change?!
There's no settings on my multiline textfields (with formats) that allow me to change the allowed formats.
EDIT: Based on the description of that settings page, i really don't understand what this has to do with per-field-formatter-enable/disable...
Comment #18
Jamie Holly CreditAttribution: Jamie Holly commented@Mrio -
Go to admin/structure/types. Click on "manage fields" for a content type. Go to the body or a textfield that has processing and edit that field. You will get the table to change the order and enable/disable formats on the edit page under "INPUT FORMATS".
Comment #19
TripleEmcoder CreditAttribution: TripleEmcoder commentedIs ordering ready in this patch? I applied from #16 and I only get weight dropdowns instead of the usual JavaScript reordering.
Comment #20
Jamie Holly CreditAttribution: Jamie Holly commentedI just applied the patch to a fresh pull of bf and it applied fine and gives me the draggable ordering of the formats. Couple things to check:
- Any JS errors?
- Do you get the show/hide weights link above the table? (NOTE: that toggle is stickied in the session. I've been caught by that more than once, thinking dragging isn't working, but rather I had clicked that toggle link somewhere else).
Comment #21
emarchak CreditAttribution: emarchak commentedApplied patch from #16, and everything's working fine. Rerolled it to work with drush make.
Comment #22
stano.lacko CreditAttribution: stano.lacko commentedScreenshots looks very nice, but when it will be in 7.x-dev version?
Comment #23
miro_dietikerPity... i still cannot reproduce this patch and the things it changes... My UI doesn't show any options after applying, even if i enable the checkbox "Use field default".
Have no clue what i'm missing. Please help me to understand this since we'll push this issue to be fixed once i see a way to go.
Comment #24
tsvenson CreditAttribution: tsvenson commentedCross-post: This patch and #1295248: Allow per-field-instance configuration of allowed formats are aiming for adding a similar feature improvement. Would be great if the authors could agree and work together on a solution so we can get this much needed improvement committed thanks.
Comment #25
tsvenson CreditAttribution: tsvenson commentedTreid the patch in #16 as the patch in #21 didn't apply using git. Found several issues though:
Love the draggable UI though.
Still, I suggest reusing the draggable UI (but changing to Allowed) for the patch in #1295248: Allow per-field-instance configuration of allowed formats with the suggestions I made in comment #50 there.
Comment #26
tsvenson CreditAttribution: tsvenson commentedSetting correct status and demoting to normal.
Comment #27
dragonwize CreditAttribution: dragonwize commentedPriority is being used to show issues needed for D7 release.
Comment #28
donquixote CreditAttribution: donquixote commentedSorry, if my following comment is going to be totally uninformed of what has been discussed before :)
If it is, maybe that's a hint to update the issue summary.
-------
Imo, there should be three possible default states for a formatted text field:
Instead, the global default format for the user role or entity type will be used.
The fourth option, default text without format, does not make sense. If there is a text, there must be a format.
Also, the "allowed formats" are a different story, this is only about the default format.
We need to be very careful to clearly distinguish state (1) and state (2).
The form element for format selection (select or radios) needs an additional option "use site default" (or role default, etc). And the validation needs to complain, if a non-empty text is to be saved with a "use site default" format.
This extra option does only exist on the widget for the default value, not on the regular field value widget in the entity edit form.
If this is what all the proposed patches attempt to do, all that needs to change is the issue summary :)
Otherwise, I hope this post can inspire some new thinking.
Comment #29
capellicVery excited about the "per entity" scope here. I have had many cases where I didn't want to give the same WYSIWYG toolset on all the rich text fields on a given node. The most common use case is wanting to have a Body and a Teaser field. The Body field would have a full WYSIWYG toolset while the Teaser field would have a much smaller toolset because we don't want them going nuts with the formatting for the Teaser.
The CKEditor Module would allow me to override fields so that I could show a simpler toolset for the Teaser... but then I was limited to only two profiles and the WYSIWYG module doesn't support this.
I like the idea of being able to control CKEditor profiles based on the input format the user is allowed to use per entity... the options are endless. Thanks for all the work so far, looking forward to this feature getting into DEV.
Comment #30
steinmb CreditAttribution: steinmb commenteda big +1 from me on controlling the input format on field level. Anyone working on #21 at the moment? Looking at the code review #25 and the writeup in #28 do I get the feeling that it need some work, and that patch in #21 at least need to be rerolled against latest dev.
Comment #31
BerdirIt probably makes sense to focus on #1295248: Allow per-field-instance configuration of allowed formats first and then rebuild this patch on top of that. Right now they probably overlap quite a bit and provide a different user interface.
Comment #32
steinmb CreditAttribution: steinmb commentedYou are right. This issue contain multiple comments regarding that. Don't shoot me but I close this as a duplicate of #1295248: Allow per-field-instance configuration of allowed formats.
Comment #33
BerdirThe maintainer has reverted a duplicate status multiple times now.
It's not really a duplicate, it just depends on the other issue to provide the basic functions and UI.
Comment #34
steinmb CreditAttribution: steinmb commentedOK, but I do not get it why they tried to roll an patch then this issue clearly depend on that the patch in 1295248 to get committed. So let's all get #1295248: Allow per-field-instance configuration of allowed formats tested, reviewed and commited. Could someone pls. make the title more descriptive so it's closed by someone else? I could but then again I'm no longer sure what this issue is supposed to provide of functionality. Sorting of input formats on field level?
Comment #35
BerdirThe other issue is about *allowed* formats, this one is to additionally select a default one.
Comment #36
steinmb CreditAttribution: steinmb commentedOK, more of the stuff we have in the D6 version of this module. Nice :)
Comment #37
dragonwize CreditAttribution: dragonwize commentedMerged Jamie Holly's work with the allowed formats work in another issue.
Committed. Thanks everyone.
Please file any follow-ups separately.