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

adamdicarlo’s picture

Vigorously subscribing.

adamdicarlo’s picture

I 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]....

justafish’s picture

subscribe

mrfelton’s picture

subscribe. This would provide a great way to include default boxes in features, that could have their content safely overwritten by content editors.

rich.3po’s picture

Subscribing.

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...

febbraro’s picture

Status: Active » Closed (works as designed)

Seems 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.

adamdicarlo’s picture

Thanks 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):

/**
 * Implements hook_install().
 */
function discursive_front_blocks_install() {
  // Create placeholder boxes for the front page
  $box = boxes_factory('simple', array(
    'delta' => 'front_large',
    'title' => '',
    'description' => 'Large box for the front page',
    'options' => array(
      'body' => array(
        'value' => '<img src="/profiles/discursive/themes/steam/images/front_large.png" />',
        'format' => 'full_html',
      ),
    ),
  ));
  $box->save();

  $box = boxes_factory('simple', array(
    'delta' => 'front_small_1',
    'title' => '',
    'description' => 'Small box 1 for the front page',
    'options' => array(
      'body' => array(
        'value' => '<img src="/profiles/discursive/themes/steam/images/front_small_1.png" />',
        'format' => 'full_html',
      ),
    ),
  ));
  $box->save();

  $box = boxes_factory('simple', array(
    'delta' => 'front_small_2',
    'title' => '',
    'description' => 'Small box 2 for the front page',
    'options' => array(
      'body' => array(
        'value' => '<img src="/profiles/discursive/themes/steam/images/front_small_2.png" />',
        'format' => 'full_html',
      ),
    ),
  ));
  $box->save();

  $box = boxes_factory('simple', array(
    'delta' => 'front_small_3',
    'title' => '',
    'description' => 'Small box 3 for the front page',
    'options' => array(
      'body' => array(
        'value' => '<img src="/profiles/discursive/themes/steam/images/front_small_3.png" />',
        'format' => 'full_html',
      ),
    ),
  ));
  $box->save();

  $box = boxes_factory('simple', array(
    'delta' => 'front_small_4',
    'title' => '',
    'description' => 'Small box 4 for the front page',
    'options' => array(
      'body' => array(
        'value' => '<img src="/profiles/discursive/themes/steam/images/front_small_4.png" />',
        'format' => 'full_html',
      ),
    ),
  ));
  $box->save();
}
rich.3po’s picture

Thanks 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

BarisW’s picture

Status: Closed (works as designed) » Active

Re-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...

rich.3po’s picture

This 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

BarisW’s picture

That'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.

sirkitree’s picture

If 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.

sethmac’s picture

Wanted 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?

mqanneh’s picture

Issue summary: View changes

Subscribing