The most common use of this context is so that overrides of 'moodle/block:view' capability can be used to make some blocks visible to some users but not others. (A good example would be a HTML block you want only visible to teachers.)
In Moodle 2.0, things have changed so there is more flexibility about where a block will appear. I think I had better take a detour to explain the new system before getting back to my question.
Basically we have generalised sticky blocks. There are now three tests done to determine whether block B appears on page P.
The data used in the test are:
From the block_instances table, the fields contextid, showinsubcontexts, pagetypepattern and subpagepattern; and from the page object fields contextid, pagetype, and subpage.
- The block contextid (this is the block the context belongs to, not the block context. Perhaps I should rename this to parentcontextid?) is compared with the page context. If showinsubcontexts is false, then the two contexts must be the same, otherwise the page context must be a subcontext of the block context. (This is so you can do things like add a block to every course in a course category.)
- The page's pagetype must match the pagetypepattern of the block instance. A pagetype pattern might look like 'course-view', 'mod-forum-*' or 'mod-*-view'. (This lets you add a block to every page within a forum, or to the index.php page of every activity type in a course.) Note that the pattern 'a-*' does match the page type 'a-b-c'.
- Subpage is only used occasionally, For most pages subpage is '' (empty string). However, it used in a few places like the different pages of a quiz or lesson attempt, or the tags pages for different tags. Subpage pattern is either a string that must match exactly, or NULL, which means match anything. (I might change that to *).
OK, so the summary is that now, every now every block clearly belongs to one particular context. This means that it would be possible to give each block its own context, becuase there is a clear parent context to use. Note also that when a block is actually displayed there is also a clearly defined page context, which might also be used for checking some permissions. (For example, a block might be designed to be used as a sticky block, so it is added to a course category and appears on all the course pages in that category, but then uses the course context - which is the page context - to decide what to show.)
So, the question is, should we give each block its own context?
The big potential problem is performance. And I don't think we have any idea how people will use the new flexibility for configuring blocks, so we don't know what typical blocks data will look like in the future, which makes trying to predict performance implications harder.
Certainly there would be more contexts if we did this, but would it be a few more, or many more? (And there may even be fewer, what if you decide that every course will have a participants block, so add one sticky block, and remove all the speparate blocks on each course.)
My best guess is that with one possible exception, the performance penalty will be small and so the extra flexibility and consistency make the change worthwhile.
The one possible exception is the get_user_access_sitewide function. How would we hand block contexts (belonging to sticky blocks) there?
Does anyone have any useful ideas?