I think this works better:

.side-post-only #page-content #region-post

.side-post-only #page-content #region-pre

There is a lot less to account for and seems to address the issue. If anyone else sees differently, let me know. Otherwise, I will make this change and commit it in the next few days.

Hi John, thanks for your reply.

Your solution works until you turn edting on in a .side-post-only course (please look at the attachement above).
I think there are some unwanted interferences between the body classes .edting, .has-dock and .side-post-only!?
That's why I proposed a more complicated solution.

Regards!
Dietmar

(Same problem in sky-high)

Hi John,
as I'm going on foreign travel in the next days I would like to leave some further thoughts.

I think the gap between .region-main and .region-post in nonzero should not open before moving blocks.
But we can live with your (and my) solution that the gap comes up if you turn editing on.

On the other hand, there are some themes that have a strange behaviour in the same situation.
If you have a .side-post-only course

• and theme standard/anomaly/overlay and perhaps other themes you are "imprisoned" in .side-post-only layout as there is no such gap and it is not possible to move blocks to .region-pre,
• and theme magazine there is no such gap but it is possible to move blocks to the left.

Shouldn't all themes behave similar in the described situation?

Regards,
Dietmar

Lets start again.

Nonzero, course view, side-post-only, right column disappears.

We agree that changing

.side-post-only #page-content #region-post

to
.side-post-only #page-content #region-post

makes region-post visible in course view.

[.side-post-only #page-content #region-pre

has no effects!?]

Everything seems to be fine so far.

Course

But if you turn editing on, the class side-post-only is no more related to the body and you get a gap at the place where region-pre should be.
Why that?? This gap is only required when moving blocks.
If you dock one of the blocks after that, the gap disappears and the body is again side-post-only. What for??

Frontpage

Go to the frontpage and undock all blocks, but let editing turned on.
If you now move all the blocks to right side the class side-post-only stays related to the body, even if you turn editing off and on again, and you can't see any gap.
What's the difference between a side-post-only pagelayout-course and a side-post-only pagelayout-frontpage??

If you try to move a block to region-pre in this situation, you have no chance to do that.
But if you dock one of the blocks, it is possible to move the other blocks to region-pre. Confusing??!!
Undocking this block leaves all as it is???

My Conclusion

All that doesn't really make sense. We could correct this issues by some more css rules in nonzero/pagelayout.css.
As even the core themes don't work correctly in side-post-only situations I propose to rework the body classes
(pagelayout-course, pagelayout-frontpage, editing, side-post-only, has_dock and blocks-moving) as a whole.

What's your opinion?

Dietmar

I think that gap, when editing is turned on, is to give you a place to move blocks. Otherwise, you could not get out of that layout. This was probably the easiest way to do it (i.e., remove the side-post-only and side-pre-only classes when editing is turned on).

I can live with the gap when editing is turned on, as similar behavior would be expected from all three-column themes. However I am open to something else if you can think of anything...

You are right. I can live with this gap too. But it should also be visible on a side-post-only frontpage when editing is turned on, or? And the gap should not disappear, when you dock one of the blocks!

This should fix the main issues:

/** Only side post **/

.side-post-only #page-content #region-main-box

.side-post-only #page-content #region-post-box

.side-post-only #page-content #region-main

.side-post-only #page-content #region-post

.editing.side-post-only.has_dock #page-content #region-main-box #region-post-box #region-post

.editing.side-post-only.has_dock #page-content #region-main-box #region-post-box #region-main

.pagelayout-frontpage.editing.side-post-only #page-content #region-main-box #region-post-box #region-main

.pagelayout-frontpage.editing.side-post-only #page-content #region-main-box #region-post

.pagelayout-frontpage.editing.side-post-only #page-content #region-main-box #region-pre

.has_dock.side-post-only .page-middle #region-main-box #region-post-box #region-main-wrap #region-main

(Perhaps we can have a little bit shorter.)

One issue is left:
Go to a side-post-only course, turn editing on, dock a block, undock it: region-post jumps to a position it never had before!Unable to render embedded object: File (?? Very strange) not found.! Any idea?

The frontpage issue, is related to a problem with the way the frontpage layout file has declared the body classes. It works just as expected it they are corrected to:

$hasheading = ($PAGE->heading);
$hasnavbar = (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar());
$hasfooter = (empty($PAGE->layout_options['nofooter']));
$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);
$custommenu = $OUTPUT->custom_menu();
$hascustommenu = (empty($PAGE->layout_options['nocustommenu']) && !empty($custommenu));

$bodyclasses = array();
if ($hassidepre && !$hassidepost)

else if ($hassidepost && !$hassidepre)

else if (!$hassidepost && !$hassidepre)

if ($hascustommenu)

Of course, that still leaves the problem of docking when in editing mode. Docking, when in editing mode, creates the body class that turning on editing removes.

I believe your code works for the most part, I am just worried about maintainability...

Some important hints ...!

Finally - in order to retain maintainability - I think you should do some minimal changes

• at the top of the frontpage.php and general.php (body classes) and
• to the pagelayout.css (.side-post-only #page-content #region-post { left: [[setting:regionpostwidth]]; width: [[setting:regionpostwidth]]; }

hoping that the side-post-only issue happens extremely rarely.

Thanks for caring about this issue!

Welcome here, Mary! Let's start again.

Here the TODO-LIST for nonzero (as far as I can see):

1. fix the ;;-bug

2. change
.side-post-only #page-content #region-post

to
.side-post-only #page-content #region-post

3. add
.side-post-only #page-content #region-pre

4. add
.blocks-moving.side-post-only #page-content #region-main-box

.blocks-moving.side-post-only #page-content #region-post-box

.blocks-moving.side-post-only #page-content #region-main

.blocks-moving.side-post-only #page-content #region-pre

.blocks-moving.side-post-only #page-content #region-post

5. alter first lines of general.php: copy the following lines form the frontpage.php and paste them into general.php:

<?php

$hasheading = ($PAGE->heading);
$hasnavbar = (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar());
$hasfooter = (empty($PAGE->layout_options['nofooter']));

$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);

$showsidepre = ($hassidepre && !$PAGE->blocks->region_completely_docked('side-pre', $OUTPUT));
$showsidepost = ($hassidepost && !$PAGE->blocks->region_completely_docked('side-post', $OUTPUT));

$custommenu = $OUTPUT->custom_menu();
$hascustommenu = (empty($PAGE->layout_options['nocustommenu']) && !empty($custommenu));

$bodyclasses = array();
if ($showsidepre && !$showsidepost)

else if ($showsidepost && !$showsidepre)

else if (!$showsidepost && !$showsidepre)

if ($hascustommenu)

6. test, test, test ... (It works for me!)

Cheers
Dietmar

It's looking good!

These seem to match what I have in my version of Nonzero.

Cheers
Mary

Thanks guys - this has been integrated now. Spot on

Thanks Sam!

In attempt to test this, I moved all pre-side block to post-side then attempted a move for 1 of the block, I noticed the indication for possible new location for pre-side block is located on the top right of page-content section (see-attachment). It also effected IE9 and chrome. on the side note, I did purge all caches and browser cache.

This issue also occurs in formFormat theme. I will create new issue to fix formformat.

I put a wrong value in for.blocks-moving.side-post-only #region-pre. For some reason I picked up the wrong code for that line!!! It should read as follows:

.blocks-moving.side-post-only #page-content #region-main-box #region-post-box #region-pre {

    float: right;

    position: relative;

    width: [[setting:regionprewidth]];

    left: [[setting:regionprewidth]];

}

Is it too late to fix?

@Sam

I have just made amendments to MDL-26953, MDL-26953-M20 and MDL-26953-M21 to correct the error in the CSS I hope I have done the right thing by correcting this and not spoilt the chances of this getting through in this weeks PULL???

CHANGED from THIS

.blocks-moving.side-post-only #page-content #region-main-box #region-post-box #region-pre {

    float: right;

    position: relative;

    width: [[setting:leftregionwidthmargin]]; 

    left: [[setting:regionprewidth]];

}

to THIS

.blocks-moving.side-post-only #page-content #region-main-box #region-post-box #region-pre {

    float: right;

    position: relative; 

    width: [[setting:regionprewidth]];

    left: [[setting:regionprewidth]];

}

Cheers
Mary

Failing the test to allow Sam to re-integrate.

Thanks Rossiani

Thanks for spotting Rosie and thanks for the fix Mary.
The fix has been integrated and this is up for testing now.

Cheers
Sam

Thanks Mary and Sam.

This is now working great.

Test passed.

Many thanks for all the hard work. This is now part of Moodle, your favorite LMS.

Closing as fixed, ciao