MoodleDocs - User contributions [en]

Moodle Wishlist

2015-02-04T01:38:31Z

Dwahl:

Warning! This page is highly speculative.

It is basically a dumping ground for random ideas from anyone who wants to write something here. It is not in any way an official Moodle roadmap or policy. Some of the good ideas here may be adopted, but most of the ideas are pretty crazy, and will never work. Basically, it is a place to brainstorm. Please add your own crazy ideas! They don't need to be consistent yet, just make sure your ideas are here to be boiled down later on.

Think Big!

===One type of plugin===

All plugins/modules could be subclassed from one plugin class, making installation easier and simplifying the API a lot.

Or even just [[unify all activities and resources]]...

===Look at new framework===

Possibly base Moodle 3.0 on new existing frameworks? Ruby on Rails? Drupal? Symfony2? +2

Why not consider something like Phalcon PHP (http://phalconphp.com/en/)? (Blazing faster than Drupal or Symfony) -- [[User:Sebsoft|Sebastian Berm]]

Keypoints: -- [[User:Gabriel_Mazetto|Gabriel Mazetto]]
* MVC is a must ''(we waste too much time reimplementing "mvc" in every single page, and we lack best practices by doing it again and again and again)''
* Better ORM ''(I understand that in some time of the history, it was a good idea to create our own ORM, but today's lack of modern ORM means bad APIs, ancient unit tests, no "factories" which leads to expensive tests and bazilion fixtures)''
* Object Orientation done right ''(doesn't matter if it's php, ruby or whatever, but let's use all the useful features the language has to offer and lets make the code easy hackable, no more useless private/protected that makes impossible to overwrite pieces of code without having to duplicate everything).''
* Use more external libraries ''(let's just not reinvent the well again, there is a lot of good libraries out there that have strong community to maintain, and let's not waste time reimplementing our "perfect" version of them, that soon will be obsolete as no one is willing to maintain... and also let's make an effort to update regularly thous external libraries).''

==== Drupal ====
There's an interesting discussion in the Language Teaching Course:
[http://moodle.org/mod/forum/discuss.php?d=83963 How can Moodle be more of a social networking site?] with some links to the [http://groups.drupal.org/drupal-education Drupal in Education User Group]. --[[User:Frank Ralf|Frank Ralf]] 14:27, 18 January 2009 (CST)

(I started a section about [[User_talk:Frank_Ralf#What_Moodle_could_learn_from_Drupal|What Moodle could learn from Drupal]] on my User talk page. --[[User:Frank Ralf|Frank Ralf]] 06:35, 21 January 2009 (CST))

There are some activities in the Drupal community regarding better interoperability and integration of Moodle and Drupal, see [http://moodle.org/mod/forum/discuss.php?d=121859 Drupal Quiz module - data exchange with other LMSes] and [http://moodle.org/mod/forum/discuss.php?d=119857 Moodle integration with Drupal]. --[[User:Frank Ralf|Frank Ralf]] 08:10, 10 June 2009 (UTC)

==== Symfony ====

Drupal successfully moved to Symfony. Its a good framework and may attract more community contributions.

==== Zend Framework ====
How about [http://framework.zend.com/ZendFramework ZendFramework]? It's open source, of course, runs on PHP, already has a pretty cool API with a well stocked service library, and the coders are working closely with Google, Adobe and Microsoft, among others, to produce some really high quality code. One feature I particularly like is that the main bulk of the PHP code is outside the public HTML directory. Since version 1.7 It also offers pretty good support for Flash Remoting (AMF0 and AMF3) making it especially easy to create integrated RIA frameworks. [http://framework.zend.com/about/components Check here] to see what you get "out of the box". It looks like they've already done most of the hard work for you.

==== Node.js ====

Thinking "big", how about ditching PHP entirely and building on top of node.js? You could exploit its real-time-friendly design, and integrate the node.js-based etherpad-lite for synchronous document collaboration. And javascript has some of the same hacker-friendliness that PHP has.

=== Moodlets===

Individual-independent-activities backup/restore + metadata - Eloy

=== Support for alternate interfaces, mobile interfaces ===

Optimized for tablet computing: iPad, others
Completely flash-based interface? Designed for offline clients?

=== Integrated category/taxonomy system ===

Putting together the "course categories", "tags" into a generic taxonomy system.

=== Save the 1970-2038 limitation ===

Those UNIX timestamps are [http://moodle.org/mod/forum/discuss.php?d=101984 pretty limited].

=== Translation framework ===
Drupal uses [http://www.gnu.org/software/gettext/gettext.html GNU gettext].po files for providing translations which is a very robust and well understood format.

Or XLIFF format (use in Zend Framework, Symfony, Intl extension) with [http://icu-project.org/download/rbmanager.html Resource bundle manager]

=== Use PHP 5.3 Native Power ===
Like : PDO, SPL, Namespace, Intl, Phar...
(Zend Framework 2 use it)

=== Caching with Edge Side Includes (ESI) and a proxy (varnish, squid) ===

This should provide performance improvements while not having to limit the number of portlets on a page for optimisation.
(Symfony2 provides that possibility out of the box, leaving the choice to activate it or not)

=== Make a replica Moodle ===
1 Moodle library, 100 Moodle platforms, just adding plugins and themes.

=== Please Sanitize the PHP code ===
Don't use : '''ini_set'''

Don't use : '''error_reporting
'''
Don't use : '''@'''

Don't use : '''eval
'''

Don't use alias : exemple : '''die''' (it's '''exit''')

Don't use depreciates functions : exemple : '''split''' (it's '''explode''' or '''preg_split''')

'''A simple way to show all errors : (in php.ini with PHP 5.3) :'''

disable_functions = ini_set, error_reporting

error_reporting = E_ALL | E_STRICT

display_errors = On

(eval can be disable with Suhosin)

Use the right functions : exemple : it's not '''ini_set('include_path')''' it's '''set_include_path'''

Use Registry Pattern instead global

Use Docbook everywhere

Moodle is now PHP 5 : clear "'''var'''" in class, methods are '''public'''/'''private'''/'''protected''' '''function''' (not just '''function''') and '''__construct''' for constructor method

:Many thanks for your invaluable and expert opinion, we'll be working hard on all those, sincerely! --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 01:37, 19 February 2011 (UTC)

=== Built for Teacher-to-teacher Content Sharing ===

Drag-and-drop courses and course items from Moodle Hubs

=== Learn from LAMS and Dokeos ===

Integrated authoring system
Drag-and-drop sequential scenario-building

=== Invent something crazily new ===
3-line ideas are welcome here:
* participation reward systems
* Add trashcan and /or undo function
* Make editing of modules WYSIWYG, no more icons that change layout
* Collaborative spreadsheet editing functionality - like Google Docs.

=== Even more crazy ===
* To turn Moodle as a Community of Practice Management tool.
* To make it general enough so that it becomes a terrific tool for many types of activities that manages communities, but still based on socio-constructivist principles.
* Use fractal principles where a course categories is in fact a course. They both are containers/circles with parent-child links.
* If enrolled in a child circle, than automatically enrolled in the upper parents category/containers.
* The scope of a Glossary should be extendable to child containers/circles.
* Tags : Any persons, any containers/circles, any calendar events, any objects should be taggable. So that anyone that is looking for resources can find it easily. Sorted by center of interests, geographical proximity and time line.

=== More Agile Development ===
There are many elements in agile development that could apply to Moodle and benefit the development process tremendously. With proper application of these elements, the Moodle's core code can be more solid and robust. Any programmer can make changes to the source with confidence and not be afraid of breaking any other features.

==== Test Driven Development ====
Require unit tests and acceptance tests be written for every change made to the core code. No code should be committed to the core without any test written. A code reviewer should run the tests and expect them to be failed before applying the code changes, and expect they all passed after applying the fix or code changes. S/he should also run the full test suite to make sure the changes did not break any existing features and functionalities.

==== Code Review ====
Implement a code review process like the [http://codereview.chromium.org Google Chromium project]. Developers can only commit to the trunk with one or more reviewers' approval.

''I wonder if the person who added these ideas has any idea how Moodle development actually works. I would guess not. The process is already very agile. All contributions are code-reviewed. There are not enough unit tests yet, but writing unit tests for legacy code is the hardest sort of tests to write (see the book xUnit test patterns) so frankly, it is not worth the effort, except in new code. I can get away with saying that because I have written 2500+ test cases for the latest bit of development I did.''--[[User:Tim Hunt|Tim Hunt]] 15:23, 6 February 2011 (UTC)

''Hi Tim, please don't take me wrong. I think the development team at Moodle is already very agile. It is actually one of the few agile projects that I have seen in the open source communities. The effort that you and many diligent individuals have made to coordinate and integrate contributions from all over the world is outstanding. I just made these comments based on the software development environment I came from, where no code change is allowed to commit without any test written and reviewer signs off. Our VCS is actually configured to reject any commit that do not have these two elements present. You are correct that I do not fully know the Moodle development process yet, but the fact that I see codes (particular contributed codes) being checked in without any tests, I just thought it would help bolster Moodle's core code by enforcing this rule in future commits. And implementing something like [http://codereview.chromium.org Google Chromium code review] interface allows more eyes on the check-in codes, and hopefully alleviates some of the loads from you and the rest of the core team, who have been doing a wonderful work on peer-reviewing all these time. Again, please don't take this as a criticism but a brian-storming idea if you will. Peace.'' --Carson

===Audio Feedback===

* The ability for lecturers to leave audio feedback on students work (student uploaded work could be: text,audio,video...) as opposed to written text feedback. Students can then listen to feedback rather than read text feedback on-line.
* On the (moodle) activity/assignment submissions page, beside each students text input box, have a record, pause & stop button for teachers to record & save the audio feedback.
* It would be for all audio feedback left by lecturers in a particular course for a particular student could be aggregated into one podcast, which could be listened to by students on their mobiles, on the move--Jago Brown

: This does not require any major changes to Moodle. It just requires a few plugins, possibly just a 'record audio' repository plugin. And, perhaps, a new assignment type or question type. This is all perfectly possible in Moodle 2.x.--[[User:Tim Hunt|Tim Hunt]] 16:22, 10 September 2011 (WST)

=== Being able to use apostrophe in file and folder names ===
It would be good, to respect user choice (and language) to be able to use apostrophe in folder names and filenames.
A tracker issue was opened for that : MDL-42724

===Fix the Scroll of Death===

Allow layout settings to be applied to course sections (as they are to courses).
Allow multiple image types to be added to themes for activity / resource types.
Allow images to be overridden (uploaded) for individual activities.
Allow sections to be added and deleted on the in line within the course page as opposed to defining them in the course settings.

The idea would be that within each course section you could choose between grid / tiled layouts, columns, collapsable toggles, accordians etc.
Because this would be based on sections not the entire course you could mix and match different layouts within a single course as required.

Another approach would be to build a system of shortcodes into the text editor.
Commercial Wordpress themes have done this for some time for example "Avada Theme", "FlexForm", "U-Design" (all can be found on ThemeForest).
If shortcodes were an option templates could be saved and re-used / loaded into a given course.

===Split Assignments out From Content===

Assignments grades and feedback should belong to the student not to the course.
Clearing down of these records should be driven by a site (and possibly category) wide retention policy not by a teacher deciding (or not as the case may be) to reset the course.

===Rebuild MOODLE modules as Drupal Components ===

I see Drupal has been already mentioned, but rather than rebuild MOODLE using Drupal, rebuild the functionality and modules as a series of standalone Drupal modules. MOODLE would not be an application in its self but a collection of modules, best practices for on-line delivery, and a Drupal distribution.

https://drupal.org/documentation/build/distributions

From a learning perspective this would open up new ways for people to access the pedagogy that underpins MOODLE. From a technology point of view development time would be sped up as many modules already exist in Drupal and the potential developer base would explode in terms of size.

===Make Quiz Module Work as a Class Response System===

The Quiz module is a best of breed example of a question, answer and feedback activity, but the implicit message in its design is content is pre-arranged for students working alone. Master teachers introduce questions as they see necessary in classes to stimulate thinking and discussion and debate to force examination and building of concepts. Having a "live quiz mode" wherein a teacher can add a question "on the fly" even verbally (for example: What will happen when I do this), then collect and dsiplay responses is one of the most powerful additions technology can make to a conventional classroom.

:: It does not make sense to cram this into the quiz module. It is a different type of activity, and someone has already made it: https://moodle.org/plugins/view.php?plugin=mod_realtimequiz --[[User:Tim Hunt|Tim Hunt]] ([[User talk:Tim Hunt|talk]]) 16:24, 5 January 2015 (AWST)

===Make Moodle a Tin Can LRS===

Making Moodle a Learning Record Store (LRS) based on the Tin Can API will enable learning experiences that happen outside of Moodle to be captured as part of a learner’s total education.

==== Make Everything a Module ====
Make moodle 'core' 3.0 have essentially 0 plugins, then make every activity, resource, theme, auth, enrollment, etc... a stand-alone plugin. Then we could provide a cool 'build' page where people check what they want and moodle downloads with those components. Eventually moodle.com could stop developing plugins they don't want to maintain anymore (like they did with all the <2.7 themes) and create new one that they do. New ones could be added much more quickly without bloating the core.

CSS Coding Style

2013-07-17T07:42:13Z

Dwahl: /* Progressive Enhancement */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>.selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-07-17T07:41:42Z

Dwahl: /* Correct */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>.selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-07-17T07:41:22Z

Dwahl: /* Correct */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>.selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-07-17T07:40:58Z

Dwahl: /* Correct */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>.selector_name {
color: #fff;
}</code>

or

<code css>.selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-07-17T07:40:34Z

Dwahl: /* Incorrect */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>.selector_one, .selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

CSS Coding Style

2013-07-17T07:40:13Z

Dwahl: /* Correct */

{{Work in progress}}

The Moodle CSS coding style

== Overview ==

=== Scope ===

This document describes style guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

=== Goals ===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness

== Naming Conventions ==

Within plugins, CSS files are normally named *styles.css*.

In the theme, files can be named according to the theme designer's wishes but should:

* use lowercase letters only
* be as short as possible

== Block Style ==

* Each selector should be on its own line. If there is a comma in a selector list, follow it with a line break.
* Property-value pairs should be on their own line, with four spaces of indentation and an ending semicolon.
* The closing brace should use the same level of indentation as the opening selector.
* Add a blank line between sections, but leave no lines between blocks in a section.

=== Correct ===

<code css>@media only screen and (min-width: 768px) {
.selector_one,
.selector_two {
color: #fff;
background-color: #000;
}
}</code>

=== Incorrect ===

<code css>#selector_one, #selector_two { color: #fff; background-color: #000; }</code>

== Selectors ==

* Follow Moodle [[Coding style]] for naming selectors.
* Names should be simple English lowercase words.
* Words should be separated by underscores or hyphens.
* Verbosity is encouraged: names should be as illustrative as is practical to enhance understanding.
* Use [http://css-tricks.com/semantic-class-names/ semantic names]: names tell what this is instead of what should it look like.
* Avoid using IDs as selectors wherever possible. IDs are a tad faster, but far more difficult to maintain and override. If you can't write the needed selectors successfully without using an ID, then submit a [http://tracker.moodle.org Tracker ticket] to have classnames added.

=== Correct ===

<code css>#selector_name {
color: #fff;
}</code>

or

<code css>#selector-name {
color: #fff;
}</code>

=== Incorrect ===

<code css>#selName {
color: #fff;
}</code>

or

<code css>#Sel-Name {
color: #fff;
}</code>

== Properties and Values ==

* Properties should be followed by a colon and a space, unless it is the last rule in the list of CSS mark-up.
* All properties and values should be lowercase, except for font names and vendor-specific properties.
* For color codes, lowercase is preferred
* For color codes, use of the shorthand version where possible is preferred, (e.g: #fff instead of #ffffff or #c06 instead of #cc0066).
* For color codes, if you use HSLA or RGBA, provide a HEX fallback (always).
* Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and padding values.
* Prefixed vendor-specific properties pairs should appear directly before the generic property they refer to.
* Do not use !important unless the is a good reason! If you need to use !important, something is wrong with the CSS you are trying to override. Rather than adding more problematic CSS, submit a [http://tracker.moodle.org Tracker ticket] to get the existing problem fixed.

=== Correct ===

<code css>#selector {
color: #fff;
}</code>

=== Correct ===

<code css>#selector {
color: #fff;
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: hsla(0, 0%, 100%, 1);
}</code>

=== Incorrect ===

<code css>#selector {
color: #FFFFFF !important;
}</code>

== Documentation and Comments ==

A block-style comment at the top of the CSS file should explain the purpose of the rules in the file.
<code css>
/**
* base.css
* Contains base styles for theme basic.
*/
</code>

Block-style comments can also be used to denote a section in a CSS file where all rules pertain to a specific component, view, or functionality:
<code css>
/**
* SCORM Navigation Sidebar
*/
</code>

Use single-line comments to provide more information to other developers about a single rule or small subset of rules:
<code css>
/* Required because YUI resets add a black border to all tables */
</code>

== Progressive Enhancement ==

* Code should follow the Moodle principle of progressive enhancement for all supported browsers for that specific version of Moodle. Supported browsers are listed in the [https://docs.moodle.org/dev/Releases Release notes] for the Moodle version.
* Fallbacks should always be provided. For example, provide a background color fallback to background images and gradients.
* Use vendor prefixes only when the supported browser in question does not support the unprefixed property. Outdated vendor prefixes can be removed. Use [http://caniuse.com/ Can I use] or like resource to determine what's supported.
* The standard property should preferably come after the vendor-prefixed property.

<code css>#selector {
background-color: #444; /* Fallback for browsers that don't support gradients */
filter: progid:DXImageTransform.Microsoft.gradient(startColorStr='#444', EndColorStr='#999'); /* IE6-IE9 */
background-image: -webkit-gradient(linear, left top, left bottom, from(#444), to(#999)); /* Safari 4+, Chrome */
background-image: -webkit-linear-gradient(top, #444, #999); /* Chrome 10+, Safari 5.1+, iOS 5+ */
background-image: -moz-linear-gradient(top, #444, #999); /* Firefox 3.6 */
background-image: -ms-linear-gradient(top, #444, #999); /* IE10 */
background-image: -o-linear-gradient(top, #444, #999); /* Opera 11.10+ */
background-image: linear-gradient(top, #444, #999); /* W3C Standard */
}</code>

=== Browser Hacks ===

* Do not use any browser-specific hacks. Moodle provides a more appropriate way to write browser-specific CSS using classes that are added to the body element. For example:

<code css>
.ie7 .forum-post {
min-height: 1px;
}
</code>

* It is not necessary to include hacks for versions of browsers that Moodle Core does not provide support for (e.g. IE6 in Moodle 2, except legacy theme).

=== LESS and Other CSS Preprocessors ===
[http://lesscss.org/ LESS] is not CSS. LESS will be evaluated according to the [http://lesscss.org/#docs LESS documentation]. If the LESS is valid according to the LESS documentation, and does not result in invalid CSS when compiled, it does not need to be further changed, revised, updated, or documented. The same goes for SASS and any other preprocessor languages coming down the pike. It's important that your LESS or SASS files be clear and accessible to others, and where the rules above apply, for example, with regard to line breaks and syntax, please follow them.

Some additional features allowed in LESS or SASS conflict with CSS usage. One example is inline comments in LESS. However, these inline comments do not appear in the compiled CSS file. The rule of thumb is that so long as the feature is part of the documented LESS or SASS feature set, is clear and usable by other developers (who have read the LESS or SASS documentation), and does not break or interfere with the functioning of the compressed CSS file, we let it stand in peer review.

== Credits ==

This document was drawn from the following sources:

# The [http://codex.wordpress.org/CSS_Coding_Standards WordPress CSS Coding Standards]

== See Also ==

* [[Coding]]
* [[Coding_style|Coding style]]

[[Category:Coding guidelines|CSS Coding style]]

Talk:PHPUnit installation in OS X

2012-12-07T03:02:06Z

Dwahl: Created page with "This info seems to be outdated. On OS X 10.8 I only had to add "detect_unicode = off" to my php.ini and then follow the normal PHPUnit via/ Composer instructions."

This info seems to be outdated. On OS X 10.8 I only had to add "detect_unicode = off" to my php.ini and then follow the normal PHPUnit via/ Composer instructions.

Creating a theme

2011-12-28T03:17:53Z

Dwahl: /* Using images within CSS */

{{Template:Themes}}{{Moodle 2.0}}This document describes how to create a theme for Moodle 2.0. It assumes you have some understanding of how themes within Moodle work as well as a good understanding of HTML and CSS.

===Theme designer mode===

Under normal operation Moodle does several things in the name of performance, one of these is to combine all of the CSS into one file, minimize it, cache it on the server, and then serve it. After the first request the cached version is served to greatly improve page performance.

What this means for you as a themer? When you make changes they will not be seen immediately. In fact you will need to tell Moodle to rebuild the cache that it is serving.
This isn't practical for designing themes of course so the '''theme designer mode''' was added. When enabled it tells Moodle not to combine or cache the CSS that gets delivered. This has the downside that page load times will take significantly longer, however you will see your changes immediately every time.

Theme designer mode may be enabled via ''Administration > Appearance > Themes > [[Theme settings]]''.

'''Warning''': Internet Explorer versions 6 and 7 have BIG problems when a site attempts to link to more than 31 stylesheets, in which case either a limited number or no styles get applied. Because Moodle sends up all of the CSS all of the time with theme designer mode turned on there is a very high chance you will get more than 31 stylesheets being included. This will, of course, cause major problems for Internet Explorer until theme designer mode is turned off.

==Getting started==

The first thing you need to do is create the directories and files you will be using, the first thing to create is the actual directory for your theme. This should be the name of your theme, in my case it's 'excitement'. The directory should be located within the theme directory of Moodle, ./moodle/theme/excitement/ will be the directory I create.

Now within that directory we can immediately create several files that we know we are going to need.

So the files that we want to create are:
; config.php : All of our settings will go here.
; /style/ : This directory will contain all of our stylesheets.
; /style/excitement.css : All of our css will go in here.
; /pix/ : Into this directory we'll put a screen shot of our theme as well as our favicon and any images we use in CSS.
; /layout/ : Our layout files will end up in this directory.
; /layout/standard.php : This will be our one basic layout file.
; /lang/en/ : The file we put here will make our theme name show properly on the Theme Selector page. You need a few standard entries. Copy the one from the Standard theme and modify is easiest.

So after this setup step you should have a directory structure similar to what is shown below.

[[image:Learn_to_theme_01.jpg]]

==Configuring our theme==

Open config.php in your favourite editor and start by adding the opening PHP tags '''<nowiki><?php</nowiki>'''.

Now we need to add the settings:

<code php>
$THEME->name = 'excitement';
</code>
Very simply this tells Moodle the name of your theme, and if you ever have several config.php files open this will help you identify which one you are looking at.

Next, the parents for this theme.
<code php>
$THEME->parents = array('base');
</code>
This tells Moodle that my new theme ''`excitement`' wants to extend the base theme.

A theme can extend any number of themes. Rather than creating an entirely new theme and copying all of the CSS, you can simply create a new theme, extend the theme you like and just add the changes you want to your theme.

Also worth noting is the purpose of the base theme: it provides us with a basic layout and just enough CSS to make everything fall into place.

Now we will tell Moodle about our stylesheets:
<code php>
$THEME->sheets = array('excitement');
</code>

The final thing we need to add into our theme's config.php file is the definition of the layouts for our theme:
<code php>
$THEME->layouts = array(
'base' => array(
'file' => 'standard.php',
'regions' => array(),
),
'standard' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'course' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post'
),
'coursecategory' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'incourse' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'frontpage' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'admin' => array(
'file' => 'standard.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
'mydashboard' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
'options' => array('langmenu'=>true),
),
'mypublic' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'login' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('langmenu'=>true),
),
'popup' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true),
),
'frametop' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true),
),
'maintenance' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true, 'nonavbar'=>true),
),
'print' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true, 'nonavbar'=>false),
),
);

/** List of javascript files that need to be included on each page */
$THEME->javascripts = array();
$THEME->javascripts_footer = array();

</code>

What you are looking at is the different layouts for our theme. Why are there so many? Because, that is how many there are in Moodle. There is one for every general type of page. With my ''`excitement`'' theme I have chosen to use my own layout. Unless there was a specific reason to do so, normally you would not need to create your own layouts, you could extend the base theme, and use its layouts, meaning you would only have to write CSS to achieve your desired look.

For each layout above, you will notice the following four things are being set:
; file : This is the name of the layout file we want to use, it should always be located in the above themes layout directory. For us this is of course standard.php as we only have one layout file.
; regions : This is an array of block regions that our theme has. Each entry in here can be used to put blocks in when that layout is being used.
; defaultregion : If a layout has regions it should have a default region, this is where blocks get put when first added.
; options : These are special settings, anything that gets put into the options array is available later on when we are writing our layout file.

There are additional settings that can be defined in the config.php file - see [[Themes 2.0|Themes 2.0]] for the full list.

==Configuring the language file==
Open theme_base.php file from '''base/lang/en/theme_base.php'''

Save it as '''excitement/lang/en/theme_excitement.php'''.

Change
<code php>
$string['pluginname'] = 'Base';
</code>
to
<code php>
$string['pluginname'] = 'Excitement';
</code>

After making these changes and perhaps clearing theme caches and/or purging all caches, the new theme name should now show properly in the Theme Selector: ''Site Administration > Appearance > Themes > Theme Selector''

You can also edit the theme description:

<code php>
$string['choosereadme'] = 'Write your theme description here.';
</code>

You need to leave the following two lines in place (you can change the wording if you need to) to avoid notices when editing blocks etc.:

<code php>
$string['region-side-post'] = 'Right';
$string['region-side-pre'] = 'Left';
</code>

==Writing the layout file==

The excitement theme has just one layout file.

The downside of this is that I have to make the layout file do everything I want which means I need to make use of some options (as defined in the layouts in config.php).

The upside is that I only need to maintain one file.

Other than maintenance, using multiple layout files provides many advantages to real world themes in that you can easily tweak and customise specific layouts to achieve the goals of the organisation using the theme.

Before learning more it is good to understand the two primary objects that will be used in your layout files: $OUTPUT and $PAGE.

'''$OUTPUT''' is an instance of the <code>core_renderer</code> class which is defined in lib/outputrenderers.php. Each method is clearly documented there, along with which is appropriate for use within the layout files.

'''$PAGE''' is an instance of the <code>moodle_page</code> class defined in lib/pagelib.php. Most of the things you will want to use are the properties that are all documented at the top of the file. If you are not familiar with PHP properties, you access them like $PAGE->activityname, just like fields of an ordinary PHP object. (However, behind the scenes the value you get is produced by calling a function. Also, you cannot change these values, they are '''read-only'''. However, you don't need to understand all that if you are just using these properties in your theme.)

So lets start writing standard.php, the layout file for my ''`excitement`'' theme.

===The top of the layout file===

<code php>
<?php
$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);
echo $OUTPUT->doctype(); ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title ?></title>
<?php echo $OUTPUT->standard_head_html() ?>
</head>
</code>

Lets look at the code that goes into this section:
<code php>
<?php
echo $OUTPUT->doctype(); ?>
</code>
This is very important and is required to go at the very top of the page. This tells Moodle to print out the document type tag that is determined by the settings within Moodle.

<code php>
<html <?php echo $OUTPUT->htmlattributes() ?>>
</code>
Here we open the HTML tag and then ask Moodle to print the attributes that should go inside it.

<code php>
<title><?php echo $PAGE->title ?></title>
</code>
Simply creates the title tag and asks Moodle to fill it in.

<code php>
<?php echo $OUTPUT->standard_head_html() ?>
</code>
Here we are asking Moodle to print all of the other tags and content that need to go into the head. This includes stylesheets, script tags, and inline JavaScript code.

===The page header===

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<div id="page">
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
<div id="page-header">
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div>
<?php } ?>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</div>
<?php } ?>
</code>

So there is a bit more going on here obviously.

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
</code>
Again much like what we did for the opening HTML tag in the head we have started writing the opening body tag and are then asking Moodle to give us the ID we should use for the body tag as well as the classes we should use.

<code php>
<?php echo $OUTPUT->standard_top_of_body_html() ?>
</code>
This very important call writes some critical bits of JavaScript into the page. It should always be located after the body tag as soon as possible.

<code php>
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
......
<?php } ?>
</code>
Here we are checking whether or not we need to print the header for the page. There are three checks we need to make here:
# '''$PAGE->heading''' : This checks to make sure that there is a heading for the page. This will have been set by the script and normally describes the page in a couple of words.
# '''empty($PAGE->layout_options['nonavbar'])''' : Now this check is looking at the layout options that we set in our config.php file. It is looking to see if the layout set 'nonavbar' => true.
# '''$PAGE->has_navbar()''' The third check is to check with the page whether it has a navigation bar to display.
If either there is a heading for this page or there is a navigation bar to display then we will display a heading.

Leading on from this lets assume that there is a header to print.
<code php>
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
.....
<?php } ?>
</code>
This line is simply saying if the page has a heading print it. In this case we run the first check above again just to make sute there is a heading, we then open a heading tag that we choose and ask the page to print the heading.

<code php>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div>
</code>
Here we are looking to print the menu and content that you see at the top of the page (usually to the right). We start by getting Moodle to print the login information for the current user. If the user is logged in this will be their name and a link to their profile, if not then it will be a link to login.

Next we check our page options to see whether a language menu should be printed. If in the layout definition within config.php it sets '''langmenu => true''' then we will print the language menu, a drop down box that lets the user change the language that Moodle displays in.

Finally the page also has a heading menu that can be printed. This heading menu is special HTML that the page you are viewing wants to add. It can be anything from drop down boxes to buttons and any number of each.

<code php>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</code>
The final part of the header.

Here we want to print the navigation bar for the page if there is one. To find out if there is one we run checks number 2 and 3 again and proceed if they pass.

Assuming there is a header then there are two things that we need to print. The first is the navigation bar. This is a component that the OUTPUT library knows about. The second is a button to show on the page.

In both cases we choose to wrap them in a div tag with a class attribute to enable theming on those elements.

Well that is it for the header. There is a lot of PHP compared to the other sections of the layout file but it does not change and can be copied and pasted between themes.

===The page content===

I am going with the default two block regions plus the main content.

Because I have based this theme and layout file on the base theme the HTML looks a little intense. This is because it is a floating div layout where the content comes first and then we get the columns (even though one column will be to the left of the content.) Don't worry too much about it. When it comes to writing your own theme you can go about it as you choose.

<code php>
<div id="page-content">
<div id="region-main-box">
<div id="region-post-box">
<div id="region-main-wrap">
<div id="region-main">
<div class="region-content">
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</div>
</div>
</div>
<?php if ($hassidepre) { ?>
<div id="region-pre">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</div>
</div>
<?php } ?>

<?php if ($hassidepost) { ?>
<div id="region-post">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</div>
</div>
<?php } ?>
</div>
</div>
</div>
</code>

In regards to PHP this section is very easy. There are only three lines for the whole section one to get the main content and one for each block region.
<code php>
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</code>
This line prints the main content for the page.

<code php>
<?php if ($hassidepre) { ?>
....
<?php } ?>
</code>
These lines of code check the variables we created earlier on to decide whether we should show the pre block region. If you try to display a block region that isn't there or has no content then Moodle will give you an error message so these lines are very important.

For those who get an error message if it is "unknown block region side-pre" or "unknown block region side-post" then this is the issue you are experiencing. Simply add the following lines and all will be fine.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</code>
This line gets all of the blocks and more particularly the content for the block region '''side-pre'''. This block region will be displayed to the left of the content.

<code php>
<?php if ($hassidepost) { ?>
....
<?php } ?>
</code>
Again we should make this check for every block region as there are some pages that have no blocks what-so-ever.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</code>
Here we are getting the other block region '''side-post''' which will be displayed to the right of the content.

===The page footer===
Here we want to print the footer for the page, any content required by Moodle, and then close the last tags.
<code php>
<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</div>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

The section of code is responsible for printing the footer for the page.
<code php>
<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</code>
The first thing we do before printing the footer is check that we actually want to print it. This is done by checking the options for the layout as defined in the config.php file. If '''nofooter => true''' is set the we don't want to print the footer and should skip over this body of code.

Assuming we want to print a footer we proceed to create a div to house its content and then print the bits of the content that will make it up.
There are four things that the typical page footer will want to print:
; echo page_doc_link(get_string('moodledocslink')) : This will print a link to the Moodle.org help page for this particular page.
; echo $OUTPUT->login_info(); : This is the same as at the top of the page and will print the login information for the current user.
; echo $OUTPUT->home_link(); : This prints a link back to the Moodle home page for this site.
; echo $OUTPUT->standard_footer_html(); : This prints special HTML that is determined by the settings for the site. Things such as performance information or debugging will be printed by this line if they are turned on.

And the final line of code for our layout file is:
<code php>
<?php echo $OUTPUT->standard_end_of_body_html(); ?>
</code>
This is one of the most important lines of code in the layout file. It asks Moodle to print any required content into the page, and there will likely be a lot although most of it will not be visual.

It will instead be things such as inline scripts and JavaScript files required to go at the bottom of the page. If you forget this line its likely no JavaScript will work!

We've now written our layout file and it is all set to go. The complete source is below for reference. Remember if you want more practical examples simply look at the layout files located within the layout directory of other themes.

<code php>
<?php
$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);
echo $OUTPUT->doctype() ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title; ?></title>
<link rel="shortcut icon" href="<?php echo $OUTPUT->pix_url('favicon', 'theme')?>" />
<?php echo $OUTPUT->standard_head_html() ?>
</head>

<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<div id="page">
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
<div id="page-header">
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div><?php } ?>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</div>
<?php } ?>

<div id="page-content">
<div id="region-main-box">
<div id="region-post-box">
<div id="region-main-wrap">
<div id="region-main">
<div class="region-content">
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</div>
</div>
</div>
<?php if ($hassidepre) { ?>
<div id="region-pre">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</div>
</div>
<?php } ?>

<?php if ($hassidepost) { ?>
<div id="region-post">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</div>
</div>
<?php } ?>
</div>
</div>
</div>

<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</div>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

==Adding some CSS==
With config.php and standard.php both complete the theme is now usable and starting to look like a real theme, however if you change to it using the theme selector you will notice that it still lacks any style.

This of course is where CSS comes in. When writing code Moodle developers are strongly encouraged to not use inline styles anywhere. This is fantastic for us as themers because there is nothing (or at least very little) in Moodle that cannot be styled using CSS.

===Moodle CSS basics===

In Moodle 2.0 all of the CSS for the whole of Moodle is delivered all of the time! This was done for performance reasons. Moodle now reads in all of the CSS, combines it into one file, shrinks it removing any white space, caches it, and then delivers it.

'''What this means for you as a themer?'''

You will need to write good CSS that won't clash with any other CSS within Moodle.

Moodle is so big and complex,there is no way to ensure that classes don't get reused. What we can control however is the classes and id that get added to the body tag for every page. When writing CSS it is highly encouraged to make full use of these body classes, using them will help ensure the CSS you write has the least chance of causing conflicts.

You should also take the time to look at how the Moodle themes use CSS. Look at their use of the body classes and how they separate the CSS for the theme into separate files based on the region of Moodle it applies to.

Check out [[Themes 2.0|Themes 2.0]] and [[CSS coding style]] for more information about writing good CSS.

===Starting to write excitement.css===

<code css>
a {
text-decoration: none;
}

.addcoursebutton .singlebutton {
text-align: center;
}

h1.headermain {
color: #fff;
}

h2.main {
border-bottom: 3px solid #013D6A;
color: #013D6A;
text-align: center;
}

h2.headingblock {
font-size: 18pt;
margin-top: 0;
background-color: #013D6A;
color: #FFF;
text-align: center;
}

#page-header {
background-color: #013D6A;
}

#page-header .headermenu {
color: #FFF;
}

#page-header .headermenu a {
color: #FDFF2A;
}

.navbar {
padding-left: 1em;
}

.breadcrumb li {
color: #FFF;
}

.breadcrumb li a {
color: #FFF;
}

.block {
background-color: #013D6A;
}

.block .header .title {
color: #FFF;
}

.block .header .title .block_action input {
background-color: #FFF;
}

.block .content {
border: 1px solid #000;
padding: 5px;
background-color: #FFF;
}

.block .content .block_tree p {
font-size: 80%;
}

.block_settings_navigation_tree .content .footer {
text-align: center;
}

.block_settings_navigation_tree .content .footer .adminsearchform {
margin-left: 5%;
width: 90%;
font-size: 9pt;
}

.block_settings_navigation_tree .content .footer .adminsearchform #adminsearchquery {
width: 95%;
}

.block_calendar_month .content .calendar-controls a {
color: #013D6A;
font-weight: bold;
}

.block_calendar_month .content .minicalendar td {
border-color: #FFF;
}

.block_calendar_month .content .minicalendar .day {
color: #FFF;
background-color: #013D6A;
}

.block_calendar_month .content .minicalendar .day a {
color: #FFF000;
}

.block_calendar_month .content .minicalendar .weekdays th {
border-width: 0;
font-weight: bold;
color: #013D6A;
}

.block_calendar_month .content .minicalendar .weekdays abbr {
border-width: 0;
text-decoration: none;
}
</code>
[[image:Learn_to_theme_02.jpg|400px|thumb|Excitement theme screenshot]]
This isn't all of the CSS for the theme, but just enough to style the front page when the user is not logged in.
Remember this theme extends the base theme so there is already CSS for layout as well.

Note:
* The CSS is laid out in a single line format. This is done within the core themes for Moodle. It makes it quicker to read the selectors and see what is being styled.
* I have written my selectors to take into account the structure of the HTML (more than just the one tag I want to style). This helps further to reduce the conflicts that I may encounter.
* I use generic classes like ''.sideblock'' only where I want to be generic, as soon as I want to be specific I use the unique classes such as ''.block_calendar_month''

<br style="clear:right;" />

===Using images within CSS===

I will add two image files to the pix directory of my theme:
; /theme/excitement/pix/background.png : This will be the background image for my theme.
; /theme/excitement/pix/gradient.jpg : This will be a gradient I use for the header and headings.
I quickly created both of these images using gimp and simply saved them to the pix directory.
<code css>
html {
background-image: url([[pix:theme|background]]);
}

h2.headingblock,
#page-header,
.sideblock,
.block_calendar_month .content .minicalendar .day {
background-image: url([[pix:theme|gradient]]);
background-repeat: repeat-x;
background-color: #0273C8;
}
</code>
[[image:Learn_to_theme_03.jpg‎|400px|thumb|Excitement theme screenshot]]
The CSS above is the two new rules that I had to write to use my images within CSS.

The first rule sets the background image for the page to background.png

The second rule sets the background for headings, and the sideblocks to use gradient.jpg

You will notice that I did not need to write a path to the image. This is because Moodle has this special syntax that can be used and will be replaced when the CSS is parsed before delivery.
The advantage of using this syntax over writing the path in is that the path may change depending on where you are or what theme is being used.

Other themers may choose to extend your theme with their own; if you use this syntax then all they need to do to override the image is to create one with the same name in their themes directory.

You will also notice that I don't need to add the image files extension. This is because Moodle is smart enough to work out what extension the file uses. It also allows themers to override images with different formats.

<br style="clear:right" />
The following is the complete CSS for my theme:
<div style="overflow:auto;height:860px;">
<code css>
a {text-decoration: none;}
.addcoursebutton .singlebutton {text-align: center;}

h1.headermain {color: #fff;}
h2.main {border-bottom: 3px solid #013D6A;color: #013D6A;text-align: center;}
h2.headingblock {font-size: 18pt;margin-top: 0;background-color: #013D6A;color: #FFF;text-align: center;}
#page-header {background-color: #013D6A;border-bottom:5px solid #013D6A;}
#page-header .headermenu {color: #FFF;}
#page-header .headermenu a {color: #FDFF2A;}

.sideblock {background-color: #013D6A;}
.sideblock .header .title {color: #FFF;}
.sideblock .header .title .block_action input {background-color: #FFF;}
.sideblock .content {border: 1px solid #000;padding: 5px;background-color: #FFF;}
.sideblock .content .block_tree p {font-size: 80%;}

.block_settings_navigation_tree .content .footer {text-align: center;}
.block_settings_navigation_tree .content .footer .adminsearchform {margin-left: 5%;width: 90%;font-size: 9pt;}
.block_settings_navigation_tree .content .footer .adminsearchform #adminsearchquery {width: 95%;}

.block_calendar_month .content .calendar-controls a {color: #013D6A;font-weight: bold;}
.block_calendar_month .content .minicalendar td {border-color: #FFF;}
.block_calendar_month .content .minicalendar .day {color: #FFF;background-color: #013D6A;}
.block_calendar_month .content .minicalendar .day a {color: #FFF000;}
.block_calendar_month .content .minicalendar .weekdays th {border-width: 0;font-weight: bold;color: #013D6A;}
.block_calendar_month .content .minicalendar .weekdays abbr {border-width: 0;text-decoration: none;}

html {background-image:url([[pix:theme|background]]);}

h2.headingblock,
#page-header,
.sideblock,
.block_calendar_month .content .minicalendar .day {background-image:url([[pix:theme|gradient]]);
background-repeat:repeat-x;background-color: #0273C8;}
</code>
</div>

==Adding a screenshot and favicon==
The final thing to do at this point is add both a screenshot for this theme as well as a favicon for it.
The screenshot will be shown in the theme selector screen and should be named ''screenshot.jpg''.
The favicon will be used when someone bookmarks this page.
Both images should be located in your themes pix directory as follows:
* /theme/excitement/pix/screenshot.jpg
* /theme/excitement/pix/favicon.ico

In the case of my theme I have taken a screenshot and added it to that directory, and because I don't really want to do anything special with the favicon I have copied it from /theme/base/pix/favicon.ico so that at least it will be recognisable as Moodle.

==See also==
* [[Themes 2.0]]
* [[Themes 2.0 overriding a renderer]]

[[Category:Themes]]
[[es:Desarollo:Temas 2.0 creando tu primer tema]]

Creating a theme

2011-12-28T03:16:50Z

Dwahl: /* Starting to write excitement.css */

{{Template:Themes}}{{Moodle 2.0}}This document describes how to create a theme for Moodle 2.0. It assumes you have some understanding of how themes within Moodle work as well as a good understanding of HTML and CSS.

===Theme designer mode===

Under normal operation Moodle does several things in the name of performance, one of these is to combine all of the CSS into one file, minimize it, cache it on the server, and then serve it. After the first request the cached version is served to greatly improve page performance.

What this means for you as a themer? When you make changes they will not be seen immediately. In fact you will need to tell Moodle to rebuild the cache that it is serving.
This isn't practical for designing themes of course so the '''theme designer mode''' was added. When enabled it tells Moodle not to combine or cache the CSS that gets delivered. This has the downside that page load times will take significantly longer, however you will see your changes immediately every time.

Theme designer mode may be enabled via ''Administration > Appearance > Themes > [[Theme settings]]''.

'''Warning''': Internet Explorer versions 6 and 7 have BIG problems when a site attempts to link to more than 31 stylesheets, in which case either a limited number or no styles get applied. Because Moodle sends up all of the CSS all of the time with theme designer mode turned on there is a very high chance you will get more than 31 stylesheets being included. This will, of course, cause major problems for Internet Explorer until theme designer mode is turned off.

==Getting started==

The first thing you need to do is create the directories and files you will be using, the first thing to create is the actual directory for your theme. This should be the name of your theme, in my case it's 'excitement'. The directory should be located within the theme directory of Moodle, ./moodle/theme/excitement/ will be the directory I create.

Now within that directory we can immediately create several files that we know we are going to need.

So the files that we want to create are:
; config.php : All of our settings will go here.
; /style/ : This directory will contain all of our stylesheets.
; /style/excitement.css : All of our css will go in here.
; /pix/ : Into this directory we'll put a screen shot of our theme as well as our favicon and any images we use in CSS.
; /layout/ : Our layout files will end up in this directory.
; /layout/standard.php : This will be our one basic layout file.
; /lang/en/ : The file we put here will make our theme name show properly on the Theme Selector page. You need a few standard entries. Copy the one from the Standard theme and modify is easiest.

So after this setup step you should have a directory structure similar to what is shown below.

[[image:Learn_to_theme_01.jpg]]

==Configuring our theme==

Open config.php in your favourite editor and start by adding the opening PHP tags '''<nowiki><?php</nowiki>'''.

Now we need to add the settings:

<code php>
$THEME->name = 'excitement';
</code>
Very simply this tells Moodle the name of your theme, and if you ever have several config.php files open this will help you identify which one you are looking at.

Next, the parents for this theme.
<code php>
$THEME->parents = array('base');
</code>
This tells Moodle that my new theme ''`excitement`' wants to extend the base theme.

A theme can extend any number of themes. Rather than creating an entirely new theme and copying all of the CSS, you can simply create a new theme, extend the theme you like and just add the changes you want to your theme.

Also worth noting is the purpose of the base theme: it provides us with a basic layout and just enough CSS to make everything fall into place.

Now we will tell Moodle about our stylesheets:
<code php>
$THEME->sheets = array('excitement');
</code>

The final thing we need to add into our theme's config.php file is the definition of the layouts for our theme:
<code php>
$THEME->layouts = array(
'base' => array(
'file' => 'standard.php',
'regions' => array(),
),
'standard' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'course' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post'
),
'coursecategory' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'incourse' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'frontpage' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'admin' => array(
'file' => 'standard.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
'mydashboard' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
'options' => array('langmenu'=>true),
),
'mypublic' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'login' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('langmenu'=>true),
),
'popup' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true),
),
'frametop' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true),
),
'maintenance' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true, 'nonavbar'=>true),
),
'print' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true, 'nonavbar'=>false),
),
);

/** List of javascript files that need to be included on each page */
$THEME->javascripts = array();
$THEME->javascripts_footer = array();

</code>

What you are looking at is the different layouts for our theme. Why are there so many? Because, that is how many there are in Moodle. There is one for every general type of page. With my ''`excitement`'' theme I have chosen to use my own layout. Unless there was a specific reason to do so, normally you would not need to create your own layouts, you could extend the base theme, and use its layouts, meaning you would only have to write CSS to achieve your desired look.

For each layout above, you will notice the following four things are being set:
; file : This is the name of the layout file we want to use, it should always be located in the above themes layout directory. For us this is of course standard.php as we only have one layout file.
; regions : This is an array of block regions that our theme has. Each entry in here can be used to put blocks in when that layout is being used.
; defaultregion : If a layout has regions it should have a default region, this is where blocks get put when first added.
; options : These are special settings, anything that gets put into the options array is available later on when we are writing our layout file.

There are additional settings that can be defined in the config.php file - see [[Themes 2.0|Themes 2.0]] for the full list.

==Configuring the language file==
Open theme_base.php file from '''base/lang/en/theme_base.php'''

Save it as '''excitement/lang/en/theme_excitement.php'''.

Change
<code php>
$string['pluginname'] = 'Base';
</code>
to
<code php>
$string['pluginname'] = 'Excitement';
</code>

After making these changes and perhaps clearing theme caches and/or purging all caches, the new theme name should now show properly in the Theme Selector: ''Site Administration > Appearance > Themes > Theme Selector''

You can also edit the theme description:

<code php>
$string['choosereadme'] = 'Write your theme description here.';
</code>

You need to leave the following two lines in place (you can change the wording if you need to) to avoid notices when editing blocks etc.:

<code php>
$string['region-side-post'] = 'Right';
$string['region-side-pre'] = 'Left';
</code>

==Writing the layout file==

The excitement theme has just one layout file.

The downside of this is that I have to make the layout file do everything I want which means I need to make use of some options (as defined in the layouts in config.php).

The upside is that I only need to maintain one file.

Other than maintenance, using multiple layout files provides many advantages to real world themes in that you can easily tweak and customise specific layouts to achieve the goals of the organisation using the theme.

Before learning more it is good to understand the two primary objects that will be used in your layout files: $OUTPUT and $PAGE.

'''$OUTPUT''' is an instance of the <code>core_renderer</code> class which is defined in lib/outputrenderers.php. Each method is clearly documented there, along with which is appropriate for use within the layout files.

'''$PAGE''' is an instance of the <code>moodle_page</code> class defined in lib/pagelib.php. Most of the things you will want to use are the properties that are all documented at the top of the file. If you are not familiar with PHP properties, you access them like $PAGE->activityname, just like fields of an ordinary PHP object. (However, behind the scenes the value you get is produced by calling a function. Also, you cannot change these values, they are '''read-only'''. However, you don't need to understand all that if you are just using these properties in your theme.)

So lets start writing standard.php, the layout file for my ''`excitement`'' theme.

===The top of the layout file===

<code php>
<?php
$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);
echo $OUTPUT->doctype(); ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title ?></title>
<?php echo $OUTPUT->standard_head_html() ?>
</head>
</code>

Lets look at the code that goes into this section:
<code php>
<?php
echo $OUTPUT->doctype(); ?>
</code>
This is very important and is required to go at the very top of the page. This tells Moodle to print out the document type tag that is determined by the settings within Moodle.

<code php>
<html <?php echo $OUTPUT->htmlattributes() ?>>
</code>
Here we open the HTML tag and then ask Moodle to print the attributes that should go inside it.

<code php>
<title><?php echo $PAGE->title ?></title>
</code>
Simply creates the title tag and asks Moodle to fill it in.

<code php>
<?php echo $OUTPUT->standard_head_html() ?>
</code>
Here we are asking Moodle to print all of the other tags and content that need to go into the head. This includes stylesheets, script tags, and inline JavaScript code.

===The page header===

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<div id="page">
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
<div id="page-header">
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div>
<?php } ?>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</div>
<?php } ?>
</code>

So there is a bit more going on here obviously.

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
</code>
Again much like what we did for the opening HTML tag in the head we have started writing the opening body tag and are then asking Moodle to give us the ID we should use for the body tag as well as the classes we should use.

<code php>
<?php echo $OUTPUT->standard_top_of_body_html() ?>
</code>
This very important call writes some critical bits of JavaScript into the page. It should always be located after the body tag as soon as possible.

<code php>
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
......
<?php } ?>
</code>
Here we are checking whether or not we need to print the header for the page. There are three checks we need to make here:
# '''$PAGE->heading''' : This checks to make sure that there is a heading for the page. This will have been set by the script and normally describes the page in a couple of words.
# '''empty($PAGE->layout_options['nonavbar'])''' : Now this check is looking at the layout options that we set in our config.php file. It is looking to see if the layout set 'nonavbar' => true.
# '''$PAGE->has_navbar()''' The third check is to check with the page whether it has a navigation bar to display.
If either there is a heading for this page or there is a navigation bar to display then we will display a heading.

Leading on from this lets assume that there is a header to print.
<code php>
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
.....
<?php } ?>
</code>
This line is simply saying if the page has a heading print it. In this case we run the first check above again just to make sute there is a heading, we then open a heading tag that we choose and ask the page to print the heading.

<code php>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div>
</code>
Here we are looking to print the menu and content that you see at the top of the page (usually to the right). We start by getting Moodle to print the login information for the current user. If the user is logged in this will be their name and a link to their profile, if not then it will be a link to login.

Next we check our page options to see whether a language menu should be printed. If in the layout definition within config.php it sets '''langmenu => true''' then we will print the language menu, a drop down box that lets the user change the language that Moodle displays in.

Finally the page also has a heading menu that can be printed. This heading menu is special HTML that the page you are viewing wants to add. It can be anything from drop down boxes to buttons and any number of each.

<code php>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</code>
The final part of the header.

Here we want to print the navigation bar for the page if there is one. To find out if there is one we run checks number 2 and 3 again and proceed if they pass.

Assuming there is a header then there are two things that we need to print. The first is the navigation bar. This is a component that the OUTPUT library knows about. The second is a button to show on the page.

In both cases we choose to wrap them in a div tag with a class attribute to enable theming on those elements.

Well that is it for the header. There is a lot of PHP compared to the other sections of the layout file but it does not change and can be copied and pasted between themes.

===The page content===

I am going with the default two block regions plus the main content.

Because I have based this theme and layout file on the base theme the HTML looks a little intense. This is because it is a floating div layout where the content comes first and then we get the columns (even though one column will be to the left of the content.) Don't worry too much about it. When it comes to writing your own theme you can go about it as you choose.

<code php>
<div id="page-content">
<div id="region-main-box">
<div id="region-post-box">
<div id="region-main-wrap">
<div id="region-main">
<div class="region-content">
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</div>
</div>
</div>
<?php if ($hassidepre) { ?>
<div id="region-pre">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</div>
</div>
<?php } ?>

<?php if ($hassidepost) { ?>
<div id="region-post">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</div>
</div>
<?php } ?>
</div>
</div>
</div>
</code>

In regards to PHP this section is very easy. There are only three lines for the whole section one to get the main content and one for each block region.
<code php>
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</code>
This line prints the main content for the page.

<code php>
<?php if ($hassidepre) { ?>
....
<?php } ?>
</code>
These lines of code check the variables we created earlier on to decide whether we should show the pre block region. If you try to display a block region that isn't there or has no content then Moodle will give you an error message so these lines are very important.

For those who get an error message if it is "unknown block region side-pre" or "unknown block region side-post" then this is the issue you are experiencing. Simply add the following lines and all will be fine.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</code>
This line gets all of the blocks and more particularly the content for the block region '''side-pre'''. This block region will be displayed to the left of the content.

<code php>
<?php if ($hassidepost) { ?>
....
<?php } ?>
</code>
Again we should make this check for every block region as there are some pages that have no blocks what-so-ever.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</code>
Here we are getting the other block region '''side-post''' which will be displayed to the right of the content.

===The page footer===
Here we want to print the footer for the page, any content required by Moodle, and then close the last tags.
<code php>
<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</div>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

The section of code is responsible for printing the footer for the page.
<code php>
<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</code>
The first thing we do before printing the footer is check that we actually want to print it. This is done by checking the options for the layout as defined in the config.php file. If '''nofooter => true''' is set the we don't want to print the footer and should skip over this body of code.

Assuming we want to print a footer we proceed to create a div to house its content and then print the bits of the content that will make it up.
There are four things that the typical page footer will want to print:
; echo page_doc_link(get_string('moodledocslink')) : This will print a link to the Moodle.org help page for this particular page.
; echo $OUTPUT->login_info(); : This is the same as at the top of the page and will print the login information for the current user.
; echo $OUTPUT->home_link(); : This prints a link back to the Moodle home page for this site.
; echo $OUTPUT->standard_footer_html(); : This prints special HTML that is determined by the settings for the site. Things such as performance information or debugging will be printed by this line if they are turned on.

And the final line of code for our layout file is:
<code php>
<?php echo $OUTPUT->standard_end_of_body_html(); ?>
</code>
This is one of the most important lines of code in the layout file. It asks Moodle to print any required content into the page, and there will likely be a lot although most of it will not be visual.

It will instead be things such as inline scripts and JavaScript files required to go at the bottom of the page. If you forget this line its likely no JavaScript will work!

We've now written our layout file and it is all set to go. The complete source is below for reference. Remember if you want more practical examples simply look at the layout files located within the layout directory of other themes.

<code php>
<?php
$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);
echo $OUTPUT->doctype() ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title; ?></title>
<link rel="shortcut icon" href="<?php echo $OUTPUT->pix_url('favicon', 'theme')?>" />
<?php echo $OUTPUT->standard_head_html() ?>
</head>

<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<div id="page">
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
<div id="page-header">
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div><?php } ?>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</div>
<?php } ?>

<div id="page-content">
<div id="region-main-box">
<div id="region-post-box">
<div id="region-main-wrap">
<div id="region-main">
<div class="region-content">
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</div>
</div>
</div>
<?php if ($hassidepre) { ?>
<div id="region-pre">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</div>
</div>
<?php } ?>

<?php if ($hassidepost) { ?>
<div id="region-post">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</div>
</div>
<?php } ?>
</div>
</div>
</div>

<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</div>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

==Adding some CSS==
With config.php and standard.php both complete the theme is now usable and starting to look like a real theme, however if you change to it using the theme selector you will notice that it still lacks any style.

This of course is where CSS comes in. When writing code Moodle developers are strongly encouraged to not use inline styles anywhere. This is fantastic for us as themers because there is nothing (or at least very little) in Moodle that cannot be styled using CSS.

===Moodle CSS basics===

In Moodle 2.0 all of the CSS for the whole of Moodle is delivered all of the time! This was done for performance reasons. Moodle now reads in all of the CSS, combines it into one file, shrinks it removing any white space, caches it, and then delivers it.

'''What this means for you as a themer?'''

You will need to write good CSS that won't clash with any other CSS within Moodle.

Moodle is so big and complex,there is no way to ensure that classes don't get reused. What we can control however is the classes and id that get added to the body tag for every page. When writing CSS it is highly encouraged to make full use of these body classes, using them will help ensure the CSS you write has the least chance of causing conflicts.

You should also take the time to look at how the Moodle themes use CSS. Look at their use of the body classes and how they separate the CSS for the theme into separate files based on the region of Moodle it applies to.

Check out [[Themes 2.0|Themes 2.0]] and [[CSS coding style]] for more information about writing good CSS.

===Starting to write excitement.css===

<code css>
a {
text-decoration: none;
}

.addcoursebutton .singlebutton {
text-align: center;
}

h1.headermain {
color: #fff;
}

h2.main {
border-bottom: 3px solid #013D6A;
color: #013D6A;
text-align: center;
}

h2.headingblock {
font-size: 18pt;
margin-top: 0;
background-color: #013D6A;
color: #FFF;
text-align: center;
}

#page-header {
background-color: #013D6A;
}

#page-header .headermenu {
color: #FFF;
}

#page-header .headermenu a {
color: #FDFF2A;
}

.navbar {
padding-left: 1em;
}

.breadcrumb li {
color: #FFF;
}

.breadcrumb li a {
color: #FFF;
}

.block {
background-color: #013D6A;
}

.block .header .title {
color: #FFF;
}

.block .header .title .block_action input {
background-color: #FFF;
}

.block .content {
border: 1px solid #000;
padding: 5px;
background-color: #FFF;
}

.block .content .block_tree p {
font-size: 80%;
}

.block_settings_navigation_tree .content .footer {
text-align: center;
}

.block_settings_navigation_tree .content .footer .adminsearchform {
margin-left: 5%;
width: 90%;
font-size: 9pt;
}

.block_settings_navigation_tree .content .footer .adminsearchform #adminsearchquery {
width: 95%;
}

.block_calendar_month .content .calendar-controls a {
color: #013D6A;
font-weight: bold;
}

.block_calendar_month .content .minicalendar td {
border-color: #FFF;
}

.block_calendar_month .content .minicalendar .day {
color: #FFF;
background-color: #013D6A;
}

.block_calendar_month .content .minicalendar .day a {
color: #FFF000;
}

.block_calendar_month .content .minicalendar .weekdays th {
border-width: 0;
font-weight: bold;
color: #013D6A;
}

.block_calendar_month .content .minicalendar .weekdays abbr {
border-width: 0;
text-decoration: none;
}
</code>
[[image:Learn_to_theme_02.jpg|400px|thumb|Excitement theme screenshot]]
This isn't all of the CSS for the theme, but just enough to style the front page when the user is not logged in.
Remember this theme extends the base theme so there is already CSS for layout as well.

Note:
* The CSS is laid out in a single line format. This is done within the core themes for Moodle. It makes it quicker to read the selectors and see what is being styled.
* I have written my selectors to take into account the structure of the HTML (more than just the one tag I want to style). This helps further to reduce the conflicts that I may encounter.
* I use generic classes like ''.sideblock'' only where I want to be generic, as soon as I want to be specific I use the unique classes such as ''.block_calendar_month''

<br style="clear:right;" />

===Using images within CSS===

I will add two image files to the pix directory of my theme:
; /theme/excitement/pix/background.png : This will be the background image for my theme.
; /theme/excitement/pix/gradient.jpg : This will be a gradient I use for the header and headings.
I quickly created both of these images using gimp and simply saved them to the pix directory.
<code css>
html {background-image:url([[pix:theme|background]]);}

h2.headingblock,
#page-header,
.sideblock,
.block_calendar_month .content .minicalendar .day {background-image:url([[pix:theme|gradient]]);background-repeat:repeat-x;background-color: #0273C8;}
</code>
[[image:Learn_to_theme_03.jpg‎|400px|thumb|Excitement theme screenshot]]
The CSS above is the two new rules that I had to write to use my images within CSS.

The first rule sets the background image for the page to background.png

The second rule sets the background for headings, and the sideblocks to use gradient.jpg

You will notice that I did not need to write a path to the image. This is because Moodle has this special syntax that can be used and will be replaced when the CSS is parsed before delivery.
The advantage of using this syntax over writing the path in is that the path may change depending on where you are or what theme is being used.

Other themers may choose to extend your theme with their own; if you use this syntax then all they need to do to override the image is to create one with the same name in their themes directory.

You will also notice that I don't need to add the image files extension. This is because Moodle is smart enough to work out what extension the file uses. It also allows themers to override images with different formats.

<br style="clear:right" />
The following is the complete CSS for my theme:
<div style="overflow:auto;height:860px;">
<code css>
a {text-decoration: none;}
.addcoursebutton .singlebutton {text-align: center;}

h1.headermain {color: #fff;}
h2.main {border-bottom: 3px solid #013D6A;color: #013D6A;text-align: center;}
h2.headingblock {font-size: 18pt;margin-top: 0;background-color: #013D6A;color: #FFF;text-align: center;}
#page-header {background-color: #013D6A;border-bottom:5px solid #013D6A;}
#page-header .headermenu {color: #FFF;}
#page-header .headermenu a {color: #FDFF2A;}

.sideblock {background-color: #013D6A;}
.sideblock .header .title {color: #FFF;}
.sideblock .header .title .block_action input {background-color: #FFF;}
.sideblock .content {border: 1px solid #000;padding: 5px;background-color: #FFF;}
.sideblock .content .block_tree p {font-size: 80%;}

.block_settings_navigation_tree .content .footer {text-align: center;}
.block_settings_navigation_tree .content .footer .adminsearchform {margin-left: 5%;width: 90%;font-size: 9pt;}
.block_settings_navigation_tree .content .footer .adminsearchform #adminsearchquery {width: 95%;}

.block_calendar_month .content .calendar-controls a {color: #013D6A;font-weight: bold;}
.block_calendar_month .content .minicalendar td {border-color: #FFF;}
.block_calendar_month .content .minicalendar .day {color: #FFF;background-color: #013D6A;}
.block_calendar_month .content .minicalendar .day a {color: #FFF000;}
.block_calendar_month .content .minicalendar .weekdays th {border-width: 0;font-weight: bold;color: #013D6A;}
.block_calendar_month .content .minicalendar .weekdays abbr {border-width: 0;text-decoration: none;}

html {background-image:url([[pix:theme|background]]);}

h2.headingblock,
#page-header,
.sideblock,
.block_calendar_month .content .minicalendar .day {background-image:url([[pix:theme|gradient]]);
background-repeat:repeat-x;background-color: #0273C8;}
</code>
</div>

==Adding a screenshot and favicon==
The final thing to do at this point is add both a screenshot for this theme as well as a favicon for it.
The screenshot will be shown in the theme selector screen and should be named ''screenshot.jpg''.
The favicon will be used when someone bookmarks this page.
Both images should be located in your themes pix directory as follows:
* /theme/excitement/pix/screenshot.jpg
* /theme/excitement/pix/favicon.ico

In the case of my theme I have taken a screenshot and added it to that directory, and because I don't really want to do anything special with the favicon I have copied it from /theme/base/pix/favicon.ico so that at least it will be recognisable as Moodle.

==See also==
* [[Themes 2.0]]
* [[Themes 2.0 overriding a renderer]]

[[Category:Themes]]
[[es:Desarollo:Temas 2.0 creando tu primer tema]]

Creating a theme

2011-12-28T03:13:14Z

Dwahl: /* Moodle CSS basics */

{{Template:Themes}}{{Moodle 2.0}}This document describes how to create a theme for Moodle 2.0. It assumes you have some understanding of how themes within Moodle work as well as a good understanding of HTML and CSS.

===Theme designer mode===

Under normal operation Moodle does several things in the name of performance, one of these is to combine all of the CSS into one file, minimize it, cache it on the server, and then serve it. After the first request the cached version is served to greatly improve page performance.

What this means for you as a themer? When you make changes they will not be seen immediately. In fact you will need to tell Moodle to rebuild the cache that it is serving.
This isn't practical for designing themes of course so the '''theme designer mode''' was added. When enabled it tells Moodle not to combine or cache the CSS that gets delivered. This has the downside that page load times will take significantly longer, however you will see your changes immediately every time.

Theme designer mode may be enabled via ''Administration > Appearance > Themes > [[Theme settings]]''.

'''Warning''': Internet Explorer versions 6 and 7 have BIG problems when a site attempts to link to more than 31 stylesheets, in which case either a limited number or no styles get applied. Because Moodle sends up all of the CSS all of the time with theme designer mode turned on there is a very high chance you will get more than 31 stylesheets being included. This will, of course, cause major problems for Internet Explorer until theme designer mode is turned off.

==Getting started==

The first thing you need to do is create the directories and files you will be using, the first thing to create is the actual directory for your theme. This should be the name of your theme, in my case it's 'excitement'. The directory should be located within the theme directory of Moodle, ./moodle/theme/excitement/ will be the directory I create.

Now within that directory we can immediately create several files that we know we are going to need.

So the files that we want to create are:
; config.php : All of our settings will go here.
; /style/ : This directory will contain all of our stylesheets.
; /style/excitement.css : All of our css will go in here.
; /pix/ : Into this directory we'll put a screen shot of our theme as well as our favicon and any images we use in CSS.
; /layout/ : Our layout files will end up in this directory.
; /layout/standard.php : This will be our one basic layout file.
; /lang/en/ : The file we put here will make our theme name show properly on the Theme Selector page. You need a few standard entries. Copy the one from the Standard theme and modify is easiest.

So after this setup step you should have a directory structure similar to what is shown below.

[[image:Learn_to_theme_01.jpg]]

==Configuring our theme==

Open config.php in your favourite editor and start by adding the opening PHP tags '''<nowiki><?php</nowiki>'''.

Now we need to add the settings:

<code php>
$THEME->name = 'excitement';
</code>
Very simply this tells Moodle the name of your theme, and if you ever have several config.php files open this will help you identify which one you are looking at.

Next, the parents for this theme.
<code php>
$THEME->parents = array('base');
</code>
This tells Moodle that my new theme ''`excitement`' wants to extend the base theme.

A theme can extend any number of themes. Rather than creating an entirely new theme and copying all of the CSS, you can simply create a new theme, extend the theme you like and just add the changes you want to your theme.

Also worth noting is the purpose of the base theme: it provides us with a basic layout and just enough CSS to make everything fall into place.

Now we will tell Moodle about our stylesheets:
<code php>
$THEME->sheets = array('excitement');
</code>

The final thing we need to add into our theme's config.php file is the definition of the layouts for our theme:
<code php>
$THEME->layouts = array(
'base' => array(
'file' => 'standard.php',
'regions' => array(),
),
'standard' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'course' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post'
),
'coursecategory' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'incourse' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'frontpage' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'admin' => array(
'file' => 'standard.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
'mydashboard' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
'options' => array('langmenu'=>true),
),
'mypublic' => array(
'file' => 'standard.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
),
'login' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('langmenu'=>true),
),
'popup' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true),
),
'frametop' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true),
),
'maintenance' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true, 'nonavbar'=>true),
),
'print' => array(
'file' => 'standard.php',
'regions' => array(),
'options' => array('nofooter'=>true, 'nonavbar'=>false),
),
);

/** List of javascript files that need to be included on each page */
$THEME->javascripts = array();
$THEME->javascripts_footer = array();

</code>

What you are looking at is the different layouts for our theme. Why are there so many? Because, that is how many there are in Moodle. There is one for every general type of page. With my ''`excitement`'' theme I have chosen to use my own layout. Unless there was a specific reason to do so, normally you would not need to create your own layouts, you could extend the base theme, and use its layouts, meaning you would only have to write CSS to achieve your desired look.

For each layout above, you will notice the following four things are being set:
; file : This is the name of the layout file we want to use, it should always be located in the above themes layout directory. For us this is of course standard.php as we only have one layout file.
; regions : This is an array of block regions that our theme has. Each entry in here can be used to put blocks in when that layout is being used.
; defaultregion : If a layout has regions it should have a default region, this is where blocks get put when first added.
; options : These are special settings, anything that gets put into the options array is available later on when we are writing our layout file.

There are additional settings that can be defined in the config.php file - see [[Themes 2.0|Themes 2.0]] for the full list.

==Configuring the language file==
Open theme_base.php file from '''base/lang/en/theme_base.php'''

Save it as '''excitement/lang/en/theme_excitement.php'''.

Change
<code php>
$string['pluginname'] = 'Base';
</code>
to
<code php>
$string['pluginname'] = 'Excitement';
</code>

After making these changes and perhaps clearing theme caches and/or purging all caches, the new theme name should now show properly in the Theme Selector: ''Site Administration > Appearance > Themes > Theme Selector''

You can also edit the theme description:

<code php>
$string['choosereadme'] = 'Write your theme description here.';
</code>

You need to leave the following two lines in place (you can change the wording if you need to) to avoid notices when editing blocks etc.:

<code php>
$string['region-side-post'] = 'Right';
$string['region-side-pre'] = 'Left';
</code>

==Writing the layout file==

The excitement theme has just one layout file.

The downside of this is that I have to make the layout file do everything I want which means I need to make use of some options (as defined in the layouts in config.php).

The upside is that I only need to maintain one file.

Other than maintenance, using multiple layout files provides many advantages to real world themes in that you can easily tweak and customise specific layouts to achieve the goals of the organisation using the theme.

Before learning more it is good to understand the two primary objects that will be used in your layout files: $OUTPUT and $PAGE.

'''$OUTPUT''' is an instance of the <code>core_renderer</code> class which is defined in lib/outputrenderers.php. Each method is clearly documented there, along with which is appropriate for use within the layout files.

'''$PAGE''' is an instance of the <code>moodle_page</code> class defined in lib/pagelib.php. Most of the things you will want to use are the properties that are all documented at the top of the file. If you are not familiar with PHP properties, you access them like $PAGE->activityname, just like fields of an ordinary PHP object. (However, behind the scenes the value you get is produced by calling a function. Also, you cannot change these values, they are '''read-only'''. However, you don't need to understand all that if you are just using these properties in your theme.)

So lets start writing standard.php, the layout file for my ''`excitement`'' theme.

===The top of the layout file===

<code php>
<?php
$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);
echo $OUTPUT->doctype(); ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title ?></title>
<?php echo $OUTPUT->standard_head_html() ?>
</head>
</code>

Lets look at the code that goes into this section:
<code php>
<?php
echo $OUTPUT->doctype(); ?>
</code>
This is very important and is required to go at the very top of the page. This tells Moodle to print out the document type tag that is determined by the settings within Moodle.

<code php>
<html <?php echo $OUTPUT->htmlattributes() ?>>
</code>
Here we open the HTML tag and then ask Moodle to print the attributes that should go inside it.

<code php>
<title><?php echo $PAGE->title ?></title>
</code>
Simply creates the title tag and asks Moodle to fill it in.

<code php>
<?php echo $OUTPUT->standard_head_html() ?>
</code>
Here we are asking Moodle to print all of the other tags and content that need to go into the head. This includes stylesheets, script tags, and inline JavaScript code.

===The page header===

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<div id="page">
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
<div id="page-header">
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div>
<?php } ?>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</div>
<?php } ?>
</code>

So there is a bit more going on here obviously.

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
</code>
Again much like what we did for the opening HTML tag in the head we have started writing the opening body tag and are then asking Moodle to give us the ID we should use for the body tag as well as the classes we should use.

<code php>
<?php echo $OUTPUT->standard_top_of_body_html() ?>
</code>
This very important call writes some critical bits of JavaScript into the page. It should always be located after the body tag as soon as possible.

<code php>
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
......
<?php } ?>
</code>
Here we are checking whether or not we need to print the header for the page. There are three checks we need to make here:
# '''$PAGE->heading''' : This checks to make sure that there is a heading for the page. This will have been set by the script and normally describes the page in a couple of words.
# '''empty($PAGE->layout_options['nonavbar'])''' : Now this check is looking at the layout options that we set in our config.php file. It is looking to see if the layout set 'nonavbar' => true.
# '''$PAGE->has_navbar()''' The third check is to check with the page whether it has a navigation bar to display.
If either there is a heading for this page or there is a navigation bar to display then we will display a heading.

Leading on from this lets assume that there is a header to print.
<code php>
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
.....
<?php } ?>
</code>
This line is simply saying if the page has a heading print it. In this case we run the first check above again just to make sute there is a heading, we then open a heading tag that we choose and ask the page to print the heading.

<code php>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div>
</code>
Here we are looking to print the menu and content that you see at the top of the page (usually to the right). We start by getting Moodle to print the login information for the current user. If the user is logged in this will be their name and a link to their profile, if not then it will be a link to login.

Next we check our page options to see whether a language menu should be printed. If in the layout definition within config.php it sets '''langmenu => true''' then we will print the language menu, a drop down box that lets the user change the language that Moodle displays in.

Finally the page also has a heading menu that can be printed. This heading menu is special HTML that the page you are viewing wants to add. It can be anything from drop down boxes to buttons and any number of each.

<code php>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</code>
The final part of the header.

Here we want to print the navigation bar for the page if there is one. To find out if there is one we run checks number 2 and 3 again and proceed if they pass.

Assuming there is a header then there are two things that we need to print. The first is the navigation bar. This is a component that the OUTPUT library knows about. The second is a button to show on the page.

In both cases we choose to wrap them in a div tag with a class attribute to enable theming on those elements.

Well that is it for the header. There is a lot of PHP compared to the other sections of the layout file but it does not change and can be copied and pasted between themes.

===The page content===

I am going with the default two block regions plus the main content.

Because I have based this theme and layout file on the base theme the HTML looks a little intense. This is because it is a floating div layout where the content comes first and then we get the columns (even though one column will be to the left of the content.) Don't worry too much about it. When it comes to writing your own theme you can go about it as you choose.

<code php>
<div id="page-content">
<div id="region-main-box">
<div id="region-post-box">
<div id="region-main-wrap">
<div id="region-main">
<div class="region-content">
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</div>
</div>
</div>
<?php if ($hassidepre) { ?>
<div id="region-pre">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</div>
</div>
<?php } ?>

<?php if ($hassidepost) { ?>
<div id="region-post">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</div>
</div>
<?php } ?>
</div>
</div>
</div>
</code>

In regards to PHP this section is very easy. There are only three lines for the whole section one to get the main content and one for each block region.
<code php>
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</code>
This line prints the main content for the page.

<code php>
<?php if ($hassidepre) { ?>
....
<?php } ?>
</code>
These lines of code check the variables we created earlier on to decide whether we should show the pre block region. If you try to display a block region that isn't there or has no content then Moodle will give you an error message so these lines are very important.

For those who get an error message if it is "unknown block region side-pre" or "unknown block region side-post" then this is the issue you are experiencing. Simply add the following lines and all will be fine.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</code>
This line gets all of the blocks and more particularly the content for the block region '''side-pre'''. This block region will be displayed to the left of the content.

<code php>
<?php if ($hassidepost) { ?>
....
<?php } ?>
</code>
Again we should make this check for every block region as there are some pages that have no blocks what-so-ever.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</code>
Here we are getting the other block region '''side-post''' which will be displayed to the right of the content.

===The page footer===
Here we want to print the footer for the page, any content required by Moodle, and then close the last tags.
<code php>
<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</div>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

The section of code is responsible for printing the footer for the page.
<code php>
<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</code>
The first thing we do before printing the footer is check that we actually want to print it. This is done by checking the options for the layout as defined in the config.php file. If '''nofooter => true''' is set the we don't want to print the footer and should skip over this body of code.

Assuming we want to print a footer we proceed to create a div to house its content and then print the bits of the content that will make it up.
There are four things that the typical page footer will want to print:
; echo page_doc_link(get_string('moodledocslink')) : This will print a link to the Moodle.org help page for this particular page.
; echo $OUTPUT->login_info(); : This is the same as at the top of the page and will print the login information for the current user.
; echo $OUTPUT->home_link(); : This prints a link back to the Moodle home page for this site.
; echo $OUTPUT->standard_footer_html(); : This prints special HTML that is determined by the settings for the site. Things such as performance information or debugging will be printed by this line if they are turned on.

And the final line of code for our layout file is:
<code php>
<?php echo $OUTPUT->standard_end_of_body_html(); ?>
</code>
This is one of the most important lines of code in the layout file. It asks Moodle to print any required content into the page, and there will likely be a lot although most of it will not be visual.

It will instead be things such as inline scripts and JavaScript files required to go at the bottom of the page. If you forget this line its likely no JavaScript will work!

We've now written our layout file and it is all set to go. The complete source is below for reference. Remember if you want more practical examples simply look at the layout files located within the layout directory of other themes.

<code php>
<?php
$hassidepre = $PAGE->blocks->region_has_content('side-pre', $OUTPUT);
$hassidepost = $PAGE->blocks->region_has_content('side-post', $OUTPUT);
echo $OUTPUT->doctype() ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title; ?></title>
<link rel="shortcut icon" href="<?php echo $OUTPUT->pix_url('favicon', 'theme')?>" />
<?php echo $OUTPUT->standard_head_html() ?>
</head>

<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<div id="page">
<?php if ($PAGE->heading || (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar())) { ?>
<div id="page-header">
<?php if ($PAGE->heading) { ?>
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php
echo $OUTPUT->login_info();
if (!empty($PAGE->layout_options['langmenu'])) {
echo $OUTPUT->lang_menu();
}
echo $PAGE->headingmenu
?></div><?php } ?>
<?php if (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar()) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</div>
<?php } ?>

<div id="page-content">
<div id="region-main-box">
<div id="region-post-box">
<div id="region-main-wrap">
<div id="region-main">
<div class="region-content">
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</div>
</div>
</div>
<?php if ($hassidepre) { ?>
<div id="region-pre">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</div>
</div>
<?php } ?>

<?php if ($hassidepost) { ?>
<div id="region-post">
<div class="region-content">
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</div>
</div>
<?php } ?>
</div>
</div>
</div>

<?php if (empty($PAGE->layout_options['nofooter'])) { ?>
<div id="page-footer" class="clearfix">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</div>
<?php } ?>
</div>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

==Adding some CSS==
With config.php and standard.php both complete the theme is now usable and starting to look like a real theme, however if you change to it using the theme selector you will notice that it still lacks any style.

This of course is where CSS comes in. When writing code Moodle developers are strongly encouraged to not use inline styles anywhere. This is fantastic for us as themers because there is nothing (or at least very little) in Moodle that cannot be styled using CSS.

===Moodle CSS basics===

In Moodle 2.0 all of the CSS for the whole of Moodle is delivered all of the time! This was done for performance reasons. Moodle now reads in all of the CSS, combines it into one file, shrinks it removing any white space, caches it, and then delivers it.

'''What this means for you as a themer?'''

You will need to write good CSS that won't clash with any other CSS within Moodle.

Moodle is so big and complex,there is no way to ensure that classes don't get reused. What we can control however is the classes and id that get added to the body tag for every page. When writing CSS it is highly encouraged to make full use of these body classes, using them will help ensure the CSS you write has the least chance of causing conflicts.

You should also take the time to look at how the Moodle themes use CSS. Look at their use of the body classes and how they separate the CSS for the theme into separate files based on the region of Moodle it applies to.

Check out [[Themes 2.0|Themes 2.0]] and [[CSS coding style]] for more information about writing good CSS.

===Starting to write excitement.css===

<code css>
a {text-decoration: none;}
.addcoursebutton .singlebutton {text-align: center;}

h1.headermain {color: #fff;}
h2.main {border-bottom: 3px solid #013D6A;color: #013D6A;text-align: center;}
h2.headingblock {font-size: 18pt;margin-top: 0;background-color: #013D6A;color: #FFF;text-align: center;}
#page-header {background-color: #013D6A;}
#page-header .headermenu {color: #FFF;}
#page-header .headermenu a {color: #FDFF2A;}

.navbar {padding-left: 1em;}
.breadcrumb li {color: #FFF;}
.breadcrumb li a {color: #FFF;}

.block {background-color: #013D6A;}
.block .header .title {color: #FFF;}
.block .header .title .block_action input {background-color: #FFF;}
.block .content {border: 1px solid #000;padding: 5px;background-color: #FFF;}
.block .content .block_tree p {font-size: 80%;}

.block_settings_navigation_tree .content .footer {text-align: center;}
.block_settings_navigation_tree .content .footer .adminsearchform {margin-left: 5%;width: 90%;font-size: 9pt;}
.block_settings_navigation_tree .content .footer .adminsearchform #adminsearchquery {width: 95%;}

.block_calendar_month .content .calendar-controls a {color: #013D6A;font-weight: bold;}
.block_calendar_month .content .minicalendar td {border-color: #FFF;}
.block_calendar_month .content .minicalendar .day {color: #FFF;background-color: #013D6A;}
.block_calendar_month .content .minicalendar .day a {color: #FFF000;}
.block_calendar_month .content .minicalendar .weekdays th {border-width: 0;font-weight: bold;color: #013D6A;}
.block_calendar_month .content .minicalendar .weekdays abbr {border-width: 0;text-decoration: none;}
</code>
[[image:Learn_to_theme_02.jpg|400px|thumb|Excitement theme screenshot]]
This isn't all of the CSS for the theme, but just enough to style the front page when the user is not logged in.
Remember this theme extends the base theme so there is already CSS for layout as well.

Note:
* The CSS is laid out in a single line format. This is done within the core themes for Moodle. It makes it quicker to read the selectors and see what is being styled.
* I have written my selectors to take into account the structure of the HTML (more than just the one tag I want to style). This helps further to reduce the conflicts that I may encounter.
* I use generic classes like ''.sideblock'' only where I want to be generic, as soon as I want to be specific I use the unique classes such as ''.block_calendar_month''

<br style="clear:right;" />

===Using images within CSS===

I will add two image files to the pix directory of my theme:
; /theme/excitement/pix/background.png : This will be the background image for my theme.
; /theme/excitement/pix/gradient.jpg : This will be a gradient I use for the header and headings.
I quickly created both of these images using gimp and simply saved them to the pix directory.
<code css>
html {background-image:url([[pix:theme|background]]);}

h2.headingblock,
#page-header,
.sideblock,
.block_calendar_month .content .minicalendar .day {background-image:url([[pix:theme|gradient]]);background-repeat:repeat-x;background-color: #0273C8;}
</code>
[[image:Learn_to_theme_03.jpg‎|400px|thumb|Excitement theme screenshot]]
The CSS above is the two new rules that I had to write to use my images within CSS.

The first rule sets the background image for the page to background.png

The second rule sets the background for headings, and the sideblocks to use gradient.jpg

You will notice that I did not need to write a path to the image. This is because Moodle has this special syntax that can be used and will be replaced when the CSS is parsed before delivery.
The advantage of using this syntax over writing the path in is that the path may change depending on where you are or what theme is being used.

Other themers may choose to extend your theme with their own; if you use this syntax then all they need to do to override the image is to create one with the same name in their themes directory.

You will also notice that I don't need to add the image files extension. This is because Moodle is smart enough to work out what extension the file uses. It also allows themers to override images with different formats.

<br style="clear:right" />
The following is the complete CSS for my theme:
<div style="overflow:auto;height:860px;">
<code css>
a {text-decoration: none;}
.addcoursebutton .singlebutton {text-align: center;}

h1.headermain {color: #fff;}
h2.main {border-bottom: 3px solid #013D6A;color: #013D6A;text-align: center;}
h2.headingblock {font-size: 18pt;margin-top: 0;background-color: #013D6A;color: #FFF;text-align: center;}
#page-header {background-color: #013D6A;border-bottom:5px solid #013D6A;}
#page-header .headermenu {color: #FFF;}
#page-header .headermenu a {color: #FDFF2A;}

.sideblock {background-color: #013D6A;}
.sideblock .header .title {color: #FFF;}
.sideblock .header .title .block_action input {background-color: #FFF;}
.sideblock .content {border: 1px solid #000;padding: 5px;background-color: #FFF;}
.sideblock .content .block_tree p {font-size: 80%;}

.block_settings_navigation_tree .content .footer {text-align: center;}
.block_settings_navigation_tree .content .footer .adminsearchform {margin-left: 5%;width: 90%;font-size: 9pt;}
.block_settings_navigation_tree .content .footer .adminsearchform #adminsearchquery {width: 95%;}

.block_calendar_month .content .calendar-controls a {color: #013D6A;font-weight: bold;}
.block_calendar_month .content .minicalendar td {border-color: #FFF;}
.block_calendar_month .content .minicalendar .day {color: #FFF;background-color: #013D6A;}
.block_calendar_month .content .minicalendar .day a {color: #FFF000;}
.block_calendar_month .content .minicalendar .weekdays th {border-width: 0;font-weight: bold;color: #013D6A;}
.block_calendar_month .content .minicalendar .weekdays abbr {border-width: 0;text-decoration: none;}

html {background-image:url([[pix:theme|background]]);}

h2.headingblock,
#page-header,
.sideblock,
.block_calendar_month .content .minicalendar .day {background-image:url([[pix:theme|gradient]]);
background-repeat:repeat-x;background-color: #0273C8;}
</code>
</div>

==Adding a screenshot and favicon==
The final thing to do at this point is add both a screenshot for this theme as well as a favicon for it.
The screenshot will be shown in the theme selector screen and should be named ''screenshot.jpg''.
The favicon will be used when someone bookmarks this page.
Both images should be located in your themes pix directory as follows:
* /theme/excitement/pix/screenshot.jpg
* /theme/excitement/pix/favicon.ico

In the case of my theme I have taken a screenshot and added it to that directory, and because I don't really want to do anything special with the favicon I have copied it from /theme/base/pix/favicon.ico so that at least it will be recognisable as Moodle.

==See also==
* [[Themes 2.0]]
* [[Themes 2.0 overriding a renderer]]

[[Category:Themes]]
[[es:Desarollo:Temas 2.0 creando tu primer tema]]

Themes overview

2011-12-28T03:10:16Z

Dwahl: /* Making use of images */

{{Template:Themes}}{{Moodle 2.0}}Welcome to the new world of themes in Moodle 2.0!

A Moodle theme allows the user to change the look and feel of a Moodle site. Themes can be applied on the site, category, course and activity levels by users with permissions to do so. Themes can be designed for specific devices such as mobile phones or tablets. This page explains how themes work in Moodle and is intended to help you create or modify most themes for Moodle 2.0

You can use contributed themes or create your entire own to share with the community. Themes can also be based on parent themes with only few customizations. Themes accomplish this using CSS, changing the underlying markup structure and also adding Javascript to add more advanced behaviors.

Most theme developers simply add a few changes to their new theme by basing it on an existing one. The Moodle Theme architecture is designed in such a way whereby the base theme will act as a fall-back that is used when nothing has been defined in the theme based on it. This makes it easy to create new themes that simply seek out to make minor changes.

==What's new in 2.0==

The theme system was completely redesigned in Moodle 2.0. Known issues have been addressed and new features have been added to meet community requests.

Unfortunately it was not possible to maintain backward compatibility, so all Moodle 1.x themes need to be recreated for Moodle 2.0.

Major changes include:
* Clearer and more consistent CSS classes and IDs throughout all pages in Moodle
* Introduction of layout files (templates) describing overall layout HTML for many different types of pages in Moodle.
* Introduction of renderers, which produce the smaller "parts" of a HTML page. Advanced themes can choose to override these too if they choose.
* Introduction of standard methods for adding Javascript to themes.
* Easier control over icons and images in Moodle.
* The old "standard" theme has been split into two themes:
**'''base''' - contains absolutely basic layout, and
**'''standard''' - which adds CSS to the base theme to make it look like the old standard theme.
* Performance tuning: In normal production mode CSS files are combined into a single optimised file, and both CSS and JavaScript files are minimised to ensure there are no wasted connections or traffic. Files are heavily cached, but also versioned, so that users never need to clear their caches.

==The structure of a theme==

Some important things to know when building good themes:

# '''config.php''' - this file is required in every theme. It defines configuration settings and definitions required to make the theme work in Moodle. These include theme, file, region, default region and options.
# '''Layouts and layout files''' - in config.php there is one definition for each page type (see [[#theme_layouts_table|Appendix A: Theme layouts]] for a list of over 12 types). Each page type definition tells Moodle which layout file will be used, what block regions this page type should display and so on. The layout file contains the HTML and the minimum PHP required to display basic structure of pages. (If you know Moodle 1.9, it's like a combination of header.html and footer.html).
# '''The base theme''' - is not intended to be used for production sites. It sets up the simplest possible generic layout and includes only CSS essential to that layout ''or'' to Moodle as a whole. It tries not to make any unnecessary rules and makes as few assumptions as possible. It's the perfect base on which to start designing a theme, as there are very few colours, borders, margins, and alignments to override. You can just start adding what you need.

===Files and folders===
A theme's files are placed in a folder with under moodle/theme folder and have subfolders. They are laid out like this:

{| class="nicetable"
|-
! Directory
! File
! Description
|-
|
| /config.php
| Contains all of the configuration and definitions for each theme
|-
|
| /lib.php
| Contains speciality classes and functions that are used by theme
|-
|
| /renderers.php
| Contains any custom renderers for the theme.
|-
|
| /settings.php
| Contains custom theme settings. These local settings are defined by the theme allowing the theme user to easily alter something about the way it looks or operates. (eg a background colour, or a header image)
|-
| /javascript/
|
| All specialty JavaScript files the theme requires should be located in here.
|-
| /lang/
|
| Any special language files the theme requires should be located in here.
|-
| /layout/
|
| Contains the layout files for the theme.
|-
| /pix/
|
| Contains any images the theme makes use of either in CSS or in the layout files.
|-
| /pix
| /favicon.ico
| The favicon to display for this theme.
|-
| /pix
| /screenshot.jpg
| A screenshot of the theme to be displayed in on the theme selection screen.
|-
| /style
|
| Default location for CSS files.
|-
|
|/*.css
|CSS files the theme requires
|}

There are also several other places that stylesheets can be included from (see the CSS how and why section below).

==Theme options==
All theme options are set within the config.php file for the theme. The settings that are most used are: parents, sheets, layouts, and javascripts. Have a look at the '''[[#theme_options_table|theme options table]]''' for a complete list of theme options which include lesser used specialised or advanced settings.

===Basic theme config example===
Lets have a look at a basic theme configuration file and the different bits that make it up:
<code php>
$THEME->name = 'newtheme';

$THEME->parents = array(
'base'
);

$THEME->sheets = array(
'admin',
'blocks',
'calendar',
'course',
'grade',
'message',
'question',
'user'
);

$THEME->layouts = array(
'base' => array(
'theme' => 'newtheme',
'file' => 'general.php',
'regions' => array(),
),
'standard' => array(
'theme' => 'newtheme',
'file' => 'general.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
)
//.......
);

$THEME->javascripts_footer = array(
'navigation'
);
</code>

===Basic theme example settings explained===
First up you will notice everything is added to $THEME. This is the theme's configuration object, it is created by Moodle using default settings and is then updated by whatever settings you add to it.

; $THEME->name : The first setting, is the theme's name. This should simply be whatever your theme's name is, most likely whatever you named your theme directory.

; $THEME->parents : This defines the themes that the theme will extend. In this case it is extending only the base theme.

; $THEME->sheets : An array containing the names of the CSS stylesheets to include for this theme. Note that it is just the name of the stylesheet and does not contain the directory or the file extension. Moodle assumes that the theme's stylesheets will be located in the styles directory of the theme and have .css as an extension.

; $THEME->layouts : In this example, two layouts have been defined to override the layouts from the base theme. For more information see the [[#Layouts|layouts]] section below.

; $THEME->javascripts_footer : The final setting is to include a JavaScript file. Much like stylesheets, you only need to provide the files name. Moodle will assume it is in your themes JavaScript directory and be a .js file.

'''''Note''''': When you first begin writing themes, make sure you take a look at the configuration files of the other themes that get shipped with Moodle. You will get a good picture of how everything works, and what is going on in a theme, simply by reading it and taking notice of what it is including or excluding.

==CSS==
===Locations of CSS files===
First lets look at where CSS can be included from within Moodle:
; \theme\themename\style\*.css : This is the default location for all of the stylesheets that are used by a theme and the place which should be used by a theme designer.

New theme developers should note that the order in which CSS files are found and included creates a hierarchy. This order ensures that the rules, within a theme's style sheets, take precedence over identical rules in other files that may have been introduced before. This can both extend another files definitions (see parent array in the config file) and also ensures that the current theme's CSS rules/definitions have the last say.

There are other locations that can be used (although very rarely) to include CSS in a page. A developer of a php file can manually specify a stylesheet from anywhere within Moodle, like the database. Usually, if code is doing this, it is because there is a non-theme config or plugin setting that contains information requires special CSS information. As a theme designer you should be aware of, but not have to worry about, these locations of CSS files. Here are some examples:

; {pluginpath}\styles.css e.g. \block\blockname\styles.css or \mod\modname\styles.css : Every plugin can have its own styles.css file. This file should only contain the required CSS rules for the module and should not add anything to the look of the plugin such as colours, font sizes, or margins other than those that are truly required.<br />Theme specific styles for a plugin should be located within the themes styles directory.
; {pluginpath}\styles_themename.css : This should only ever be used by plugin developers. It allows them to write CSS that is designed for a specific theme without having to make changes to that theme. You will notice that this is never used within Moodle and is designed to be used only by contributed code.

As theme designers, we will only use the first method of introducing CSS: adding rules to a stylesheet file located in the theme's style directory.

===Moodle's core CSS organisation===
The next thing to look at is the organisation of CSS and rules within a theme. Although as a theme designer it is entirely up to you as to how you create and organise your CSS. Please note that within the themes provided in the standard install by Moodle there is a very clear organisation of CSS.

First is the pagelayout.css file. This contains the CSS required to give the layouts their look and feel. It doesn't contain any rules that affect the content generated by Moodle.

Next is the core.css file. If you open up core you will notice that it contains all manner of general (usually simple) rules that don't relate to a specific section of Moodle but to Moodle as a whole.

There can also be rules that relate to specific sections. However, this is done only when there are only a handful of rules for that section. These small clusters of rules are grouped together and separated by comments identifying for which section each relates.

Finally there are all the other CSS files, you will notice that there is a file for each section of Moodle that has a significant collection of rules.

:For those who are familiar with Moodle 1.9 theme's, this organisation will be a big change. In 1.9, CSS was organised by its nature (for example: colours, layout, other).

===How to write effective CSS rules within Moodle===
In Moodle 2.0, writing good CSS rules is incredibly important.

Due to performance requirements and browser limitations, all of the CSS files are combined into a single CSS file that gets included every time. This means that rules need to be written in such a way as to minimise the chances of a collision leading to unwanted styles being applied. Whilst writing good CSS is something most designers strive for we have implemented several new body classes and prompt developers to use appropriate classnames.

====<body> CSS id and classes ====
As of Moodle 2.0 the ID tag that gets applied to the body will always be a representation of the URI. For example if you are looking at a forum posting and the URI is '/mod/forum/view.php' then the body tags ID will be '#page-mod-forum-view'.

As well as the body's ID attribute the URI is also exploded to form several CSS classes that get added to the body tag, so in the above example '/mod/forum/view' you would end up with the following classes being added to the body tag '.path-mod', '.path-mod-forum'. Note that '.path-mod-forum-view' is not added as a class, this is intentionally left out to lessen confusion and duplication as rules can relate directly to the page by using the ID and do not require the final class.

The body ID and body classes described above will form the bread and butter for many of the CSS rules you will need to write for your theme, however there are also several other very handy classes that get added to the body tag that will be beneficial to you once you start your journey down the rabbit hole that is themeing. Some of the more interesting classes are listed below.

* If JavaScript is enabled then 'jsenabled' will be added as a class to the body tag allowing you to style based on JavaScript being enabled or not.
* Either 'dir-rtl' or 'dir-ltr' will be added to the body as a class depending on the direction of the language pack: rtl = right to left, ltr = left to right. This allows you to determine your text-alignment based on language if required.
* A class will be added to represent the language pack currently in use, by default en_utf8 is used by Moodle and will result in the class 'lang-en_utf8' being added to the body tag.
* The wwwroot for Moodle will also be converted to a class and added to the body tag allowing you to stylise your theme based on the URL through which it was reached. e.g. http://sam.moodle.local/moodle/ will become '.sam-moodle-local—moodle'
* If the current user is not logged then '.notloggedin' will be added to the body tag.

What does all of this look like in practise? Well using the above example /mod/forum/view.php you would get at least the following body tag:
<code html4strict><body id=”page-mod-forum-view” class=”path-mod path-mod-forum” /></code>

====Writing your rules====

By following the [[CSS coding style]] and CSS best-practices and understanding the [http://htmlhelp.com/reference/css/structure.html#cascade cascading order] of CSS a theme developer will reduce collisions and lines of CSS that is written. CSS classes have been placed where it is believed anyone may want to apply their own styles.

When starting to write rules make sure that you have a good understanding of where you want those rules to be applied, it is a good idea to make the most of the body classes mentioned above.
If you want to write a rule for a specific page make use of the body tag's ID, e.g.:

<code css>#page-mod-forum-view .forumpost {
border: 1px solid orange;
}</code>

If you want to write a rule that will be applied all throughout the forum.:

<code css>.path-mod-forum .forumpost {
border: 1px solid orange;
}</code>

The other very important thing to take into consideration is the structure leading up to the tag you want to style. Browsers apply conflicting styles with priority on the more specific selectors. It can be very beneficial to keep this in mind and write full selectors that rely on the structure of the tags leading to the tag you wish to style.

By making use of body id's and classes and writing selectors to take into account the leading structure you can greatly minimise the chance of a collision both with Moodle now and in the future.

==Layouts==
Layouts are defined in '''config.php'''.

All themes are required to define the layouts they wish to be responsible for as well as create; however, many layout files are required by those layouts. If the theme is overriding another theme then it is a case of deciding which layouts this new theme should override. If the theme is a completely fresh start then you will need to define a layout for each of the different possibilities.

It is also important to note that a new theme that will base itself on another theme (overriding it) does not need to define any layouts or use any layout files if there are no changes that it wishes to make to the layouts of the existing theme. The standard theme in Moodle is a good example of this as it extends the base theme simply adding CSS to achieve its look and feel.

So layouts... as mentioned earlier layouts are defined in config.php within $THEME->layouts. The following is an example of one such layout definition:
<code php>
$THEME->layouts = array(
// Standard layout with blocks, this is recommended for most pages with general information
'standard' => array(
'theme' => 'base',
'file' => 'general.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post'
)
)
</code>
The first thing Moodle looks at is the name of the layout, in this case it is `standard` (the array key in PHP), it then looks at the settings for the layout, this is the theme, file, regions, and default region. There are also a couple of other options that can be set by a layout.

; theme : is the theme the layout file exists in. That's right you can make use of layouts from other installed themes. ''Optional''
; file : is the name of the layout file this layout wants to use. ''Required''
; regions : is the different block regions (places you can put blocks) within the theme. ''Required''
; defaultregion : is the default location when adding new blocks. '''Required if regions is non-empty, otherwise optional'''
; options : an array of layout specific options described in detail below. '''Optional'''

The '''theme''' is optional. Normally the the layout file is looked for in the current theme, or, if it is not there, in the parent theme. However, you can use a layout file from any other theme by giving the theme name here.

You can define whatever regions you like. You just need to pick a name for each one. Most themes just use one or both of '''side_pre''' and '''side_post''', which is like 'left side' and 'right side', except in right to left languages, when they are reversed. If you say in config.php that your the layout provides regions called 'fred' and 'barney', then you must call $OUTPUT->blocks_for_region('fred') and $OUTPUT->blocks_for_region('barney') somewhere in the layout file.

The final setting '''options''' is a special case that only needs to be set if you want to make use of it. This setting allows the theme designer to specify special options that they would like to create that can be later accessed within the layout file. This allows the theme to make design decisions during the definition and react upon those decisions in what ever layout file is being used.

One such place this has been used is within the base theme. If you take a look first at theme/base/config.php you will notice that several layouts specify options '''nonavbar''' and '''nofooter''' which can both be set to either true or false. Then if we take a look at theme/base/layout/general.php you will spot lines like the following:
<code php>
<?php
$hasnavbar = (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar());
$hasfooter = (empty($PAGE->layout_options['nofooter']));
?>
............
<?php if ($hasnavbar) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</code>
What you are seeing here is the use of those settings from the layout within the layout file. In this case it is being used to toggle the display of the navigation bar and page footer.

==Layout files==
A layout file is a file that contains the core HTML structure for a layout including the header, footer, content and block regions. For those of you who are familiar with themes in Moodle 1.9 this is simply header.html and footer.html combined. Of course it is not all HTML, there are bits of HTML and content that Moodle needs to put into the page, within each layout file this will be done by a couple of simple PHP calls to get bits and pieces including content.

Before learning more it is good to understand the two primary objects that will be used in your layout files: $OUTPUT and $PAGE.

'''$OUTPUT''' is an instance of the <code>core_renderer</code> class which is defined in lib/outputrenderers.php. Each method is clearly documented there, along with which is appropriate for use within the layout files.

'''$PAGE''' is an instance of the <code>moodle_page</code> class defined in lib/pagelib.php. Most of the things you will want to use are the properties that are all documented at the top of the file. If you are not familiar with PHP properties, you access them like $PAGE->activityname, just like fields of an ordinary PHP object. (However, behind the scenes the value you get is produced by calling a function. Also, you cannot change these values, they are '''read-only'''. However, you don't need to understand all that if you are just using these properties in your theme.)

The following is a very simple layout file to illustrate the different bits that make it up:
<code php>
<?php echo $OUTPUT->doctype() ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title ?></title>
<?php echo $OUTPUT->standard_head_html() ?>
</head>
<body id="<?php p($PAGE->bodyid) ?>" class="<?php p($PAGE->bodyclasses) ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<table id="page">
<tr>
<td colspan="3">
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php echo $OUTPUT->login_info(); echo $PAGE->headingmenu; ?></div>
</td>
</tr>
<tr>
<td>
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</td>
<td>
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</td>
<td>
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</td>
</tr>
<tr>
<td colspan="3">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</td>
</tr>
</table>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

We assume you know enough HTML to understand the basic structure above, but let's explain the PHP code since that is less obvious.
<code php>
<?php echo $OUTPUT->doctype() ?>
</code>
This occurs at the VERY top of the page, it must be the first bit of output and is responsible for adding the (X)HTML document type definition to the page. This of course is determined by the settings of the site and is one of the things that the theme designer has no control over.

<code php>
<html <?php echo $OUTPUT->htmlattributes() ?>>
</code>
Here we have started writing the opening html tag and have asked Moodle to give us the HTML attributes that should be applied to it. This again is determined by several settings within the actual HTML install.

<code php>
<?php echo $PAGE->title ?>
</code>
This gets us the title for the page.

<code php>
<?php echo $OUTPUT->standard_head_html() ?>
</code>
This very important call gets us the standard head HTML that needs to be within the HEAD tag of the page. This is where CSS and JavaScript requirements for the top of the page will be output as well as any special script or style tags.

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
</code>
Much like the html tag above we have started writing the body tag and have asked for Moodle to get us the desired ID and classes that should be applied to it.

<code php>
<h1 class="headermain"><?php echo $PAGE->heading; ?></h1>
<div class="headermenu"><?php echo $OUTPUT->login_info(); echo $PAGE->headingmenu; ?></div>
</code>
Here we are creating the header for the page. In this case we want the heading for the page, we want to display the login information which will be the current users username or a link to log in if they are not logged in, and we want the heading menu if there is one.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</code>
Here we get the HTML to display the blocks that have been added to the page. In this case we have asked for all blocks that have been added to the area labelled ''side-pre''.

<code php>
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</code>
This is one of the most important calls within the file, it determines where the actual content for the page gets inserted.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</code>
Here we get the HTML to display the blocks that have been added to the page. In this case we have asked for all blocks that have been added to the area labelled ''side-post''.

<code php>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</code>
This final bit of code gets the content for the footer of the page. It gets the login information which is the same as in the header, a home link, and the standard footer HTML which like the standard head HTML contains all of the script and style tags required by the page and requested to go in the footer.

'''''Note''''': Within Moodle 2.0 most of the JavaScript for the page will be included in the footer. This greatly helps reduce the loading time of the page.

When writing layout files think about the different layouts and how the HTML that each makes use of will differ. You will most likely find you do not need a different layout file for each layout, most likely you will be able to reuse the layout files you create across several layouts. You can of course make use of layout options as well to further reduce the number of layout files you need to produce.

Of course as mentioned above if you are customising an existing theme then you may not need to create any layouts or layout files at all.

==Language File==

You need to create a language file for your theme with a few standard strings in it. At a minimum create a file called lang/en.theme_themename.php in your theme folder. For example, the 'standard' theme has a language file called lang/en/theme_standard.php.

You '''must''' define the following lines in your file (example is from standard theme, adapt as required):

<code php>
$string['pluginname'] = 'Standard';
$string['region-side-post'] = 'Right';
$string['region-side-pre'] = 'Left';
$string['choosereadme'] = 'This theme is a very basic white theme, with a minimum amount of
CSS added to the base theme to make it actually usable.';
</code>

Without the above you will get notices for the missing strings.

==Making use of images==
Right at the start when listing the features of the new themes system one of the features mentioned was the ability to override any of the standard images within Moodle from within your theme. At this point we will look at both how to make use of your own images within your theme, and secondly how to override the images being used by Moodle.
So first up a bit about images within Moodle,

# Images you want to use within your theme '''need''' to be located within your theme's pix directory.
# You can use sub directories within the pix directory of your theme.
# Images used by Moodle's core are located within the pix directory of Moodle.
# Modules, blocks and other plugins should also store their images within a pix directory.

So making use of your own images first up. Lets assume you have added two image files to the pix directory of your theme.

* /theme/yourthemename/pix/imageone.jpg
* /theme/yourthemename/pix/subdir/imagetwo.png

Notice that one image is a JPEG image, and the second is a PNG. Also the second image is in a subdirectory.

The following code snippet illustrates how to make use of your images within HTML, such as if you wanted to use them within a layout file.
<code php>
<img src="<?php echo $OUTPUT->pix_url('imageone', 'theme');?>" alt="" />
<img src="<?php echo $OUTPUT->pix_url('subdir/imagetwo', 'theme');?>" alt="" />
</code>

'''DO NOT''' include the image file extension. Moodle will work it out automatically and it will not work if you do include it.

In this case rather than writing out the URL to the image we use a method of Moodle's output library. Its not too important how that functions works but it is important that we use it as it is what allows images within Moodle to be over-rideable.

The following is how you would use the images from within CSS as background images.
<code css>
.divone {
background-image: url([[pix:theme|imageone]]);
}

.divtwo {
background-image: url([[pix:theme|subdir/imagetwo]]);
}
</code>
If this case we have to use some special notations that Moodle looks for. Whenever Moodle hands out a CSS file it first searches for all ''[[something]]'' tags and replaces them with what is required.

The final thing to notice with both of the cases above is that at no point do we include the images file extension.
The reason for this leads us into the next topic, how to override images.

From within a theme you can VERY easily override any standard image within Moodle by simply adding the replacement image to the theme's pix directory in the same sub directory structure as it is in Moodle.
So for instance we wanted to override the following two images:
# /pix/moodlelogo.gif
# /pix/i/user.gif
We would simply need to add our replacement images to the theme in the following locations
# /theme/themename/pix_core/moodlelogo.gif
# /theme/themename/pix_core/i/user.gif
''Note that we have created a '''pix_core''' directory in our theme. For module images we need a '''pix_mod''' directory. See [[Themes_2.0_How_to_use_images_within_your_theme|using images within your theme]] for the full story.

Now the other very cool thing to mention is that Moodle looks for not just replacements of the same image type (jpg, gif, etc...) but also replacements in any image format. This is why above when working with our images we never specified the images file extension.
This means that the following would also work:
# /theme/themename/pix_core/moodlelogo.png
# /theme/themename/pix_core/i/user.bmp

For a more detailed description of how this all works see the page on [[Themes_2.0_How_to_use_images_within_your_theme|using images within your theme]]

==Unobvious Things==
===Getting Your Theme to Appear Correctly in Theme Selector===
If you follow the examples on this page to the letter, when you go to the Theme Selector page you may be discouraged to find that your theme does not appear like the other themes do. In fact, instead of your theme's name, you will see something along the lines of <nowiki>[[pluginname]]</nowiki>.

To correct this, you must add the theme/THEMENAME/lang/en/theme_THEMENAME.php file, where THEMENAME is the name of the theme folder. Inside that file, add the string "$string['pluginname'] = 'THEMENAME'; ". Make THEMENAME the name of your theme, however you want it displayed in the Theme selector.

The screenshot for the theme should be about 500x400 px.

===Required theme divs===

Some parts of Moodle may rely on particular divs, for example the div with id 'page-header'.

Consequently all themes must include at least the divs (with the same ids) that are present in the 'base' theme.

Missing out these elements may result in unexpected behaviour within specific modules or other plugins.

==Appendix A==
===Theme options as of April 28th, 2010===
{| class="nicetable" id="theme_options_table"
|-
! Setting
! Effect
|-
| $THEME->'''csspostprocess'''
| Allows the user to provide the name of a function that all CSS should be passed to before being delivered.
|-
| $THEME->'''editor_sheets'''
| An array of stylesheets to include within the body of the editor.
|-
| $THEME->'''enable_dock'''
| If set to true the side dock is enabled for blocks
|-
| $THEME->'''hidefromselector'''
| Used to hide a theme from the theme selector (unless theme designer mode is on). Accepts true or false.
|-
| $THEME->'''filter_mediaplugin_colors'''
| Used to control the colours used in the small media player for the filters
|-
| $THEME->'''javascripts'''
| An array containing the names of JavaScript files located in /javascript/ to include in the theme. (gets included in the head)
|-
| $THEME->'''javascripts_footer'''
| As above but will be included in the page footer.
|-
| $THEME->'''larrow'''
| Overrides the left arrow image used throughout Moodle
|-
| $THEME->'''layouts'''
| An array setting the layouts for the theme
|-
| $THEME->'''name'''
| Name of the theme. Most likely the name of the directory in which this file resides.
|-
| $THEME->'''parents'''
| An array of themes to inherit from
|-
| $THEME->'''parents_exclude_javascripts'''
| An array of JavaScript files NOT to inherit from the themes parents
|-
| $THEME->'''parents_exclude_sheets'''
| An array of stylesheets not to inherit from the themes parents
|-
| $THEME->'''plugins_exclude_sheets'''
| An array of plugin sheets to ignore and not include.
|-
| $THEME->'''rarrow'''
| Overrides the right arrow image used throughout Moodle
|-
| $THEME->'''renderfactory'''
| Sets a custom render factory to use with the theme, used when working with custom renderers.
|-
| $THEME->'''resource_mp3player_colors'''
| Controls the colours for the MP3 player
|-
| $THEME->'''sheets'''
| An array of stylesheets to include for this theme. Should be located in the theme's style directory.
|}
===The different layouts as of August 17th, 2010===
{| class="nicetable" id="theme_layouts_table"
|-
! Layout
! Purpose
|-
| base
| Most backwards compatible layout without the blocks - this is the layout used by default.
|-
| standard
| Standard layout with blocks, this is recommended for most pages with general information.
|-
| course
| Main course page.
|-
| coursecategory
| Use for browsing through course categories.
|-
| incourse
| Default layout while browsing a course, typical for modules.
|-
| frontpage
| The site home page.
|-
| admin
| Administration pages and scripts.
|-
| mydashboard
| My dashboard page.
|-
| mypublic
| My public page.
|-
| login
| The login page.
|-
| popup
| Pages that appear in pop-up windows - no navigation, no blocks, no header.
|-
| frametop
| Used for legacy frame layouts only. No blocks and minimal footer.
|-
| embedded
| Embeded pages, like iframe/object embedded in moodleform - it needs as much space as possible
|-
| maintenance
| Used during upgrade and install. This must not have any blocks, and it is good idea if it does not have links to other places - for example there should not be a home link in the footer.
|-
| print
| Used when the page is being displayed specifically for printing.
|}

==See also==

* [[Themes 2.0 creating your first theme]] - A quick step by step guide to creating your first theme.
* [[Themes 2.0 overriding a renderer]] - A tutorial on creating a custom renderer and changing the HTML Moodle produces.
* [[Themes 2.0 How to use images within your theme]] - Explains how to use and override images within your theme.
* [[Themes 2.0 adding a settings page]] - Looks at how to add a setting page making your theme easily customisable.
* [[Themes 2.0 extending the custom menu]] - Customising the custom menu.
* [[Themes 2.0 adding courses and categories to the custom menu]] - Extending the custom menu further adding all categories + courses
* [[Themes 2.0 how to make the dock horizontal]] - Modifying the dock to make it horizontal.
* [[Themes 2.0 adding upgrade code]]
* [[Styling and customising the dock]] - How to style and customise the dock.
* [[Theme changes in 2.0]]
* [[Using jQuery with Moodle 2.0]]
* [[Themes 2.0 how to clone a Moodle 2.0 theme]]
* [http://www.youtube.com/watch?v=OvaU54uh-qA New themes in Moodle 2.0 video]

[[de:Designs 2.0]]
[[es:Temas 2.0]]

CSS Coding Style

2011-12-28T03:08:54Z

Dwahl: /* Progressive Enhancement */

Themes overview

2011-12-28T03:07:00Z

Dwahl: /* Writing your rules */

{{Template:Themes}}{{Moodle 2.0}}Welcome to the new world of themes in Moodle 2.0!

A Moodle theme allows the user to change the look and feel of a Moodle site. Themes can be applied on the site, category, course and activity levels by users with permissions to do so. Themes can be designed for specific devices such as mobile phones or tablets. This page explains how themes work in Moodle and is intended to help you create or modify most themes for Moodle 2.0

You can use contributed themes or create your entire own to share with the community. Themes can also be based on parent themes with only few customizations. Themes accomplish this using CSS, changing the underlying markup structure and also adding Javascript to add more advanced behaviors.

Most theme developers simply add a few changes to their new theme by basing it on an existing one. The Moodle Theme architecture is designed in such a way whereby the base theme will act as a fall-back that is used when nothing has been defined in the theme based on it. This makes it easy to create new themes that simply seek out to make minor changes.

==What's new in 2.0==

The theme system was completely redesigned in Moodle 2.0. Known issues have been addressed and new features have been added to meet community requests.

Unfortunately it was not possible to maintain backward compatibility, so all Moodle 1.x themes need to be recreated for Moodle 2.0.

Major changes include:
* Clearer and more consistent CSS classes and IDs throughout all pages in Moodle
* Introduction of layout files (templates) describing overall layout HTML for many different types of pages in Moodle.
* Introduction of renderers, which produce the smaller "parts" of a HTML page. Advanced themes can choose to override these too if they choose.
* Introduction of standard methods for adding Javascript to themes.
* Easier control over icons and images in Moodle.
* The old "standard" theme has been split into two themes:
**'''base''' - contains absolutely basic layout, and
**'''standard''' - which adds CSS to the base theme to make it look like the old standard theme.
* Performance tuning: In normal production mode CSS files are combined into a single optimised file, and both CSS and JavaScript files are minimised to ensure there are no wasted connections or traffic. Files are heavily cached, but also versioned, so that users never need to clear their caches.

==The structure of a theme==

Some important things to know when building good themes:

# '''config.php''' - this file is required in every theme. It defines configuration settings and definitions required to make the theme work in Moodle. These include theme, file, region, default region and options.
# '''Layouts and layout files''' - in config.php there is one definition for each page type (see [[#theme_layouts_table|Appendix A: Theme layouts]] for a list of over 12 types). Each page type definition tells Moodle which layout file will be used, what block regions this page type should display and so on. The layout file contains the HTML and the minimum PHP required to display basic structure of pages. (If you know Moodle 1.9, it's like a combination of header.html and footer.html).
# '''The base theme''' - is not intended to be used for production sites. It sets up the simplest possible generic layout and includes only CSS essential to that layout ''or'' to Moodle as a whole. It tries not to make any unnecessary rules and makes as few assumptions as possible. It's the perfect base on which to start designing a theme, as there are very few colours, borders, margins, and alignments to override. You can just start adding what you need.

===Files and folders===
A theme's files are placed in a folder with under moodle/theme folder and have subfolders. They are laid out like this:

{| class="nicetable"
|-
! Directory
! File
! Description
|-
|
| /config.php
| Contains all of the configuration and definitions for each theme
|-
|
| /lib.php
| Contains speciality classes and functions that are used by theme
|-
|
| /renderers.php
| Contains any custom renderers for the theme.
|-
|
| /settings.php
| Contains custom theme settings. These local settings are defined by the theme allowing the theme user to easily alter something about the way it looks or operates. (eg a background colour, or a header image)
|-
| /javascript/
|
| All specialty JavaScript files the theme requires should be located in here.
|-
| /lang/
|
| Any special language files the theme requires should be located in here.
|-
| /layout/
|
| Contains the layout files for the theme.
|-
| /pix/
|
| Contains any images the theme makes use of either in CSS or in the layout files.
|-
| /pix
| /favicon.ico
| The favicon to display for this theme.
|-
| /pix
| /screenshot.jpg
| A screenshot of the theme to be displayed in on the theme selection screen.
|-
| /style
|
| Default location for CSS files.
|-
|
|/*.css
|CSS files the theme requires
|}

There are also several other places that stylesheets can be included from (see the CSS how and why section below).

==Theme options==
All theme options are set within the config.php file for the theme. The settings that are most used are: parents, sheets, layouts, and javascripts. Have a look at the '''[[#theme_options_table|theme options table]]''' for a complete list of theme options which include lesser used specialised or advanced settings.

===Basic theme config example===
Lets have a look at a basic theme configuration file and the different bits that make it up:
<code php>
$THEME->name = 'newtheme';

$THEME->parents = array(
'base'
);

$THEME->sheets = array(
'admin',
'blocks',
'calendar',
'course',
'grade',
'message',
'question',
'user'
);

$THEME->layouts = array(
'base' => array(
'theme' => 'newtheme',
'file' => 'general.php',
'regions' => array(),
),
'standard' => array(
'theme' => 'newtheme',
'file' => 'general.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post',
)
//.......
);

$THEME->javascripts_footer = array(
'navigation'
);
</code>

===Basic theme example settings explained===
First up you will notice everything is added to $THEME. This is the theme's configuration object, it is created by Moodle using default settings and is then updated by whatever settings you add to it.

; $THEME->name : The first setting, is the theme's name. This should simply be whatever your theme's name is, most likely whatever you named your theme directory.

; $THEME->parents : This defines the themes that the theme will extend. In this case it is extending only the base theme.

; $THEME->sheets : An array containing the names of the CSS stylesheets to include for this theme. Note that it is just the name of the stylesheet and does not contain the directory or the file extension. Moodle assumes that the theme's stylesheets will be located in the styles directory of the theme and have .css as an extension.

; $THEME->layouts : In this example, two layouts have been defined to override the layouts from the base theme. For more information see the [[#Layouts|layouts]] section below.

; $THEME->javascripts_footer : The final setting is to include a JavaScript file. Much like stylesheets, you only need to provide the files name. Moodle will assume it is in your themes JavaScript directory and be a .js file.

'''''Note''''': When you first begin writing themes, make sure you take a look at the configuration files of the other themes that get shipped with Moodle. You will get a good picture of how everything works, and what is going on in a theme, simply by reading it and taking notice of what it is including or excluding.

==CSS==
===Locations of CSS files===
First lets look at where CSS can be included from within Moodle:
; \theme\themename\style\*.css : This is the default location for all of the stylesheets that are used by a theme and the place which should be used by a theme designer.

New theme developers should note that the order in which CSS files are found and included creates a hierarchy. This order ensures that the rules, within a theme's style sheets, take precedence over identical rules in other files that may have been introduced before. This can both extend another files definitions (see parent array in the config file) and also ensures that the current theme's CSS rules/definitions have the last say.

There are other locations that can be used (although very rarely) to include CSS in a page. A developer of a php file can manually specify a stylesheet from anywhere within Moodle, like the database. Usually, if code is doing this, it is because there is a non-theme config or plugin setting that contains information requires special CSS information. As a theme designer you should be aware of, but not have to worry about, these locations of CSS files. Here are some examples:

; {pluginpath}\styles.css e.g. \block\blockname\styles.css or \mod\modname\styles.css : Every plugin can have its own styles.css file. This file should only contain the required CSS rules for the module and should not add anything to the look of the plugin such as colours, font sizes, or margins other than those that are truly required.<br />Theme specific styles for a plugin should be located within the themes styles directory.
; {pluginpath}\styles_themename.css : This should only ever be used by plugin developers. It allows them to write CSS that is designed for a specific theme without having to make changes to that theme. You will notice that this is never used within Moodle and is designed to be used only by contributed code.

As theme designers, we will only use the first method of introducing CSS: adding rules to a stylesheet file located in the theme's style directory.

===Moodle's core CSS organisation===
The next thing to look at is the organisation of CSS and rules within a theme. Although as a theme designer it is entirely up to you as to how you create and organise your CSS. Please note that within the themes provided in the standard install by Moodle there is a very clear organisation of CSS.

First is the pagelayout.css file. This contains the CSS required to give the layouts their look and feel. It doesn't contain any rules that affect the content generated by Moodle.

Next is the core.css file. If you open up core you will notice that it contains all manner of general (usually simple) rules that don't relate to a specific section of Moodle but to Moodle as a whole.

There can also be rules that relate to specific sections. However, this is done only when there are only a handful of rules for that section. These small clusters of rules are grouped together and separated by comments identifying for which section each relates.

Finally there are all the other CSS files, you will notice that there is a file for each section of Moodle that has a significant collection of rules.

:For those who are familiar with Moodle 1.9 theme's, this organisation will be a big change. In 1.9, CSS was organised by its nature (for example: colours, layout, other).

===How to write effective CSS rules within Moodle===
In Moodle 2.0, writing good CSS rules is incredibly important.

Due to performance requirements and browser limitations, all of the CSS files are combined into a single CSS file that gets included every time. This means that rules need to be written in such a way as to minimise the chances of a collision leading to unwanted styles being applied. Whilst writing good CSS is something most designers strive for we have implemented several new body classes and prompt developers to use appropriate classnames.

====<body> CSS id and classes ====
As of Moodle 2.0 the ID tag that gets applied to the body will always be a representation of the URI. For example if you are looking at a forum posting and the URI is '/mod/forum/view.php' then the body tags ID will be '#page-mod-forum-view'.

As well as the body's ID attribute the URI is also exploded to form several CSS classes that get added to the body tag, so in the above example '/mod/forum/view' you would end up with the following classes being added to the body tag '.path-mod', '.path-mod-forum'. Note that '.path-mod-forum-view' is not added as a class, this is intentionally left out to lessen confusion and duplication as rules can relate directly to the page by using the ID and do not require the final class.

The body ID and body classes described above will form the bread and butter for many of the CSS rules you will need to write for your theme, however there are also several other very handy classes that get added to the body tag that will be beneficial to you once you start your journey down the rabbit hole that is themeing. Some of the more interesting classes are listed below.

* If JavaScript is enabled then 'jsenabled' will be added as a class to the body tag allowing you to style based on JavaScript being enabled or not.
* Either 'dir-rtl' or 'dir-ltr' will be added to the body as a class depending on the direction of the language pack: rtl = right to left, ltr = left to right. This allows you to determine your text-alignment based on language if required.
* A class will be added to represent the language pack currently in use, by default en_utf8 is used by Moodle and will result in the class 'lang-en_utf8' being added to the body tag.
* The wwwroot for Moodle will also be converted to a class and added to the body tag allowing you to stylise your theme based on the URL through which it was reached. e.g. http://sam.moodle.local/moodle/ will become '.sam-moodle-local—moodle'
* If the current user is not logged then '.notloggedin' will be added to the body tag.

What does all of this look like in practise? Well using the above example /mod/forum/view.php you would get at least the following body tag:
<code html4strict><body id=”page-mod-forum-view” class=”path-mod path-mod-forum” /></code>

====Writing your rules====

By following the [[CSS coding style]] and CSS best-practices and understanding the [http://htmlhelp.com/reference/css/structure.html#cascade cascading order] of CSS a theme developer will reduce collisions and lines of CSS that is written. CSS classes have been placed where it is believed anyone may want to apply their own styles.

When starting to write rules make sure that you have a good understanding of where you want those rules to be applied, it is a good idea to make the most of the body classes mentioned above.
If you want to write a rule for a specific page make use of the body tag's ID, e.g.:

<code css>#page-mod-forum-view .forumpost {
border: 1px solid orange;
}</code>

If you want to write a rule that will be applied all throughout the forum.:

<code css>.path-mod-forum .forumpost {
border: 1px solid orange;
}</code>

The other very important thing to take into consideration is the structure leading up to the tag you want to style. Browsers apply conflicting styles with priority on the more specific selectors. It can be very beneficial to keep this in mind and write full selectors that rely on the structure of the tags leading to the tag you wish to style.

By making use of body id's and classes and writing selectors to take into account the leading structure you can greatly minimise the chance of a collision both with Moodle now and in the future.

==Layouts==
Layouts are defined in '''config.php'''.

All themes are required to define the layouts they wish to be responsible for as well as create; however, many layout files are required by those layouts. If the theme is overriding another theme then it is a case of deciding which layouts this new theme should override. If the theme is a completely fresh start then you will need to define a layout for each of the different possibilities.

It is also important to note that a new theme that will base itself on another theme (overriding it) does not need to define any layouts or use any layout files if there are no changes that it wishes to make to the layouts of the existing theme. The standard theme in Moodle is a good example of this as it extends the base theme simply adding CSS to achieve its look and feel.

So layouts... as mentioned earlier layouts are defined in config.php within $THEME->layouts. The following is an example of one such layout definition:
<code php>
$THEME->layouts = array(
// Standard layout with blocks, this is recommended for most pages with general information
'standard' => array(
'theme' => 'base',
'file' => 'general.php',
'regions' => array('side-pre', 'side-post'),
'defaultregion' => 'side-post'
)
)
</code>
The first thing Moodle looks at is the name of the layout, in this case it is `standard` (the array key in PHP), it then looks at the settings for the layout, this is the theme, file, regions, and default region. There are also a couple of other options that can be set by a layout.

; theme : is the theme the layout file exists in. That's right you can make use of layouts from other installed themes. ''Optional''
; file : is the name of the layout file this layout wants to use. ''Required''
; regions : is the different block regions (places you can put blocks) within the theme. ''Required''
; defaultregion : is the default location when adding new blocks. '''Required if regions is non-empty, otherwise optional'''
; options : an array of layout specific options described in detail below. '''Optional'''

The '''theme''' is optional. Normally the the layout file is looked for in the current theme, or, if it is not there, in the parent theme. However, you can use a layout file from any other theme by giving the theme name here.

You can define whatever regions you like. You just need to pick a name for each one. Most themes just use one or both of '''side_pre''' and '''side_post''', which is like 'left side' and 'right side', except in right to left languages, when they are reversed. If you say in config.php that your the layout provides regions called 'fred' and 'barney', then you must call $OUTPUT->blocks_for_region('fred') and $OUTPUT->blocks_for_region('barney') somewhere in the layout file.

The final setting '''options''' is a special case that only needs to be set if you want to make use of it. This setting allows the theme designer to specify special options that they would like to create that can be later accessed within the layout file. This allows the theme to make design decisions during the definition and react upon those decisions in what ever layout file is being used.

One such place this has been used is within the base theme. If you take a look first at theme/base/config.php you will notice that several layouts specify options '''nonavbar''' and '''nofooter''' which can both be set to either true or false. Then if we take a look at theme/base/layout/general.php you will spot lines like the following:
<code php>
<?php
$hasnavbar = (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar());
$hasfooter = (empty($PAGE->layout_options['nofooter']));
?>
............
<?php if ($hasnavbar) { ?>
<div class="navbar clearfix">
<div class="breadcrumb"><?php echo $OUTPUT->navbar(); ?></div>
<div class="navbutton"> <?php echo $PAGE->button; ?></div>
</div>
<?php } ?>
</code>
What you are seeing here is the use of those settings from the layout within the layout file. In this case it is being used to toggle the display of the navigation bar and page footer.

==Layout files==
A layout file is a file that contains the core HTML structure for a layout including the header, footer, content and block regions. For those of you who are familiar with themes in Moodle 1.9 this is simply header.html and footer.html combined. Of course it is not all HTML, there are bits of HTML and content that Moodle needs to put into the page, within each layout file this will be done by a couple of simple PHP calls to get bits and pieces including content.

Before learning more it is good to understand the two primary objects that will be used in your layout files: $OUTPUT and $PAGE.

'''$OUTPUT''' is an instance of the <code>core_renderer</code> class which is defined in lib/outputrenderers.php. Each method is clearly documented there, along with which is appropriate for use within the layout files.

'''$PAGE''' is an instance of the <code>moodle_page</code> class defined in lib/pagelib.php. Most of the things you will want to use are the properties that are all documented at the top of the file. If you are not familiar with PHP properties, you access them like $PAGE->activityname, just like fields of an ordinary PHP object. (However, behind the scenes the value you get is produced by calling a function. Also, you cannot change these values, they are '''read-only'''. However, you don't need to understand all that if you are just using these properties in your theme.)

The following is a very simple layout file to illustrate the different bits that make it up:
<code php>
<?php echo $OUTPUT->doctype() ?>
<html <?php echo $OUTPUT->htmlattributes() ?>>
<head>
<title><?php echo $PAGE->title ?></title>
<?php echo $OUTPUT->standard_head_html() ?>
</head>
<body id="<?php p($PAGE->bodyid) ?>" class="<?php p($PAGE->bodyclasses) ?>">
<?php echo $OUTPUT->standard_top_of_body_html() ?>
<table id="page">
<tr>
<td colspan="3">
<h1 class="headermain"><?php echo $PAGE->heading ?></h1>
<div class="headermenu"><?php echo $OUTPUT->login_info(); echo $PAGE->headingmenu; ?></div>
</td>
</tr>
<tr>
<td>
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</td>
<td>
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</td>
<td>
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</td>
</tr>
<tr>
<td colspan="3">
<p class="helplink"><?php echo page_doc_link(get_string('moodledocslink')) ?></p>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</td>
</tr>
</table>
<?php echo $OUTPUT->standard_end_of_body_html() ?>
</body>
</html>
</code>

We assume you know enough HTML to understand the basic structure above, but let's explain the PHP code since that is less obvious.
<code php>
<?php echo $OUTPUT->doctype() ?>
</code>
This occurs at the VERY top of the page, it must be the first bit of output and is responsible for adding the (X)HTML document type definition to the page. This of course is determined by the settings of the site and is one of the things that the theme designer has no control over.

<code php>
<html <?php echo $OUTPUT->htmlattributes() ?>>
</code>
Here we have started writing the opening html tag and have asked Moodle to give us the HTML attributes that should be applied to it. This again is determined by several settings within the actual HTML install.

<code php>
<?php echo $PAGE->title ?>
</code>
This gets us the title for the page.

<code php>
<?php echo $OUTPUT->standard_head_html() ?>
</code>
This very important call gets us the standard head HTML that needs to be within the HEAD tag of the page. This is where CSS and JavaScript requirements for the top of the page will be output as well as any special script or style tags.

<code php>
<body id="<?php p($PAGE->bodyid); ?>" class="<?php p($PAGE->bodyclasses); ?>">
</code>
Much like the html tag above we have started writing the body tag and have asked for Moodle to get us the desired ID and classes that should be applied to it.

<code php>
<h1 class="headermain"><?php echo $PAGE->heading; ?></h1>
<div class="headermenu"><?php echo $OUTPUT->login_info(); echo $PAGE->headingmenu; ?></div>
</code>
Here we are creating the header for the page. In this case we want the heading for the page, we want to display the login information which will be the current users username or a link to log in if they are not logged in, and we want the heading menu if there is one.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-pre') ?>
</code>
Here we get the HTML to display the blocks that have been added to the page. In this case we have asked for all blocks that have been added to the area labelled ''side-pre''.

<code php>
<?php echo core_renderer::MAIN_CONTENT_TOKEN ?>
</code>
This is one of the most important calls within the file, it determines where the actual content for the page gets inserted.

<code php>
<?php echo $OUTPUT->blocks_for_region('side-post') ?>
</code>
Here we get the HTML to display the blocks that have been added to the page. In this case we have asked for all blocks that have been added to the area labelled ''side-post''.

<code php>
<?php
echo $OUTPUT->login_info();
echo $OUTPUT->home_link();
echo $OUTPUT->standard_footer_html();
?>
</code>
This final bit of code gets the content for the footer of the page. It gets the login information which is the same as in the header, a home link, and the standard footer HTML which like the standard head HTML contains all of the script and style tags required by the page and requested to go in the footer.

'''''Note''''': Within Moodle 2.0 most of the JavaScript for the page will be included in the footer. This greatly helps reduce the loading time of the page.

When writing layout files think about the different layouts and how the HTML that each makes use of will differ. You will most likely find you do not need a different layout file for each layout, most likely you will be able to reuse the layout files you create across several layouts. You can of course make use of layout options as well to further reduce the number of layout files you need to produce.

Of course as mentioned above if you are customising an existing theme then you may not need to create any layouts or layout files at all.

==Language File==

You need to create a language file for your theme with a few standard strings in it. At a minimum create a file called lang/en.theme_themename.php in your theme folder. For example, the 'standard' theme has a language file called lang/en/theme_standard.php.

You '''must''' define the following lines in your file (example is from standard theme, adapt as required):

<code php>
$string['pluginname'] = 'Standard';
$string['region-side-post'] = 'Right';
$string['region-side-pre'] = 'Left';
$string['choosereadme'] = 'This theme is a very basic white theme, with a minimum amount of
CSS added to the base theme to make it actually usable.';
</code>

Without the above you will get notices for the missing strings.

==Making use of images==
Right at the start when listing the features of the new themes system one of the features mentioned was the ability to override any of the standard images within Moodle from within your theme. At this point we will look at both how to make use of your own images within your theme, and secondly how to override the images being used by Moodle.
So first up a bit about images within Moodle,

# Images you want to use within your theme '''need''' to be located within your theme's pix directory.
# You can use sub directories within the pix directory of your theme.
# Images used by Moodle's core are located within the pix directory of Moodle.
# Modules, blocks and other plugins should also store their images within a pix directory.

So making use of your own images first up. Lets assume you have added two image files to the pix directory of your theme.

* /theme/yourthemename/pix/imageone.jpg
* /theme/yourthemename/pix/subdir/imagetwo.png

Notice that one image is a JPEG image, and the second is a PNG. Also the second image is in a subdirectory.

The following code snippet illustrates how to make use of your images within HTML, such as if you wanted to use them within a layout file.
<code php>
<img src="<?php echo $OUTPUT->pix_url('imageone', 'theme');?>" alt="" />
<img src="<?php echo $OUTPUT->pix_url('subdir/imagetwo', 'theme');?>" alt="" />
</code>

'''DO NOT''' include the image file extension. Moodle will work it out automatically and it will not work if you do include it.

In this case rather than writing out the URL to the image we use a method of Moodle's output library. Its not too important how that functions works but it is important that we use it as it is what allows images within Moodle to be over-rideable.

The following is how you would use the images from within CSS as background images.
<code css>
.divone {background-image:url([[pix:theme|imageone]]);}
.divtwo {background-image:url([[pix:theme|subdir/imagetwo]]);}
</code>
If this case we have to use some special notations that Moodle looks for. Whenever Moodle hands out a CSS file it first searches for all ''[[something]]'' tags and replaces them with what is required.

The final thing to notice with both of the cases above is that at no point do we include the images file extension.
The reason for this leads us into the next topic, how to override images.

From within a theme you can VERY easily override any standard image within Moodle by simply adding the replacement image to the theme's pix directory in the same sub directory structure as it is in Moodle.
So for instance we wanted to override the following two images:
# /pix/moodlelogo.gif
# /pix/i/user.gif
We would simply need to add our replacement images to the theme in the following locations
# /theme/themename/pix_core/moodlelogo.gif
# /theme/themename/pix_core/i/user.gif
''Note that we have created a '''pix_core''' directory in our theme. For module images we need a '''pix_mod''' directory. See [[Themes_2.0_How_to_use_images_within_your_theme|using images within your theme]] for the full story.

Now the other very cool thing to mention is that Moodle looks for not just replacements of the same image type (jpg, gif, etc...) but also replacements in any image format. This is why above when working with our images we never specified the images file extension.
This means that the following would also work:
# /theme/themename/pix_core/moodlelogo.png
# /theme/themename/pix_core/i/user.bmp

For a more detailed description of how this all works see the page on [[Themes_2.0_How_to_use_images_within_your_theme|using images within your theme]]

==Unobvious Things==
===Getting Your Theme to Appear Correctly in Theme Selector===
If you follow the examples on this page to the letter, when you go to the Theme Selector page you may be discouraged to find that your theme does not appear like the other themes do. In fact, instead of your theme's name, you will see something along the lines of <nowiki>[[pluginname]]</nowiki>.

To correct this, you must add the theme/THEMENAME/lang/en/theme_THEMENAME.php file, where THEMENAME is the name of the theme folder. Inside that file, add the string "$string['pluginname'] = 'THEMENAME'; ". Make THEMENAME the name of your theme, however you want it displayed in the Theme selector.

The screenshot for the theme should be about 500x400 px.

===Required theme divs===

Some parts of Moodle may rely on particular divs, for example the div with id 'page-header'.

Consequently all themes must include at least the divs (with the same ids) that are present in the 'base' theme.

Missing out these elements may result in unexpected behaviour within specific modules or other plugins.

==Appendix A==
===Theme options as of April 28th, 2010===
{| class="nicetable" id="theme_options_table"
|-
! Setting
! Effect
|-
| $THEME->'''csspostprocess'''
| Allows the user to provide the name of a function that all CSS should be passed to before being delivered.
|-
| $THEME->'''editor_sheets'''
| An array of stylesheets to include within the body of the editor.
|-
| $THEME->'''enable_dock'''
| If set to true the side dock is enabled for blocks
|-
| $THEME->'''hidefromselector'''
| Used to hide a theme from the theme selector (unless theme designer mode is on). Accepts true or false.
|-
| $THEME->'''filter_mediaplugin_colors'''
| Used to control the colours used in the small media player for the filters
|-
| $THEME->'''javascripts'''
| An array containing the names of JavaScript files located in /javascript/ to include in the theme. (gets included in the head)
|-
| $THEME->'''javascripts_footer'''
| As above but will be included in the page footer.
|-
| $THEME->'''larrow'''
| Overrides the left arrow image used throughout Moodle
|-
| $THEME->'''layouts'''
| An array setting the layouts for the theme
|-
| $THEME->'''name'''
| Name of the theme. Most likely the name of the directory in which this file resides.
|-
| $THEME->'''parents'''
| An array of themes to inherit from
|-
| $THEME->'''parents_exclude_javascripts'''
| An array of JavaScript files NOT to inherit from the themes parents
|-
| $THEME->'''parents_exclude_sheets'''
| An array of stylesheets not to inherit from the themes parents
|-
| $THEME->'''plugins_exclude_sheets'''
| An array of plugin sheets to ignore and not include.
|-
| $THEME->'''rarrow'''
| Overrides the right arrow image used throughout Moodle
|-
| $THEME->'''renderfactory'''
| Sets a custom render factory to use with the theme, used when working with custom renderers.
|-
| $THEME->'''resource_mp3player_colors'''
| Controls the colours for the MP3 player
|-
| $THEME->'''sheets'''
| An array of stylesheets to include for this theme. Should be located in the theme's style directory.
|}
===The different layouts as of August 17th, 2010===
{| class="nicetable" id="theme_layouts_table"
|-
! Layout
! Purpose
|-
| base
| Most backwards compatible layout without the blocks - this is the layout used by default.
|-
| standard
| Standard layout with blocks, this is recommended for most pages with general information.
|-
| course
| Main course page.
|-
| coursecategory
| Use for browsing through course categories.
|-
| incourse
| Default layout while browsing a course, typical for modules.
|-
| frontpage
| The site home page.
|-
| admin
| Administration pages and scripts.
|-
| mydashboard
| My dashboard page.
|-
| mypublic
| My public page.
|-
| login
| The login page.
|-
| popup
| Pages that appear in pop-up windows - no navigation, no blocks, no header.
|-
| frametop
| Used for legacy frame layouts only. No blocks and minimal footer.
|-
| embedded
| Embeded pages, like iframe/object embedded in moodleform - it needs as much space as possible
|-
| maintenance
| Used during upgrade and install. This must not have any blocks, and it is good idea if it does not have links to other places - for example there should not be a home link in the footer.
|-
| print
| Used when the page is being displayed specifically for printing.
|}

==See also==

* [[Themes 2.0 creating your first theme]] - A quick step by step guide to creating your first theme.
* [[Themes 2.0 overriding a renderer]] - A tutorial on creating a custom renderer and changing the HTML Moodle produces.
* [[Themes 2.0 How to use images within your theme]] - Explains how to use and override images within your theme.
* [[Themes 2.0 adding a settings page]] - Looks at how to add a setting page making your theme easily customisable.
* [[Themes 2.0 extending the custom menu]] - Customising the custom menu.
* [[Themes 2.0 adding courses and categories to the custom menu]] - Extending the custom menu further adding all categories + courses
* [[Themes 2.0 how to make the dock horizontal]] - Modifying the dock to make it horizontal.
* [[Themes 2.0 adding upgrade code]]
* [[Styling and customising the dock]] - How to style and customise the dock.
* [[Theme changes in 2.0]]
* [[Using jQuery with Moodle 2.0]]
* [[Themes 2.0 how to clone a Moodle 2.0 theme]]
* [http://www.youtube.com/watch?v=OvaU54uh-qA New themes in Moodle 2.0 video]

[[de:Designs 2.0]]
[[es:Temas 2.0]]

CSS Coding Style

2011-11-11T01:44:20Z

Dwahl: /* Comments */

CSS Coding Style

2011-11-11T01:42:22Z

Dwahl: /* Correct */

CSS Coding Style

2011-11-11T01:40:43Z

Dwahl: /* Block Style */

CSS Coding Style

2011-11-11T01:38:31Z

Dwahl: Created page with "{{Work in progress}} The Moodle CSS coding style == Overview == === Scope === This document describes style guidelines for developers working on or with Moodle code. It talk..."