Can Not Re-order Blocks

You must order the "weight" column.

the smaller means the lighter (go to the top)
The biggest number will sink the block to the most bottom part.

Regards

I will investigate it.

I can't seem to replicate your problem.

I have made a block reference autocomplete text field, with 'unlimited' choices, and I selected several regions to pick blocks from.

The weight column doesn't show up - this is normal caused by content.module handling drag-n-drop ordering.

When you say "Block List" are you refering to the table of autocomplete fields?

When you say "Save Blocks" do you actually mean "Save" ? Because there is no "Save Blocks" button. There's a "Save Blocks" button on the blocks config page..-

wait.. what are we talking about here

Are you saying this started happening when you installed blockreference.module ? The screen shot you posted is not from blockreference.module and should not be affected :/

So the underlying finctionality is there, but the drag and drop is playing up.
I was going to suggest you see what happens with JS off :-)

So it may come down to your browser and a JS error or conflict. You've seen no JS errors? Little red cross in the bottom or top right of FF? They are nowadays suppressed by default and you need to turn the debug options on in your browser to see them.

There's (or was) a lightweight "show script errors" option somewhere on a plain install, but with the developer toolbar you are much better served so that's moot.
At this point I guess it's a code bug. Probably not against block_reference but the core blocks GUI.
Unless you've narrowed it down to ONLY these types of blocks? Other normal system blocks shuffle around as expected?

Heck I dunno. I've only got troubleshooting tips, no contact with either lump of code.

From what I can tell it is probably more like an issue with the drag'n'drop functionality in drupal, than either blocks or block_reference module.
Feel free to reopen if you know that I'm wrong.

I am having the same problem as JamesKB: as of today I am unable to *save* changes to my block ordering, though I have been using drag-and-drop successfully to order my blocks for a month now. I do not know how to go about accessing a weight option for this function, but then why would weighing the blocks be useful to me, when the problem is that I need to move specific blocks into specific regions? If anyone can figure out why this problem is occurring, I would be extremely grateful. It looks to be a serious impediment to the development of my site (future site of ach.org).

Thanks!
Jkatko

I have modified the module to use the standard Drupal select widget for multiple values and re-ordering. Is this worth making a patch for?

Do you mean a multi select lists for values and weights? Or a better way to do drag'n'drop? I'm sure the code would be helpful for someone even if you don't want to supply a patch.

Yes, the widget with 6.x-1.14 was just a standard HTML multi select, which only allowed me to select multiple values by holding down shift or cntrl.

My fix turned it into a the Drupal select widget with the multiple attribute, so that you just select one value, and then click "Add another" and another select box appears... at which point you can drag-and-drop to re-order them.

I supplied a patch at http://drupal.org/node/659584

I just looked at View Reference module's code for how it does the Drupal select widget, and I got it working for Block Reference. I was hoping you could look at my code to ensure that it works well. I never touched Autocomplete

Well I don't think the original issue here was actually related to this module, and I don't think #16 onwards is talking about the same thing. I will address jmonkfish's posts in the other thread he linked.

Hi,
I just spent a day trying to get the blocks region/position/weight save when I hit "save" button. They just won't save! For me, the problem came "out of nowhere" (used to work, and did not change anything on the website or with the server configuration). The problem maniphested both on my D5.18 and D6.15 installs on the same server.

Turns out, it had to do with some hosting settings.
First, turning off suhosin (php module which you kind of want on your server, because it protects you) helped.
Add to your php.ini file in public_html folder a couple of lines:

; Misc Options
suhosin.simulation = On

This effectively "turns off" suhosin. Use devel module or other means of displaying php_info() for your website. See if suhosin.simulation is, indeed, OFF. Did it fix the problem?
To me, it fixed it, but I did not want to turn Suhosin off because it would compromise security off my site. I then removed the "suhosin.simulation" line and instead added

suhosin.request.max_vars="2048"
suhosin.post.max_vars="2048"

This seems to have fixed it. Hope it helps someone else.
Other threads where i read about a similar issue (though not nessesarily all these people had the same cause for that issue).
http://drupal.org/node/157712
http://drupal.org/node/269376

Hi,

I found another solution. I turned of Javascript in my browser. After that you will see the weight order like it was before the "drag and drop" feature. I realized that i have around 50 blocks but the weight range was from -10 to 10, so the first 20 blocks got numbers between -10 to 10, all the others 10. So form block 20 on the blocks were ordered alphabetically.

Because it was only important for me to have one special block always at the bottom, i gave him the weight 10, all the other blocks before 9. Saved it and it works.

I think it would have been better to change the weight range, let´s say -50 to 50 or even more. Perhaps someone knows a way how to do this so the "drag and drop" feature would work properly.

I think the problem is with the data-type of the "weight" column in the "blocks" table. The type is "tinyint" which can store values between -128 and 127. So if you have huge number of blocks, the weight range available in the block admin page may go beyond this range (the weight range is not -10 to 10, it depends on the number of blocks). Changing the type in the table will actually solve the problem; but that may not be an ideal solution. I think this should be in the issue queue (if it's already not there) of "block" module or Drupal core.

Thank you for this very useful comment (#24). I was able to resolve the same issue by writing an update script in a custom module that set all the weights of my 'left' region to 0. Blocks were then able to be weighted just fine.

@a6hiji7 #24 - this solved my problem as well. Too many blocks were created via the admin interface, and the weights started getting outside of tinyint's range (-128 to 127). The correct solution is probably to adjust the automatic weight assignment logic (somewhere in tabledrag.js). But the quick and dirty solution is to change the type in mysql.

  mysql> ALTER TABLE blocks MODIFY weight SMALLINT NOT NULL DEFAULT 0;

I had an issue where the block containing the image was not displayed because I was using a relative url and the path tends to change depending on where the block is placed. Hence it was not displaying properly.

Ok. One solution to this (which seems obvious now) is to let Drupal dynamically generate the path using php. i.e. Insert this before your link:

<?php global $base_path;
print $base_path;?>

This works well if you have images embedded in your template file. So if you move sites, the base_path will just need to be changed once, preventing you from having to manually relink everything.

oops, just realised this is probably not the best place to post about this issue.

@kscheirer Thanks! This totally solved my problem.

THIS APPLIES TO DRUPAL 7:

We are having the same issue. Large numbers of blocks > 100 seems to trigger the JS bug. Any site that has large numbers of blocks, you will notice you cant drag them into place anymore.

In the meantime, use "show weights" link and manually order the blocks according to weight. I wish someone would come up with a bulk delete blocks feature. LARGE NUMBERS OF BLOCKS BREAK THE JS REORDERING.

If you don't construct Drupal CMS from the beginning, you are dealing with the DEVIL!!!

This is still not a Block Reference issue, but Drupal core. Block Reference has nothing to do with Drupal core's block admin overview.

I had the same problem, where I couldn't get blocks to stay in the order I would drag them to. The fix I found was to delete abut 50 blocks that weren't needed any longer. I had a huge number of blocks, almost 300, though most were disabled, but by deleting a lot of them, fixed the problem for our site.

In my case it was max_input_vars limit in php.ini. You should increase this value.

I removed unused blocks from the site and it fixed the issue for me too. I use Drupal 7.