Error when saving context - unable to define weight

I'm able to save block weights just fine, but I'm on a relatively clean install. Any other details you could provide about your setup, i.e. what block you're trying to add as a reaction, any other modules that might be interfering with blocks/context?

I am also encountering the same problem, but without the error. We upgraded these modules and Drupal core just yesterday, which before that time the context weights were exporting ok.

Apache Solr 7.x-1.0-beta16 (2012-Feb-01)
Boxes 7.x-1.0-beta7 (2012-Jan-26)
Calendar 7.x-3.0-rc1 (2012-Feb-14)
Date 7.x-2.1 (2012-Feb-14)
Facet API 7.x-1.0-rc2 (2012-Jan-29)
Field Permissions 7.x-1.0-beta2 (2012-Jan-25)
Location 7.x-3.x-dev (2012-Feb-04)
Token 7.x-1.0-rc1 (2012-Jan-31)
Views 7.x-3.x-dev (2012-Feb-16)
Drupal Core 7.12

Looking in the exported feature for one of our content types, here is a section related to a block going into the sidebar:
'views-basic_node_content-block_5' => array(
'module' => 'views',
'delta' => 'basic_node_content-block_5',
'region' => 'sidebar_second',
'weight' => NULL,
),

The weight shows as NULL. On the contexts that I didn't edit, but still exported, the weights showed correctly in the exported feature.

Manually inputting the weights into the exported feature, then reverting to the feature correctly weights the items. Resaving the context after that (but not changing the manual number weights at all, just clicking save) the values are replaced with NULL again.

I've done a bit more testing on the issue.

1. First, I created a brand new context that wasn't part of an exported feature. Then I went back into that context and edited the weights, resaved, and checked it worked ok. That seems to be good so far.

2. Then, I exported the context into a feature and checked the generated code. The weights were exported ok and the display was still correct.

3. Next test I enabled the created feature with the context. The display was still good.

4. In the features administration, I insured that the database was no longer overriding the feature for the context. Again, the display was good here too. Going into the context to edit the weights they showed correctly.

5. Final test I went into the context as it was part of the feature, and edited the weights, then saved the context. That is when the display was broken. Going into the context confirmed that the values were all set to NULL.

The problem might be related to how the context weight values are pushed into the system to have the database override the feature code.

Confirming this bug - all weights are exported with NULL.

Manually changing the weight in code and reverting the context fixes the weights on the page but changing order in the context UI and re-exporting produces NULL as weight again.

I stated by posting this problem to drupal core http://drupal.org/node/1452152
I have figured out what was the problem.

The problem was the new code introduced in form.inc in drupal 7.12 that switches between select or textfield for the weights. The problem seems to be when you save some context it does not retrieve the numbers from the input field(textfield) thus serializing the array with all weights as NULL.

I found out that you could set the variable 'drupal_weight_select_max' to some higher number then 100 sinze the contstant is 100. It solves the problem.

So if someone encounters this problem you can set the variable in database either by using variable_set or with insert in mysql to some hight number. I set my variable to 1000. And context was able to save normally with nomal weights.

The workaround in #6 worked for me! The values were saved and exported fine. Going back into the context UI showed the correct values after the save.

As the post suggested I placed this line in one of my custom modules to insert the value into the database:
variable_set('drupal_weight_select_max', 1000);

I confirm bug and workaround fixes it.

I'm also posting to confirm the bug and that the workaround in #6 work for me.

Thanks, worked for me to. I was pulling my hair out trying to get the blocks to stay in the order I wanted :)

Thank god you found that! That's a BIG bug IMO.

I set the variable with drush:

drush vset drupal_weight_select_max 1000

Moving to a bug report.

For reference, the change in Drupal core (described above) that may have led to this is #1346760: Add a scalable weight select element.

I'm not sure that I'm setting the variable value in the right place in the database or setting it correctly.

I've gone into the variable table but all values are saved as longblob?

Don't presently have ssh/drush access to change it that way either, any help would be greatly appreciated pretty urgent...

Sorry for needing the spoon feeding :(

In addition, the change I made to the database results in the following error
Notice: unserialize() [function.unserialize]: Error at offset 0 of 4 bytes in variable_initialize() (line 943 of /usr/local/www/vhosts/mydomain.com/httpdocs/includes/bootstrap.inc).

@jlabernethy Variables are saved serialized in the variable table. Must be, because sometimes they're (huge) arrays and sometimes they're tiny strings.

2 ways to update that variable if you don't have drush:

• Call variable_set in a module or theme. I'm sure you have access to some PHP anywhere. Anywhere is fine: variable_set('drupal_weight_select_max', 1000);
• Update the database yourself, passing in a serialized int: UPDATE variable SET value = 'i:1000;' WHERE name = 'drupal_weight_select_max';

If you can, please use the first one. You might need to flush the cache after.

@rudiedirkx love your work!!! Thanks

no changes are applied, still get the error and weights are still NULL

@rudiedirkx none of your solutions worked. Is there anyway the a new dev can be released with the changes? Still getting the error message...

@BeaPower Don't forget to flush all cache. Variables are cached. The variable should be the solution though... If that doesn't do it, I don't know what will. (I didn't even come up with this one.)

Confirming #6 solves the weight issue

help it didn't work for me. Can someone step by step guide me how to do this in phpmyadmin? Can't find drupal_weight_select_max in the variables table.

@BeaPower, you can open your settings.php file, there is a section for hard-setting variables there, just read the instructions and set the drupal_weight_select_max var to 1000.

@franz, I added - $conf['drupal_weight_select_max '] = '1000'; but still no changes.

anyone?

The following patch changes the javascript used to extract the weight from the form such that it should work on both textfield and select elements.

This patch fixed the issue for me aswell

Thanks, finally it worked using the patch.

I'm still getting that message, however it now only appears when i'm adding a block, not when re-arranging

Notice: Undefined property: stdClass::$weight in context_reaction_block->options_form_submit() (line 104 of docroot/sites/all/modules/contrib/context/plugins/context_reaction_block.inc).

Here's a patch which works when rearranging existing blocks and when adding new blocks.

My solution assumes that the weight will always come from either a text input or select, and that it will be the only select / input in the table row.

The patch was created for 7.x-3.0-beta3 but I think it will work for beta2 as well.

Adding tag for tracking

#29 Works fine. Should get commited into 7.xdev as it was not yet included in last dev version.

We are using this in production and it works. It doesn't apply cleanly against current HEAD (or the 7.x-3.0-beta4 tag), otherwise I would RTBC it. Here it is rerolled.

Rerolled for 7.x-3.0-beta4

Patch from #29 committed with commit 9539d091d836a56b6f1509e8a2ede435d083ef92. Thanks for the bug report and the patch.

Thank You, the problem is solved: #25

This problem came to happen after installing Nodeblocks module. But they don't appear to be related. (I actually installed Nodeblocks on my test site and Context was fine.) I did fix this by setting the variable in #6. What could have caused this? Are there too many contexts set? Is setting the variable sufficient or will there be a later time I will have to set it to a higher number?

@digibrill - the problem arises once there are a large number of blocks available in the system. If all you did was set the variable in #6 you will need to set it again once the number of blocks exceeds that value. If you apply the patch from #25 or use a version of context with it applied already (3.x-dev currently) you should not need to adjust the variable any longer.

Thank you tekante, just another question - if Drupal or Apache is restarted, will I have to set the variable again? (And where?) Thanks!

No, the variable setting should be persistent across restarts of Apache or MySQL. There's no such concept as restarting Drupal as far as I know.

Thanks tekante, what about the current recommended version 7.x-3.0-beta5 ?

This fix is included in that version. This is noted by the presence of this ticket in the release notes here: http://drupal.org/node/1860390

Oh sorry, I will look next time. Thank you!

I can confirm that drush vset drupal_weight_select_max 1000 worked for 7.x-3.0-beta4

Had the same issue with Drupal 7.25, Features 2.0 and Context 3.1

We solved the problem by giving the block that was getting the weight NULL a weight in the module or feature that creates the block itself*. (Did this by edited that feature/module manually)

Then went on to manually edit the weight in the context feature, and made sure that it was a number.

 'my_problematic_block' => array(
   'module' => 'my module',
   'delta' => 'block_name',
   'region' => 'content',
   'weight' => NULL,
 ),

Replace NULL with '0' or what ever value you need.

To confirm that it works you can force reverted all features and emptied the cache, then do a new context feature export. The value now should stay a numer as expected.

//

Further testing points to that Context is unable to get the weight value for some blocks, and if that happens Context will save the weight as NULL.

If Context was unable to get the weight and then was saved it seems to be unable to realise that the weight for the block has been changed by the module/feature that originally created it. To fix this you can export the feature containing the Context and change the weight manually in the feature.

This only works as long as you at the same time give the module or feature that creates the problematic block a weight. If you don't, at the moment you go and save the context it will revert to NULL.

* In some instances this is not an optimal solution, as a weight set in a module might conflict with other weights - but if it is your internal system it is one solution.