## General developer forum

### Proposed format plugin changes

This discussion has been locked because a year has elapsed since the last post. Please start a new discussion topic.
Proposed format plugin changes
The following is a proposal for modifying core code to allow formats to have greater flexibility in their page layout and design. The key change is allowing formats to declare their pagelib.php to extend the page_course class definition. This would allow formats to control their block columns along with page presentation like header, content body and footer.

All of the proposed changes are meant to be done in a general fashion to allow backwards compatibility and for extension by formats and activities.

Please note that this proposal is not designed to solve all format issues, but rather a single step of many in the right direction.

Let me know what you think about the changes and the possibility of including them into the core Moodle code.

Cheers,
Mark

PS: I tried to attach a PDF version of the proposal, but it is 176KB and the max upload size is 100KB.

## Start of the proposal:

Currently, all course formats are limited to a single set of left and right column blocks. The goal of the below changes is to allow formats to define their own columns and to create multiple set of blocks. To do this, the core code needs to be as flexible as the current block API and the backup code needs to allow the backup and restore of multiple sets of blocks.

## Code Changes

All of the following proposed code changes are not specific to the Page Format, but instead are generalizations of the code so it can be more easily extended by the course formats.

### Remove any hard coded references to block positions

In library code, remove directly referenced left and right block positions. This prevents formats from creating new columns for blocks. At first look, this appears to be resolved in the Moodle 1.9 code base.

### Allow formats to declare their own pagelib.php

This will allow formats to extend the base course page definition and give them more control over layout and presentation. To make this possible, the following areas would need to be modified: /course/view.php, backup routine and areas that directly reference the course-view page type. This change only seems natural since modules can already define their own pagelib.php to extend the base activity page definition.

### Allow formats to backup their blocks

The current routine for backing up blocks is to backup all blocks that relate directly to the course. However, if we have multiple sets of blocks, meaning the pageid field is not set to the course ID, then those blocks are not backed up. During the backup routine, a page object method could be called that returns all blocks that should be backed up. The following would be added to the page_base class definition in lib/pagelib.php:

/**
* Gets all of the blocks that should be backed up
* during the backup routine.
*
* @param object $preferences Backup preferences * @return array **/ function blocks_get_backup_set($preferences) {
return blocks_get_by_page($this); } The above method would ensure backwards compatibility with current course-view page types and activity page types. Since the pageid is not necessarily the course ID, then the pageid needs to be remapped during restore. Currently, the pageid is remapped somewhat manually during restore. Instead, let's define a method in the page class definition to remap the pageid field. The following method would be added to the page_course class definition in lib/pagelib.php: /** * Remap the block_instance table's pageid field. Return * false on failure. * * @param int$pageid The current value for pageid that needs to be remapped
* @param object $restore Restore object * @return mixed **/ function restore_pageid($pageid, $restore) { return$restore->course_id;
}

And then for activities, the following would be added to page_generic_activity class definition in lib/pagelib.php:

/**
* Remap the block_instance table's pageid field. Return
* false on failure.
*
* @param int $pageid The current value for pageid that needs to be remapped * @param object$restore Restore object
* @return mixed
**/
function restore_pageid($pageid,$restore) {
if ($restore->mods[$this->activityname]->restore) {
$getid = backup_getid($restore->backup_unique_code, $this->activityname,$pageid);

if (!empty($getid->new_id)) { return$getid->new_id;
}
}
return false;
}

The above methods would ensure the backwards compatibility with current activity and course page definitions.

The last change to the restore routine is that blocks should be restored after any other plugin that could potentially add them. In backup/restorelib.php, the block restore code needs to be moved down after the format restore code in the method restore_execute().

## End result

In the end, formats will be able to define multiple pages that relate to a single course and each page could have its own set of blocks. Also, formats could extend the default course page definition to customize layout and design. These code changes would not only benefit formats, but also modules. For example, the lesson module could have a page of blocks that relate to an actual lesson page. This would allow lesson builders to define sets of blocks for each lesson page that may accompany the question content.

Average of ratings: -
Re: Proposed format plugin changes
Thanks, Mark. We really do need to fix up and rationalise course formats, blocks and page types. I'm OK for a complete radical rewrite in 2.0 even if it's not backward compatible.

I'll read your post more carefully later on, but some quick thoughts:

1) Put this in the wiki where it can be worked on: http://docs.moodle.org/en/Development:Pagelib_2.0 and maybe http://docs.moodle.org/en/Development:Course_formats_2.0

2) I think we should drop the whole id of a "pageid" and simply use standard contextids everywhere (they were added after original pagelib). This'll mean also extending contexts a little to cover some new areas like tags, blogs etc but it means we have a consistent framework between roles, pages, etc.

Average of ratings: -
Re: Proposed format plugin changes

I would rather kill different pagelib classes completely, to be replaced with something else. (Although I must admint to not being terribly sure what pagelib does.)

pageid certainly has to go. We were thinking that these days, the correct way to identify where the blocks should go is the combination (contextid, pagetype). That would let backup be taken care of automatically.

We were also wondering about generalising stickyblocks, we were wondering about generalising it, so you could define sticky blocks in any context, for a particular page type, and then those blocks would appear on those types of page in any subcontext. That idea is a bit vague at the moment.

The area where I disagree with your proposal is that I don't think page positions like 'left' and 'right' are properties of the course format. To start with, blocks don't just appear on the course page. I think this is a properly of the theme. The issue with that is, what happens when you change theme? One option is for each theme to nominate one of its places to put blocks, to be used to dump blocks that are in un-recognised positions.

(In the simplest case, a theme that only wants blocks on the 'right' could say put any blocks with any other position, e.g. 'left', at the end of the 'right' area. This could probably be the same as the place that is used to add new blocks. Or we could make it a separate setting.)

Also, what happens to the re-arrangement controls? One option is to change the UI so that instead of arrows to move a block just one postition, we instead make it like rearragning activities in the course. So, you click once and you get a lot of drop targets, and then you click on the target you want. That should work with any configuration of places to put blocks.

Average of ratings: -
Re: Proposed format plugin changes
Hi Tim,

I would rather kill different pagelib classes completely, to be replaced with something else. (Although I must admint to not being terribly sure what pagelib does.)

From my understanding, the pagelib class is the start of the features proposed here and it just has not fully matured yet. This is what I'm proposing here, is that we beef up the class to define as much as possible about the current page. I think your ideas build upon this proposal and could add a lot of needed functionality.

pageid certainly has to go. We were thinking that these days, the correct way to identify where the blocks should go is the combination (contextid, pagetype). That would let backup be taken care of automatically.

I do like the idea of using contextid, but the primary drawback is what about pages that do not have a specific context, but share a common one? A great example of this would be the lesson module where one may want to add a block to a single page within the lesson, but that page shares the same context as ever other page in the lesson. For this scenario, I think the pageid is a more elegant solution. Is there a way to solve this scenario while using contextids?

We were also wondering about generalising stickyblocks...

This is a great idea!

The area where I disagree with your proposal is that I don't think page positions like 'left' and 'right' are properties of the course format. To start with, blocks don't just appear on the course page. I think this is a properly of the theme. The issue with that is, what happens when you change theme? One option is for each theme to nominate one of its places to put blocks, to be used to dump blocks that are in un-recognised positions.

The 'left' and 'right' properties are really not properties of the format, they are properties of the page definition and are defined in the pagelib class. The real problem is that formats are stuck with the one page definition and are thus limited to only 'left' and 'right' columns.

Themes with blocks is a really different direction. I have thought about this before as it is an elegant solution for providing nice things like a consistent left/right navigation. I think one of the problems with theme's controlling blocks and layout is that we then create the assumption that the whole site has a single layout. Yes, we could change the theme as the course level, but what about modules that may have a different layout from the course? So, instead of the theme defining layouts, why not go down the route of allowing plugins to define their own layouts and then give themes the ability to extend those layouts and ultimately redefine them as much as necessary.

Also, what happens to the re-arrangement controls? One option is to change the UI so that instead of arrows to move a block just one postition, we instead make it like rearragning activities in the course. So, you click once and you get a lot of drop targets, and then you click on the target you want. That should work with any configuration of places to put blocks.

I have built a three column page layout and the blocks just get more arrows. So, if the block is in the center column, it gets both left and right arrows and depending on its potions, also up and down arrows. The two step move process that you are describing would make it easier to move blocks from one corner to another.

Cheers,
Mark

Average of ratings: -
Re: Proposed format plugin changes

You are right that it is just a choice of words issue whether you call my proposal 'killing the old pagelib' or 'maturing pagelib towards the original vision'.

Have you been following the thread about templates? The question of weather pages or themes own the block slots is basically the same issue. I don't know what the right answer is, so we need to go on debating this. (We meaning everyone, but not me. I have had little to do with customising blocks, course formats or themes so I don't have a good feel for the requirements.)

I think we are agreed that two-step move is generally more efficient UI - and it probably lends itself better to being converted to Ajax-y drag and drop later.

The bit I want to discuss in detail now is the contextid question. I suspect (without evidence) that it is the HTML block you are talking about when you ask for different blocks on different lesson pages. And further I speculate that this use of HTML blocks is actually a bit of a hack to emulate something that should really be a feature of the lesson module.

I think that if it was a 'real' block like calendar, or latest course news, or something, then you would either want it on all lesson pages, or none.

I don't really know how lesson works. In the quiz, view.php, attempt.php and review.php would all be different page types, and you could have different blocks on those.

If, however, I am wrong, and you have identified a genuine need then one option is to have three columns (contextid, pagetype, subpageid), where subpageid defaults to 0 in most cases.

Or we could stick with just two columns, and lesson could play nasty games with pagetype to treat each page in a lesson as separate.

Average of ratings: -
Re: Proposed format plugin changes
Is this the correct thread for the templates? The thread is rather long, but after scanning, my conclusion was that the issue is being able to template blocks of HTML output, not necessarily the whole page. To me, the way Moodle is setup for using blocks, one cannot really determine page layout and block positioning with just an HTML template. The pagelib defines a lot of logic about where blocks can go, what blocks can be added, etc. Perhaps the template comes in after the pagelib does its work? Then the template can say, the 'right' blocks actually go along the top instead down the right hand column. This is where your two phase move makes a lot of sense as the arrows would loose all meaning. I agree though, more discussion is needed.

Regarding blocks in lesson, I'm actually referring to any configurable block. Blocks are one of the easiest plugins to create in Moodle that can offer an array of functionality. So, lesson developers could get really creative with lesson design and supplement it with blocks of content. I dissagree about the 'real' blocks comment and how one would want on all pages or none. What about a course orientation lesson? One page could be about the calendar and display the calendar block to the right and explain its features.

Another fault of the contextid is creating a page in a contextless area. Example, would it be possible to make the My Moodle area without creating a new context? Currently, I think it just uses the system context, but wouldn't the site page use that, or the admin area? I think this introduces a unecessary limitation to developers since we cannot dynamically create new contexts. For example, a developer may want to create landing or portal page for an organization and include Moodle blocks on that page.

Cheers,
Mark

Average of ratings: -
Re: Proposed format plugin changes
Yes. That is the templates thread. You have to distinguish what people are asking for, as opposed to what they are going to get.

OK, to get our definitions clear, let us define 'pagelib' to be the part of Moodle repsonsible for determining which blocks go on which pages. So it needs to store the information about which blocks go on which page, and provide UI for editing both the block layout on any page and admin settings that costrain it.

My question is in an ideal world, which other parts of Moodle should pagelib consult in doing its job. At the moment, I think it works like this:
1. Blocks can list the pagetypes they are allowed to appear on
2. There are hard-coded left and right slots on pages that support blocks.
3. Each page that supports blocks is responsible for calling the function to print each column of blocks.

And, what I am saying is that we want to get rid of the hard-coded left and right slots because:

A. Some themes (like the one here) are designed to look good only with blocks on one side.
B. Some people want blocks in other places, like in the middle column, or at the top or bottom.
C. Some pages (imagine a wide report, or a popup window) don't really want blocks at all, or at least have special knowledge about this particular page that should be taken note of.
D. Not just pages. Some course formats within the course view page.

I think the we can find a solution that does not hard-code anything, and does consult both the theme, and the page being rendered. However I am still thinking through the details, and need to try to write something down.

However, I would be more than happy for other people the weigh in here with their opinions.

You have convinced me with your take on the lesson example. There are some really nice possibilities there. So we need to support that sort of thing.

However, there is not problem with using context the My Moodle page should be in the user context. (Just had a discussion with Martin about how My Moodle needs work, but not until Moodle 2.0 )

So I am currently favouring (contextid, pagetype, subpage), with subpage being textual - we would need to give each lesson page a shortname field, but going that way avoids backup and restore recoding horrors.

And we would need this for pagetype mod-quiz-report.

And perhpas we want to invent subpage='*' meaning show this block on all sublages. Or maybe I am overcomplicating.

Average of ratings: -
Re: Proposed format plugin changes

Since opinions were invited, I'll jump in. The discussion about multiple blocks instances sparked my interest - and I'm really trying to get a grasp on the infinite inner workings. Until that happens, though, I can't contribute to the technical part of the discussion; I can only contribute a user's take on it, and hope that that might help you guys sort out the details (which look like they can sometimes have teeth).

We use three themes: two for student lounges (K-6 and 7-12) and the main custom theme. Default site and topic blocks and their layouts are defined in site config.php (we don't use weekly format).

I like Mark's idea of having plugins define layout (though I'm not sure what that entails) and allowing themes to extend/redefine layout. I'm assuming a themes defined layout would require configuration for every theme used. But as Tim pointed out, if you use a theme somewhere that wanted blocks only on the right, would this be part of the 'extend/redefine' capabilities Mark mentions?

(Side question: If plugins define their own layout, how would that work? ...each time I try to further explain what I'm asking, I just end up sounding like an idiot, I'll stop while I'm ahead and leave it as is. Hopefully someone will take a shot at it )

I like Tim's idea about two-step block arrangement (I wish courses/categories had this!) Might solve the frequent problem of stubborn blocks that won't let new blocks sit above them. Maybe the default is fighting to keep its rightfully-defined config place *lol* I don't know.

Now the part I'm really interested in is Tim's proposal to generalize sticky blocks. I think this would be a huge asset and would address numerous situations (Override Permission my moodle sticky blocks being one).

I use the config file for blocks because we can't do anything with a sticky. But the only way (that I know of) to define default blocks on My Moodle is to pin them, so that's what we do. As a K-12 school we want to be more involved and have more control over the student dashboard, and want certain blocks static.

One of the problems with that (as anyone using stickies knows) is that teachers are then stuck with the same layout. Add to that the blocks we want default for teachers (all course ungraded work, etc.) and it makes for a fairly cluttered (and static) home page.

We had a student-created glossary and wikipedia search block as My Moodle sticky but removed them because: a) teachers didn't need them there and their pages were getting overloaded, and b) we needed to hide they from some classes during exams, but could only hide them sidewide.

(Not realizing then that students could add them anyway, and also not realizing the 'disallow multiple block instances' should prevent this, but the function works everywhere BUT My Moodle page, so it's a moot point).

Allowing an override capability for stickies, as Mike mentions in his thread, would almost be the perfect world, and alone might address some issues (more practical in courses, and teachers wouldn't be stuck with student blocks), but just the ability to set static stickies in different contexts would be a big improvement. At least you could vary settings for different categories or grade levels.

Again, I don't profess to know how things do or should work , just trying to contribute to brainstorming from the layman's angle, and maybe give more insight into the countless ways users interact with Moodle.

Average of ratings: -
Re: Proposed format plugin changes
Well, the technical bits I can mostly manage myself. Views from the user point of view are really valuable, so please go ahead.

I have now come up with a specific proposal: Development:Very_flexible_block_system_proposal. I would like to know what people think. I really don't know if it is the right proposal, it is just an idea I had that does a lot of the things we want.

Average of ratings: -
Re: Proposed format plugin changes
I like the look of the proposal.

One thing which I haven't seen mentioned[1] is giving blocks to control to add css/javascript hooks to their display/configure pages.

For a particular use case: I have been playing with putting YUI into the RSS block to streamline the configuration process. It'd be nice if we could have an ajaxy configure screen for the block, but not require the JavaScript for displaying its static content. (I'm no blocks expert so may be barking up the wrong tree here)

On the process for adding a block the third step is:
3. Redirect to the course page, in move mode, so you can put the block wherever you like immediately

Would the blocks be configurable at a different contexts? If so would the redirect not be to the context page rather than course?

[1] Please excuse me if its in one of the other threads - i'm lagging behind trying to catch up!

Average of ratings: -
Re: Proposed format plugin changes
I can't see why require_js is not sufficient, but I may be missing something. Of course, we need a require_css too, and we will have one in 2.0.

And yes, s/the course page/the page the block is being added to/.

Average of ratings: -
Re: Proposed format plugin changes
Sounds fine to me - the problem at the moment is that the block content functions are not called until after the header has been printed.

Average of ratings: -
Re: Proposed format plugin changes
This is not a problem for require_js.

It is a problem for a future require_css. I may not have made it clear, but I am planning to add a function call (hook) into each block that appears on the page, and each active filter, so they can do stuff before print_header. In fact, this will probably be inside print_header, as one of the first things it does.

Average of ratings: -
Re: Proposed format plugin changes

Thanks for linking to my thread and letting me know this thread is here(I managed to miss it).

Having the ability to set capability overrides on sticky blocks would be very useful (I've still not found a solution to my problem), it seems odd that this isn't already a feature- it seems like a break in the usually very consistent system

Thanks,
Mike

Average of ratings: -
Re: Proposed format plugin changes
It is inconsistent, and is only like that because at the moment it is not possible to implement things consistently. My proposed changes make things consistent. That is one of their advantages. However, there may be problems, so we need more discussion before they are implemented.

Average of ratings: -
Re: Proposed format plugin changes
So I am currently favouring (contextid, pagetype, subpage), with subpage being textual - we would need to give each lesson page a shortname field, but going that way avoids backup and restore recoding horrors.

I put some thought into this and I really cannot find a strong argument to support the three keys. First, I strongly disagree with subpage being a textual field and putting the burden on the Moodle users to come up with unique textual keys for pages. Instead, let's stick with one field for a numeric key and one field for the pagetype. So, if one thought it was necessary to use the contextid, then for that pagelib definition, s/he would use the contextid. If one thought it was necessary to use another key entirely (like Lesson ID), then for that pagelib definition, s/he would use that key. Now we go back to the original proposal where we remove references to $this->instance->pageid and implement those backup and restore hooks. We can look into making the calls to those hooks more efficient by calling them statically. Now, that leads to another question though. How does a block know where it is without using the$this->instance->pageid? I think that blocks that need to know this sort of information should get it from the $PAGE global which is set to the current pagelib definition. As pagelib matures, developers should be able to use it to retrieve whatever information s/he needs about the current page (URL, context, ID, etc). Maybe we wont see eye to eye on the three key vs two key approach, but I'm having a hard time justifying the three key approach when the two key seems to be more flexible and easier to implement for developers and end users. Average of ratings: - Re: Proposed format plugin changes Flexibility is a double-edged sword. It means that anything might be possible, but it also means that Moodle core has no idea what is going on, and so cannot really contribute. Complete flexibility also tends to lead to a lack of consistency. Two specific problems that we have at the moment: 1. Because block_instance.pageid could be anything, currently we need a page subclass for each type of page in Moodle that wants to have blocks. (And there is no documentation I have ever seen about how to do that.) As a result, you can only have blocks on some types of Moodle page. To me that seems like strong evidence that the current system is not "eas[y] to implement for developers". 2. Blocks are meant to be integrated into the roles system, so, for example, you can control block visibility or editing by role. However, at the moment, only (non-sticky) blocks on the course page have a context, and so can be controlled in this way. If all blocks belong to a parent context, with that relationship clear in the database, it is easy to create a context for each block. I agree with you that blocks should be able to get most of the information they need about where they are from a good$PAGE global.

But to me, that is not the main problem. The tricky part is before you have created the block instances, when you are trying to find out which block instances should be on this page. Well, at them moment it is not too bad, we just have to ask the page subclass for the pageid number. However, if we want to make sticky blocks more flexible (e.g. show this block on all courses in this category), then having to include page types in the calcuation becomes much harder.

Anyway, I now have some more detail about what I am proposing: Development:Very_flexible_block_system_proposal. Note that in this proposal, someone writing a new module, or other type of page that might show blocks, has to do absolutely nothing in order to support blocks. Now that is easy

Whether subpage is textual or an integer is a deatail I don't care strongly about. I think it is worth avoiding the need to re-code on backup and restore, if possible, but I am prepared to put the necessary hooks in the code if people want. (Another option is to use a string, and have Moodle auto-generate a globally unique string behind the scenes, so users aren't bothered.)

I hope I can convince you about this, or you can convince me, becuase you have been more deeply involved in the blocks system than me before, so you probably know more about it. Therefore it would worry me to continue with a proposal you weren't happy with.

Average of ratings: -
Re: Proposed format plugin changes
Lots of proposals I'm curious as to how the communication will occur for figuring out where the blocks will be printed on a specific page (EG: when $HTML->print_header/footer are called)? It seems like the themes are now responsible for this and so if I wanted to make a new layout, I would have to add it to the standard theme? Just wondering how I would make a custom block layout for a format. My first thought on this, is that the plugin/area would define the layout or use the default layout and then the theme could override it when necessary. Still digesting this proposal... Another option is to use a string, and have Moodle auto-generate a globally unique string behind the scenes, so users aren't bothered. I believe that if we go down this route, then when one makes a record that should be associated with a subpage of blocks, then s/he would need to store that auto-generated string along with that record. Perhaps this overhead is worth the more simplified backup/restore? Average of ratings: - Re: Proposed format plugin changes Yes. Lots of proposal. Take that as a sign that I don't really know where I am going with this. I have just brain dumped a lot of partial ideas that try to solve various parts of the problem. We really do need to pick the the ideas apart now and make them better. I am hoping to repeat good experiences I have had in the past with technical discussions here. I am aware that some time between now and when we start to write code, it needs to be reduced to a single proposal, written with the aim of clearly communicating our intentions. But it was enough of a struggle getting the ideas out of my head and into writing, I am hoping that what I have written so far is enough to start discussing. I am now mainly working on some quiz and question bank changes, to allow time for this discussion to happen. OK here is an attempt to explain what I mean with a couple of pictures: This picture tries to show how things are now. Note that the area of the page that the module is in charge of is just rectangle. In the HTML, it will be a div. (When I say module, I mean whichever PHP script the user went to in their browser. It may be part of an activity module, core code, or a page belonging to some other plugin.) Because different scripts print the overall page layout, we get the current situation where some pages use tables for layout, some use CSS floaded divs, and the way block appear (on in some cases can't appear) is different on different pages. Average of ratings: - Re: Proposed format plugin changes Now, this is the equivalent picture for what I am suggesting: Note that the blue rectangle (<div>) that the module controls is smaller. The overall page-layout is controlled by the theme. That is, print_header, which the module still has to call, generates more of the page. This should be good for consistency. In addition, if the module wants to, it can declare an extra area for blocks inside the rectangle it controls. For example, a course format might do this. I am thinking that this might be a good way to handle pages like the site front page: The blue rectangle for /index.php would simply contain one red rectangle for holding blocks. And we would make new blocks to replicate each of the choices News items, List of courses, List of categories and Combo list that you can currently display on the front page, if they don't already exist. One issue with this is when you get a page like the grader report, or a quiz report, which is very wide. In those cases, the same blocks layout as on most pages might not be appropriate, that is why suggested the$PAGE->set_page_class(PAGECLASS_WIDEREPORT); thing. That is, there needs to be a little bit of negotiation between the theme and the module about what the page layout is.

Average of ratings: -
Drupal: Regions for page layout
Hi Tim,

It's my two Drupal cents again

"Drupal theme authors can define and implement any number of 'regions' for content to be rendered into. This improved regions system replaces the previous 'left' and 'right' sidebar placements and should enable greater flexibility with layout and design."
http://drupal.org/node/29140

"Regions are essentially containers to which you can add [...] blocks. You can also add other non-block content to a region using PHP. An example of a region is your sidebar.

These regions can be assigned to either the whole page or any other themed elements, including in nodes or comments."
http://drupal.org/node/29139

I don't know whether this is technically feasible in Moodle but I think the concept is attractive.

Kind regards,
Frank

Average of ratings: -
Frankly, I am getting a little confused where to put my comments. I think there is a lot of overlapping content between this thread and the following two:

"The Future of Moodle Templates?"
http://moodle.org/mod/forum/discuss.php?d=108993

"How hard is it to theme for Moodle?"
http://moodle.org/mod/forum/discuss.php?d=116398

Perhaps there is a way to merge them or start a new thread?

Average of ratings: -
Re: Too many theming related threads?
It is tricky, because I find that the one thing that the Moodle forums don't cope with well is when a single thread becomes too long. And the three threads combined total (20+58+29 = 107 posts. Oops 108 now ). So I think separate threads for separate strands of the conversation are better. With people posting the occasional cross-link to help others keep track.

Also, people in the themes forum are more likely to contribute there than here, and we need their input. Perhaps we need another thread in the blocks forum too .

Average of ratings: -
Re: Drupal: Regions for page layout
If you read my proposal, you will see that is exactly what I am proposing.

Average of ratings: -
Re: Drupal: Regions for page layout
Tim emailed to grab my attention for comments about changes to blocks because

"I would particularly like some input form the OpenLearn side about the blocks part, since they do clever stuff with blocks, and it would be nice to know whether what we are talking about meets their needs."

I don't think OpenLearn does anything that clever with blocks - what were you thinking of? What follows are the things I've found difficult with blocks though, which I would hope a new system might address...

- All OpenLearn blocks are sticky, so more flexible sticky blocks as you've discussed e.g per category or on all instances of a given module, would be great.

- One thing I've struggled with is capability checking for myMoodle blocks e.g. MDL-13888 and MDL-13891 where blocks don't seem to be able to display themselves correctly depending on the current user's permissions.

- Another thing is that some of our blocks have content in moodledata and database entries that are course-specific. I don't think there's a decent clean-up for this when the course is deleted, particularly if the block is sticky. So we've had to add code in local_delete_course() instead. That's a hack, so support for course deletion could be better. Now you're going to tell me I've overlooked something I expect

- I find the CONTEXT_BLOCK level confusing since a block is always inside a category/course/module so surely the context there should apply? This will need sorting out (at least in my head) if we use contextid not pageid to define where the block is displayed. Some of the comments above suggest CONTEXT_BLOCK doesn't work anyway, so maybe I'm right to be confused?

- Something I've been asked to do, and had to refuse, is to promote a single block instance on one course in among the sticky blocks. Currently Moodle renders all the sticky ones first and only then adds those defined for the course. Users would like to add a course-specific block in the middle of the sticky ones completely flexibly. This might be possible with the new database structure you've defined.

- One other odd thing we've done with blocks recently is create one block to point to the content of many others. The idea is to reduce the number of blocks on the screen. The new block has a single link for each original block pointing to a new page which uses the get_content function of each block to work out what it ought to display - so I wouldn't want to see that get_content function disappear!

That's pretty rambling, I hope it makes sense!

Average of ratings: -
Re: Drupal: Regions for page layout
* Good.

* Those two bugs are interesting. I'll have to consider that, but it should be fixable.

* I think the theory these days is that stuff like blocks cleanup when a course is deleted should be possible to do properly with the events API, but I have no idea if it actually works.

* Context block is confusing, and probably not necessary for most blocks, since you can use the page the block is on. It probably comes into its own for things like newsfeed, where you might want to assign or override a role specifically in the block.

* Flexible mixing of sticky and non-sticky blocks is possible in my proposal.

* I am sure a part of the API as fundamental as get_content won't go away.

Average of ratings: -
Re: Proposed format plugin changes
Comment from Ralf Hilgenstock on the talk page (I moved it here for easier dicussion):

very good ideas. Can you add the option to show course blocks in every activity as default setting by this development. It seems inconsistent that some activities/ressourse support blocks and others don't do it.

As far as I can see, it is only the text and web page resource types that supported the 'Show the course blocks' option. So it is inconsistent.

The new flexible sticky blocks setting will let you add blocks consistently to all pages within your course. The trade-off will be that it is slightly more complex to set up at the course level, but then you won't need to make any settings inside individual activities.

Average of ratings: -