21 February 2014, 0:48

Hi all,

We recently upgraded to Mahara 1.8, and have had a report from a user that pages that were formerly displaying in a single column are now displaying in 3 columns, making content difficult to read. These appear to be pages where layout is null in the database, so I presume this is the default.

This is affecting a large number of pages. Is there a way of setting the default page layout to single column globally, or does this need to be done for each individual page in the database?

21 February 2014, 8:30

Hi Rob,

for new pages this works for me to have one row and one column.

In the file /htdocs/lib/view.php on line 572 change '3' to '1' like so:

'columnsperrow' => array(1 => (object)array('row' => 1, 'columns' => 1)),

For existing pages, I imagine there is a query that one can run in the database to change all 3's to 1's but I could not tell you how to do that safely.

21 February 2014, 8:49

If you wanted to turn all the views with 1 row / 3 cols layouts to 1 row / 1 col you could run:

UPDATE view SET layout = (SELECT viewlayout FROM view_layout vl, view_layout_rows_columns vlrc WHERE vlrc.row = 1 AND vlrc.columns = 1 AND vlrc.viewlayout = vl.id AND vl.rows = 1 AND iscustom = 0) WHERE layout = (SELECT viewlayout FROM view_layout vl, view_layout_rows_columns vlrc WHERE vlrc.row = 1 AND vlrc.columns = 3 AND vlrc.viewlayout = vl.id AND vl.rows = 1 AND iscustom = 0);

21 February 2014, 12:26

Hi Rob,

I was unable to replicate the problem you describe, of one-column views turning into three-column views after upgrading. Were you using custom code in your Mahara 1.7?

A NULL value in "view.layout" doesn't necessarily mean the view had the "default" layout of 3 columns. In Mahara 1.7, if "view.layout" is NULL, it means the number of columns is determined by the value in "view.numcolumns". (The way to create a view with NULL in view.layout and something other than the default 3 in "view.numcolumns", is by using the "Show controls to add and remove columns when editing a page" account setting).

So, what you want to check, to identify views that were 1 column in Mahara 1.7, is view.numcolumns. This column is no longer used for anything in Mahara 1.8, but we haven't dropped it from the database yet.

In Mahara 1.8, the situation is similar. If a view's layout is NULL, then, because a view can have multiple rows, we look in the "view_rows_columns" table to determine the number of columns in each row of the view.  There is also a "view.numrows" column, which should agree with the number of records in "view_rows_columns".

The 1.7 -> 1.8 upgrade process should have inserted exactly 1 record into view_rows_columns for each existing view, with the old view.numcolumns value being inserted into view_rows_columns.columns.

So in short, before you make any DB changes, to get a sense of what's going on with these views you should check out the view's values in "view.numcolumns", "view.numrows", and in the "view_rows_columns" table.

Cheers,

Aaron

21 February 2014, 23:29

HI Aaron,

We had a delay in upgrading, so we went straight from 1.4.6 to 1.8.1. I have to admit that I can't say for sure that the layout of these pages changed, as I hadn't checked them before the upgrade - I'm just going on what's been reported.

Checking the layouts for portfolio pages where the layout is null in the view table, the majority are set to 3 columns:

mahara=# select rc.row, rc.columns, count(*) from view v join view_rows_columns rc on v.id = rc.view where v.layout is null and v.type = 'portfolio' group by rc.row, rc.columns;
 row | columns | count
-----+---------+-------
   1 |       4 |     8
   1 |       1 |   807
   1 |       5 |     6
   1 |       3 |  6391
   1 |       2 |    57

24 February 2014, 11:43

Hm, I wasn't able to replicate the problem doing a direct upgrade from 1.4 to 1.8 either.

Well, another thing that may be instructive, is comparing what's in view.numcolumns to what's in view_rows_columns. Something like this:

select v.numcolumns, rc.columns, count(*) from view v inner join view_rows_columns rc on v.id=rc.view where v.layout is null and v.numrows=1 and v.type='portfolio' group by v.numcolumns, rc.columns order by v.numcolumns, rc.columns;

You should find that nearly all pages have the same number of columns in "v.numcolumns" as they have in "rc.columns", unless the page has been created and/or edited since the upgrade took place.

For instance, here's what it looks like when I run this query for a large 1.8 site that we host:

 numcolumns | columns | count
------------+---------+-------
          1 |       1 |  4666
          1 |       2 |     2
          2 |       1 |   296
          2 |       2 |  3255
          2 |       3 |  5756
          2 |       4 |     3
          3 |       1 |     5
          3 |       2 |     5
          3 |       3 | 89580
          4 |       1 |     1
          4 |       4 |   170
          5 |       5 |    72
(12 rows)

If you find a large number that have v.numcolumns=1 and rc.columns=3, then that would probably be the reported pages that have changed in number of columns at some point during the upgrade process.

If the extra columns are empty on these pages, I guess you could just update "view_rows_columns.columns" to "1" for each of these pages. On the other hand, if the columns contain blocks, you'd need to shift those blocks back over to the remaining column, and that's a bit trickier, probably something it would be better to use a PHP script for. If you take a look at the function View->removecolumn() in lib/view.php, it shows the things you need to do to relocate the blocks when removing a column.

Cheers,

Aaron

 numcolumns | columns | count
------------+---------+-------
          1 |       1 |  4666
          1 |       2 |     2
          2 |       1 |   296
          2 |       2 |  3255
          2 |       3 |  5756
          2 |       4 |     3
          3 |       1 |     5
          3 |       2 |     5
          3 |       3 | 89580
          4 |       1 |     1
          4 |       4 |   170
          5 |       5 |    72
(12 rows)