If you really want to understand what is going on, you need to understand this query in blocklib.php: https://github.com/moodle/moodle/blob/272fec367fba2957cb0818460c31d10d09352bca/lib/blocklib.php#L604
Unfortunately I'm not very good with PHP so this doesn't help me much. A teacher asked me the original question so I was hoping for something that I could pass on to them.
OK, let me see how well I can explain it:
How pages are identified
Every page in Moodle is identified by two or three things:
- The context. This is the same context as is used in the Roles and permissions system, so at the top level you have the systme context, then course-categories, then the courses, then individual activities. See diagram 13.3 of http://www.aosabook.org/en/moodle.html and the surrounding text for more explanation of contexts.
- The page type. This is normally (but not always) related to the URL, so it might be course-view, or mod-forum-view, or mod-quiz-view or mod-quiz-attempt, etc.
- (Optionally) a sub-page id. This applies in cases like a quiz with the questions split over multiple pages. If so, there are mutliple mod-quiz-attempt pages for that quiz, and you need to use the page number to tell them apart.
If you want to learn more about this, then you can go to Admin -> Development -> Debugging, and turn on Show page information. Probably best to do that on a test system, not your real Moodle site. It adds some information like "This page is: General type: admin. Context System (context id 1). Page type admin-setting-debugging." to the footer of each page.
(You probably don't need to worry about point 3. above for now. Nor the "General type: admin" bit above. Also, I lied in 2. when I said course-view. It is actually slightly more complex than that, but again that is not an important detail for now.)
Where blocks appear
OK, so once you understand how pages are identified, then you can start to understand which pages a block might appear on.
A block will have restrictsions based on all three of the page identifiers, and all of them must match for the block to appear:
- A block belongs to a particular context, and then there are two options, either a. appear just in that context, or b. appear in that context and all sub-contexts.
- A block will have a page-type pattern, with will either be a specific page-type like mod-quiz-attempt, or it might be a pattern like mod-quiz-* (anywhere in the quiz) or mod-*-view (the view page for any type of activity).
- Sub-page: again, either a specific value (e.g. page 3) or * to mean match all.
If you look in the block_instances table, you will see these values directly, in the parentcontextid, showinsubcontexts, pagetypepattern and subpagepattern columns.
In the user-interface, these raw values are displayed slighty differently, in what is meant to be a slighly more user-friendly form.
But that is not all
The extra complexity is that there might be extra reasons why a block does not show up. For example perissions checks, of other logic. Some examples
- If a HTML block is empty, it does not appear unless Editing is on.
- Some blocks only appear to people with appropriate capabilities. (E.g. the participants block probably does not appear to guests.)
Thanks a lot for this detailed explanation which really does help and is much appreciated. I'll do some testing based on what you've said and explore things a little further. I have a feeling that block display isn't quite working as it should in our system, but I'll try and find out if it's and a specific problem with our setup or if I've spotted a bug.