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
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | homebox-drupal-alter.patch | 383 bytes | kyoder |
Comments
Comment #1
Sylense commentedI believe I am experiencing the same issue. I have a homebox layout included in one of my features and it also fails to revert on my multisite. Other features seem to function properly but when I look at diff it looks like there's a problem with the homebox layout being overwritten.
Edit: I also get the following code if I view the overwritten state
I've tried to revert using the UI as well as in Drush to no avail
Comment #2
Sylense commentedI fixed my error and I think it was a different problem than the OP is experiencing. Somehow the machine name for my Homebox was not all lower case and so it was not re-creating the homebox on the second site. I manually changed the machine name to all lowercase, updated the feature and now it successfully built out the homebox.
Comment #3
deastlack commentedI am currently using the 7.x-2.0-beta 6 version and have been exploring whether the newly released 7.x-2.0 DEV version will resolve this issue.
The beta 6 version seems to rely on the bid element, ignoring the machine name. This works well enough when there is only one developer and the bid numbers remain in sequence between the local environment and the DEV integration environment. If the developers code and database are resynchronized everyday this is ok As we have all probably experienced, this does not always ocur. Relying on "block" plus the string of the bid element in the serialized data of the homebox page layout seems curious at best. Would it be too difficult to use the machine name instead?
Has anyone noticed this issue in the newly released Dev version?
Comment #4
globaltask commentedHello Guys,
for any of you still with this problem. The issue is with the Homebox code for features.
The file with the error is: homebox.features.inc.
The problem is the implementation on homebox_features_revert($module = NULL)
The code is trying to homebox_delete_page($name); while actually the page has never been created and added to the database. (That's also the reason why you get the Notice message.
I fixed it by updating the code in the hook to actually create the Homebox page.
One thing to note is that I didn't have access to the Page's name, so I'm using the title.
Also, the module_invoke is returning an array while the homebox_save_page function needs an object.
Here is my implementation:
I hope it helps!
Comment #5
DanielWashbrook commentedI second this, fixed my homebox feature and allowed it to import. Thanks for the code!
Comment #7
drummNon-overridden homebox pages should not be stored in the database. Homeboxes can be defined either by code, like
your_feature_homebox()inyour_feature.features.incor in the database. Callinghomebox_delete_page()gets the DB version out of the way so code can take over.I did find my test homebox couldn't be overridden. Homebox pages from hook_homebox() are passed through
homebox_check_page_object(). In my case, it was considered invalid for a silly reason, there wasn't at least one block. I committed a fix to not require that. I suspect there are other silly checks inhomebox_check_page_object().Comment #8
kyoder commentedHere's a patch that adds a drupal_alter so it can be overridden.
Comment #9
kyoder commentedComment #10
anybodyPlease create a new Drupal 8+ (3.0.x) issue, referencing this one, if this is still relevant for Drupal 8+ (3.0.x).
As this issue was created for Drupal 7 which is close to EOL and won't receive any new features here anymore (unless someone implements them or sponsors development) I'm closing this issue for cleanup now.
If anyone works on this or has a solution, feel free to reopen! :)
Thank you.