I am using Homebox 7.x.2.beta6 and have created homebox pages for each role in my site, along with a page
Since I am not sure if this is a problem with homebox or features for each users profile. so far so good.

Each page has blocks assigned - some are view displays, some are php/html blocks. no problems with either type of block locally.

In order to integrate these homebox pages with work done by others on my team I have created a feature using the features module. Features captures the homebox pages, blocks, and settings for the blocks (including all homebox region and title setting), along with all the other settings and permissions one might expect. However when importing the feature to the Dev environment from my local workstation to integrate the work product and reverting the feature in the new environment, all settings for the php/html blocks fail to revert. the settings for views block displays revert as expected.

The upshot is that each time I move the feature from Local to Dev to Staging I must re work the layout for each homebox page and flush the settings. I need to resolve this issue before releasing the feature to production. I'm sure that the users will not be happy to have their settings flushed when new blocks are added in future releases.

Further review indicates that there is a problem in the processing of custom blocks and the processing of serialized data using the bid field in the blocks_custom table without joining to the FE_boxes table and using the machine name field.

Local env = Quickstart Ubuntu
Dev Env = Windows 7 enterprise with uniserver
Staging Env = Windows 7 enterprise with uniserver
Drupal 7.16 in all environments

Comments

hjackson’s picture

We're having this exact problem at the moment. We're working on deploying all changes forwards by making everything a feature and this is currently blocking us. Basically as we work in our development environments the following auto_increment (block_custom.bid) key is getting out of sync between our systems so when we do reverts and updates we end up with blocks renamed [block_name.bid] and since bid is an auto increment this is doomed to eventually fail badly.

block_custom | CREATE TABLE `block_custom` (
`bid` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'The block’s block.bid.',
`body` longtext COMMENT 'Block contents.',
`info` varchar(128) NOT NULL DEFAULT '' COMMENT 'Block description.',
`format` varchar(255) DEFAULT NULL COMMENT 'The filter_format.format of the block body.',
PRIMARY KEY (`bid`),
UNIQUE KEY `info` (`info`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='Stores contents of custom-made blocks.'

We're also using Features version 7.x-1.0 with ubuntu. Does anyone know if this is fixed in the 7.x-2.0-rc3, if this gets fixed it might be the only thing preventing us from deploying everything forwards in code and that's a killer feature? The only way I can see this working is by using a unique machine name and having the system barf when someone has reused the machine name on their box without co-ordinating with the rest of the team, there may be a neater way but I'm relatively new to Drupal.

hefox’s picture

Status: Active » Postponed (maintainer needs more info)

Whatever module you're using that is providing export or features integration for blocks, that's the module to move this issue to

Unless something slipped in I didn't notice, features core doesn't provide block integration.

serundeputy’s picture

Component: Block » Code
Status: Postponed (maintainer needs more info) » Needs review

I have a feature that is implementing commerce tax rules. The rule contains an 'Execute PHP Code' condition.

If I make a tax rule without the PHP code push the feature to our staging server it reverts fine and works as expected.

When I include the custom PHP and move the feature to staging it will not revert.

Any thoughts would be appreciated. If I can provide anymore info or testing I would be glad to.

thanks,
Geoff

hefox’s picture

Status: Needs review » Postponed (maintainer needs more info)

Doesn't sound related to this issue.

Please read about what statuses mean -- needs review means there's a patch. Check rules issue queue

mpotter’s picture

Priority: Major » Normal