Admin configuration of blocks is absolutely backwards

Admin configuration of blocks is absolutely backwards

by Bob Puffer -
Number of replies: 6

As an admin:

  1. Turn editing on for the course
  2. pick any page for which you'd like to remove one (or all) of the blocks from that "type" of page so content will be wider.  For this example I chose the Categories and items page in the gradebook because it's so hilariously impossible to use the screen with blocks on it (and damn hard without) -- you need to scroll way to the right to get your controls and no longer know what item your controlling.
  3. Click the 'Edit settings' icon
  4. Display the 'Where this block appears'
  5. Click the 'Display on page types'

In my case, this is what I get, a choice to have the NAV block display at whatever level of the grade-edit-tree-index structure and anything below it WHILE TOTALL ELIMINATING IT FROM EVERY OTHER PAGE ON THE SITE!!!

For those who have to use Moodle as an instrument of instruction, its obvious this dropdown should result in restrictions having to do with the grade-edit-tree-index structure (as an Admin, site-wide) and not affect any other page on the site.

Average of ratings: -
In reply to Bob Puffer

Re: Admin configuration of blocks is absolutely backwards

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Since blocks are shown on every page, then whenever any user looks at any page, we need to calculate which blocks appear on each page very fast. This constrains the type of configuration options we can offer.

Categories and items usability is a specific issue that could be worked on.

In reply to Tim Hunt

Re: Admin configuration of blocks is absolutely backwards

by Bob Puffer -

Try this, NOT on a site you may not ever want to use again:

  1. Turn editing on
  2. As Admin go into any gradebook page of any course site 
  3. Click the edit settings icon for the Administration block (because you want to remove it from pages like this)
  4. Click 'Where this block appears' and
  5. Click the any setting besides 'On all pages'
  6. Save your changes

Try to get back to an Administrative block anywhere.  Try to get back to the place where you disabled it.  Its possible but not very easy to find and if there's been any lag of time, you may not remember the specific course.  I got back by knowing the url but couldn't even get the block back then.  I think this instance has just become disposable.

I don't think you addressed the gist of my inquiry, "what use is 'Where this block appears' outside of the system context"?  We as an admin can't configure the placement or non-placement of blocks across all courses (like don't have the NAV block show up on every single page) unless we remove them across the board everywhere else.  The dropdown serves as an 'opt-in' to the exclusion of EVERYWHERE else.  Can you help me make sense out of that design decision?  

 

In reply to Bob Puffer

Re: Admin configuration of blocks is absolutely backwards

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

If you really want to understand this, you need to read the code in load_blocks in lib/blocklib.php. The design criterion, as I said before, was to make this as flexible as possible without destroying performance.

Some of that flexibility, as you point out, is probably not useful, so don't use that. In other places it is very useful. For example, outside the system context, you might wan to add a block to all courses in a particular course category. Or all wikis, in all courses, in a course category.

There is then the questoin of how this flexibility should be exposed in the UI. That is a good question. It has got better over time, but it might be possible to improve it more.

In reply to Tim Hunt

Re: Admin configuration of blocks is absolutely backwards

by Bob Puffer -

Thank you.  I read through that (several times).  It would seem that my suggestion would not have that great an impact on performance and would actually give the administrator the flexibility the designers intended (at this point, ADDING blocks that are not standard is the only thing this feature accomplishes).  If the block_instances table contained records of structures where blocks shouldn't show up the query would need to look for only one additional item, a record that matches the structure of the page its currently displaying that 'negates' that block's appearance.  Then the dropdown for 'Where this block appears' would actually accomplish what it purports to do.  There is no warning anywhere that 'You are about to lock yourself out of your system entirely unless you know the DB structure and can manually edit the record this procedure's about to screw up!'. 

In reply to Bob Puffer

Re: Admin configuration of blocks is absolutely backwards

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Well, as they say in the open source world: patches welcome.

In reply to Tim Hunt

Re: Admin configuration of blocks is absolutely backwards

by Bob Puffer -

Thanks.  After some discussions in the themes forum I guess I'll have to give this a try since I need the blocks to go away on gradebook pages but obviously don't want to sacrifice them all through the site.