After reading several blocks-related discussions recently and a gentle nudge from Daryl it seems that it would be a very good time to comment a bit on everything related to blocks:
Right now we 're in the process of finalizing the new Blocks2 and writing the library code for a new concept for Moodle developers: "pages". Pages will provide Moodle with the ability to recognize and provide specialized configuration for different sceens in Moodle. For example, each course (in addition to being a course) will also be a disctinct "page". Moodle will thus be able to provide multiple instances, per-instance configuration and other goodies for Blocks, which in the beginning will be the only part of Moodle taking advantage of Pages right now.
Pages were designed to provide far-reaching capabilities to Blocks. But as the development of Moodle 1.5 continues we will probably see other features taking advantage of Pages in conjunction with Blocks, like for example Blogs and even Activities. (yes, this will now become technically feasible without ripping Moodle apart!)
Since nothing of the above has been made completely final as yet, developers might wish to put writing blocks on hold for a little while to avoid the API changing under their feet in the meantime. When Blocks2 and Pages are done, we will also be providing official documentation to developers for the new APIs at their disposal. Including examples, even!
So if you guys could be patient for a week...
Freedom and organisation choice:
An organisation must have the choice to decide which choices they offer teachers and professors: we would prefer to make these choices on institute/schoollevel, so the real admins must be able to give coursecreators the power to create course templates to the users in their institute after discussions in that institute. (The rights of coursecreators should be upgraded)
So institutes can freezze the blocks taht should be available for all the studenst on institute level.
To keep the choices for teachers ans professors optimal, all blocks should be available as moduls and vice versa.
(The design rationale for me is that you choose for moduls when an activity is course releated ("we will use wikipedia and adopt a page to fill in this course") and the block version when it is shared by one course or more OR it is a tool that is handy on the studalent course-dashboard ("wikipedia as glob student tool"...)
Traditionally Moodle let you add one thing to your courses: activities. Now that was really really confining when it came to new development, because you just couldn't implement a calendar as an activity. Gustav had tried it; I had tried it; it was just the wrong idea. The whole blocks concept was introduced at the point where people were finding it difficult to agree on where and how to put the calendar in Moodle courses, to give everyone the ability to choose for themselves.
Suddenly you could also add something else to your courses, blocks. Now normally a block "should be" just an interface for something else (all traditional Moodle blocks are) but... it also gives you the ability to add something that isn't an activity to your courses!
That's exactly what has caused people to write blocks that do pretty much anything and led to an "out of control situation" as you note. Simply put, there are things that people want that just cannot be activities; so they make them into blocks. It's only natural that you can't fit all the blocks in one page, they were made for people with different needs and desires.
I have a secret project underway (look for a discussion on "Moodle components") that, if it ever sees the light of day, would allow people to seamlessly plug chunks of code in Moodle. That code won't have any user interface at all as the plan stands, but rather existing bits of interface will dynamically detect its presence and enrich themselves as required. Thus, it would allow you to do more with the existing blocks rather that add a new block for each new feature.
As for subsuming sections inside the blocks, that's interesting and I can tell you that it will be technically feasible with Blocks2 (it will allow you to put blocks pretty much anywhere in theory). Of course we 're talking about a major overhaul here so it's not that simple a matter, but personally I like the idea.
I just tried to setup 1.5 and it won't set up because in postgres it's trying to insert block information into prefix_block rather than prefix_blocks.
The code has changed, mysql.sql has changed, but not postgres.sql - I'm guessing that it's just this new block thing?
PS: I just noticed these messages in the forums. Anyone knowledgeable enough about postgres to advise?
Also, Penny, you were right. Fixed that one too...
I would have fixed it myself, but I wasn't sure if it was related to the changes or something in the works, or what.
Fatal error: Call to undefined function: instance_allow_config() in /var/www/html/moodtrans/lib/blocklib.php on line 210
I can't get out of this, I then have to close the browser window and re-open it.
I've had a look at blocklib.php but with my minimal php knowledge couldn't see where the problem was.
Does anyone else have this problem?
I think you somehow did a partial upgrade. instance_allow_config() is very definitely defined in the latest moodleblock.class.php and thus it is inherited by all the blocks without exception. Most probably if you grab the latest blocks/moodleblock.class.php your problem will go away, but in your position I 'd do a full upgrade just to be sure.
That is strange - I am using CVS with cvs update -dP, which should work (I am using this site to commit the Korean language pack).
I get this message from the CVS output:
RCS file: /cvsroot/moodle/moodle/blocks/moodleblock.class.php,v
retrieving revision 1.24
retrieving revision 1.25
Merging differences between 1.24 and 1.25 into moodleblock.class.php
blocks/moodleblock.class.php already contains the differences between 1.24 and 1.25
What does this mean, especially "RCS file"?
I have tried to update via CVS several times and the same error recurs. I have also replaced both my blocks/moodleblock.class.php and lib/blocklib.php files without any improvement.
Any more comments or advice Jon or anyone? Is this definitely a problem at my end only?
I recently posted an update to cvs for moodleblock.class.php. My update changed the version from 1.24 to 1.25. I have removed and checked out the file again with success. It looks like you may have a locally modified file?
Try this: completely remove moodleblock.class.php from the blocks folder. Then issue a "cvs update -dP ." command in the blocks folder. This should get you the latest version - 1.25.
By the way RCS is "revision control system" - a system for file diff management which CVS is built on.
Other ways to see what the status of your local file is:
cvs status moodleblock.class.php - the output will tell you if the local file is modified, in sync or if there is a newer version on the server
cvs diff moodleblock.class.php - if the local file does not match the remote file a diff listing will be shown
I think one of the problems was that I somehow deleted one of the block directories (the html block), and when the database couldn't find it it came up with a fatal error.
Also I checked out a completely new copy from CVS.
Also, there were a number of empty directories checked out from CVS such as mod/resource/type/reference, mod/resource/type/program, and lang/sr with I had to delete to get the menus working properly.
Thanks a lot to Jon and Daryl for offering a hand,