It's not an Essential thing, as you point out it's from the Bootstrap CSS that Bootstrapbase/Clean includes.
I'm sure I looked at this before. Is this the place where they're using tiny little single color images instead of just setting the background-color on a div? If it is I'd just tell them to fix it by using divs.
It looks like it was discussed here, regarding another theme:
https://moodle.org/mod/forum/discuss.php?d=219854
So it seems just setting the height of that image to a particular pixel height should fix this. I don't have questionnaire installed so someone who does will need to figure out the CSS required to target these images. But the right place for the fix is in the Questionnaire module, there's no point multiple different themes including the fix for an optional component (that's doing something a bit weird and unnecessary in the first place).
David Scotson
Posts made by David Scotson
Ah, we jumped from 1.9 to 2.3 at our institution so I just assumed it had disappeared earlier.
I'm actually suggesting that javascript not be used to rewrite the page at all, beyond fairly minor things like swapping blocks around in locations that already exist. To abuse that old quote:
Some Moodle programmers, when confronted with a problem, think "I know, I'll use javascript." Now they have two problems.
There's just too much going on in this area already, and as we continue to add more and more patches and workarounds that all rely on very specific implementations of everything else in multiple different layers it's just going to become an unmaintainable mess (assuming that hasn't happened already).
Another potential solution/workaround is to not hide the move icon when drag'n'drop gets activated. This has multiple other benefits (e.g. it works better on touch devices, it's more discoverable, saves time on page load as things don't get added and then removed from the page) and means when someone wants to shift something from one side to the other they can click and icon and the page can reload with both columns visible and allow you to target the other side as a destination.
Some Moodle programmers, when confronted with a problem, think "I know, I'll use javascript." Now they have two problems.
There's just too much going on in this area already, and as we continue to add more and more patches and workarounds that all rely on very specific implementations of everything else in multiple different layers it's just going to become an unmaintainable mess (assuming that hasn't happened already).
Another potential solution/workaround is to not hide the move icon when drag'n'drop gets activated. This has multiple other benefits (e.g. it works better on touch devices, it's more discoverable, saves time on page load as things don't get added and then removed from the page) and means when someone wants to shift something from one side to the other they can click and icon and the page can reload with both columns visible and allow you to target the other side as a destination.
I think the tricky bit is that if you do drag'n'drop a block from the other side then you want that to behave correctly from that moment on, even before you change page, which means you're forced to basically rewrite the page from one form into another via javascript. One of the many odd-corners that snazzy conveniences like javascript drag'n'drop blocks create.
(I note that this reminds me a lot of the "add block" block, which is added, in edit mode, to the "default" side. Which means if you had no other blocks in that side, you'd suddenly have a block column there just for the ability to add a new block. That used to really annoy some of my users that were keen on having only one block column, particularly after they moved everything over to the default side to avoid it, and then we upgraded and the "default" side switched sides.)
Thinking outside the box a little: how about, if you are in editing mode, and if you only have blocks on one side of the screen, a link/button gets added to the top of the block column with the text "show other column". On clicking this the page reloads to show what you see in your screenshots, except at the top of the empty column there would be a similar link that says "hide this column" that does the reverse.
This avoids the need for all kinds of tricky logic, puts most of what's left in the PHP and lets javascript do one simple job, hopefully in a way that doesn't make too many assumptions about how the theme is laid out.
(I note that this reminds me a lot of the "add block" block, which is added, in edit mode, to the "default" side. Which means if you had no other blocks in that side, you'd suddenly have a block column there just for the ability to add a new block. That used to really annoy some of my users that were keen on having only one block column, particularly after they moved everything over to the default side to avoid it, and then we upgraded and the "default" side switched sides.)
Thinking outside the box a little: how about, if you are in editing mode, and if you only have blocks on one side of the screen, a link/button gets added to the top of the block column with the text "show other column". On clicking this the page reloads to show what you see in your screenshots, except at the top of the empty column there would be a similar link that says "hide this column" that does the reverse.
This avoids the need for all kinds of tricky logic, puts most of what's left in the PHP and lets javascript do one simple job, hopefully in a way that doesn't make too many assumptions about how the theme is laid out.