Moodle

The problem, at least as far as it occurs when moving blocks up and down, is caused by a bug in /lib/blocklib.php.

The code to move blocks up and down is in the function blocks_execute_action(). This uses the $pageblocks array, which in this case is created by the function blocks_get_by_page_pinned().

Now, when moving a block ($instance) up, blocks_execute_action() [line 553] tries to find the block above ($other), and move it down so that the 2 blocks swap positions. However, it does this by using ($instance->weight - 1) as an key in $pageblocks. This doesn't work, because blocks_get_by_page_pinned() has constructed $pageblocks by simply sticking the pinned and user blocks together in a single array, without accounting for that fact that the values of 'weight' for pinned and user blocks can be the same.

Therefore blocks_execute_action() fails to identify the correct block to move down and, depending on the number of pinned and user blocks on that side, we get all sorts of weird results.

The attached patch is only a temporary fix. It sidesteps the issue by searching backwards from the end of $pageblocks to make sure that the first match it finds is a user block, not a pinned block.

However the real solution must be to make sure that the array of blocks received by blocks_execute_action() properly distinguishes between pinned and user blocks - perhaps 2 arrays should be passed. I haven't dared to start messing with $pageblocks as it is used throughout this script. I think a proper fix needs to be done by someone with a wider understanding of blocklib.php than I have.

We're seeing this problem with 1.8.4 as well.

Updated to show that it affects 1.8.4

Just FYI, there's no point in using the test URL I supplied in the original report, as Steve Bond's code is running on that server. We've also been using it in production since mid October.

We have also had a client come across this issue. It can be reproduced in new installs of 1.9 and current 1.9+

On a new install:

• In Admin -> Blocks -> Sticky Blocks, Add any block to Course pages (Right Hand Side)
• Add a new course
  The default RHS blocks are:
  The sticky block added above, Latest News, Upcoming Events, Recent Activity
• Add a new block to this course
• Move the new block up one position.
  The Upcoming Events and Recent Activity blocks disappear.

Continuing to move the blocks around causes random behaviour. In some circumstances, it is possible to loose blocks completely.

Addressing this for next releases... Nicolas, can you take a look to this, plz. There are repeated reports... TIA!

Ciao

A workaround, that users can implement, that seems to help clear up the issue (for Moodle 1.9.1)

Just move the blocks from right to left or vice versa. I was watching the changes in the database as I did this and the code seems to clear up the weird entries that this bug puts in mdl_block_instances. (This bug creates a lot of dupes in this table, as well as multiple rows with the same blockid, position, and weight.) Move the blocks from one side to the other and the missing ones start to reappear. Then delete the dupes if there are any.

And another thing that might help prevent this from occuring could be put in place at the database level. A Unique key on ( blockid, pageid, position, weight) would certainly prevent dupes and prevent this problem. The blocklib code would have to gracefully react to attempts to move a block into a position occupied by a block that would violate the unique key, though.

sending another possible solution - it sets negative weights for pinned blocks if both displayed at the same time
I noticed there is still a problem when the sticky blocks are rearanged,

Blocks definitely need full cleanup or even rewrite in 2.0

assigning to original author of sticky blocks

can anyone confirm this was a regression introduced in 1.8? i definitely didn't see any reports for a few releases since i wrote it for 1.5 ... figuring out where it was introduced will help fix the problem.

also you're not supposed to be able to reorder sticky blocks in courses - they should ALWAYS be at the top. you should only be able to reorder them in admin, and that should be displayed in every course.

I can sort of confirm. We went from 1.6 to 1.8 on our production server and it was then that we noticed the problem.

We did run a test version of 1.7 for a while but not for long enough to allow this bug to reveal itself. So it could have been there in 1.7 as well.

I first experienced this issue last year when we were evaluating Moodle 1.7 and it has continued since the enterprise-wide implementation with Moodle 1.8 and with our recent upgrade to 1.8.5. I notice it both in the management of sticky blocks and at the course level with instructor-editing of blocks. We are monitoring this issue because we continue to have new complaints from our instructors. - Kathy Cannon, Academic Systems & Technology, Brandeis University.

Thanks Steve & Kathy for further information.

One last question - do you expect that you should be able to re-order sticky blocks within a course page or only in the administration section?

Since I'm watching this thing, I'll comment on your last question, Penny.

Personally, I think the expected behavior of sticky blocks would be that by default, they can only be rearranged by administrators. However, if I were a user (and mind you, I am definitely not ) I would also expect that my Moodle admin would be able to flip a switch and let me move the sticky blocks around if I begged and pleaded. I know Moodle dosn't have a allow-sticky-block-movement flag anywhere, but call that a feature suggestion, if you will.

But I do think the "expected behavior" would be "only movable by an admin".

That was the way they were designed... and the controls didn't appear in normal courses to be able to move blocks that are sticky. The reason for this is that there is only one copy of them, they're not duplicated for every course. If they are moved in the database they move everywhere they've been pinned.

No, I wouldn't expect to be able to move sticky blocks within a course page, regardless of role.

PS we haven't had any reported problems since I installed my kludge of October last year

anyone have a test server I can repro on or clear steps to reproduce

eg

1. create a course
2. make sure the following blocks are on the course page in the following postitions (left: blah blah blah, right: blah, blah blah)
3. set up sticky blocks for course page the following way (left: blah, blah, blah, right: blah, blah, blah)
4. move blocks around on course page (move a to b then x to y etc)

including whether 2 or 3 happens first or a 3 then 2 then 3 again or whatever. also what user is performing each action (roughly - like site admin or what role they have or whatever)

i'm playing with it on a test setup but haven't managed to reproduce it yet.

Hi Penny,

I was able to reproduce this on demo.moodle.org as follows:

1. Create a new, default course. There are 5 blocks on the left (top to bottom: People, Activities, Search forums, Administration, Courses), and 3 blocks on the right (Latest News, Upcoming events, Recent activity).
2. Go to Sticky blocks and add the Calendar block to the right column.
3. Go back into the course and turn editing on.
4. Move the Upcoming events block up. Result -> the Latest News block disappeared.
5. Move the Recent activity block up. Result -> the Latest News block reappeared and the Upcoming events block vanished.
6. Move the Search forum block from the left column to the right column, and then up. Result -> the Upcoming events block reappeared and the Search forum block disappeared.

Notes: using all default settings, just after the demo site was wiped clean on the hour, ajax disabled. Followed steps 3-6 using both the admin and teacher demo accounts with identical results.

We decided to make a couple of course blocks sticky on Moodle 1.9.5. Added the the blocks and shifted them to the left on the admin/stickyblocks.php page.

All our courses had most of their right-hand-blocks vanish.

System-wide, 2118 of our right-hand course-view blocks with weight >0 changed to weight 0 (leaving 71 with weight>0).

Sticky blocks are unusable. We've restored our DB and won't be using them until we're sure these weighting bugs are fixed.

There should be a way to remove the now-duplicate user blocks from all courses when adding sticky blocks.

It's also a big shame you can't pin the administration block at BOTTOM-left. We don't want people deleting it but we certainly don't want it floating above user course blocks.

Rosie can you please duplicate this and get familiar with the problem? You can show me if you like, then we can talk about how to fix it (in 1.9 only since 2.0 has all-new blocks)

Hi,

We appear to have the same issue here (having upgraded from 1.84 - > 1.95 a couple of weeks ago)
We added a new sticky block and lost all other blocks in the same column
I have compared with the old 1.8db table and it seems 5704 blocks have changed from a non-zero weight to a zero weighting

What is strange is that not all blocks have been affected - some courses have their original block weightings intact.
as per Bruce Webster's comment, this renders sticky-blocks unusable at present - which is going to cause quite a headache as term starts.

This issue might be related to the following problem:

"Blocks all have the same weight after upgrade"
http://moodle.org/mod/forum/discuss.php?d=132329

The attached patch (v2_blocklib.php.patch )might fix the sticky block issue.
Please apply the patch on lib/blocklib.php file.

Note: The patch has not fully tested yet.

I made couple changes on v2_blocklib.php.patch and reproduce the patch (v3_blocklib.php.patch).

I have tested the patch numerous times and it seems to work properly. Could anybody else test it and let me know if there's any additional bugs?

Thanks
Rosie

I patched v 1.129.2.7 of blocklib.php with v3_blocklib.php.patch, and can confirm blocks now behave as expected.

I have a sticky (pinned) block at the top of each column, and course blocks no longer disappear when being moved. However, I haven't looked at the database to observe weights being changed.

There are still some similar issues when course-editing AJAX is on. Can you look into that Rossiani?

I think MDL-19204 is a duplicate of this. Is that right?

Yes it is and I posted a link to this tracker.

Thanks Tim.

Please try the 20091002.block.patch for the blocks.

Rosie

Latest patch.

Please let me know if there's more error.

This is a collection of patches to fix the block order through ajax and manual (using the arrow button).

We implement the patch (20091007_block.patch) and is working fine in our moodle 1.9.5
But in order to correct all the disappeared blocks we had to clean up the duplicated weights in the mdl_block_instance table.

We are using a 1.9.5 moodle with a 8.4.0 postgres and 5.2.3 PHP installed in a SUSE Linux Enterprise Server.

Will this fix land in 1.9.7+ anytime soon? I have users that are getting pretty frustrated that block drag and drop isn't working correctly.

Using moodle 1.9.7. with AJAX enabled and disable AJAX course editing OFF...
The behaviour of moving blocks up and down in courses is quite erratic.
1. There is no problem moving blocks to the left or to the right
2- When moving blocks up and down,
a. it is not clear where exactly a block should be "dropped" relative to the other blocks
b. sometimes the block being moved will "stick" to the mouse and it will be impossible to drop it anywhere
c. most of the time, after a block has been moved (up or down) to its new place, upon quitting the Edit mode, the blocks are re-arranged in a totally unpredictable order, neither the original order nor the new order.
Joseph

Thanks for the summary of problems Joseph. This is getting very frustrating!

Rossiani, thanks! Can you please:
1) check this into 1.9.8 (only) today (and mark files as MERGED, since it won't go into HEAD at all), and
2) provide a list of testing instructions so people can confirm it works as expected?

Testers, can you please test this feature really well during this week to make sure it's absolutely problem-free before the weekly build next Wednesday?

The patch has been committed to 1.9.8

in order to fix the blocks' weight, you need to reset the weight value for the blocks.

To do this:
1. turn-on the editing mode.
2. delete stick blocks for the page.
3. re-add sticky blocks.
4. repeat steps 1 and 2 for the rest of the course.

Deleting the block, will clear the weight value recorded in the database and re-adding them to the page will ensure the blocks has the correct weight for the page.

after re-adding the blocks, you can freely move the block around.

Just tested the fix, it works fine for me ... at long last!
Thanks,
Joseph

Hi all,

Here's my experience:

Before I did the steps – on 1 of my courses:

I moved a block from right to left, then repositioned it, turned editing off, when I turned editing back on firefox crashed (repeatedly - every time I went back in to edit after that).

So then I went in without ajax turned on, deleted the blocks as per instructions above, re-added the blocks and things worked ok again.

Here are some issues:

1) When positioning a block to the 1st position - the block automatically drops to the bottom when editing is turned off.
2) Moving blocks up or down in position doesn't always give you the results you may think. For example I moved a block that was in position 2 and moved it to position 3, turned editing off and it went to the bottom. (I have 4 blocks on the left side).

Turned editing back on, moved the last block up to position 2 , turned editing off and it went back to the bottom.

Our instructors love the ajax for setting up their courses, but get frustrated when things don't stay where they're supposed to. I think that the ajax is still pretty buggy but is way better then it used to be.

I hope that helps!

Lori

Lori, are you absolutely certain you have updated your Moodle site to the latest fix? The symptoms you describe are exactly those I experienced before the recent fix was applied and I can report that any problem has now disappeared.

which fix?

We are running: Moodle 1.9.7 (Build: 20091126)

Should I be adding something else?

The patches were just checked into MOODLE19_STABLE today, so they won't be available in a downloadable package until next week.

Ryan, I update my moodle install by CVS and the fix IS available in CVS today, Jan. 20th (Paris time). I tested it and it's working.

Yes, I updated from CVS this morning and got the fix too. It won't be compiled into MOODLE19_WEEKLY until next week, for the general download on download.moodle.org

Hi all,

We have a bit of custom additions to our code (mainly mnet and weblib.php --nanogong) Is there an easy way for me to update so that I can get ours working too?

Lori

Thank you Joseph, Lori and Ryan for testing it.

@Lori:
you could try applying the latest patch to your distribution.

here is the list of files that get updated yesterday:
/lib/ajax/ajaxcourse.js
lib/ajax/block_classes.js
lib/blocklib.php
course/rest.php
theme/standard/styles_layout.css

Please let me know if you have more question

Rosie

Hi,

How would I get the most current files for 1.9.7 with cvs. I made a temp area and got the lastest weekly build using cvs, but what do I run to update to get the update files above?

Thanks for all the help everyone, I think I figured it out and it seems to be working wonderfully.

committed to 19_stable