Packt is pleased to announce a new book on Moodle that is aimed at helping users create a Moodle Theme right from the graphic design stage to the finished Moodle Theme. Written by Paul James Gadsdon, this book will offer design examples to administrators, designers or teachers and help them create appropriate themes for different student age groups and styles.

Moodle is a highly extensible virtual learning environment and is used to deliver online teaching and training materials. Theming is one of the main features of Moodle that can be used to customize your online courses and make them look exactly how you want them to.

Users will first learn the concept of Moodle themes and how they work. They will then learn how to create themes for Moodle, the tools that are required for the job, and how to download new themes from various resources on the Internet. Along with the creation of themes, they will also be shown how to choose and change an existing Moodle theme, and test the changes they have made.

read more

Merging HTML, CSS and RedDot templates
Read how to do it the right way.

This article covers the key factors for successful CSS and HTML integration into your RedDot CMS Open Text Content Management Server project. This best practice article outlines the major points to pay attention to when implementing your HTML into the CMS.

What you should do when you integrate HTML and CSS into your content class templates

1. If you can avoid it, do not create templates for your CSS or Javascript files. A detailed post can be found here.
2. Don’t target HTML elements directly within the CSS. Always use classes. Specifically with anchor, image and span tags. If you target HTML elements directly this might affect the red dots which will be placed inside the templates because they are anchors, images and spans.
3. Always target the ‘first’ item in a collection of items (lists, repeating blocks, …) by using a CSS class. Within the RedDot CMS you can identify the first item in a list using ASP and PreExecute script blocks but not always can you identify the last item. Especially when the amount of items is varying and you cannot utilize Render Tags.
4. Ensure dynamic HTML is accessible when switched off. Using Javascript code within the CMS editing view can be problematic because it can hide editable content. Ensure that when using dynamic scripts the content is also visible when Javascript is deactivated. For example when you are using jQuery with tabs and your CMS editor changes content, the page reloads when the element is being saved and the user has to open the tab again. It’s better to deactivate the tabs when the page is ‘open’ and in SmartEdit editing mode.
5. Files such as background images, styles heets, javascript and others need to be referenced relative (../mystyle.css) rather than root or absolute referencing (/cms/projectfolder/folder-not-working-on-live-site/mystyle.css). RedDot CMS has its own folder and sub folder structure and during editing it can’t use absolute referenced style or JS files and will mix those up.

Summary

RedDot CMS is a fairly easy to use system when it comes down to templating. I am not saying it’s straight forward or a technological top notch solution. It also is not meant to be an IDE. The good thing to say about the CMS is that the elements are modularized to each single HTML object and can be used in an infinite number of ways. Pay attention to the best practice rules above and think about where your files and references will be used. When using the guidance above the HTML of your project will run smoothly on any platform and publishing target.

What is your RedDot CMS Consultant integration experience?
How do you use HTML and CSS within the RedDot CMS?
Have you ever had any trouble or even an “CMS integration epiphany”?
Read more RedDot CMS best practice articles here.

Share and Enjoy:

Another big question that comes up every couple of weeks when people start developing websites with the RedDot CMS Open Text Web Solutions Management Server is this one:

How should I integrate my CSS code into the CMS?

And the answer is fairly easy to give and even easier to remember:

Don’t do it. Do NOT integrate your CSS code into the CMS !

It took me several projects to actually reach encounter this epiphany. It’s not worth doing it. And there are several good reasons for not doing it. And I will share them with you, more than happy to discuss it.

Since last year I suggest the following procedure for every project I come across:
Remove the CSS templates and related images to style your site from your project and put them outside of the template and therefore outside of your CMS logic.

A template is meant to semantically structure the stored data from the datasource (a database or sometimes even just XML files). We call this environment a CMS – Content Management System. The presentation layer for this content is formed by those templates and the combined usage of style sheet files. This methodology is similar to XML and XSL, where one stores content, the other defines the way to present it.

Don’t integrate CSS into Content Classes » Markup arguments

• CSS is not a template

  Keep in mind style sheets are NOT templates. CSS influences the way content is presented graphically. CSS is not responsible for the semantically correct markup. There is a reason why it is called “content class” inside the CMS. Because it’s about content.

• Background images are no content

  Images such as background images, bullet points, logos, etc. are NO content, they are a way to present content. Hence they don’t belong inside the CMS template structure. They do not help you manage the content nor do they store any valuable information for your visitors which you want to change as CMS editor.

• Border or Shades are no separators

  A border below a DIV or a headline is not a separator, a separator is a horizontal ruler set in the HTML by using a <hr>-tag and. That’s how content is semantically correct separated not using the content elements borders.

Don’t integrate CSS into Content Classes » Process & Budget

And if these three semantic reasons are not enough for you then here are another four development reasons why you should not mix up CSS & templating.

• It takes more time

  Changing a value in a CSS file takes about 5 minutes. In RedDot CMS you have to do this: Open your CSS template, change the value, publish it to your staging server, test the result, go back to the CMS, if required make some changes, publish again to the staging server, then test again – repeat this step until you have the desired outcome, then – publish the file to your live environment, done.

• It doesn’t work fast enough with international projects / shared RedDot projects

  When using shared content classes for several projects they develop over time different layouts. Some marketing departments want slightly separate styles and your CMS construct starts to get cracks and you have to add an special CSS template here and another one there. Keeping styles separate from projects gives you more options to change them faster without having to pay too much attention to all depending projects.

• It gives you more flexibility

  Assuming you have multiple projects and you run a style change on all of them. You have to test each change which works for Project A also in Project B, C and all the others. And you have to wait for all of them to be changed in the development process until you can start testing because they still might change in the background if you start testing before the last change has been made

• It adds more stability

  Your presentation layer should be static. Whenever your content gets published usually the styles heet files will get published too if they are part of the template set. Content changes approximately everyday in your company.
  How often does the style change of your project? Exactly.
  Why would you re-publish this everyday risking that it might fall over because editors have the ability to influence your companies CI? They don’t have access to it? Fine then again, remove the CSS from your project.

What should you do instead?

• Use a proper set of HTML templates before you start setting up your RedDot CMS project. Each final page template in the CMS should have an according HTML template. (If you didn’t go down that path yet it’s about time to set it up now, it safes you a lot of maintenance time and stress)
• Develop, test and maintain CSS changes in these HTML templates. If you find out that entered content in the CMS affects the way your site renders then test it in here and create an example page. It’s faster to test these pages in all browsers anyway.
• Once your development & testing is ready set up your project or update your existing project. A good place for your CSS files is the plugin folder of your CMS.
• Create a folder for each project inside the plugins folder and place the CSS folder structure and relevant files in there.
• Do the same by manually deploying the CSS files to your web server.

In your RedDot CMS project reference to the CSS files on your RedDot server when parsing the template code. For published files reference to your website CSS. This can be done by using render tags as described here.

How could Open Text tackle this issue

Open Text could easily integrate a CSS file compressor. This module takes the set of referenced CSS files and compresses them as one single file. It also reads out the image references. The compressed file and the image reference then will be attached to a publishing process. A file watcher checks for updates on the CSS files / CSS images. Whenever the CSS files change the compression / publishing process takes place.
This module can be switched off for development purposes and specific publishing targets. The RedDot CMS is NOT an IDE and should not be used to develop or maintain HTML and CSS changes. This module would be a great enhancement.

What do you think? How do you use CSS within RedDot CMS and what is your best practise for this?

Share and Enjoy:

Taming the beast that Open Text so frankly called ‘Web Solutions Management Server’ we have some pretty nice tools available since version 7.1. Render Tags are a quick and effective way to create navigation elements like this breadcrumb navigation below.

    
        
            
<%!! Context:CurrentIndex.Headline !!%>

                <% currentDepth = <%!! Context:CurrentDepth !!%> %>
            
        
        
            
                
                    
<a class="first" href="<%!! Context:CurrentIndex.GetUrl() !!%>"
                            title="<%!! Context:CurrentIndex.Headline !!%>"><%!! Context:CurrentIndex.Headline !!%></a> / 

                        
                    
                
                
                    
<a href="<%!! Context:CurrentIndex.GetUrl() !!%>" title="<%!! Context:CurrentIndex.Headline !!%>">
                            <%!! Context:CurrentIndex.Headline !!%></a> / 

                        
                    
                
            
        
    

A pretty nice piece of code. It creates a breadcrumb navigation with several CSS class names, giving you many options to style the whole thing very detailed.

Embed this in your project

1. Put it in a separate template
2. Create a container (for example ‘con_breadcrumb’) in your MasterPage(s)
3. Create ONE instance of the breadcrumb template in the container inside the homepage template (you don’t need to place the container in the HTML of your homepage it’s just a good place to store unique project wide pages)
4. Reference the ‘con_breadcrumb’ container in your homepage page to all MasterPage templates (and if required to all already exisiting pages – thankfully there is a plugin available from Open Text for this, just ask them!)

Done.

Credits

I asked Neil Fegen, if I can use his enhanced version of the script from Ingo Hillebrand who came up with it last Friday on the RedDot Google Group. Thank you guys for sharing this stuff with us!

Share and Enjoy: