Define which fields should be available as blocks.
| Project: | CCK Blocks |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
If you have a lot of CCK fields, your blocks configuration page can easily get cluttered. Even worse, you can easily mix up one field with another on this page, and publish fields as a block that were never meant to be used as such.
A solution would be to have a separate configuration option for each CCK field that defines whether this field should be available as a block. There can be a checkbox within the individual field configuration page, plus a configuration page with a list of fields and checkboxes (maybe as a sub-tab in the blocks config page, so you have it easily available).
The problem would not exist (or be less severe) if the inactive blocks in the blocks config page were grouped by module (they would have to be re-sorted every time you submit).
#1
Marking that as critical, as I do agree completely, that a huge number of cck fields can turn the list of blocks into a mess.
Maybe we can have a look at the nodeblock module (http://drupal.org/project/nodeblock). I guess, they do, what you suggested, not with cck fields but with content types.
#2
I think it is important that you have the configuration page easily available from the blocks admin page, so you don't need to scratch your head where the CCK blocks have gone.
Where should the information be stored? In content_node_field.global_settings, or somewhere in content_node_field_instance? I think it would make sense to do both, and allow to override the setting for field instances.
#3
nodeblock: You can't really compare that, I think. If nodeblock would not have a checkbox per content type, you would end up with tens of thousands of blocks, as many as you have nodes. As it is now, I only have as many block nodes as I need, which is around 2 or 3 of them.
#4
Hm, let me see if I understood the difference. I guess:
- content_node_field.global_settings are the global settings of a field, regardless of the content type, the field is assigned to
- content_node_field_instance are the instance specific settings for a field, attached to a node
In my opinion, we should avoid storing (and presenting) this option at more than one configuration page. I guess, one does not have that many node types, that it's too much work to enable/disable the "show as block" feature for every instance of a field, you want to have in a block. I guess, there are not more than 10-20 blocks on one paga and not every block will display a cck field.
So my recommendation is to provide this option for field instances only. Maybe
admin/content/node-type/*/displayis the right place to add an checkbox "display as block". Alternatively, a checkbox in the fields configuration page (at the bottom, in a "cck blocks" area) is possible.#5
I have a use case for storing things in content_node_field.global_settings.
I made a CCK field (flexifield with imagefield + radiobutton options) that allows to define background images for nodes of different content types. There is a "content_bg" region where the blocks work as page backgrounds, and the CCK block for this flexifield is one of them.
To make a new content type that can do background images, I simply give it this flexifield. And for pages that are not nodes, I have a nodeblock that does the same job. Advanced shit.
It would be quite a few steps more work if I had to configure block visibility separately for every content type. The field is made for being a block, no matter which content type it is used in.
And that aside, the module provides one block per field, not per field instance. That's how it works.
I think it would make sense to provide both options, but have a central place to manage it all.
#6
Obviously ;-)
So, in the first step, I would recomend to provide an option for activating / deactivating the block per field, as it seems, that a field should have the same meaning in every content type it is used with.
I guess it's not too much work, if you need the same functionallity without a block, to copy the field and then to have to fields, say, "field_background_block" and "field_background_no_block".
Unfortunately, I'm out of my office for the next three weeks, but i'm looking forward to the discussion, that is hopefully going on here without me. In my opinion, his is an important topic!
#7
Please have a look at tomorrows -dev release. Do you have enough experience in cck to see, where to make the changes to solve this issue?
#8
Subscribing.
#9
subscribe