I'm writing Rules support for Deploy module, but is running into something weird. I'm implementing a new action that will add an entity to a deployment plan.
An error occurs whenever I'm trying to set my second parameter to 'type' => 'entity'. It all boils down to when Rules is trying to add metadata for the 'site' entity type, that for some reason doesn't exist. This is strange.
It feels like I'm doing something wrong with my implementation, because this is working in all other actions that Rules provides :)
The quick and dirty solution would be to check if we have site metadata, before trying to add it.
I don't have SSH/Git access from where I'm sitting right now, but I'll roll this patch soon.
public static function addSiteMetadata(EntityMetadataWrapper $wrapper, $property_info) {
$site_info = entity_get_property_info('site');
$property_info['properties'] += $site_info['properties']; // <--- This key in $site_info doesn't exist.
[...]
}
/**
* Implements hook_rules_action_info().
*/
function deploy_rules_action_info() {
return array(
'deploy_rules_action_add_to_managed_plan' => array(
'label' => t('Add entity to managed deployment plan'),
'group' => t('Deploy'),
'parameter' => array(
'plan_name' => array(
'type' => 'text',
'label' => t('Plan name'),
'description' => t('The plan to add the entity to.'),
'options list' => 'deploy_rules_manager_plan_get_options'
),
'entity' => array(
'type' => 'entity', // <----- Things break when this is set to 'entity'.
'label' => t('Entity'),
'description' => t('The entity that shall be added to the plan.'),
'wrapped' => TRUE,
),
),
),
);
}
( ! ) Fatal error: Unsupported operand types in [..]/sites/all/modules/rules/includes/rules.state.inc on line 612
Call Stack
#TimeMemoryFunctionLocation
10.0003140592{main}( )../index.php:0
20.03934372104menu_execute_active_handler( )../index.php:21
30.03964372184call_user_func_array
( )../menu.inc:503
40.03974372184ajax_form_callback( )../menu.inc:0
50.05025534368drupal_process_form( )../ajax.inc:374
60.06596521864drupal_rebuild_form( )../form.inc:914
70.06606521864drupal_retrieve_form( )../form.inc:442
80.06606522992call_user_func_array
( )../form.inc:785
90.06606522992rules_ui_add_element( )../form.inc:0
100.06646523232RulesPlugin->form( )../ui.forms.inc:285
110.06656523712RulesExtendable->__call( )../rules.core.inc:1089
120.06656523712FacesExtendable->__call( )../rules.core.inc:293
130.06666524312call_user_func_array
( )../faces.inc:130
140.06666524912RulesAbstractPluginUI->form( )../faces.inc:0
150.06666524912RulesPluginUI->form( )../ui.core.inc:835
160.09527132536RulesPluginUI->getParameterForm( )../ui.core.inc:233
170.09537132536call_user_func
( )../ui.core.inc:309
180.09537132536RulesDataUI::selectionForm( )../ui.core.inc:0
...
Comments
Comment #1
davidwhthomas commentedSame error here, with latest -dev version
Did you find a fix?
DT
Comment #2
davidwhthomas commentedThis error caused the whole site to WSOD, the attached patch brought things back again.
Comment #4
thekevinday commentedI just upgrade token module to 7.x-1.0-rc1 and uuid module to 7.x-1.0-alpha3.
After doing so, I got wsod as mentioned here.
The above patch to the rules module fixes the wsod.
Comment #5
mrfelton commentedI'm getting this error too. The patch does clear the WSOD for me too.
Comment #6
davidwhthomas commentedGood to hear the patch helps.
It would be interesting to figure out why the
siteentity property info isn't available at that point.But the check to ensure it does fixes the WSOD and the
sitevars are still available in rules admin.Comment #7
thekevinday commentedIn my case this was isolated to the uuid module.
The problem has also gotten worse with the upgrade to D7.12, see: #1427662: Drupal 7.10 to 7.12 causes Recoverable fatal error: in EntityMetadataWrapperIterator::__construct().
Comment #8
mrfelton commentedInterestingly, the UUID module was the cause of this and several other issues for me. With UUID installed, I could neither install Profile2 or the Registration modules, and 90% of the commerce Rules would fail the integrity check. I tried with UUID latest dv, and the last 2 beta's. I ended up having to completely disable it for now. I am also running Drupal 7.12, and before I upgraded to that I could use these modules together without issue.
Comment #9
mcarbone commented#2: 1423234-rules-site-property-metadata-fix.patch queued for re-testing.
Comment #10
mcarbone commentedPatch works for me but it doesn't follow Drupal coding standards. (Put the 'else' on a new line.)
Comment #11
randallknutson commentedThe patch almost worked for me. I cleaned up the coding style and returned the default property_info if false. This fixed it for me.
Comment #13
sarjeet.singh commentedThis patch worked for me.
Comment #15
sarjeet.singh commentedRe-submit #13 patch
Comment #16
brandy.brown commented15 works for me. Although, I now don't have any replacement patterns available ... is this related?
Comment #17
zhangtaihao commentedIf anyone reporting these problems is running UUID 7.x-1.0-alpha3, the final commit before 7.x-1.0-alpha3 was released broke entity property info. It was immediately reverted. Try updating to 7.x-1.x-dev and see if that fixes the issue without these patches.
Comment #18
brandy.brown commented@zhangtaihao I am running UUID 7 1 dev and I still had to apply this patch.
Comment #19
fagoThis site-metadata should not be empty. That's just the symptom, not the problem.
This are all problems that stem from in-complete caches. Thus, with UUID installed caches get built incomplete somehow. That might happen if caches are built during other caches are built, thus not-yet complete. So cache A might be built with in-complete information of cache B.
Thus, not sure what's the concrete cause here. Is UUID still invoking hook_entity_info() from hook_schema(). If so, I'd assume that's the cause of those problems.
Comment #20
dixon_This was fixed a while ago in UUID. It was indeed because of incomplete schema caches, caused by stupid code written by myself ;)
Was fixed on January 31st and included in UUID as of 7.x-1.0-alpha3: http://drupal.org/node/1268602#comment-5537538
Comment #21
duaelfrHi dixon_ !
Are you sure of that ?
I have UUID-7.x-1.0-alpha3 and Rules-7.x-2.1 installed.
When UUID is enabled I get this error while trying to add components to existing rules/components.
If I disabled UUID (without uninstalling), errors are gone.
For information I work on a project started a month ago so this error is not related to an upgrade of the module.
Comment #22
somimi commentedI'm having the same issue as brandy.brown - no more replacement patterns. Rules is still broken for me after patching - less broken, but still unusable.
Comment #23
somimi commentedHmm, so without Rules being functional for me right now, are there any other alternatives for, say, sending emails to a site administrator when content is created on the site? I tested Notifications briefly, but it only seems to trigger actions for published nodes, and I need the ability to trigger emails when unpublished nodes are saved.
Comment #24
cilestin commentedFor those who actually need UUID to continue working, the following patch fixed UUID's hook_entity_property_info_alter() and made rules data selector work again for me:
http://drupal.org/node/1782422
Comment #25
kristen polI am still seeing this problem. Things I have tried:*
disabling/enabling uuid*
updating uuid to latest dev*
updating rules to latest dev*
applying patch in #15I get this error:Any ideas?Doh! Helps if you update the correct docroot :/
I have confirmed that updating the uuid to latest dev fixes the problem.
Comment #26
kristen polsee previous comment... sorry for the noise
Comment #27
jomarocas commented15: rules-site-property-metadata-fix-1423234-15.patch queued for re-testing.
Comment #28
mel-miller commentedDespite being closed, I have a question for others having this problem... Does/should your PHP version matter when using certain versions of Rules?
My prod environment is running PHP 5.2.17 and Rules 7.x-2.6, and I've tried all of the fixes here with no luck.
However, based on a hunch, I moved the site to a server running 5.3.17 and all is good -- even without the patch. But then I have this older site running Rules 7.x-2.3 just fine on that same production server.
So to sum up:
Rules 7.x-2.3 + PHP 5.2.17 = OK
Rules 7.x-2.6 + PHP 5.2.17 = NOT OK AT ALL (white screen, etc...)
Should this be expected?
Comment #29
capellic@miller2676's post on 3 January 2014 tipped me off to the problem I was having with PHP, I was running 7.0.15. I reverted back to 5.6.30 and all was fine.
Comment #30
tr commentedThis issue was closed in #26. It should not have been reopened in #27, which apparently was done to test the patch in #15. That patch will not be committed, as the problem was not in Rules so Rules does not need to be changed. #28 and #29 are not relevant to this issue, so not sure why those comments were posted here.
Closing this again. If you have a similar problem, please open a new issue with details about how to reproduce the problem with the current version of Rules.
Comment #31
rahulk commented#15 also worked for me. Thank you