Posted by univate on November 19, 2010 at 8:16am
9 followers
| Project: | Spaces |
| Version: | 6.x-3.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
I'm attempting to build a site/distribution that has features similar to openatrium, so naturally attempting to re-use alot of the great processes that have been engineered in openatrium.
But I don't seem to be able to get the dashboard to save changes.
In debugging I found the two variables $original and $context in the below section of code were the same when the editor form was submitted, by removing the if statements I was able to get the dashboard to start saving. Wondering if anyone more familiar with this code might have any idea whats going on. I guess it seems unnecessary to worry about checking for un-changed things when you could just save everything, as the editor is not used that often.
<?php
/**
* Save handler for context_block_editor().
*/
function spaces_context_ui_editor_submit(&$form, &$form_state) {
$space = spaces_get_space();
if ($space) {
$saved = FALSE;
foreach ($form_state['values']['contexts'] as $name => $values) {
$original = drupal_clone($values['context']);
$context = context_ui_editor_process($values);
foreach (array_keys(context_conditions(TRUE)) as $condition) {
if ($context->conditions[$condition] != $original->conditions[$condition]) {
$space->controllers->context->set("$context->name:condition:$condition", $context->conditions[$condition]);
$saved = TRUE;
}
}
foreach (array_keys(context_reactions(TRUE)) as $reaction) {
if ($context->reactions[$reaction] != $original->reactions[$reaction]) {
$space->controllers->context->set("$context->name:reaction:$reaction", $context->reactions[$reaction]);
$saved = TRUE;
}
}
}
if ($saved) {
drupal_set_message(t('Saved %title for %space.', array(
'%title' => (!empty($context->description) ? $context->description : $context->name),
'%space' => $space->title()
)));
}
}
}
?>
Comments
#1
"I don't seem to be able to get the dashboard to save changes."
You may need to change a context setting. A common error with constructing dashboards is that the regions you're trying to place content in are not available (or only those regions that already have content in them are available). To address this issue, you need to configure the Context module (temporarily, since you usually don't want to do this on a production site) to always output to all theme regions. You'll find this option on the context settings form.
If this is not the issue you're having, pls explain in detail what you're trying to do and what happens or doesn't happen.
#2
Same here. Dashboard is not saving changes. I have enabled all theme regions. Removing those two IFs allows to save dashboard.
UPDATE: after clean install, repeated setup and changes in Spaces Node module I managed to get everything working. @original poster Do you use Spaces Node module?
#3
No, I'm not using the spaces_node module - I haven't had much of a chance to really investigate this further.
#4
It seems this has something to do with the order/process that everything is setup. After putting stuff into features and using drush_make to build my distributions it seems to work.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.
#6
I'm experiencing the same issue!
I noticed that property $original->reactions is a reference and the clone method is preserving that.
In this way :
($context->reactions[$reaction] != $original->reactions[$reaction])
is always false and nothing is saved.
The only way I was able to save was to add this line :
$original = unserialize(serialize($original));
in function spaces_context_ui_editor_submit after
$original = drupal_clone($values['context']);
I'm attaching a diff!
I checked context and spaces configuration but I did not find the origin of this issue, any idea?
#7
Subscribe.
#8
This is a PHP 5.3 issue. The patch in #6 resolves the issue, re-rolled here (still using p0 since drush make doesn't work with p1 yet).
For reference, the context_ui module had the same issue, but resolved it slightly differently: #786542: PHP 5.3 clone fail in context_ui_editor submit function.
#9
I can confirm this fixes the problem.
#10
It may fix the problem, but it's kind of a hack, don't you think?
Also, all patches need to be made with git diff now.
#11
The alternative to the unserialize(serialize()) call would be to follow a similar fix that context implemented in #786542: PHP 5.3 clone fail in context_ui_editor submit function.
The patch was made with git diff, but out of habit, it was set to p0 instead of p1.
#12
Actually, the fix for context was identical (unserialize(serialize()). So it may be a hack, but I'm not sure how else one gets around the shallow cloning issue.
http://drupalcode.org/project/context.git/blobdiff/53b5c96ea2ca07f96039d...
#13
I just noticed something odd--since context now implements __clone, I would think when spaces calls drupal_clone on a context object, the unserialize/serialize would take place. The fix here may be to figure out why that method isn't called on clone--it may be that the context objects in $form_state are of stdClass instead of the proper context class.
#14
Here's a corresponding patch for 7.x.
#15
After further testing, the patch in #14 isn't needed in 7.x--that means that for 6.x something weird is going on with drupal_clone.
#16
There is a bug with
drupal_write_record(http://drupal.org/node/227677) that means any update that removes all spaces overrides will not be saved. This is becausedrupal_write_recordcannot update to a NULL value.As long as there is always at least 1 override still in place, changes are saved correctly (when patch #08 is applied)
This particular case therefore isn't caused by the spaces or spaces_dashboard module, but could easily be mistaken as such.