Hi, sorry for the lengthy post but bear with me...

Boxes is a great module, and an ideal replacement for the somewhat flakey core blocks system that Drupal offers. The key advantage for me is that boxes can be assigned a machine name (system ID), meaning that they can be reliably deployed to test/live environments without breaking components that rely on that ID (contexts, for example)

However, the stumbling block i keep running into - and something i've seen quite a few other developers posting about - is that box config+content is exported to code when you build them into Features. In my experience, 90% of the time this produces undesirable effects as web admins will go in and edit the box content on a live environment, causing the containing feature to be overridden. Once again, this makes deployment difficult (and dangerous) and has regrettably caused me to stop using the Boxes module on my latest projects

You may ask why not omit the box component from features? I use the Context module to configure block (box) placement, due to the fact that they are powerful and exportable; the problem is that Context automatically discovers any boxes that exist in its configuration, and in turn exports them to code. Hence the problem: you cannot prevent boxes from being exported to features! I've tried removing the components in the features info file, and helper modules such as Features Plumber, but neither solve the problem.

I could be barking up the wrong tree, and this could in fact be an issue with Context itself, or perhaps even CTools (neither of which are my areas of expertise). Either way, could you offer any advice / support on solving this issue? What would be ideal would be the ability to control whether a box should be exportable on a case-by-case basis - not sure how feasible this would be though? For now, just the ability to disable altogether would be a solution for me.

Hope this makes sense, thanks in advance

Comments

jec006’s picture

jec006 commented
Category: feature » bug
Priority: Normal » Critical

I believe this could also be phrased:

Ensure that features only exports a box once.

The OP does a good job explaining how this becomes really annoying really fast.

This is a major issue in my opinion - marking it as bug, critical.

andreiashu’s picture

andreiashu commented

Same problem here

jyraya’s picture

jyraya commented

I am interested too.

I add also that the problem exist with Panels or Panelizer too.

stephaneq’s picture

stephaneq
Primary language French
Location Paris 🇫🇷
commented

I had the same issue on a project I worked for few weeks ago and I did the following workarround:

  1. I added a myfeature.install file to my feature module with a hook_install()
  2. I created the box manually in the hook_install and did not add it to my feature. To create a box you have to use the boxes_factory function and then save it.
    For example : 
    $box = boxes_factory('my_box_machine_name', array(
    'delta' => 'instance_machine_name',
    'title' => 'Instance title',
    'description' => 'Some description',
    'options' => array(
      'content_title' => 'Contact us',
      'body' => array(
        'value' => '',
        'format' => 'full_html',
      ),
      'link_text' => 'Email us',
      'link_url' => '',
      'i18n_boxes' => array(
        'language' => '__LOCALIZE__',
      ),
      'additional_classes' => '',
    ),
  ));
  $box->save();

    3. Then when the feature is installed for the first time, the box will be created and the panelizer will revert with it inside. So if you change the box settings, it will not be overriden by the feature. If the feature already exists, you can create the box also in a hook_update().

    Hope it helps.