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.
Right now, if I store a box in a feature, it stores everything including the content inside the box. I'd like the ability to store everything about the box *except* the content inside. This way, the box acts as a sort of placeholder, and when the content team edits the text inside it, I don't have to keep recreating my overridden feature.
Comments
Comment #1
adamdicarlo CreditAttribution: adamdicarlo commentedVigorously subscribing.
Comment #2
adamdicarlo CreditAttribution: adamdicarlo commentedI don't have time to try to write a patch/custom module now, but it looks to me, after quick digging, like we'd need to use hook_schema_alter() (or modify boxes's hook_schema) to set/use the 'export callback' for ctools, and basically exclude the body from the export if [whatever condition]....
Comment #3
justafishsubscribe
Comment #4
mrfelton CreditAttribution: mrfelton commentedsubscribe. This would provide a great way to include default boxes in features, that could have their content safely overwritten by content editors.
Comment #5
rich.3po CreditAttribution: rich.3po commentedSubscribing.
This has been a problem for me for a long time. Anyone got a work around for D6? I've tried features plumber amoungst other modules, all of which just seem to result in the box getting deleted when i try and remove it from the feature...
Comment #6
febbraro CreditAttribution: febbraro commentedSeems like this could be more easily written as a custom box plugin in an external module. No need to change the architecture of Boxes for this use case.
Comment #7
adamdicarlo CreditAttribution: adamdicarlo commentedThanks for the hint, febbraro. I might try to write a plugin for that sometime (not sure when).
Everyone - what I've been doing is manually creating the boxes in my features' hook_install() functions. Example (from Discursive):
Comment #8
rich.3po CreditAttribution: rich.3po commentedThanks for everyone's input.
adamdicarlo - what you seem to be saying is that you don't in fact use Features to store your boxes, however doesn't this undermine the entire purpose of the Boxes module? ie the ability to export block settings to Features and hence make deployment a whole lot easier? If you use install hooks, might you not just as well use core blocks instead?
Another point to make is that I always use Context to place blocks, which uses the auto-discovery system to include required components - in this case, boxes. So, whenever I update a Feature that contains a Context that in turn contains placed boxes, the boxes are auto-discovered and exported to the Feature. Deleting the box component from the .info file does not seem to help (Context just adds it back again)
I'm still stumped as to the best way to solve this; at present i'm experimenting with features_extra:
http://drupal.org/project/features_extra
It attempts to differentiate between blocks settings and block content, which may solve the problem
Cheers,
R
Comment #9
BarisW CreditAttribution: BarisW commentedRe-opening this thread to start a discussion.
@febbraro: could you please elaborate a bit more why this is default behavior of Boxes? 'Because it works this way' might not be the best reason ;)
We currently use boxes as it's the easiest way to strore blocks in features. Plus we can allow maintainers to edit the content of some boxes without having to give them Block edit permissions. For this use case, Boxes are great. But the big problem now is that all the time our features on Production are overridden. Which is quite bugging when deploying new stuff.
It's really not so hard to change the way the features are created (ctools export) to custom code. See my blog post about this subject: http://www.bariswanschers.com/blog/exporting-your-module-configuration-u...
Comment #10
rich.3po CreditAttribution: rich.3po commentedThis could be a potential solution:
http://drupal.org/project/ftools
It allows you to 'unlink' features components after you have initially deployed them. I've not given it a test-drive yet, but looks promising
Comment #11
BarisW CreditAttribution: BarisW commentedThat's a nice module but it doesn't work with boxes. I mean, you can get the complete box settings out of a feature, but we only want the title/content.
As boxes/blocks are part of the system, we need to fixate their position and css-class. We're not interested in the coontent - that's up to the content editors.
Comment #12
sirkitree CreditAttribution: sirkitree commentedIf you watch the video they have provided, it explains that you can still commit the boxes to code, just unlinked from the feature. When you push that code to the remote server, you can then execute that unlinked file which has the effect of adding the boxes to the system, still unlinked. So it seems that your machine names of the boxes would remain unchanged (I assume) and your css would still apply. And when your client, or users edited those boxes, the feature would not show up as overridden.
[edit]: Though this solution does seem like a sledgehammer.
Comment #13
sethmac CreditAttribution: sethmac commentedWanted to reopen this issue now that boxes is in a stable release. Is there a recommended practice for separating box content when exporting with features?
Comment #14
mqannehSubscribing