Hi Urs, thanks for reporting this. Can you please elaborate how the change of the pagelayout is supposed to fix the problem of the wide table not fitting into the screen?

Thanks for reporting this.

I've put it on our backlog and we'll try to get to it as soon as we can.

In the meantime adding more information, such as screenshots, replication instructions, fix test instructions, a workaround or even a code solution, will help us and other users.

Simply said the "report" pagetype is optimized for wide page content and the language editing table needs a lot of space.

The 4 columns - some with a lot of text - and the textarea column to the right need to be all visible.

When you for example use "Splash" and open the language editing page on a 1200 px laptop screen the right column with the textareas is cut. And you see that there is a lot of white space on both page sides. When you change the pagetype to "report" the unused white space on both sides disappears and the table is not cut off.

So changing the pagetype to "report" solves the issue.

Hmm well. But that sounds to me as a bug in the standard layouts actually. If there is a content too wide, no layout should just cut it should it? From my point of view, breaking a "nice" layout of the blocks is less evil than hiding a content. (No offence, just trying to get the fix right)

David, great that you keep asking. The pagetypes are an area which has not been discussed very well.

Moodle 2 offers a lot of pagetypes. As I know there are no definitions/commitments for what content the pagetype stands for.

For example where should the "base" type be used and where "standard"? What does the "standard" pagetype really mean - does it mean a fallback when somebody does not really know which pagetype to set? Why do not all pages in the admin area use the "admin" pagetype?

On admin pages like the language editing I would expect the "admin" page type, but the "standard" pagetype is set. The "report" pagetype has been introduced short before Moodle 2 was finished to solve the wide page issues mainly with the wide report tables. So I think the "report" pagetype is best for wide content - it only has a misleading name.

If all pages in the admin area would use the "admin" pagetype the "admin" pagetype would be the one to be flexible in width and optimized to adopt to content and not cut of page areas.

To answer your question about breaking pages many clients wish fixed width layouts at about 960px page width. This width works good for content pages and solves the problem with reading problems when you have long lines on the modern 1200+ px screens. The fixed width does not work for many admin, settings and reports pages in Moodle.

From my point of view the best approach for the different needs for the two page categories - presentational content pages on one side and functional admin, settings, report pages on the other side - would be to consequently set the appropriate pagetypes. And to offer at minimum one Moodle standard theme showing how to work with the different pagetypes.

For modern webdesign there should be the chance to present content pages different from admin pages. In Moodle you can't really work following this approach because the pagetypes are not set consequently.

How could a solution for the language editing page look?

At the actual state of our discussion I'd propose to change the pagetype to "admin". And change the pagetype of all pages in the admin area that don't use the "admin" pagetype to "admin". And do the same for settings pages.

With these consistently set pagetypes it will be possible to create a flexible "admin" page design that handles all kinds of page width. And in the same theme use a fixed width page design for content.

And I'll be a bit more happy

+1 I like the idea that all admin pages has a specific pagetype. That would allow to do different layout for the administration backend - like typical content management systems have. In fact, even the CSS for the admin pages could be well defined in the base theme and then theme designers can fully focus on the frontend only.

So can we modify the title of this issue to "All admin pages should use the 'admin' page layout" and start to collect some votes and objections?

and yes, I am OK with setting the page type to "report" as a temporary solution for the customlang report.

You wrote "That would allow to do different layout for the administration backend - like typical content management systems have."

That's what I have developed for Moodle 1.9 with a lot of effort and had hoped would be easier in Moodle 2. I called it "Admin theme".

After solving this issue the "Admin theme" might be easy to implement. Either as part of the base theme or a individual parent theme.

@Urs

If I had seen this before I would have voted for it earlier.
Thanks for leaving the link in the theme's forum.

I've raised this issue here too: MDL-28447

As noted in the above issue, it's not only admin or report pages where this is an issue. See also Page and URL (esp. with embed) pages.

With editing turned on the issue is made worse as the Add a block block position is fixed.

This issue was assigned to me, however I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue. For more information, see http://docs.moodle.org/dev/Changes_to_issue_assignment

@Urs, as reporter of this issue can you Peer Review this?
Also I need help with Test Instructions...someone?

I personally feel it is a good move. I have, in the Sky High theme, recently changed the Admin $THEME->layout in theme/sky_high/config.php to use 'report.php' for exactly the same reason Urs advocates for this issue.

If everyone is happy with this, I can get this back-ported to 2.3 and 2.4 as well as be in 2.5 and future development.

Glad to see this issue being addressed. Many thanks Mary. +1 from me, as this will improve user experience for our lecturers.

Thanks Thomas, I've just pushed it for integration review. I hope the Test Instructions are OK?

I have just created a META issue to finish of this task, as I am not sure at this stage how many files exist that require change.

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

TIA and ciao

Thanks Mary - this has been integrated now

Thanks guys, tested and passed.

Thanks for giving me joys and smiles
Thanks for sharing my trouble's pile

Thanks for wipeing the tears of my eye
Thanks for showing me the glad view of sky

Thanks for lending me your shoulders to lean
Thanks for giving my words a proper mean

Thanks for telling me the value of life
Thanks for showing me the rules to survive

Thanks for lending me the sympathetic ears
Thanks for showing how much you care

From all this what I mean in the end
Is thanks for being my special friend.

– Seema Chowdhury

Sent upstream so... closing, thanks!