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