Custom Block Attributes
Permalink 1 user found helpful
I've often run into issues where I needed a slight variation on an existing block.
* For example, what if you wanted to add a 'Title' to a Slide Show Block?
* What if you wanted to associate a thumbnail with a Content Block for special treatment?
* Maybe you need to tag your block with some meta data?
My solution is creating Custom Block Attributes. The same way you can dynamically create and associate attributes with files/collections/users, I want to be able to create / associate attributes with blocks.
I've got a quick solution prototyped (see attachments), but it unfortunately requires me to hack the core. I'm curious to see if there's enough desire for this functionality to try and push it to core?
So, I'm looking for two things: If you would like to see this functionality added, please voice your support.
If you have an idea of how to make this functionality better / expand on the concept, please comment as well.
Thanks
* For example, what if you wanted to add a 'Title' to a Slide Show Block?
* What if you wanted to associate a thumbnail with a Content Block for special treatment?
* Maybe you need to tag your block with some meta data?
My solution is creating Custom Block Attributes. The same way you can dynamically create and associate attributes with files/collections/users, I want to be able to create / associate attributes with blocks.
I've got a quick solution prototyped (see attachments), but it unfortunately requires me to hack the core. I'm curious to see if there's enough desire for this functionality to try and push it to core?
So, I'm looking for two things: If you would like to see this functionality added, please voice your support.
If you have an idea of how to make this functionality better / expand on the concept, please comment as well.
Thanks
+1 for me.. Seems very useful, I also often need a small modifications to an existing block in order to meet client needs, and going through the process of copying it over renaming all the handles.. etc etc is a pain..
+1 here too.
we had an interesting talk in IRC on this,
opinions?
[3:29pm} Mnkras-Laptop: I was thinking of combining it with custom templates [3:29pm] Raverix: Interesting... [3:29pm] Raverix: I like the idea of integrating it with custom templates. [3:29pm] Mnkras-Laptop: [3:29pm] Mnkras-Laptop: in the custom template dialog [3:30pm] Mnkras-Laptop: like having a controller for custom templates that extends the block controller [3:30pm] Mnkras-Laptop: and having a form.php that is pulled to the custom template dialog [3:31pm] Mnkras-Laptop: and a db.xml [3:31pm] Raverix: I'm sold. [3:31pm] Raverix: I'd love to work on something like that. [3:31pm] Mnkras-Laptop: I was also thinking of instead of having the custom template thing as a menu item [3:31pm] Raverix: But I don't want to have to re-implement it everytime C5 upgrades the core. [3:31pm] Mnkras-Laptop: to integrate it into the add/edit dialog [3:31pm] Raverix: Put it in the edit block, absolutely. [3:32pm] Raverix: Of course, if you did that, you add a whole new level of complexity.
Viewing 15 lines of 18 lines. View entire code block.
opinions?
Well, the idea is interesting, but I think it's WAY over the head of the "typical" user, content editor, or site maintainer. As such, putting that functionality in front of everyone with an edit-mode UI might clutter and confuse more than anything. Perhaps a dashboard UI is more appropriate. Might it make more sense to access that UI when editing a block type in the "Add Functionality" section?
Then again, it sounds like you're talking about block attributes being associated with block instances and not block types. Is that correct?
-Steve
Then again, it sounds like you're talking about block attributes being associated with block instances and not block types. Is that correct?
-Steve
With this particular execution, which I really like and think would be good, it would still be in the hands of the developer creating custom templates to define which additional information you need to render the template. To give you an idea of how this might look, I comp'd up an example (see attachment).
If the user is expected to be able to select from a series of custom templates, I think they can be expected to fill in the fields when prompted for them.
If the user is expected to be able to select from a series of custom templates, I think they can be expected to fill in the fields when prompted for them.
> * For example, what if you wanted to add a 'Title' to a Slide Show Block?
> * What if you wanted to associate a thumbnail with a Content Block for special treatment?
> * Maybe you need to tag your block with some meta data?
Isn't that what overriding and editing block controllers and templates is for? If you're talking about this being a part of the standard editing UI, I'm not sure that kind of functionality belongs in the hands of the typical site maintainer.
-Steve
> * What if you wanted to associate a thumbnail with a Content Block for special treatment?
> * Maybe you need to tag your block with some meta data?
Isn't that what overriding and editing block controllers and templates is for? If you're talking about this being a part of the standard editing UI, I'm not sure that kind of functionality belongs in the hands of the typical site maintainer.
-Steve
Yes, all you need to do is copy the block from the /concrete/blocks folder to your /blocks folder. Change the name, and the handles, and table references. Then modify the add/edit pages with your new field, update the SQL to save it, the db.xml, test and debug everything, and then make sure to implement any bug fixes to the core version when Concrete5 updates.
Or, have the ability to 'tack on' extra attributes to your blocks.
You don't have to create a new page class in order to add new attributes to a page, this is what I'm trying to emulate for blocks.
Or, have the ability to 'tack on' extra attributes to your blocks.
You don't have to create a new page class in order to add new attributes to a page, this is what I'm trying to emulate for blocks.
Hi Raverix,
Ok, I looked at the images you posted, and I do see value in what you're proposing - at least for very knowledgable types. It would simplify the process of enhancing a block for developer types.
However, I'm still not convinced it has a place in the standard editing UI. If there's one major complaint I have about C5, it's that there's just too much to fiddle with for the "regular" site owner (feature rich or feature laden, depending on your perspective).
> You don't have to create a new page class in order to add new attributes to a page,
> this is what I'm trying to emulate for blocks.
So then, are you talking about associating specific attribute types with blocks in general, with block types, or with block instances? I'm just wondering how you envision the attribute type associations being set up.
-Steve
Ok, I looked at the images you posted, and I do see value in what you're proposing - at least for very knowledgable types. It would simplify the process of enhancing a block for developer types.
However, I'm still not convinced it has a place in the standard editing UI. If there's one major complaint I have about C5, it's that there's just too much to fiddle with for the "regular" site owner (feature rich or feature laden, depending on your perspective).
> You don't have to create a new page class in order to add new attributes to a page,
> this is what I'm trying to emulate for blocks.
So then, are you talking about associating specific attribute types with blocks in general, with block types, or with block instances? I'm just wondering how you envision the attribute type associations being set up.
-Steve
Well, I'm not sure what the best solution is, which is why I'm trying to elicit some responses from the community. I think the need is definitely there, it's just a matter of coming up with the most flexible / easy to use solution.
Since obviously, the attributes wouldn't be displayed until you added them to the template, I think that makes for a very compelling argument that these two things should be tied together.
For example, let's say you wanted to create a callout box which was simply a content block, but has a 'title' field which is treated specially and needs custom markup around it? Well, you would have to write a custom template, so when the user selects that template, being prompted for a title makes perfect sense.
In this situation, it would be on a per custom theme basis.
Since obviously, the attributes wouldn't be displayed until you added them to the template, I think that makes for a very compelling argument that these two things should be tied together.
For example, let's say you wanted to create a callout box which was simply a content block, but has a 'title' field which is treated specially and needs custom markup around it? Well, you would have to write a custom template, so when the user selects that template, being prompted for a title makes perfect sense.
In this situation, it would be on a per custom theme basis.
Also, are you aware of jordanlev's Designer Content block?
http://www.concrete5.org/marketplace/addons/designer-content/...
I haven't actually tried it yet myself, but it seems to address at least some of the same issues - at least in terms of allowing developers to quickly create custom blocks which have specific pre-defined types of content and which end users can then easily create and edit.
-Steve
http://www.concrete5.org/marketplace/addons/designer-content/...
I haven't actually tried it yet myself, but it seems to address at least some of the same issues - at least in terms of allowing developers to quickly create custom blocks which have specific pre-defined types of content and which end users can then easily create and edit.
-Steve
@Shotster just think of this as an extension of custom templates
> just think of this as an extension of custom templates
But that, I think, poses a bit of a problem - at least for the typical user - whether it's part of an enhanced template selection dialog or a separate menu item and dialog. I see the potential for confusion on the user's part if they have to go through some alternate UI (apart from the standard block editing UI) in order to add/edit/associate some additional data/content with the block. I can see someone asking, "Why do I have to edit/configure the block, click the update button to dismiss the editing dialog, and THEN click on that same block again and choose a different menu item in order to enter MORE information about the block I just edited?!!"
-Steve
But that, I think, poses a bit of a problem - at least for the typical user - whether it's part of an enhanced template selection dialog or a separate menu item and dialog. I see the potential for confusion on the user's part if they have to go through some alternate UI (apart from the standard block editing UI) in order to add/edit/associate some additional data/content with the block. I can see someone asking, "Why do I have to edit/configure the block, click the update button to dismiss the editing dialog, and THEN click on that same block again and choose a different menu item in order to enter MORE information about the block I just edited?!!"
-Steve
This, is absolutely a downside to what I'm proposing. Which if you take a look in the list above, Mnkras and I would love to figure out how to integrate this into the add/edit dialogs...
Why is it now with the current system, to add a block with a custom template you have to add a block, add all your information, and then save, and then click the block, and open the custom template menu to complete the process?
I'd love to hear any insight you have into making this an integrated process. Moving the custom template UI into the add/edit dialog would be a step in the right direction. Maybe a tab on the same box? Maybe the fields are added to the top? the bottom?
Why is it now with the current system, to add a block with a custom template you have to add a block, add all your information, and then save, and then click the block, and open the custom template menu to complete the process?
I'd love to hear any insight you have into making this an integrated process. Moving the custom template UI into the add/edit dialog would be a step in the right direction. Maybe a tab on the same box? Maybe the fields are added to the top? the bottom?
Ok, just noticed Mnkras' IRC comment about integrating the template selection into the standard block editing dialog. That in and of itself might not be a bad idea, but I still don't think having the user enter more data when "choosing a template" makes a lot of sense.
-Steve
-Steve
Actually, that's a great package for quickly creating new types, and I use it now. However, I think there a few issues with the package.
1) It attempts to address the inability in C5 to quickly make custom blocks. Right now, you have to do it by writing custom code.
2) It adds more blocks to the system than I think are necessary. (Imagine Content block with title, content block with thumbnail, image block with title, sub title, caption, and alt tag)
3) If you want to make a modification to that block, you need to modify the existing block with code, you cannot modify it using the package, (reference the same issues above, yes, you can do it, but it's not a efficient solution),
The solution I'm proposing would overlap some of what this package does, but in my opinion, offers greater flexibility.
Here's the difference:
* Designer Content Block creates new blocks.
* My solution enhances / augments existing blocks.
The inherent benefit is that you don't need to mess with the existing code, saving a lot of time, and C5 can continue to evolve and not break your additions.
1) It attempts to address the inability in C5 to quickly make custom blocks. Right now, you have to do it by writing custom code.
2) It adds more blocks to the system than I think are necessary. (Imagine Content block with title, content block with thumbnail, image block with title, sub title, caption, and alt tag)
3) If you want to make a modification to that block, you need to modify the existing block with code, you cannot modify it using the package, (reference the same issues above, yes, you can do it, but it's not a efficient solution),
The solution I'm proposing would overlap some of what this package does, but in my opinion, offers greater flexibility.
Here's the difference:
* Designer Content Block creates new blocks.
* My solution enhances / augments existing blocks.
The inherent benefit is that you don't need to mess with the existing code, saving a lot of time, and C5 can continue to evolve and not break your additions.
I was thinking of the idea of a "extras" tab on all blocks that has a place for info and you tell it what to do with it. Something like a individual wrapper for each block where you can set before and or after code such as adding a title field to a content block. that is told to assign xxx class and put before the block. Or perhaps quick and easy add extra code to an image so when you click an image it plays a mid (please note this is only an example and I have not attached midis to web pages in over 10 years)
I am not for certain but I think it would be possible to have c5 core simply attach that tab to all add block popups and store the info separately but still attached to the block id and just automatically extend it to all blocks old and new.
I am not for certain but I think it would be possible to have c5 core simply attach that tab to all add block popups and store the info separately but still attached to the block id and just automatically extend it to all blocks old and new.
This is so weird -- just yesterday I was thinking about how to improve a tabbed interface I had on a site, and thought "wouldn't it be great if there was some meta-attribute on a block, like you could just assign a "title" to every block -- that way the block title would be my tabbed interface title" (on this site, when in edit mode the area just shows its blocks, but when not in edit mode, there's javascript in the page type template that hides all of the blocks in that area except for 1 and displays navigation tabs -- but right now the user is limited to just 1 block type being in there: a custom block I had to make with a title field, which sucks because they can't put any other block types in there).
I would suggest that a better UI for it would be an additional item in the popup menu (under "Custom Template"), not in the block editing window itself. Block attributes should just be one consistent interface (like how the page attributes UI is), not something that needs to be designed by the block author. Maybe it could be combined into the "Custom Templates" popup item so that popup menu doesn't keep getting longer... because when you think about it, a custom template is really just one kind of block attribute.
The complicated part of the code (besides the editing UI of course) would be making sure this stuff carried through when a block is aliased from the Page Defaults or is copied via the Scrapbook (or is just an alias in the scrapbook), etc. etc.
All that being said -- as much as I like this concept, maybe all that's really needed it 1 textbox for the "title" (and the title would be out of the way and optional of course) -- that would seem to cover most use cases I'd think.
I would suggest that a better UI for it would be an additional item in the popup menu (under "Custom Template"), not in the block editing window itself. Block attributes should just be one consistent interface (like how the page attributes UI is), not something that needs to be designed by the block author. Maybe it could be combined into the "Custom Templates" popup item so that popup menu doesn't keep getting longer... because when you think about it, a custom template is really just one kind of block attribute.
The complicated part of the code (besides the editing UI of course) would be making sure this stuff carried through when a block is aliased from the Page Defaults or is copied via the Scrapbook (or is just an alias in the scrapbook), etc. etc.
All that being said -- as much as I like this concept, maybe all that's really needed it 1 textbox for the "title" (and the title would be out of the way and optional of course) -- that would seem to cover most use cases I'd think.
Did this ever progress into development in any way? What a powerful feature it would be to be able to add attributes to blocks in the same way you can add attributes to pages. I use page attributes all the time and I have really found it to be one of the more powerful features of C5. I can only imagine how great it would be to extend this feature to blocks.
Any thoughts?
Any thoughts?
Block names were added (in 5.5.1 I think?)... click on a block and choose "Custom Template" from the popup menu to access that field.
Also, I've since learned that Areas already have attributes -- so in your theme code you could do this:
Getting that attribute from within the block... I'm not exactly sure how (I'm sure it's not hard, just haven't done it yet because the "block name" is enough for my uses).
But I don't think there are attributes on blocks (other than the "block name", which isn't technically an "attribute" in the C5-object-model sense -- it's just a special text field).
Also, I've since learned that Areas already have attributes -- so in your theme code you could do this:
$a = new Area('Main'); $a->setAttribute('some_attribute_key', 'some_value'); $a->display($c);
Getting that attribute from within the block... I'm not exactly sure how (I'm sure it's not hard, just haven't done it yet because the "block name" is enough for my uses).
But I don't think there are attributes on blocks (other than the "block name", which isn't technically an "attribute" in the C5-object-model sense -- it's just a special text field).
Update:
I just revisited this today, and with the new architecture changes 5.6, this can actually be accomplished entirely within a package. As of this evening, I've got BlockAttributes 100% working, saving, updating, etc.
I've got an interface set up with the custom templates dialog. Each customs template can optionally provide a list of attributes that it wants filled, which will show/hide based on the current template. I'm still working on the UI, might try a nicer integration with the edit dialog, but what I have now is workable.
My biggest use cases that I foresee:
1) augmenting existing blocks with extra attributes for display.
2) adding meta data to blocks, (filtering, tabs, ect)
3) meta blocks - blocks composed entirely of attributes.
If you can think of any other use cases, please let me know so I can try and design them IMO the architecture.
I plan to work on this a bit more, and will release an alpha version shortly, and would appreciate some help testing if anyone's interested.
I just revisited this today, and with the new architecture changes 5.6, this can actually be accomplished entirely within a package. As of this evening, I've got BlockAttributes 100% working, saving, updating, etc.
I've got an interface set up with the custom templates dialog. Each customs template can optionally provide a list of attributes that it wants filled, which will show/hide based on the current template. I'm still working on the UI, might try a nicer integration with the edit dialog, but what I have now is workable.
My biggest use cases that I foresee:
1) augmenting existing blocks with extra attributes for display.
2) adding meta data to blocks, (filtering, tabs, ect)
3) meta blocks - blocks composed entirely of attributes.
If you can think of any other use cases, please let me know so I can try and design them IMO the architecture.
I plan to work on this a bit more, and will release an alpha version shortly, and would appreciate some help testing if anyone's interested.
A use-case I can envision is a package providing a block template that requires parameters additional to the original block. I guess that is already covered by your existing use-cases.
On another thread I have been campaigning for the block cache decision (currently read from variables set in the block controller) to be open to the user interface, so block level caching can be selectively enabled/disabled. Maybe your block level attributes can play a role in this.
For your testing: what happens to block level attributes attached to a content block and display of them in a view template for the content block when the block cache is enabled?
On another thread I have been campaigning for the block cache decision (currently read from variables set in the block controller) to be open to the user interface, so block level caching can be selectively enabled/disabled. Maybe your block level attributes can play a role in this.
For your testing: what happens to block level attributes attached to a content block and display of them in a view template for the content block when the block cache is enabled?
Yes, that use case is already account for, and is currently working.
As for the cache, I hook into the update methods of the Block Model so that saving attributes to blocks triggers the same cache refresh that editing the content does.
As for the cache, I hook into the update methods of the Block Model so that saving attributes to blocks triggers the same cache refresh that editing the content does.
Maybe you could offer an opinion on this thread about Site Attributes and Package Attributes. I kicked it off to continue/develop from discussion on Totally Random.
http://www.concrete5.org/developers/pro-accounts/community-leaders-...
http://www.concrete5.org/developers/pro-accounts/community-leaders-...
I would love to see this feature integrated. Is your package in the marketplace?
I'd be interested in testing for you. It's something I've wanted for a long time.
This sounds like a great feature!
Sounds like you're close to having it ready for use.
Is your code available anywhere? I'd be very interested in both testing for you and contributing/helping you finish it up.
Sounds like you're close to having it ready for use.
Is your code available anywhere? I'd be very interested in both testing for you and contributing/helping you finish it up.
Personally, I think this would extremely powerful for block layout options (i.e. - background colors, icon/image options, anything CSS at all, etc.)
How did you fair with this? Is it a package you could release on the marketplace?
I'm really excited and would love to use it ASAP.
How did you fair with this? Is it a package you could release on the marketplace?
I'm really excited and would love to use it ASAP.
This isn't exactly the same thing, but the Designer Content Pro addon attempts to solve similar use cases as this "block attribute" idea does:
http://www.concrete5.org/marketplace/addons/designer-content-pro...
-Jordan
http://www.concrete5.org/marketplace/addons/designer-content-pro...
-Jordan
Looks & sounds very cool Jordan! When did this get released?
We'll give it a go in our next project for sure.
We'll give it a go in our next project for sure.
Released it last September. It's been working great for my company's projects, and we have a lot of happy customers. That being said, I haven't been promoting it too heavily yet because it lacks the ability to have both "repeating items" and "non-repeating items" in the same block (right now you still need to use the free Designer Content for "non-repeating" items, and the Pro version for "repeating items"). But I am definitely working on this feature, and once I get it in place we'll be spreading the word a lot more than we have been. (Will probably be a few months still though since it requires a significant amount of work). If you'd like to be on our announcement list, you can sign up for that here:http://theblockery.com
-Jordan
-Jordan
Cool! I just grabbed a copy and I'm loving it so far. Can't wait to see how it develops in the future.
Thanks again for your awesome work and help on everything C5!
Cheers
Thanks again for your awesome work and help on everything C5!
Cheers
Please help me I want to create a Block attribute and show it to all blocks(default and custom)
