Moodle
  1. Moodle
  2. MDL-31616

"Page Contexts" setting not being stored on block settings page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1.4, 2.2, 2.3, 2.4, 2.5
    • Fix Version/s: 2.3.5, 2.4.2
    • Component/s: Blocks
    • Labels:
    • Testing Instructions:
      Hide

      1. Create a category
      2. Create a course underneath the category
      3. View the category and turn editing on
      4. Add a block that includes the "page contexts" setting (e.g. HTML block)
      5. Edit the settings and change the setting "page contexts" to the 2nd option ("Display on category:[category name] and any pages within it").
      6. Save settings
      7. Re-edit settings - previously set page context still be set.

      Also, verify that there are no regressions when editing blocks elsewhere. Test changing this setting for blocks in all sorts of contexts:
      a. Front page
      b. Admin notifications (system context)
      c. Course category page (done above!)
      d. Course page
      e. Module page
      f. User profile page

      Show
      1. Create a category 2. Create a course underneath the category 3. View the category and turn editing on 4. Add a block that includes the "page contexts" setting (e.g. HTML block) 5. Edit the settings and change the setting "page contexts" to the 2nd option ("Display on category: [category name] and any pages within it"). 6. Save settings 7. Re-edit settings - previously set page context still be set. Also, verify that there are no regressions when editing blocks elsewhere. Test changing this setting for blocks in all sorts of contexts: a. Front page b. Admin notifications (system context) c. Course category page (done above!) d. Course page e. Module page f. User profile page
    • Workaround:
      Hide

      Go into the database and manually edit the table "block_instances" changing the field "showinsubcontexts" from 0 to 1, or vice versa.

      Show
      Go into the database and manually edit the table "block_instances" changing the field "showinsubcontexts" from 0 to 1, or vice versa.
    • Affected Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE, MOODLE_23_STABLE, MOODLE_24_STABLE, MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_23_STABLE, MOODLE_24_STABLE
    • Pull from Repository:
    • Pull Master Branch:
    • Rank:
      38185

      Description

      On a clean install of Moodle 2.2.1+ / 2.1.4+:

      1. Create a category
      2. Create a course underneath the category
      3. View the category and turn editing on
      4. Add a block that includes the "page contexts" setting (e.g. HTML block)
      5. Edit the settings and change the setting "page contexts" to the 2nd option ("Display on category:[category name] and any pages within it").
      6. Save settings
      7. Re-edit settings - previously set page context will not have been stored.

      This is true for upgraded installations - the setting will retain whatever it was set to before the upgrade, and will ignore any changes to the setting.

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting that.

          There has been recent work on the context settings of blocks (see linked issue), but I'm not sure they're related.

          Show
          Michael de Raadt added a comment - Thanks for reporting that. There has been recent work on the context settings of blocks (see linked issue), but I'm not sure they're related.
          Hide
          Yolanda Ordoñez Rufat added a comment - - edited

          The problem is no matter what value you chose for "Page contexts" when editing a block in a category it doesn't make its way to the database. So the field "showinsubcontexts" is always set to 0. The responsible is the code in the function process_url_edit() in blocklib.php

          Note that the field "showinsubcontexts" is a bolean whit 0 or 1 values only

          I'm working on a fix and I will report back when done.

          Show
          Yolanda Ordoñez Rufat added a comment - - edited The problem is no matter what value you chose for "Page contexts" when editing a block in a category it doesn't make its way to the database. So the field "showinsubcontexts" is always set to 0. The responsible is the code in the function process_url_edit() in blocklib.php Note that the field "showinsubcontexts" is a bolean whit 0 or 1 values only I'm working on a fix and I will report back when done.
          Hide
          Lesli Smith added a comment - - edited

          Hi. I'm not sure how the fix is coming for this issue, but I'm seeing that contexts are not getting saved on my instance, either, particularly for blocks that I need to be available only on the front page. Let me know if there is anything yet that can be tested. Forgot to mention that I'm on 2.3.1 Thanks!

          Show
          Lesli Smith added a comment - - edited Hi. I'm not sure how the fix is coming for this issue, but I'm seeing that contexts are not getting saved on my instance, either, particularly for blocks that I need to be available only on the front page. Let me know if there is anything yet that can be tested. Forgot to mention that I'm on 2.3.1 Thanks!
          Hide
          Ian David Wild added a comment -

          Hi all,

          Regarding Moodle 2.2, I believe there is a line missing from /lib/blocklib.lib. After line 1220 (i.e. after a successful call to $mform->get_data() ) you need to insert:

          $bi->showinsubcontexts = $data->bui_contexts;

          Hope this helps,

          Ian.

          Show
          Ian David Wild added a comment - Hi all, Regarding Moodle 2.2, I believe there is a line missing from /lib/blocklib.lib. After line 1220 (i.e. after a successful call to $mform->get_data() ) you need to insert: $bi->showinsubcontexts = $data->bui_contexts; Hope this helps, Ian.
          Hide
          Mary Cooch added a comment -

          Adding newer versions as this issue still persists

          Show
          Mary Cooch added a comment - Adding newer versions as this issue still persists
          Hide
          Tim Hunt added a comment -

          I think Ian's analysis is right. However, the block editing UI code has got much more complex (and, I suppose user-friendly) than when I last looked. git blame credits some crazy hacker called Martin Dougiamas with that

          Anyway, I have made a patch, and I think it is safe, but really it needs a lot more testing.

          Show
          Tim Hunt added a comment - I think Ian's analysis is right. However, the block editing UI code has got much more complex (and, I suppose user-friendly) than when I last looked. git blame credits some crazy hacker called Martin Dougiamas with that Anyway, I have made a patch, and I think it is safe, but really it needs a lot more testing.
          Hide
          Dan Poltawski added a comment -

          Hmm, well trying to understand the code, it'd be clearer to me if we set it to true only if $data->bui_contexts != BUI_CONTEXTS_FRONTPAGE_ONLY. But thats because from the initial patch its not clear to me that we're trying to get the boolean value of it.

          TBH Tim I think you're the right person to understand if this is the right solution!

          Show
          Dan Poltawski added a comment - Hmm, well trying to understand the code, it'd be clearer to me if we set it to true only if $data->bui_contexts != BUI_CONTEXTS_FRONTPAGE_ONLY. But thats because from the initial patch its not clear to me that we're trying to get the boolean value of it. TBH Tim I think you're the right person to understand if this is the right solution!
          Hide
          Tim Hunt added a comment -

          Well, I understand the blocks back-end, but I don't necessarily understand how the settings UI is trying to present that to users. Oh well. At the very least I think with the change, the code is less buggy than it was, so it is better to integrate it. Submitting.

          Show
          Tim Hunt added a comment - Well, I understand the blocks back-end, but I don't necessarily understand how the settings UI is trying to present that to users. Oh well. At the very least I think with the change, the code is less buggy than it was, so it is better to integrate it. Submitting.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

          TIA and ciao

          Show
          Eloy Lafuente (stronk7) added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Integrated (23, 24 & master), thanks!

          To testers: Plz, specially test this carefully under all the fixed branches, TIA!

          Show
          Eloy Lafuente (stronk7) added a comment - Integrated (23, 24 & master), thanks! To testers: Plz, specially test this carefully under all the fixed branches, TIA!
          Hide
          Garry Edmonds added a comment -

          Hi,

          I tested this code that had been added into our universities test environment. We are running 2.3.2. The fix seemed to work, but then I had a problem with front page blocks that were set to display within courses. This is what I did to test the front page blocks:
          • Went to Moodle Home
          • Added a new HTML block
          • Edited the block, added a title and content and set Page contexts as “Display on all pages in <our> Moodle” and saved changes
          • Went to a course site and confirmed the block is visible – it was
          • Edited the block and set the “Display on page types” to “Any type of site main page” and saved changes
          • The block should have now only been visible on course main pages including the test one, but what actually happened is the block disappeared and I cannot find it.
          It could be that there is some other code in our test environment causing this problem (we don't have it in or production one) but I think it's worth testing

          Garry

          Show
          Garry Edmonds added a comment - Hi, I tested this code that had been added into our universities test environment. We are running 2.3.2. The fix seemed to work, but then I had a problem with front page blocks that were set to display within courses. This is what I did to test the front page blocks: • Went to Moodle Home • Added a new HTML block • Edited the block, added a title and content and set Page contexts as “Display on all pages in <our> Moodle” and saved changes • Went to a course site and confirmed the block is visible – it was • Edited the block and set the “Display on page types” to “Any type of site main page” and saved changes • The block should have now only been visible on course main pages including the test one, but what actually happened is the block disappeared and I cannot find it. It could be that there is some other code in our test environment causing this problem (we don't have it in or production one) but I think it's worth testing Garry
          Hide
          Adrian Greeve added a comment -

          The main test seems to work fine, but I tried out the problem that Garry mentioned and can confirm that this is a regression.
          It seems that if you make a site wide block; go into a course, module, or my moodle page; and then change the "Display on page types" to something else; that the block will disappear from all pages. (This doesn't happen on stable branches).

          Show
          Adrian Greeve added a comment - The main test seems to work fine, but I tried out the problem that Garry mentioned and can confirm that this is a regression. It seems that if you make a site wide block; go into a course, module, or my moodle page; and then change the "Display on page types" to something else; that the block will disappear from all pages. (This doesn't happen on stable branches).
          Hide
          Tim Hunt added a comment -

          The fact that Gary's steps cause problems on master, but not on stable branches, suggest to me that the problem is not related to this change. This issue makes the same one-line change on all branches.

          I don't understand what Gary is claiming as a problem. If you set “Any type of site main page” then that means pages in the front-page context. Therefore the block should not appear on "course main pages".

          It would be useful to know what gets written to the block_instances table in that case. (I will investigate later today if no-one beats me to it.)

          Show
          Tim Hunt added a comment - The fact that Gary's steps cause problems on master, but not on stable branches, suggest to me that the problem is not related to this change. This issue makes the same one-line change on all branches. I don't understand what Gary is claiming as a problem. If you set “Any type of site main page” then that means pages in the front-page context. Therefore the block should not appear on "course main pages". It would be useful to know what gets written to the block_instances table in that case. (I will investigate later today if no-one beats me to it.)
          Hide
          Tim Hunt added a comment -

          Here is the testing I did. (Sorry, this is a bit stream-of-conciousness.)

          1. Upgrade to integration/master.

          2. Go to site front page.

          3. Add a new HTML block.

          4. Edit the block. Block title: "MDL-31616 test", Content: "Hello world!", Page contexts: "Display throughout the entire site."

          5. Go into a course. The block appears.

          6. Go back to the site front page. Edit the block. Set Page contexts to "Display on the front page only"

          7. Block still appears on the front page. Block does not appear on the course page.

          8. Add a Page resource in the Main menu block. The block does not appear on that page.

          9. Go back to the site front page. Edit the block. Set Page contexts to "Display on the front page and any pages added to the front page"

          10. Block still appears on the front page. Block does not appear on the course page. The block does appear on the Page resource.

          11. Set the block back to Page contexts: "Display throughout the entire site."

          12. Go into the course, and edit the block. Set Display on page types: "Any type of course main page".

          13. Block does not appear on the front page . The block does not appear on the Page resource. Block does not appear on the course page.

          OK, so I finaly found the bug. Almost certinaly not caused by this change, but let us try to work it out.

          The course page is: General type: course. Context Course:

          {course name}

          (context id 14). Page type: course-view-weeks.

          The block instance row now has: parentcontext: 1, showinsubcontexts: 2, pagetypepattern: "course-view-*", subpagepattern: NULL.

          Aha! That 2 looks wrong. The big SQL query in load_blocks does bi.showinsubcontexts = 1 (rather than, say bi.showinsubcontexts <> 0) so this is why the block vanishes.

          Where did that 2 come from?

          Well, when you edit the block from the course page, we get

          <input type="hidden" value="2" name="bui_contexts">

          So where did that come from?

          Ah! the problem is the bit

                  } else if ($parentcontext->contextlevel == CONTEXT_SYSTEM) {
                      $mform->addElement('hidden', 'bui_contexts', BUI_CONTEXTS_ENTIRE_SITE);
          

          in blocks/edit_form.php. That constant is 2.

          I think the safest way to fix this is to change the new line of code I added from

          $bi->showinsubcontexts = $data->bui_contexts;
          

          to

          $bi->showinsubcontexts = (bool) $data->bui_contexts;
          

          That should ensure that only 0 or 1 is written to the database here.

          I will make a patch like that.

          Show
          Tim Hunt added a comment - Here is the testing I did. (Sorry, this is a bit stream-of-conciousness.) 1. Upgrade to integration/master. 2. Go to site front page. 3. Add a new HTML block. 4. Edit the block. Block title: " MDL-31616 test", Content: "Hello world!", Page contexts: "Display throughout the entire site." 5. Go into a course. The block appears. 6. Go back to the site front page. Edit the block. Set Page contexts to "Display on the front page only" 7. Block still appears on the front page. Block does not appear on the course page. 8. Add a Page resource in the Main menu block. The block does not appear on that page. 9. Go back to the site front page. Edit the block. Set Page contexts to "Display on the front page and any pages added to the front page" 10. Block still appears on the front page. Block does not appear on the course page. The block does appear on the Page resource. 11. Set the block back to Page contexts: "Display throughout the entire site." 12. Go into the course, and edit the block. Set Display on page types: "Any type of course main page". 13. Block does not appear on the front page . The block does not appear on the Page resource. Block does not appear on the course page. OK, so I finaly found the bug. Almost certinaly not caused by this change, but let us try to work it out. The course page is: General type: course. Context Course: {course name} (context id 14). Page type: course-view-weeks. The block instance row now has: parentcontext: 1, showinsubcontexts: 2, pagetypepattern: "course-view-*", subpagepattern: NULL. Aha! That 2 looks wrong. The big SQL query in load_blocks does bi.showinsubcontexts = 1 (rather than, say bi.showinsubcontexts <> 0) so this is why the block vanishes. Where did that 2 come from? Well, when you edit the block from the course page, we get <input type="hidden" value="2" name="bui_contexts"> So where did that come from? Ah! the problem is the bit } else if ($parentcontext->contextlevel == CONTEXT_SYSTEM) { $mform->addElement('hidden', 'bui_contexts', BUI_CONTEXTS_ENTIRE_SITE); in blocks/edit_form.php. That constant is 2. I think the safest way to fix this is to change the new line of code I added from $bi->showinsubcontexts = $data->bui_contexts; to $bi->showinsubcontexts = (bool) $data->bui_contexts; That should ensure that only 0 or 1 is written to the database here. I will make a patch like that.
          Hide
          Tim Hunt added a comment -

          Right, new commit https://github.com/timhunt/moodle/commit/c734771a8bfe286c0cb6fae06607d3324c9162a7 on the MDL-31616 branch. Please could you cherry-pick that to all stable branches too.

          I have re-tested (steps as in my previous comment) and this seems to fix things.

          Show
          Tim Hunt added a comment - Right, new commit https://github.com/timhunt/moodle/commit/c734771a8bfe286c0cb6fae06607d3324c9162a7 on the MDL-31616 branch. Please could you cherry-pick that to all stable branches too. I have re-tested (steps as in my previous comment) and this seems to fix things.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          New commit applied (cherry-pick) to the 3 branches, thanks! Sending back to testing.

          Show
          Eloy Lafuente (stronk7) added a comment - New commit applied (cherry-pick) to the 3 branches, thanks! Sending back to testing.
          Hide
          Adrian Greeve added a comment -

          Tested on 2.3, 2.4 and master.
          Everything worked for me with no errors.
          Test passed.

          Show
          Adrian Greeve added a comment - Tested on 2.3, 2.4 and master. Everything worked for me with no errors. Test passed.
          Hide
          Garry Edmonds added a comment -

          Our hosts have added the latest change to our UAT and I have retested it and the setting works and both the category and system blocks are displaying correctly. I'm testing on a modified Moodle so tests don't mean a lot, but I'm happy. Sorry about the confusion regarding “Any type of site main page” earlier. I forgot that we have a language customisation - it should have been "course".

          Thanks for working on this. These blocks are heavily used here.

          Show
          Garry Edmonds added a comment - Our hosts have added the latest change to our UAT and I have retested it and the setting works and both the category and system blocks are displaying correctly. I'm testing on a modified Moodle so tests don't mean a lot, but I'm happy. Sorry about the confusion regarding “Any type of site main page” earlier. I forgot that we have a language customisation - it should have been "course". Thanks for working on this. These blocks are heavily used here.
          Hide
          Dan Poltawski added a comment -

          Hurray! We did it! Thanks to all the reporters, testers, user and watchers for a bumper week of Moodling!

          Show
          Dan Poltawski added a comment - Hurray! We did it! Thanks to all the reporters, testers, user and watchers for a bumper week of Moodling!

            People

            • Votes:
              17 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: