Description

I am trying to customize the blocks that students will see on their user profile page. I go to Settings > Site Administration > Appearance > Default profile page and click the "Customize this page" button. Then, I add a block. If I leave it as-is, it works fine, and appears where it should. But if I can go into its settings to edit its page context, strange things happen. The first time you access it, there are two choices under "Display on page types": "Only user profile pages" and "My home page." The SECOND and all later times that you return to those settings, a third option "All pages," has appeared.

What is problematic is that, once "All pages" has appeared, the block's "Display on page types" ALWAYS defaults to this, no matter what setting I choose. If I change "Only user profile pages" (see image "beforesaving.png"), and then press "Save," the setting is actually immediately reset to "All pages" (see image "aftersaving.png"). I cannot figure out why the setting that I apply won't "stick."

I have replicated this problem on both our local Moodle 2.x installation and on demo.moodle.org.

Michael de Raadt
added a comment - 18/Nov/11 9:31 AM Thanks for reporting this. A prime example of a solid bug report.
I wonder if this has to do with the page layout of the profile page.
I've put it on our backlog.
In the meantime feel free to help us work on this issue. If you are able to provide a patch, please add a patch label so we will spot it.

Martin Dougiamas
added a comment - 02/Dec/11 5:25 PM Here's another example, of trying to get a block set up to display on all user home pages (a very common requirement):
1) As admin, create a new HTML block at site level (on the front page). Make sure it's set to display on all pages in the site.
2) Go to your home page (/my). The block should be there.
3) Edit the settings and change the page type menu to display only on "my-index". Save the form.
4) Open the same settings for the block again.
5) The page type has not changed, and it not saveable.

Eloy Lafuente (stronk7)
added a comment - 02/Dec/11 6:44 PM Well,
I'm sure that the code always resetting to pagetype = '*' is the one @:
https://github.com/stronk7/moodle/blob/master/lib/blocklib.php#L1236
So any page having $data->bui_contexts == BUI_CONTEXTS_ENTIRE_SITE (line 1245) gets its page-type reset. I've quick tested it disabling that condition and then the page-type is stored properly.
Just looking to the referenced MDL-21375 issue now.

I can second Eloy's findings. I just realized the pagetypepattern is reset to '*', probably because the code expects the user actually wants sticky blocks on all page types, not a specific one... Tricky sticky.

David Mudrák
added a comment - 02/Dec/11 6:55 PM I can second Eloy's findings. I just realized the pagetypepattern is reset to '*', probably because the code expects the user actually wants sticky blocks on all page types, not a specific one... Tricky sticky.

Eloy Lafuente (stronk7)
added a comment - 02/Dec/11 6:58 PM Yeah, it seems that this comment, the "behind the scenes", is the culprit for that:
http://tracker.moodle.org/browse/MDL-21375?focusedCommentId=80072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-80072
For front page, the form hides the "page-type" and later calculates it "behind the scenes", doing:
1) if "entire site" was selected, then apply for pagetype = '*'
2) else, for any other systemcontext block, apply for pagetype = 'site-index'
And that, happening "behind the scenes", is clearly against our attempts to specify one pagetype, efectively reseting it behind the scenes, lol.
Ciao

Eloy Lafuente (stronk7)
added a comment - 02/Dec/11 7:01 PM So, perhaps, we could try to change the conditions a bit and only apply for those defaults if no pagetype is passed or so.
Or, alternatively, we could bring back in the UI the page-type and avoid any "behind the scenes". After all, it only applies to the front page.
Just attempting the first alternative...

Eloy Lafuente (stronk7)
added a comment - 02/Dec/11 7:24 PM Uhm, no way. The data comes in the form, so it is not possible to detect from where we are editing the block instance.
We would need something coming in the form like $data->editedfrom, to be able to decide, really hacky.
My +1 goes to bring back the UI to the front page edition, so any instance edited will look 100% the same if edited in the front page or in the my page or in the profile/my template pages.
And revert the "behind the scenes" code, of course.
Ciao

Eloy Lafuente (stronk7)
added a comment - 02/Dec/11 7:57 PM - edited Alternatively... we could try to prevent edition of the instance in places where it does not belong to, so:
Instances having * or site-* only will be editable in frontpage
Instances having my-index-* only editable in my/indexsys.php
Instances having user-* only editable in user/profilesys.php
Other instances (blogs, tags...) no bloody idea!
That way, each one can have its own "behind the scenes" code, and it won't be possible to allow one to mess the other.
That, or we allow to edit all possible pagetypes everywhere.
Ciao

If you create one block @ course level, setting it to "show in all pages".

Then you go to one chat activity and edit it from there and you can set it to "Any chat page" only. But it continues being a "course-context-level" block.

Then, the block is not available anymore @ course page (because it's to be shown only in chat pages) and cannot be reverted anymore to "show in all pages" because chat does not allow you to pick pagetype again.

100% locked situation. Only can delete the block and start from scratch!

So, I think the only way to avoid all this is to completely avoid edition "remotely" (of the instance-related information, np with the position information) and only allow edition if both the context and pagetype match the context and pagetype of the block.

Anything else can lead to conflicts, like the frontpage vs my, or the course vs chat.

Eloy Lafuente (stronk7)
added a comment - 02/Dec/11 8:28 PM - edited Bah, but it's really inconsistent in every place I'm looking:
If you create one block @ course level, setting it to "show in all pages".
Then you go to one chat activity and edit it from there and you can set it to "Any chat page" only. But it continues being a "course-context-level" block.
Then, the block is not available anymore @ course page (because it's to be shown only in chat pages) and cannot be reverted anymore to "show in all pages" because chat does not allow you to pick pagetype again.
100% locked situation. Only can delete the block and start from scratch!
So, I think the only way to avoid all this is to completely avoid edition "remotely" (of the instance-related information, np with the position information) and only allow edition if both the context and pagetype match the context and pagetype of the block.
Anything else can lead to conflicts, like the frontpage vs my, or the course vs chat.
Ciao, gtg now for 2-3 h

Tim Hunt
added a comment - 02/Dec/11 8:31 PM The problem there is the "because chat does not allow you to pick pagetype again."
Why not? It used to allow you to change the setting back - at least to change pagetype back to *.

You create the block in the top context (eg a course) that covers the places you want it, and make it "sticky" so it appears on all the sub-contexts.

You then go to the type of place where you want it, eg in chat and edit the block there

You set the pagetype etc to show only on THIS type of page (eg all chat pages in the course)

To undo this you:

Go to the chat page where the block appears

Edit the settings, and set the pagetypes back to "All" = *

Then the block appears in the "home" (eg course) context again

This process is exactly the same for a block that was created at the site, category, course, activity.

The "locked chat" sounds like a bug. And the situation of system blocks is a bug. You NEED to be able to edit the block in all kinds of contexts UNDER the original home location, because that's how you access the pagetypes you need.

Martin Dougiamas
added a comment - 02/Dec/11 8:46 PM - edited tim is correct, of course.
The workflow for showing a block on all pages of a certain type:
You create the block in the top context (eg a course) that covers the places you want it, and make it "sticky" so it appears on all the sub-contexts.
You then go to the type of place where you want it, eg in chat and edit the block there
You set the pagetype etc to show only on THIS type of page (eg all chat pages in the course)
To undo this you:
Go to the chat page where the block appears
Edit the settings, and set the pagetypes back to "All" = *
Then the block appears in the "home" (eg course) context again
This process is exactly the same for a block that was created at the site, category, course, activity.
The "locked chat" sounds like a bug. And the situation of system blocks is a bug. You NEED to be able to edit the block in all kinds of contexts UNDER the original home location, because that's how you access the pagetypes you need.

Martin Dougiamas
added a comment - 02/Dec/11 8:49 PM I really think we need to solve this before release, even if it's Monday or so.
It's a pretty fundamental thing in the GUI and could mess up any sites that use blocks in a meaningful way.

1) for parent-child relations (system <==> course <==> module) , all the children can revert the page-type to all the ones available in the parent.
2) For siblings relations (system <==> system), all the siblings can set all the page-types.

Nor 1) (the chat lookout) nor 2) (the frontpage able to set my-* and viceversa) are working ok now. And all because of the mutually excluding options.

Anyway that surely needs to be revisited later (after release). For now it's enough to fix the current issue (the 2 case).

IMO the problem for 2) is that the frontpage is being used both to define frontpage blocks and also as "another template" for system. And here it's where it collisions with the other 2 templates (the my and the profile ones).

Eloy Lafuente (stronk7)
added a comment - 02/Dec/11 10:01 PM Yes, your definition above would work greatly if:
1) for parent-child relations (system <==> course <==> module) , all the children can revert the page-type to all the ones available in the parent.
2) For siblings relations (system <==> system), all the siblings can set all the page-types.
Nor 1) (the chat lookout) nor 2) (the frontpage able to set my-* and viceversa) are working ok now. And all because of the mutually excluding options.
Anyway that surely needs to be revisited later (after release). For now it's enough to fix the current issue (the 2 case).
IMO the problem for 2) is that the frontpage is being used both to define frontpage blocks and also as "another template" for system. And here it's where it collisions with the other 2 templates (the my and the profile ones).
Said that, if I can help with anything, tell me... ttyl! Ciao

For the records, the "lockout" between course and modules happens with all modules, both under 21_STABLE and master. The original implementation @ 20_STABLE adds properly the last "*" element, so it's possible to "bring back" the block to the course.

Eloy Lafuente (stronk7)
added a comment - 03/Dec/11 12:01 AM For the records, the "lockout" between course and modules happens with all modules, both under 21_STABLE and master. The original implementation @ 20_STABLE adds properly the last "*" element, so it's possible to "bring back" the block to the course.

ANOTHER ONE: Category blocks also 100% broken, both 21_STABLE and master. It's not possible anymore to specify * all pages, to get the block shown in all sub-categories/courses. It worked perfectly in 20_STABLE.

Eloy Lafuente (stronk7)
added a comment - 03/Dec/11 12:08 AM ANOTHER ONE: Category blocks also 100% broken, both 21_STABLE and master. It's not possible anymore to specify * all pages, to get the block shown in all sub-categories/courses. It worked perfectly in 20_STABLE.

AND THE FINAL: Now trying to see how system (all pages) blocks are edited both at course or module level. And it's another, different, case. In this case, the list of options remains sticky to the system ones and nor the course nor the module page-types are added).

Eloy Lafuente (stronk7)
added a comment - 03/Dec/11 12:22 AM AND THE FINAL: Now trying to see how system (all pages) blocks are edited both at course or module level. And it's another, different, case. In this case, the list of options remains sticky to the system ones and nor the course nor the module page-types are added).

Lock between course blocks page-type editions at module level. (missing "*" to bring back the block to the course).

Category blocks not working anymore, not spread to all children contexts. (missing "*" to pick all pages option). And surely suffering also 1) once fixed.

System blocks not able to be edited with custom page-types at course or module level. And surely suffering also 1) if get fixed. This last is the one I don't know if is a bug of a wanted (sticky) feature, but in that case it does not have any sense to be able to change one system block at module level.

The THREE problems should have its own issue if you agree they are problems, perhaps they aren't. Ciao

Eloy Lafuente (stronk7)
added a comment - 03/Dec/11 12:28 AM - edited So, apart from the original issue, we have 3 more:
Lock between course blocks page-type editions at module level. (missing "*" to bring back the block to the course).
Category blocks not working anymore, not spread to all children contexts. (missing "*" to pick all pages option). And surely suffering also 1) once fixed.
System blocks not able to be edited with custom page-types at course or module level. And surely suffering also 1) if get fixed. This last is the one I don't know if is a bug of a wanted (sticky) feature, but in that case it does not have any sense to be able to change one system block at module level.
The THREE problems should have its own issue if you agree they are problems, perhaps they aren't. Ciao

Amazing, trying to fix subproblem 2 of MDL-30340 just realized that we have pages with "dynamic" pagetype, so on edition, the pagetype = 'admin-course-category' and when browsing it is = 'page-course-category'. So setting the former on edition, causes no effect when browsing.

Going to try if *-course-category works to cover the 2 pagetype approaches...

That apart of the missing '*' option to spread the block over all the subcategories/courses/modules.

Eloy Lafuente (stronk7)
added a comment - 03/Dec/11 7:03 PM Amazing, trying to fix subproblem 2 of MDL-30340 just realized that we have pages with "dynamic" pagetype, so on edition, the pagetype = 'admin-course-category' and when browsing it is = 'page-course-category'. So setting the former on edition, causes no effect when browsing.
Going to try if *-course-category works to cover the 2 pagetype approaches...
That apart of the missing '*' option to spread the block over all the subcategories/courses/modules.

Eloy Lafuente (stronk7)
added a comment - 03/Dec/11 10:21 PM Adding link to MDL-30564 about the "varying-pagetype" behavior of the category pages.
Also, it has been agreed about to, for now, simply add the '* option to the category blocks. Doing...

Eloy Lafuente (stronk7)
added a comment - 03/Dec/11 11:50 PM - edited I've created 2 subtaks for this:
MDL-30565 : to be able to 'bring back' the edited block to original context.
MDL-30566 : to be able to 'spread' coursecat blocks to children contexts.
Both should be integrated before this issue.

I need some feedback about the 3) related issue commented above. Is it a bug? No? Should the "local options" be shown when the block is edited at subcontexts? All the rest of multi-context blocks (course-category, course) allow to change the pagetype on children contexts. System ones do not.

One simple use case: Create one system-wide HTML block to be shown in all forums, pointing to the forumtiquette rules.

Eloy Lafuente (stronk7)
added a comment - 04/Dec/11 1:15 AM - edited I need some feedback about the 3) related issue commented above. Is it a bug? No? Should the "local options" be shown when the block is edited at subcontexts? All the rest of multi-context blocks (course-category, course) allow to change the pagetype on children contexts. System ones do not.
One simple use case: Create one system-wide HTML block to be shown in all forums, pointing to the forumtiquette rules.

Dan Poltawski
added a comment - 04/Dec/11 4:57 AM I'm the assignee on this and promised to look at this weekend, but I don't think I have the detailed level of understanding of the situation that Eloy/David now have!

Mary Evans
added a comment - 04/Dec/11 11:32 AM Eloy,
I've just been testing this following the test instructions, and not sure if I have this correct, but could it be that some of the cases for the options are actually mutually exclusive?
Just a thought in passing...
Mary

I think it solves all the major issues and would be good enough to unblock 2.2.

Problems remaining:

1) When you edit a block that is on the front page (site-index), you now see two menus that conflict. You can select:

"Display throughout the entire site" from contexts, and

"site-index" from pagetypes,
and it will only show on site-index. This is technically correct from a block code point of view, but nonsensical and confusing for users ON THIS PAGE, because there is only one site-index anyway. The solution (as it was before) is to hide the second menu altogether and always set pagetype to '*' behind the scenes (or as a hidden field). But ONLY ONLY when we are editing a block on the front page (site-index). I would like to see this fixed for 2.2 release.

2) If I create a page on the front page, then go to Tags page and make it show only on Tag pages, it works. But if I try to reverse this process I do not see "All pages" in the Page types menu, so I can't. The block is "locked" in tags. (Note this is a not a problem for Blogs, Notes, Calendar or Reports). Can be fixed after 2.2 as this kind of tag blocks are probably a small use case.

3) Editing a site-wide block on the Site-level Participants page breaks completely with block not found. Can be fixed after 2.2 though.

(Mary, the test instructions are badly written, in that the OP used them to indicate the problem. They are not for testing a solution. I'll update them)

Martin Dougiamas
added a comment - 04/Dec/11 12:52 PM I have been testing Eloy's combined branch fairly exhaustively ( https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus )
I think it solves all the major issues and would be good enough to unblock 2.2.
Problems remaining:
1) When you edit a block that is on the front page (site-index), you now see two menus that conflict. You can select:
"Display throughout the entire site" from contexts, and
"site-index" from pagetypes,
and it will only show on site-index. This is technically correct from a block code point of view, but nonsensical and confusing for users ON THIS PAGE, because there is only one site-index anyway. The solution (as it was before) is to hide the second menu altogether and always set pagetype to '*' behind the scenes (or as a hidden field). But ONLY ONLY when we are editing a block on the front page (site-index). I would like to see this fixed for 2.2 release.
2) If I create a page on the front page, then go to Tags page and make it show only on Tag pages, it works. But if I try to reverse this process I do not see "All pages" in the Page types menu, so I can't. The block is "locked" in tags. (Note this is a not a problem for Blogs, Notes, Calendar or Reports). Can be fixed after 2.2 as this kind of tag blocks are probably a small use case.
3) Editing a site-wide block on the Site-level Participants page breaks completely with block not found. Can be fixed after 2.2 though.
(Mary, the test instructions are badly written, in that the OP used them to indicate the problem. They are not for testing a solution. I'll update them)

I continue thinking that the roots of all (big, big %) of this mess is caused by the mix of system-wide/frontpage blocks that we are trying to achieve in the frontpage UI.

Life would be really easier and clearer for everybody if we could move the system-wide part to one new, isolated template, like the ones we have already for /my and /user/profile.

I agree that, for system context there is only one possibility, and * could be assumed, but the 3 available for frontpage are the ones causing the UI problem, and requiring us to show them. Hence, separating would simplify a lot.

If that is not done... I would recommend to change the UI @ frontpage to something really easier to understand and interact with. After all there are no many combinations possible there. Why not one simple drop-down menu with these combinations available:

Front-page only (site-index) (COURSE_CTX)

Any front page (site-index-*) (COURSE_CTX)

Any top level page (site-*) (COURSE_CTX)

System-wide (SYSTEM_CTX)

That is an easy picker, that prevents any forbidden combination, and it does not require JS, nor nested pickers, not hiding anything.

Ciao

PS: In fact, hehe, the menu above is exactly the "Display on page types" one, so basically we can hide the "Page contexts" one, because any page-type belongs to one and only one context (i.e. the inverse automatism - page type defines context - may work).

Eloy Lafuente (stronk7)
added a comment - 04/Dec/11 6:55 PM - edited I continue thinking that the roots of all (big, big %) of this mess is caused by the mix of system-wide/frontpage blocks that we are trying to achieve in the frontpage UI.
Life would be really easier and clearer for everybody if we could move the system-wide part to one new, isolated template, like the ones we have already for /my and /user/profile.
I agree that, for system context there is only one possibility, and * could be assumed, but the 3 available for frontpage are the ones causing the UI problem, and requiring us to show them. Hence, separating would simplify a lot.
If that is not done... I would recommend to change the UI @ frontpage to something really easier to understand and interact with. After all there are no many combinations possible there. Why not one simple drop-down menu with these combinations available:
Front-page only (site-index) (COURSE_CTX)
Any front page (site-index-*) (COURSE_CTX)
Any top level page (site-*) (COURSE_CTX)
System-wide (SYSTEM_CTX)
That is an easy picker, that prevents any forbidden combination, and it does not require JS, nor nested pickers, not hiding anything.
Ciao
PS: In fact, hehe, the menu above is exactly the "Display on page types" one, so basically we can hide the "Page contexts" one, because any page-type belongs to one and only one context (i.e. the inverse automatism - page type defines context - may work).
PS2: I'm going to take a look to the tags problem.

Do we really want to be able to send back one block from those pages to the "system template"? I really don't get the point about at. If somebody wants to create one block for all the blog pages or tag pages... why not, simply create it there? Creating it in the front-page as a system-wide block, just to "take/capture it" in the blog or tags page seems unnatural. More yet, I'm not sure if all the blocks available for those pages are suitable to be used out from those pages.

The "bring-back" feature was thought to effectively return the block to its original (parent) context, hence it only applies for system => coursecat => course => module, but not for system => system.

Blogs, for example, are able to shown the "bring back" because the * option is explicitly defined in blog_page_type_list(), but others, like note|tags_page_type_list()... don't have that option. IMO the laters are the correct ones, i.e. I'd take rid of the option in blog ASAP if the rationally in 1..3 has sense for you.

Eloy Lafuente (stronk7)
added a comment - 04/Dec/11 7:26 PM - edited Re: about all the blog/notes/tags... blocks:
ALL them are system context.
Do we really want to be able to send back one block from those pages to the "system template"? I really don't get the point about at. If somebody wants to create one block for all the blog pages or tag pages... why not, simply create it there? Creating it in the front-page as a system-wide block, just to "take/capture it" in the blog or tags page seems unnatural. More yet, I'm not sure if all the blocks available for those pages are suitable to be used out from those pages.
The "bring-back" feature was thought to effectively return the block to its original (parent) context, hence it only applies for system => coursecat => course => module, but not for system => system.
Blogs, for example, are able to shown the "bring back" because the * option is explicitly defined in blog_page_type_list(), but others, like note|tags_page_type_list()... don't have that option. IMO the laters are the correct ones, i.e. I'd take rid of the option in blog ASAP if the rationally in 1..3 has sense for you.
Ciao

admin/lib.php: correct Is the one introduced conditionally by MDL-30566 to be able to 'bring back' blocks from subcontexts to coursecat.

blog/lib.php: wrong As commented right above, it's a system => system situation. We should not allow to send it back to "system-template".

course/lib.php: wrong It only should be shown if currencontext is course. If is one block being edited @ subcontext, the 'bring-back' (MDL-30565) will add it at the end.

course/report: wrong It's exactly the same thing that the blog/notes/tags... so no way to have the '*' defined on them. Only if the block is being edited on subcontext the 'bring-back' will be shown.

lib/blocklib.php: wrong One of the uses is ok (the 'bring-back feature itself'), the other is incorrect (see default_page_type_list()). Same logic than course. The "any-page" should be shown only if editing at currentcontext (and show it on top). Else the 'bring-back' feature will show it the last.

report/: *wrong. Only the 'bring-back' (@ last position) should show the "any-page". No sense if not.

Summary:

#) Take rid of the harcoded 'page-x' options @ blog and reports. It only should be shown when the 'bring-back' feature inserts it at the end.
#) At course/lib and default_page_type_list(), modify the use, so 'page-x' is only added (on top) if editing @ currentcontext = parentcontext. Else, the 'bring-back' feature will insert it (bottom).

Eloy Lafuente (stronk7)
added a comment - 04/Dec/11 8:23 PM - edited Simple grep:
grep -r "get_string('page-x', 'pagetype" *
admin/lib.php: '*' => get_string('page-x', 'pagetype')
blog/lib.php: '*'=>get_string('page-x', 'pagetype'),
course/lib.php: return array('*'=>get_string('page-x', 'pagetype'));
course/lib.php: return array('*'=>get_string('page-x', 'pagetype'),
course/report/lib.php: '*' => get_string('page-x', 'pagetype'),
lib/blocklib.php: $patterns['*'] = get_string('page-x', 'pagetype');
lib/blocklib.php: $patterns['*'] = get_string('page-x', 'pagetype');
report/completion/lib.php: => get_string('page-x', 'pagetype'),
report/log/lib.php: '*' => get_string('page-x', 'pagetype'),
report/outline/lib.php: '*' => get_string('page-x', 'pagetype'),
report/participation/lib.php: '*' => get_string('page-x', 'pagetype'),
report/progress/lib.php: '*' => get_string('page-x', 'pagetype'),
report/stats/lib.php: '*' => get_string('page-x', 'pagetype'),
admin/lib.php: correct Is the one introduced conditionally by MDL-30566 to be able to 'bring back' blocks from subcontexts to coursecat.
blog/lib.php: wrong As commented right above, it's a system => system situation. We should not allow to send it back to "system-template".
course/lib.php: wrong It only should be shown if currencontext is course. If is one block being edited @ subcontext, the 'bring-back' ( MDL-30565 ) will add it at the end.
course/report: wrong It's exactly the same thing that the blog/notes/tags... so no way to have the '*' defined on them. Only if the block is being edited on subcontext the 'bring-back' will be shown.
lib/blocklib.php: wrong One of the uses is ok (the 'bring-back feature itself'), the other is incorrect (see default_page_type_list()). Same logic than course. The "any-page" should be shown only if editing at currentcontext (and show it on top). Else the 'bring-back' feature will show it the last.
report/ : *wrong . Only the 'bring-back' (@ last position) should show the "any-page". No sense if not.
Summary:
#) Take rid of the harcoded 'page-x' options @ blog and reports. It only should be shown when the 'bring-back' feature inserts it at the end.
#) At course/lib and default_page_type_list(), modify the use, so 'page-x' is only added (on top) if editing @ currentcontext = parentcontext. Else, the 'bring-back' feature will insert it (bottom).
Ciao

Eloy Lafuente (stronk7)
added a comment - 05/Dec/11 12:13 AM Note: I've created MDL-30574 about to discuss how system => system "bring-backs" should work and where the "any-page" option should be available. For after release.

Eloy Lafuente (stronk7)
added a comment - 05/Dec/11 1:36 AM Oki, back to this issue, recent chat copy/paste (slightly edited):
[16:26:30] <stronk7> there are 3 contexts to pick:
* system
* frontpage only
* frontpage all added
[16:26:31] <stronk7> tell me which hidden page-types go for each one
[16:26:39] <Martin Dougiamas (HQ)> *, site-index, *
[16:26:54] <stronk7> that and only that, 100%
[16:27:02] <stronk7> forever
[16:27:15] <Martin Dougiamas (HQ)> but for the middle one, note that "*" === "site-index" because it's the only pagetype in that context
[16:27:24] <stronk7> for now, yes
[16:27:28] <Martin Dougiamas (HQ)> for now, yes
[16:27:41] <stronk7> okidoki... I'll try
So I'm assuming that:
picking system sets the context to system, recursively and with page-type set to "*"
frontpage only sets the context to site-course, non-recursively and with page-type set to "site-index"
frontpage all added sets the context to site-course, recursively and with paget-type set to "*"
The wording for 3) is incorrect, should be something like "All activities in front-page" or so.
all this is only valid when editing one block in frontpage and must not apply anything extra when one block is edited in any other page.
Trying it on top of David's patch. Ciao

Please read the complete commit messages and the comments in code, they try to explain and reference all the important points.

Note that the only missing thing to consider and to add es the 4) above: think about a better wording for the "frontpage-all" (with subcontexts) page-contexts setting. Current "Display on the front page and any pages added to the front page" is not intuitive at all!

Testing should include:

Create block @ frontpage, playing with the 3 possible page contexts (system, frontpage only and frontpage-all).

Review all the rest of system-wide pages (my template, userprofile template, blogs, tags, notes), both with own defined blocks and inherited from frontpage's system-wide.

Review all the rest of contexts (course category, course, module), both with own defined blocks and inherited from all parent contexts.

The only annoyances detected should be:

MDL-30564 - Separate course-categories admin interface and normal usage (varying pagetypes problem). It shows, when editing, "admin-xxx", and should be "coursecat xxxx", but it's not fixable until we solve the duality and apply correctly on each page-type.

MDL-30574 - Delete some incorrect "any page" options that should not exist (or add some missing ones, to decide in that issue). This is leading to some small inconsistencies in system => system inheritance (that IMO should be 100% forbidden, with each page showing its own pagetypes, but others may think the opposite and enable the "bring back" feature to all them).

Eloy Lafuente (stronk7)
added a comment - 05/Dec/11 8:43 AM - edited Oki, here it is the patch reducing options as much as possible, following the points above:
https://github.com/stronk7/moodle/compare/master...MDL-30340-sticky-blocks_simplify_frontpage_ui
And the super-complete patch, including both the one above and the 2 subtasks is:
https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus
That continues applying clean to 21_STABLE:
https://github.com/stronk7/moodle/compare/MOODLE_21_STABLE...MDL-30340.totus_tuus_21
Please read the complete commit messages and the comments in code, they try to explain and reference all the important points.
Note that the only missing thing to consider and to add es the 4) above: think about a better wording for the "frontpage-all" (with subcontexts) page-contexts setting. Current "Display on the front page and any pages added to the front page" is not intuitive at all!
Testing should include:
Create block @ frontpage, playing with the 3 possible page contexts (system, frontpage only and frontpage-all).
Review all the rest of system-wide pages (my template, userprofile template, blogs, tags, notes), both with own defined blocks and inherited from frontpage's system-wide.
Review all the rest of contexts (course category, course, module), both with own defined blocks and inherited from all parent contexts.
The only annoyances detected should be:
MDL-30564 - Separate course-categories admin interface and normal usage (varying pagetypes problem). It shows, when editing, "admin-xxx", and should be "coursecat xxxx", but it's not fixable until we solve the duality and apply correctly on each page-type.
MDL-30574 - Delete some incorrect "any page" options that should not exist (or add some missing ones, to decide in that issue). This is leading to some small inconsistencies in system => system inheritance (that IMO should be 100% forbidden, with each page showing its own pagetypes, but others may think the opposite and enable the "bring back" feature to all them).
And that's all. Please, review, review, review and test, test, test... ciao

Things look good to me.
I've been playing with this for the past hour and can't really fault it.
The only thing that I did note was that if you added a user added a block to their profile page, and then moved it to their my moodle page there was no way to get it back.
I've just had a look at the code as well, everything looks good there.

Sam Hemelryk
added a comment - 05/Dec/11 10:27 AM Hi Eloy,
Things look good to me.
I've been playing with this for the past hour and can't really fault it.
The only thing that I did note was that if you added a user added a block to their profile page, and then moved it to their my moodle page there was no way to get it back.
I've just had a look at the code as well, everything looks good there.
Cheers
Sam

Martin Dougiamas
added a comment - 05/Dec/11 1:15 PM Regression: page contexts for blocks are being set to front page course after any edit, even if the block is being added to another course or an activity.

Eloy Lafuente (stronk7)
added a comment - 05/Dec/11 5:42 PM - edited So should I self-integrate and auto-pass (MD as tester) and begin rolling 2.2 ?
Or do you want anybody else to follow the standard complete steps?
And 21_STABLE ? new issue for it or integrate too?
Ciao

Perhaps I misunderstood the way that this patch works, but I am experiencing the following problem, both on my local installation and on demo.moodle.org:

If I place a block on Site Administration > Appearance > Default My Moodle page, that block never appears on the My home page of any users on the site. This behavior, at least, seemed to work semi-correctly before the patch. So how does the Default My Moodle page now work? Does it do anything?

John Lynch
added a comment - 15/Feb/12 5:09 AM Perhaps I misunderstood the way that this patch works, but I am experiencing the following problem, both on my local installation and on demo.moodle.org:
If I place a block on Site Administration > Appearance > Default My Moodle page, that block never appears on the My home page of any users on the site. This behavior, at least, seemed to work semi-correctly before the patch. So how does the Default My Moodle page now work? Does it do anything?

Will 2.2 upgrade fix this specific issue? ..We have Moodle 2.1.3 and when I add the 'People' block to the Front page and select 'Display throughout the entire site' then go to a course page and edit the block and change page types to be 'Any type of course main page' it jumps back to 'Any Page' after I save it. We want to have the 'People' block on all course main pages only (not site pages as well). We want this without having to add it manually to all courses as this block got wiped out completely from all courses during our upgrade from 1.9.13
If this issue fixes the problem then can we add a patch to our 2.1.3 instance or do we have to upgrade to 2.2? Some advice would be appreciated.
Regards,
Yvonne

Yvonne Hamilton
added a comment - 20/Mar/12 11:48 AM Will 2.2 upgrade fix this specific issue? ..We have Moodle 2.1.3 and when I add the 'People' block to the Front page and select 'Display throughout the entire site' then go to a course page and edit the block and change page types to be 'Any type of course main page' it jumps back to 'Any Page' after I save it. We want to have the 'People' block on all course main pages only (not site pages as well). We want this without having to add it manually to all courses as this block got wiped out completely from all courses during our upgrade from 1.9.13
If this issue fixes the problem then can we add a patch to our 2.1.3 instance or do we have to upgrade to 2.2? Some advice would be appreciated.
Regards,
Yvonne

Hi, I just encountered an error when I tried to edit settings on a courses block that I had set to appear on any page. The error was: Either course id or category must be specified This block (id=24) does not exist on this page (http://tim.moodle.local/moodle/).

Test steps:
1. Add a courses block to the course page.
2. Navigate to a sub page and set the block to appear on any page.
3. Navigate to edit course settings page and click the edit icon on the courses block.

Tim Barker
added a comment - 09/May/12 12:36 PM - edited Hi, I just encountered an error when I tried to edit settings on a courses block that I had set to appear on any page. The error was: Either course id or category must be specified This block (id=24) does not exist on this page ( http://tim.moodle.local/moodle/ ).
I accessed the course block settings via the edit course settings page.
Test steps:
1. Add a courses block to the course page.
2. Navigate to a sub page and set the block to appear on any page.
3. Navigate to edit course settings page and click the edit icon on the courses block.
Expected result:
Edit course settings, changes cancelled and system displays edit block settings.
Actual result:
Exception is thrown. "Either course id or category must be specified This block (id=24) does not exist on this page ( http://tim.moodle.local/moodle/ )."
I'm on integration/master

It appears that this exception is thrown on this page regardless of what type of block it is. I also noticed that the block, I am currently using an HTML block, doesn't appear on "any page". It's still stuck under the course context even though it's set to appear on "any page"!

Tim Barker
added a comment - 09/May/12 12:42 PM - edited It appears that this exception is thrown on this page regardless of what type of block it is. I also noticed that the block, I am currently using an HTML block, doesn't appear on "any page". It's still stuck under the course context even though it's set to appear on "any page"!

Tim Barker
added a comment - 09/May/12 1:38 PM Created 3 new QA tests for this MDLQA-1545 , MDLQA-1546 and MDLQA-1547 as subs of MDLQA-1 master copy. If anyone has the chance to review these for me then please let me know if more are required.