Moodle
  1. Moodle
  2. MDL-27122

The Settings block shows up two times on the Front Page without the option to remove any of them

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.0.5, 2.1.2
    • Component/s: Blocks, Usability
    • Labels:
    • Environment:
      Ubuntu Server 10.10 64 bit
      MySQL 5.1.49.1.8.1
      PHP Version 5.3.3-1ubuntu9.3
    • Database:
      MySQL
    • Testing Instructions:
      Hide

      add several instances of settings block:
      1. Go to settings of 'settings' block on the front page and make it appear only on front page
      2. Go to the course page and add a settings block
      3. Go to the front page and make settings block visible on all pages

      -now you have two settings blocks on the course page-

      4. Enter the edit mode. Ensure that you have the delete link for the settings block that appears on the course page and do not have it for the main page block.
      5. Open Site Administration->Plugins->Blocks->Manage blocks and unprotect settings block.
      6. Go back to the course page and make sure that now you are able to delete any instance of settings block

      Show
      add several instances of settings block: 1. Go to settings of 'settings' block on the front page and make it appear only on front page 2. Go to the course page and add a settings block 3. Go to the front page and make settings block visible on all pages - now you have two settings blocks on the course page - 4. Enter the edit mode. Ensure that you have the delete link for the settings block that appears on the course page and do not have it for the main page block. 5. Open Site Administration->Plugins->Blocks->Manage blocks and unprotect settings block. 6. Go back to the course page and make sure that now you are able to delete any instance of settings block
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE
    • Pull Master Branch:
      wip-MDL-27122-master
    • Rank:
      16763

      Description

      I really don't know how we managed to get the Settings block twice on the Front Page. We removed the Settings block because we did not want it in some courses.

      We realized that configuring for example the role assignement for other block relies on the Settings block being sticky through the whole Moodle site so we put it back.

      In my opinion having the Settings block sticky on the whole site is wrong because it takes away the possibility to for the users to decide 100% how their Moodle site should look. On the other hand making the Settings block sticky with the option to remove it sabotages your site because it makes some changes impossible to accomplish.

      I would prefere some changes, when the Settings block is needed to configure Moodle it should be included ad hoc.

        Issue Links

          Activity

          Hide
          Michael Blake added a comment -

          This issue is reported as causing problems for a MP. Please give it priority.

          Show
          Michael Blake added a comment - This issue is reported as causing problems for a MP. Please give it priority.
          Hide
          Helen Foster added a comment -

          Alex, thanks for your report.

          In order to investigate this issue, we need to be able to reproduce it. Please could you try on http://demo.moodle.net to reproduce the problem then write down exactly what you did.

          Show
          Helen Foster added a comment - Alex, thanks for your report. In order to investigate this issue, we need to be able to reproduce it. Please could you try on http://demo.moodle.net to reproduce the problem then write down exactly what you did.
          Hide
          Chris Follin added a comment -

          Hi, Helen. One of our clients reported to us that their front page has three instances of the Settings block and they can't delete any of them. They can hide two of the three, which has had to suffice until a fix is in place, but they can't fully remove any. I haven't been able to reproduce the issue on the front page specifically but I can reproduce it easily on just about any other page.

          1. On the front page of a site, edit the Settings block config so that it appears on the front page only.
          2. Go to a course page and manually add the Settings block via the "Add a block" block.
          3. Note that once you've manually added this Settings block, there's no red X icon to remove it.
          4. Go back to the front page of the site, edit the Settings block config again so that it appears throughout the site. (As if you changed your mind about step 1.)
          5. Return to the same course page from step 2. You now have two Settings blocks in the course and can't remove either one.

          The expected behavior is that the block that was added manually in step 2 should be removable like any other type of block. Even if a user does not complete steps 4 and 5 above to have two instances of the block, they may still want to remove the block at step 3.

          Show
          Chris Follin added a comment - Hi, Helen. One of our clients reported to us that their front page has three instances of the Settings block and they can't delete any of them. They can hide two of the three, which has had to suffice until a fix is in place, but they can't fully remove any. I haven't been able to reproduce the issue on the front page specifically but I can reproduce it easily on just about any other page. 1. On the front page of a site, edit the Settings block config so that it appears on the front page only. 2. Go to a course page and manually add the Settings block via the "Add a block" block. 3. Note that once you've manually added this Settings block, there's no red X icon to remove it. 4. Go back to the front page of the site, edit the Settings block config again so that it appears throughout the site. (As if you changed your mind about step 1.) 5. Return to the same course page from step 2. You now have two Settings blocks in the course and can't remove either one. The expected behavior is that the block that was added manually in step 2 should be removable like any other type of block. Even if a user does not complete steps 4 and 5 above to have two instances of the block, they may still want to remove the block at step 3.
          Hide
          Alex Contis added a comment -

          Hi,

          I can confirm the procedure to get two "Settings" blocks described by Chris Follin.

          A quick way to add many "Settings" blocks to the Frontpage is to select "Configuration" for the "Settings" block, in "Add a block" select "Settings" and "Save changes". Now you have at least two "Settings" blocks.

          I know that's not how it supposed to be used but nonetheless if you manage somehow to get more than one block it's hard to get rid of them. It would be desirable to have some checks that make sure you won't get more than one block of the same kind showing up.

          In my opinion the Settings block should be shown automatically whenever needed to configure an activity or some other option in Moodle. Relying it to be sticky through the whole Moodle site propagating from the Frontpage makes it error prone because people WILL sometimes delete it at the course level or higher up in the hierarchy making it hard or impossible to configure anything.

          At least make it possible to delete it like any other block. You can always put it back later

          Show
          Alex Contis added a comment - Hi, I can confirm the procedure to get two "Settings" blocks described by Chris Follin. A quick way to add many "Settings" blocks to the Frontpage is to select "Configuration" for the "Settings" block, in "Add a block" select "Settings" and "Save changes". Now you have at least two "Settings" blocks. I know that's not how it supposed to be used but nonetheless if you manage somehow to get more than one block it's hard to get rid of them. It would be desirable to have some checks that make sure you won't get more than one block of the same kind showing up. In my opinion the Settings block should be shown automatically whenever needed to configure an activity or some other option in Moodle. Relying it to be sticky through the whole Moodle site propagating from the Frontpage makes it error prone because people WILL sometimes delete it at the course level or higher up in the hierarchy making it hard or impossible to configure anything. At least make it possible to delete it like any other block. You can always put it back later
          Hide
          Sam Hemelryk added a comment -

          Hi guys,

          A bit of background about this issue.
          When the navigation and settings blocks were first implemented we ran into the problem of people deleting these blocks and then complaining that they couldn't work out how to get them back as at the same time we were removing the turn editing on buttons from the navbar.
          At the time we did this by adding a config settings undeletableblocktypes which defaults as follows:

          $CFG->undeletableblocktypes = 'navigation,settings';
          

          Essentially overriding this setting within your config.php allows you set the blocks that are and aren't deletable.

          However this keeps coming up over and over again and I'm really beginning to think more needs to be done.
          As such the following are solutions that come to mind.

          1. On the manage blocks page in the admin add a setting to enable or disable the ability to delete blocks and default it to not allow navigation and settings blocks to be deleted.
          2. Convert undeletableblocktypes to a proper setting, a multiselect that users could select blocks within that would then not be deletable.
          3. Find some way to distinguish blocks added by the user from blocks added by the system and then only enforce undeletableblocktypes only on blocks added by the user.

          Personally my vote is for option 1.
          Please let me know what you think or if you see any other options you'd rather see implemented.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi guys, A bit of background about this issue. When the navigation and settings blocks were first implemented we ran into the problem of people deleting these blocks and then complaining that they couldn't work out how to get them back as at the same time we were removing the turn editing on buttons from the navbar. At the time we did this by adding a config settings undeletableblocktypes which defaults as follows: $CFG->undeletableblocktypes = 'navigation,settings'; Essentially overriding this setting within your config.php allows you set the blocks that are and aren't deletable. However this keeps coming up over and over again and I'm really beginning to think more needs to be done. As such the following are solutions that come to mind. On the manage blocks page in the admin add a setting to enable or disable the ability to delete blocks and default it to not allow navigation and settings blocks to be deleted. Convert undeletableblocktypes to a proper setting, a multiselect that users could select blocks within that would then not be deletable. Find some way to distinguish blocks added by the user from blocks added by the system and then only enforce undeletableblocktypes only on blocks added by the user. Personally my vote is for option 1. Please let me know what you think or if you see any other options you'd rather see implemented. Cheers Sam
          Hide
          Chris Follin added a comment -

          Sam, thank you for the background info. Option 3 sounds like it would be confusing to users who might not understand why they can delete a block in some cases but not others. Options 1 and 2 are very similar and I'm not entirely sure how they're different, so I guess my vote would be for a combination of 1 and 2.

          However, does this solve the issue of a user making the Settings block deletable, removing it, and then not being able to add it back? With Settings gone, they wouldn't be able to get back to the block settings page either unless they navigate directly to the URL, right?

          Show
          Chris Follin added a comment - Sam, thank you for the background info. Option 3 sounds like it would be confusing to users who might not understand why they can delete a block in some cases but not others. Options 1 and 2 are very similar and I'm not entirely sure how they're different, so I guess my vote would be for a combination of 1 and 2. However, does this solve the issue of a user making the Settings block deletable, removing it, and then not being able to add it back? With Settings gone, they wouldn't be able to get back to the block settings page either unless they navigate directly to the URL, right?
          Hide
          Marina Glancy added a comment -

          There is new functionality in "Manage blocks" page, allowing administrator to view the list of block instances and delete any of them. It solves the problem with undeletable block instances, although it is still possible to end up with several 'settings' blocks on one page (see "testing instructions").
          The course search is removed from "Manage blocks". It was inaccurate because it listed neither instances on non-course pages, nor the instances that are located on the course pages other than course front page.

          For previous versions you can do the following:
          open config.php and add a line
          $CFG->undeletableblocktypes = '';
          Then go to the site and you will see that you are now able to delete instances of 'settings' block.
          Later you can remove the line in config.php or set it to the default value:
          $CFG->undeletableblocktypes = 'navigation,settings';

          Show
          Marina Glancy added a comment - There is new functionality in "Manage blocks" page, allowing administrator to view the list of block instances and delete any of them. It solves the problem with undeletable block instances, although it is still possible to end up with several 'settings' blocks on one page (see "testing instructions"). The course search is removed from "Manage blocks". It was inaccurate because it listed neither instances on non-course pages, nor the instances that are located on the course pages other than course front page. For previous versions you can do the following: open config.php and add a line $CFG->undeletableblocktypes = ''; Then go to the site and you will see that you are now able to delete instances of 'settings' block. Later you can remove the line in config.php or set it to the default value: $CFG->undeletableblocktypes = 'navigation,settings';
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Ho,

          I'm not confident about the proposed patch as far as it seems not able to scale properly (imagine 1000 instances of any block).

          Couldn't we, alternatively allow inline configuration / deletion by checking if the block is in $CFG->undeletableblocktypes and has pagetypepattern = '*' or so? Obviously allowing the $CFG->undeletableblocktypes in the UI.

          That way, only blocks defined as undeleteable and having * would be "protected" and all the others would be editable in an "inline" (standard) way. And, at last resort, if something has gone wrong... $CFG->undeletableblocktypes would be editable from the UI and then the block would become deletable. Much your 2) option above but adding the pagetypepattern = '*'. All the rest, 100% editable and deletable.

          Basically, I don't like special UIs for doing something the standard UI should be able to handle, more yet, if it can be scaling badly.

          Perhaps time for another think-round? My 2 cents, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Ho, I'm not confident about the proposed patch as far as it seems not able to scale properly (imagine 1000 instances of any block). Couldn't we, alternatively allow inline configuration / deletion by checking if the block is in $CFG->undeletableblocktypes and has pagetypepattern = '*' or so? Obviously allowing the $CFG->undeletableblocktypes in the UI. That way, only blocks defined as undeleteable and having * would be "protected" and all the others would be editable in an "inline" (standard) way. And, at last resort, if something has gone wrong... $CFG->undeletableblocktypes would be editable from the UI and then the block would become deletable. Much your 2) option above but adding the pagetypepattern = '*'. All the rest, 100% editable and deletable. Basically, I don't like special UIs for doing something the standard UI should be able to handle, more yet, if it can be scaling badly. Perhaps time for another think-round? My 2 cents, ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          I'm reopening this, IMO it needs one more round before implement final solution.

          Show
          Eloy Lafuente (stronk7) added a comment - I'm reopening this, IMO it needs one more round before implement final solution.
          Hide
          Marina Glancy added a comment -

          I agree with you, Eloy. Wish you were at our scrum yesterday when we discussed my solution.
          The changes that I have already made are moved to the new task MDL-28296

          Show
          Marina Glancy added a comment - I agree with you, Eloy. Wish you were at our scrum yesterday when we discussed my solution. The changes that I have already made are moved to the new task MDL-28296
          Hide
          Marina Glancy added a comment -

          Added settings page:
          Site Administration->Plugins->Blocks->Blocks appearance
          that allows to choose which blocks should be undeletable in the site-wide context.

          "Undeletable blocks" are now still "deletable" if added to course pages or actually any pages except the site index

          Removed $CFG->undeletableblocktypes from config-dist.php, because it is now "proper setting"

          Show
          Marina Glancy added a comment - Added settings page: Site Administration->Plugins->Blocks->Blocks appearance that allows to choose which blocks should be undeletable in the site-wide context. "Undeletable blocks" are now still "deletable" if added to course pages or actually any pages except the site index Removed $CFG->undeletableblocktypes from config-dist.php, because it is now "proper setting"
          Hide
          Marina Glancy added a comment -

          It's up to integrators to decide whether this change needs to be pushed to the previous versions. There is still a workaround with setting the
          $CFG->undeletableblocktypes in config.php

          Show
          Marina Glancy added a comment - It's up to integrators to decide whether this change needs to be pushed to the previous versions. There is still a workaround with setting the $CFG->undeletableblocktypes in config.php
          Hide
          Petr Škoda added a comment -
          if (is_array($CFG->undeletableblocktypes)) {
          

          is causing notices during upgrade/install, I do not understand the rest of the talk here...

          Show
          Petr Škoda added a comment - if (is_array($CFG->undeletableblocktypes)) { is causing notices during upgrade/install, I do not understand the rest of the talk here...
          Hide
          Marina Glancy added a comment -

          Petr, what kind of notice? I can not reproduce it.

          Show
          Marina Glancy added a comment - Petr, what kind of notice? I can not reproduce it.
          Hide
          Marina Glancy added a comment -
          • fixed possible notice
          • corrected extra whitespace and typo
          Show
          Marina Glancy added a comment - fixed possible notice corrected extra whitespace and typo
          Hide
          Sam Hemelryk added a comment -

          Hi Marina,
          Thanks for the work on this.
          I'm sending this back around again this week so that a couple of minor things can be fixed up:

          1. For the setting each block checkbox should be using the pluginname string rather than just printing out the block name.
          2. Calling this page 'Blocks appearance' feels wrong to me, and I think it should be renamed to block settings. Really this undeletable blocks option is a general block system setting and has little to do with the appearance of blocks. Renaming to block settings would also be more consistent with how we have called other general settings pages in the admin tree. Once this is done things like default blocks and other general block settings that can be overridden in the config for a site could also be converted to proper UI settings.

          To be truthful I'm not sure this setting should have it's own page, it would perhaps be better as a column in the manage blocks table or down the bottom of that page... although that is just my personal opinion and I'm not working on this task - I'd stick with what ever you are happy with.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Marina, Thanks for the work on this. I'm sending this back around again this week so that a couple of minor things can be fixed up: For the setting each block checkbox should be using the pluginname string rather than just printing out the block name. Calling this page 'Blocks appearance' feels wrong to me, and I think it should be renamed to block settings. Really this undeletable blocks option is a general block system setting and has little to do with the appearance of blocks. Renaming to block settings would also be more consistent with how we have called other general settings pages in the admin tree. Once this is done things like default blocks and other general block settings that can be overridden in the config for a site could also be converted to proper UI settings. To be truthful I'm not sure this setting should have it's own page, it would perhaps be better as a column in the manage blocks table or down the bottom of that page... although that is just my personal opinion and I'm not working on this task - I'd stick with what ever you are happy with. Cheers Sam
          Hide
          Marina Glancy added a comment -

          The settings for undeletableblocktypes is done on page Administration->Plugins->Blocks->Manage blocks.
          Administrator can protect instances of some block types from being deleted (but only if they were added to site-wide context).

          Show
          Marina Glancy added a comment - The settings for undeletableblocktypes is done on page Administration->Plugins->Blocks->Manage blocks. Administrator can protect instances of some block types from being deleted (but only if they were added to site-wide context).
          Hide
          Sam Hemelryk added a comment -

          Thanks Marina - this has been integrated now

          Show
          Sam Hemelryk added a comment - Thanks Marina - this has been integrated now
          Hide
          Rajesh Taneja added a comment -

          Works Great
          Thanks for fixing this Marina

          Show
          Rajesh Taneja added a comment - Works Great Thanks for fixing this Marina
          Hide
          Alex Contis added a comment -

          Thank you for fixing this!

          Show
          Alex Contis added a comment - Thank you for fixing this!
          Hide
          Tim Hunt added a comment -

          Just to say, I created a follow-up issue MDL-35964 where I propose we change how this feature is implemented.

          Show
          Tim Hunt added a comment - Just to say, I created a follow-up issue MDL-35964 where I propose we change how this feature is implemented.

            People

            • Votes:
              11 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: