Moodle
  1. Moodle
  2. MDL-21375

Create a way to easily and intuitively create system-wide sticky blocks in Moodle 2.0

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Administration, Blocks
    • Labels:
    • Affected Branches:
      MOODLE_20_STABLE
    • Rank:
      433

      Description

      In Moodle 1.9 we had a special admin page for this, but this doesn't fit into Moodle 2.0.

      In Moodle 2.0, the way you want to do this is by adding a block to the front page (which most people see as the "top" of the system) and then make it sticky "all the way down".

      The trouble is that there are two interpretations of this at the frontpage site level:
      1) All the activities in the front page course
      2) All the contexts in the whole site

      My solution is to just represent these two modes in the block config screen and let the user know the situation and decide.

      It's as simple as a menu with two options to replace the uneditable "This block belongs to" item and adding some help, so I won't bother with a mockup.

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          I've made the menu, but one problem remains.

          I wanted to make the blocks in the SYSTEM context by default, so that later if you flipped the sticky switch it worked like most people would expect. This is the patch to do that (not in CVS yet):

          Index: lib/blocklib.php
          ===================================================================
          RCS file: /cvsroot/moodle/moodle/lib/blocklib.php,v
          retrieving revision 1.233
          diff -r1.233 blocklib.php
          542c542,548
          <         $blockinstance->parentcontextid = $this->page->context->id;
          ---
          >         if ($this->page->context->contextlevel == CONTEXT_COURSE && $this->page->context->instanceid == SITEID) {
          >             // Exception: The default context for new blocks on the front page is SYSTEM
          >             $systemcontext = get_context_instance(CONTEXT_SYSTEM);
          >             $blockinstance->parentcontextid = $systemcontext->id;
          >         } else {
          >             $blockinstance->parentcontextid = $this->page->context->id;
          >         }
          

          The problem is that if you make the block a system block and NOT sticky then it no longer appears on the front page, so it disappears.

          I think the solution for this is to add a special case so that the front page ALWAYS show blocks from both SYSTEM and SITE, but I'd like some others to think about this first.

          Show
          Martin Dougiamas added a comment - I've made the menu, but one problem remains. I wanted to make the blocks in the SYSTEM context by default, so that later if you flipped the sticky switch it worked like most people would expect. This is the patch to do that (not in CVS yet): Index: lib/blocklib.php =================================================================== RCS file: /cvsroot/moodle/moodle/lib/blocklib.php,v retrieving revision 1.233 diff -r1.233 blocklib.php 542c542,548 < $blockinstance->parentcontextid = $ this ->page->context->id; --- > if ($ this ->page->context->contextlevel == CONTEXT_COURSE && $ this ->page->context->instanceid == SITEID) { > // Exception: The default context for new blocks on the front page is SYSTEM > $systemcontext = get_context_instance(CONTEXT_SYSTEM); > $blockinstance->parentcontextid = $systemcontext->id; > } else { > $blockinstance->parentcontextid = $ this ->page->context->id; > } The problem is that if you make the block a system block and NOT sticky then it no longer appears on the front page, so it disappears. I think the solution for this is to add a special case so that the front page ALWAYS show blocks from both SYSTEM and SITE, but I'd like some others to think about this first.
          Hide
          Tim Hunt added a comment -

          Great that someone is thinking about this. Thanks Martin.

          Actually, I'm not sure about the "In Moodle 1.9 we had a special admin page for this, but this doesn't fit into Moodle 2.0. " comment.

          We could make a special admin page, with some explanation and controls in the [MAIN CONTENT GOES HERE] place. The controls would let you set up the admin page to pretend to be any other page known to the system, and then let you edit the blocks there.

          Given a context we can find the right theme. We just don't have a list of all page types for a particular context. That is tricky. The simplest work-around is to get the list of page types by looking at what pages already have a block associated with them - so if the page you want is not showing up, then instructions would have to say "Go to that page, add a block, then try again."

          Anyway, I am not sure it works, but it is worth considering, because it lets us have more UI than we can afford to put on all pages when editing is on.

          Show
          Tim Hunt added a comment - Great that someone is thinking about this. Thanks Martin. Actually, I'm not sure about the "In Moodle 1.9 we had a special admin page for this, but this doesn't fit into Moodle 2.0. " comment. We could make a special admin page, with some explanation and controls in the [MAIN CONTENT GOES HERE] place. The controls would let you set up the admin page to pretend to be any other page known to the system, and then let you edit the blocks there. Given a context we can find the right theme. We just don't have a list of all page types for a particular context. That is tricky. The simplest work-around is to get the list of page types by looking at what pages already have a block associated with them - so if the page you want is not showing up, then instructions would have to say "Go to that page, add a block, then try again." Anyway, I am not sure it works, but it is worth considering, because it lets us have more UI than we can afford to put on all pages when editing is on.
          Hide
          Martin Dougiamas added a comment -

          Thanks Tim. I don't know if we need yet more UI for this though... We already have the in-place blocks editing interface which is known, works fine AFAIK and is WYSIWYG.

          The only question I really had was "should we show unsticky system blocks on the front page".

          Show
          Martin Dougiamas added a comment - Thanks Tim. I don't know if we need yet more UI for this though... We already have the in-place blocks editing interface which is known, works fine AFAIK and is WYSIWYG. The only question I really had was "should we show unsticky system blocks on the front page".
          Hide
          Tim Hunt added a comment -

          Did you see the exchange I had with Mary Cooch about this: http://moodle.org/mod/forum/discuss.php?d=140562 and http://moodle.org/mod/forum/discuss.php?d=140592 - that is, at least a little, input from a user.

          System context blocks on the front page it tricky. It will help people get started, but will make it harder for people to understand what is really going on.

          Of course, the other place we can add more explanation and help is on the block settings form.

          This needs serious thought, and I don't have any great inspiration at the moment.

          Show
          Tim Hunt added a comment - Did you see the exchange I had with Mary Cooch about this: http://moodle.org/mod/forum/discuss.php?d=140562 and http://moodle.org/mod/forum/discuss.php?d=140592 - that is, at least a little, input from a user. System context blocks on the front page it tricky. It will help people get started, but will make it harder for people to understand what is really going on. Of course, the other place we can add more explanation and help is on the block settings form. This needs serious thought, and I don't have any great inspiration at the moment.
          Hide
          Martin Dougiamas added a comment - - edited

          I have just realised that non-sticky system blocks are in fact generally pretty useless! That simplifies things a lot.

          At the moment I'm thinking that the block settings page for blocks added on the front page should work like this:

          1) Combine the context and sticky settings into one menu to choose:
          a) Show on the front page only
          b) Show on the front page (and all activities added to the front page)
          c) Show on the entire site

          2) Depending on the choice, set context and stickiness appropriately behind the scenes.

          Other contexts would be similar, except the menu would like like:

          a) Show on the 'My special course' page only
          b) Show on the 'My special course page' and all the pages inside it.

          How does that sound?

          Show
          Martin Dougiamas added a comment - - edited I have just realised that non-sticky system blocks are in fact generally pretty useless! That simplifies things a lot. At the moment I'm thinking that the block settings page for blocks added on the front page should work like this: 1) Combine the context and sticky settings into one menu to choose: a) Show on the front page only b) Show on the front page (and all activities added to the front page) c) Show on the entire site 2) Depending on the choice, set context and stickiness appropriately behind the scenes. Other contexts would be similar, except the menu would like like: a) Show on the 'My special course' page only b) Show on the 'My special course page' and all the pages inside it. How does that sound?
          Hide
          Martin Dougiamas added a comment -

          I've checked in some changes here. I think it's a big improvement.

          Next up: some explanation strings to supplement the nerdy page type regex strings ...

          Show
          Martin Dougiamas added a comment - I've checked in some changes here. I think it's a big improvement. Next up: some explanation strings to supplement the nerdy page type regex strings ...
          Hide
          Tim Hunt added a comment -

          Step in the right direction. Keep going.

          Show
          Tim Hunt added a comment - Step in the right direction. Keep going.
          Hide
          David Mudrak added a comment -

          I like the idea - it really makes the block setting more user friendly and intuitive. One comment regarding your commit http://git.moodle.cz/?a=commitdiff&p=moodle.git&h=0aed347fd1ce22c08de27e025ac61871ede0030f . Please let us not use string identifiers like in

          $string['*'] = 'Any page';
          $string['site-*'] = 'Any top-level site page';
          

          I am currently working on a proper strings file format specification and I will propose that only [a-z][0-9] ':' and '-' (minus sign) and maybe '_' (undersocre) are allowed. Generally, string identifiers should follow our convention for naming $variables - single lowercase word, no underscore. The colon ( sign can be used only in strings with the names of capabilities and nowhere else. The minus sign can be used only in string identifiers witch are partially computed, like in

          get_string('region-' . $regionid, 'theme_example');
          

          so that is a sign that we should be careful when trying to find an usage of such string in the code (which I need to do during English language pack massacre).

          Therefore, my proposal is to replace the two strings by proper $string['atanypage'] and $string['atanytoplevelpage'] with corresponding if/switch statements in the code.

          Show
          David Mudrak added a comment - I like the idea - it really makes the block setting more user friendly and intuitive. One comment regarding your commit http://git.moodle.cz/?a=commitdiff&p=moodle.git&h=0aed347fd1ce22c08de27e025ac61871ede0030f . Please let us not use string identifiers like in $string['*'] = 'Any page'; $string['site-*'] = 'Any top-level site page'; I am currently working on a proper strings file format specification and I will propose that only [a-z] [0-9] ':' and '-' (minus sign) and maybe '_' (undersocre) are allowed. Generally, string identifiers should follow our convention for naming $variables - single lowercase word, no underscore. The colon ( sign can be used only in strings with the names of capabilities and nowhere else. The minus sign can be used only in string identifiers witch are partially computed, like in get_string('region-' . $regionid, 'theme_example'); so that is a sign that we should be careful when trying to find an usage of such string in the code (which I need to do during English language pack massacre). Therefore, my proposal is to replace the two strings by proper $string ['atanypage'] and $string ['atanytoplevelpage'] with corresponding if/switch statements in the code.
          Hide
          Martin Dougiamas added a comment -

          Yes, my original rules for string names were like that but it's been broken so often that I've given up now.

          Is there any real reason to restrict string names? They are just strings indexing an array after all, and never evaluated.

          Show
          Martin Dougiamas added a comment - Yes, my original rules for string names were like that but it's been broken so often that I've given up now. Is there any real reason to restrict string names? They are just strings indexing an array after all, and never evaluated.
          Hide
          David Mudrak added a comment -

          Well, they are array keys only at the moment. But I can imagine we will want to export the definition files into different formats so the other translation tools can be used for translating them (there has been demand for this since ages). The more strict we are, the bigger chance to avoid compatibility problems in the future. In any case, $string['*'] just stinks

          Show
          David Mudrak added a comment - Well, they are array keys only at the moment. But I can imagine we will want to export the definition files into different formats so the other translation tools can be used for translating them (there has been demand for this since ages). The more strict we are, the bigger chance to avoid compatibility problems in the future. In any case, $string ['*'] just stinks
          Hide
          Tim Hunt added a comment -

          I would go for string names like page-... for these strings and change * to x.

          So, page-x, page-mod-x-view, and so on.

          Show
          Tim Hunt added a comment - I would go for string names like page-... for these strings and change * to x. So, page-x, page-mod-x-view, and so on.
          Hide
          David Mudrak added a comment -

          That string['*'] issue has been fixed

          Show
          David Mudrak added a comment - That string ['*'] issue has been fixed
          Hide
          Eloy Lafuente (stronk7) added a comment -

          NOTE: This issue was assigned to the STABLE backlog without complete triaging process. Marking it as triaged, but with this note for future reference.

          Show
          Eloy Lafuente (stronk7) added a comment - NOTE: This issue was assigned to the STABLE backlog without complete triaging process. Marking it as triaged, but with this note for future reference.
          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this issue.

          We have detected that this issue has been inactive for over a year. It was reported as affecting versions that are no longer supported.

          If you believe that this issue is still relevant to current versions (2.5 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

          Michael d.

          TW9vZGxlDQo=

          Show
          Michael de Raadt added a comment - Thanks for reporting this issue. We have detected that this issue has been inactive for over a year. It was reported as affecting versions that are no longer supported. If you believe that this issue is still relevant to current versions (2.5 and beyond), please comment on the issue. Issues left inactive for a further month will be closed. Michael d. TW9vZGxlDQo=
          Hide
          Michael de Raadt added a comment -

          I'm closing this issue as it has been inactive for over a year has been recorded as affecting versions that are no longer supported.

          This is being done as part of a bulk annual clean-up of issues.

          If you still believe this is an issue in supported versions, please create a new issue.

          Show
          Michael de Raadt added a comment - I'm closing this issue as it has been inactive for over a year has been recorded as affecting versions that are no longer supported. This is being done as part of a bulk annual clean-up of issues. If you still believe this is an issue in supported versions, please create a new issue.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: