Customizing the Backend Editing in TYPO3 Templates

Exclusive offer: get 50% off this eBook here
TYPO3 Templates

TYPO3 Templates — Save 50%

Create and modify templates with TypoScript and TemplaVoila

£16.99    £8.50
by Jeremy Greenawalt | November 2010 | Open Source

Customizing the Backend Editing covers the different ways to make the TYPO3 backend easier to use for editors by customizing the options available and making the layout and styles match the frontend more closely. It starts by showing how to customize the text editor to match the design and branding of a TYPO3 site more by removing unnecessary options and adding styles that match the overall design. After that, the chapter walks readers through modifying the backend page layouts with columns and headings to mimic the frontend design of a site.

In this article, by Jeremy Greenawalt, author of TYPO3 Templates, we will:

  • Learn about the default rich text editor in TYPO3
  • Learn how to configure the rich text for a single page or a whole page tree
  • Update the CSS in the rich text editor to match what users will see on the frontend
  • Remove unwanted classes and tools from the text editor
  • Add support for extra HTML tags and YouTube video to the text editor
  • Learn how the configure the Page module layout of our templates with backend layouts
  • Learn how to create a backend layout for data structures with multiple template objects
  • Learn about static data structures and the future of TemplaVoila templates

 

TYPO3 Templates

TYPO3 Templates

Create and modify templates with TypoScript and TemplaVoila

  • Build dynamic and powerful TYPO3 templates using TypoScript, TemplaVoila, and other core technologies.
  • Customize dynamic menus, logos, and headers using tricks you won’t find in the official documentation.
  • Build content elements and template extensions to overhaul and improve TYPO3’s default back-end editing experience.
  • Follow along with the step-by-step instructions to build a site from scratch using all the lessons in the book in a practical example.
        Read more about this book      

(For more resources on TYPO3, see here.)

Updating the rich text editor

While we are making life easier for the editors, we can work on one of the areas they have to spend the most time in: the Rich Text Editor (RTE). The rich text editor allows anybody editing text or content in the TYPO3 backend to add formatting and styling such as bold or italics without using special syntax or HTML, and see the results in the text area immediately. This is also known as a WYSIWYG (What You See Is What You Get) editor and we've used it in the previous chapters to edit our own content:

Out of the box, TYPO3 comes with the htmlArea RTE (extension key: rtehtmlarea), and it really is a good editor to work with. The problem is that it's configured by default to fit everybody, so it doesn't really fit anybody particularly well without a little bit of modification: it has it's own classes that we probably don't actually use, toolbars that may give too many options, and it blocks some handy tags such as the embed and object tags that we need for embedded video. Luckily, the htmlArea RTE is very configurable like everything in TYPO3 and allows us to override or add to almost all of its rules.

There's an entire TSref document (http://typo3.org/documentation/documentlibrary/extension-manuals/rtehtmlarea/current), so we're not going to try to cover everything that is possible. The TSref is being updated with the new releases, so I recommend checking it out if you have any questions or want to get more information on configurations that we have only glossed over or skipped.

As a final note, some of the configuration properties in this section will work on other RTE options, but many are special for the htmlArea RTE. We are going to talk about the htmlArea RTE because it is already installed by default and has a lot of powerful options, but you may choose to install a different editor as an extension in the future. TYPO3 allows us to replace the RTE in the backend with TYPO3 extensions, and we might want to replace the default htmlArea RTE if we need to support older browsers or use special features like plugins for editing images. If you are using a different editor, you may need to look at its documentation for any differences in configuration.

Editing the TSconfig

Configuration of the RTE is done completely in the TSconfig for the user or the page. We've used the TypoScript template for frontend configuration and layout, but the TSconfig is mainly used for configuring backend modules in TYPO3 like the RTE. The rich text editor is a backend module, so we need to use the TSconfig to configure it for our editors.

The TSconfig can be modified through the Page properties view on any page in the Options tab (shown in the following screenshot):

Above you can see an example of the TSconfig with some of the modifications that we are going to look at for the RTE. Of course, you can edit the TSconfig on any page in the page tree that you would like, but we are going to be working on the Root page. Like templates, the TSconfig is inherited from the parent pages in the page tree, so we can modify all of the instances of the RTE in the entire site by modifying the Root page.

CSS properties

The first thing that we want to update in our editor is the CSS. Without special configuration, the htmlArea RTE uses its own default CSS to decide how the different options such as headings, bold, italics, and so on, look in the text area preview. We can update the TSconfig, to load our own external stylesheet for the RTE that more closely resembles our working frontend site; the editors will see the same basic styling for paragraphs and headings as the visitors and have a better idea of what their content will look like in the frontend.

According to the TSref on htmlArea, the following stylesheets are applied to the contents of the editing area by default in ascending order (we'll talk about each one in a moment):

  • The htmlarea-edited-content.css file from the current backend TYPO3 skin (contains selectors for use in the editor but not intended to be applied in the frontend)
  • A CSS file generated from the mainStyleOverride and inlineStyle assignments
  • Any CSS file specified by contentCSS property in the page TSConfig

We don't need to worry about the first file, htmlarea-edited-content.css. The TYPO3 skin that styles everything in the backend controls it. By default, there is an extension named TYPO3 skin, and we can simply override any of the styles by using the contentCSS property that we will see in a minute.

The mainStyleOverride and inlineStyle properties are controlled by the htmlArea RTE, and TYPO3 generates a CSS file based on their settings in the extension. The mainStyleOverride contains all of the default text settings including sizes and font choices. If we are using our own CSS, we will want to ignore the original styles, so we are going to use the ignoreMainStyleOverride property in our TSconfig. To ignore set this property for our RTE, we can add the following line to the TSconfig on our main page:

RTE.default.ignoreMainStyleOverride = 1

The inlineStyle assignments in TYPO3 create default classes for use in the RTE. You've probably already noticed some of them as options in the style drop-downs in the editor (Frame with yellow background, Justify Center, Justify Right, and so on). If we override the inlineStyle assignments, the default classes are removed from the RTE. Of course, we don't need to eliminate these classes just to use our own, but we can do this if we are trying to clean up the RTE for other editors or want to make our own alignment styles.

Finally, we can use the contentCSS property to load our own external stylesheet into the RTE. To use our own stylesheet, we will use the following code in the TSconfig to use a new stylesheet named rte.css in our editor:

RTE.default.contentCSS = fileadmin/templates/css/rte.css

At this point, we're all pretty used to the syntax of TypoScript, but a review might be in order. In the previous line of TypoScript, we are updating the contentCSS property in the default instances of the RTE object with the new value fileadmin/templates/css/rte.css. If you understand that line, then everything else we're about to cover will be easy to pick up.

As we want to use our own CSS file and override the defaults at once, this will be the TypoScript for our TSconfig:

RTE.default {
contentCSS = fileadmin/templates/css/rte.css
ignoreMainStyleOverride = 1
}

Of course, the next thing we need to do is create our new stylesheet. We don't want to use the complete stylesheet that we are using for the frontend because it could be thousands of lines and will have a lot of formatting and page layout rules that we don't need for simple text editing. Instead, we can just copy the most important text and paragraph styles from our style.css file in the fileadmin/templates/css/ directory into a new file called rte.css. In addition, we're going to add two new classes to style.css and copy them over; we'll create a class named blue to set the font color to pure blue and a class named red to set the font color to pure red. This should be the content of our new file, rte.css:

p, ul, div {
color: #666;
font-size: 12px;
line-height: 18px;
}
h1 {
font-size: 24px;
line-height: 36px;
margin-bottom: 18px;
font-weight: 200;
font-variant: small-caps;
}
h2 {
margin-bottom: 18px;
line-height: 18px;
font-size: 18px;
}
h3 {
font-size: 15px;
line-height: 18px;
}
h4, h5, h6 {
font-size: 12px;
line-height: 18px;
}
ul, ol {
margin: 0px 0px 18px 18px;
}
ul {
list-style-type: circle;
}
ol {
list-style: decimal;
}
td {
padding: 5px;
}
:link, :visited {
font-weight: bold;
text-decoration: none;
color: #036;
}
.blue {
color: #0000ff;
}
.red {
color: #ff0000;
}

With our new CSS we will notice at least a subtle difference in our RTE. In the following screenshot, we can see the original RTE on the left and the updated RTE on the right. As you can see, our text is now spaced out better and lightened to match the frontend:

As we have overridden the default classes without creating any new ones, the Block style and Text style drop-downs are both empty now. In the RTE, block styles are used for the "blocks" of our content such as paragraphs and headings while the text styles are applied directly to words or pieces of text within a larger block. Put simply, if we wanted a whole paragraph to be blue, we would use the Block style drop-down, and we would use the Text style drop-down if we only wanted a single word to be blue. Both of these drop-downs use our CSS classes for styling, so we'll go ahead and create our new classes in the TSconfig.

Classes properties

All of the classes in our external CSS file (rte.css) are made available as soon as we declared the file with the contentCSS property. If we want to use them, we just need to associate them with a style type (paragraph, character, image, and so on) for the default RTE. If we wanted to associate the blue and red classes with text styles, for example, we would add the following to our page's TSconfig:

RTE.default.classesCharacter = blue, red

Before we assign the classes to a type, we should declare them in the TSconfig so they show up properly in the RTE. By declaring the classes, we can set the titles we want to show in the RTE and how we want the titles to be styled in the drop-downs. Without declarations, the styles will still show up, but the titles will just be CSS class names. We want to declare them in TSconfig with specific title to make our editors' lives easier. We can add the following code to the TSconfig to declare the classes in our RTE and set more descriptive titles that will be shown in blue or red in the drop-down menus:

RTE.classes {
blue {
name = Blue Text
value = color: blue;
}
red {
name = Red Text
value = color: red;
}
}

We can use CSS classes for more than just the text style, of course. The table below shows all of the main ways that we can associate and use classes in the htmlArea RTE, but you can read more in the htmlArea TSref. Go ahead and try some of them out with the example TypoScript lines that are shown.

RTE class properties

Toolbar properties

Along with what shows up inside the content of the RTE, we can modify the toolbar itself to control what editors are able to see and use. By controlling the toolbar, we can make the RTE easier for editors and make sure that the branding and styling is consistent. The table below shows some of the most useful properties we can use to alter the toolbar available to editors. We can actually go much further in editing the individual buttons of the toolbar, but this is changing enough between major releases that I recommend using the TSref as a reference for your version of the htmlArea RTE.

HTML editor properties

Finally, we can change the way that the RTE works with HTML. For example, the RTE uses paragraph tags (&ltp></p>) for all blocks in our text area, but we can replace this behavior with break tags (&ltbr />) if we want. The RTE also strips certain tags, and we can change that with RTE properties as well. The following table shows the most common properties that we can use in the Page TSconfig to modify the HTML in the htmlArea RTE. Even if we don't need anything else in this section; using allowTags to allow embedded video can make our editor" lives easier if we want to embed YouTube or Vimeo players in our website. All of this information is also available in the TSref for the htmlArea if you need an updated reference.

TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila
Published: November 2010
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on TYPO3, see here.)

Customizing the Page module

Now that we are done customizing the RTE, we can work on the main module that editors will be looking at day after day, the Page module. The look of the Page module in TemplaVoila has improved, but it does not give our editors a good idea of how pages will look in the frontend. It's also based entirely on columns, so it can get too wide for easy editing. Like all things in TYPO3, we can adjust it and customize it to our needs. We can use an HTML file like we use for TemplaVoila template objects to make the backend look more like the frontend with headers, footers, and sidebars.

We're going to update the backend layout (commonly called BELayout in TYPO3) for the newsletter template by creating a new HTML file and assigning it to the template. As you can see, our default backend layout for the newsletter shows three columns, and there is no real indication of where things will appear in the frontend view:

Creating the HTML layout

Now we can create our own backend layout to replace the default for any pages with the newsletter template:

  • We are going to make the backend layout look as much like the frontend template as possible, so we can start by copying the current newsletter HTML template, template_newsletter.html, to a new file, belayout_newsletter.html, inside the fileadmin/templates/ directory.
  • After you have created the new HTML file, open it up in a text editor so we can make some changes to adapt it to the backend better.
  • Remove the style section in the head of the HTML document. We will add CSS later, but the CSS in the head section will not affect what we want right now.
  • Let's change the main table tag to work better with the backend. We don't need to use tables in backend layouts, but we are using a table here to match what is seen on the frontend. We want our width to be fluid, so we'll remove the width property. We also don't need another border in addition to the one the Page module already provides, so we'll remove the border and replace with a plain white background color:

    <table align="center" style="background-color: #ffffff;">

  • We want the banner to show up. As this is loading in the backend, TypoScript objects will not be loaded. Instead, we'll add the image as an HTML tag in the layout file:

    <td id="banner_image" colspan="2" align="center"><img src='//dgdsbygo8mp3h.cloudfront.net/sites/default/files/blank.gif' data-original="/
    fileadmin/templates/newsletter_banner.png" alt=""></td>

  • As we are not using pixels to constrain the width of our table, we need to change the main content column:

    <td id="main_content" width="64%" valign="top">

  • Inside our HTML, we can use markers to load content fields. The markers are simply the name of the field from the data structure (field_main_article, for example) surrounded by hash tags: ###field_main_article###. TemplaVoila will replace this marker with an area for our different content elements such as the Main Article column in the default layout. So, we can use these markers in our HTML file to add the content fields to our main content column:

    <table>
    <tr>
    <td id="main_article" style="padding-bottom:
    15px;">###field_main_article###</td>
    </tr>
    <tr>
    <td id="news" style="padding-bottom: 15px;">
    <div class="news_item">###field_news###</div>
    </td>
    </tr>
    </table>

  • Next, we can update the width of the sidebar:

    <td id="sidebar" width="36%" valign="top">

  • TemplaVoila only lets us use markers for the fields of type "Content Elements", which are the fields that normally show up as columns in the Page module. Any of the other fields like TypoScript objects or fields that are set in the page properties cannot be part of the layout. The fields from our page properties, like our event fields in the newsletter, will still be automatically shown at the bottom of the page. So, we can't add the events fields to our layout, but we can add a placeholder section with a note for the editors so they still have a better preview of the frontend page:

    <td style="padding-bottom: 15px;">
    <h3 id="event_list_title">Upcoming Dates</h3>
    <p>(Edit events in page properties)</p>
    </td>
    We can use markers for the products section, though:
    <td id="product_list" style="padding-bottom: 15px;">
    <div class="product">###field_products###</div>
    </td>

  • We can use example data for the contact section. As editors will not be editing our TypoScript values, we don't need to tell them where to go to change the values. We can just show them some sample data based on the current TypoScript values so that they remember the contact information needs to fit into the column:

    <td id="contact_info_section" style="padding-bottom: 15px;">
    <h3 id="contact_info_title">Contact Us</h3>
    <div id="contact_info">
    <p>Suite 850</p>
    <p>1214 Rebekah Ave.</p>
    <p>Dallas, TX 75154 USA</p>
    <p><a href="mailto:jeremy@example.com">jeremy@example.com</
    a></p>
    <p><a href="http://www.example.com">www.example.com</a></p>
    </div>
    </td>

  • Finally, we will add some example data for the footer as well:

    <div id="footer" align="center">Copyright Example.com 2010</div>

  • After we have saved our changes to belayout_newsletter.html, we can open it in a browser to see that it structurally matches the newsletter template we are showing to visitors:

Assigning the backend layout

Now that we have an HTML file, we can assign it to the newsletter template data structure in the TemplaVoila module:

  1. Go to the TemplaVoila module, and click on the pencil icon next to the Newsletter data structure:
  2. Select our new HTML file, fileadmin/templates/belayout_newsletter.html, in the BELayout Template File field using the link icon on the right of the text field.

  3. Refresh the cache, and go to our newsletter page in the backend Page module. You will see a page that looks much more like the frontend view, has a cleaner layout overall, and will be easier for our editors to use:

Adding some CSS styling

Our new backend layout is almost perfect, but it would be nice if the titles of each content section were a little clearer. We are allowed to use stylesheet links in our HTML head, so we'll take advantage of that right now. Let's add a link to our HTML file right now:

<head>
<meta charset="utf-8" />
<link rel="stylesheet" type="text/css" href="/fileadmin/templates/
css/belayout.css">

</head>

Now, we just need to create a minimal stylesheet for our newsletter template's Page module with some updated font sizes that might stand out a little better for our editors. Lets create the blank file belayout.css in our templates CSS directory (/fileadmin/templates/css/) right now. We'll update the size of the content element titles and previews using the built-in classes. TemplaVoila uses a class called tpm-preview around each content element in the backend, so we can update the font sizes to make it easier to read. The Page module also uses a class called tpm-title-cell for the title of each section like Main Article or Products, so we can use that class to make our titles clearer:

.tpm-title-cell {
font-size: 14px;
color: #555;
font-weight: bold;
}
.tpm-preview {
font-size: 12px;
line-height: 16px;
}

If you would like to know what classes are used for the rest of the elements in the Page module, the easiest way to find them is by viewing the source code when you are looking at the Page module in your browser. If you want an easy way to scan through the entire HTML output that TYPO3 is using, I recommend Firebug (http://getfirebug.com/) for the Firefox browser or the Web Inspector in Safari (http://www.apple.com/safari/features.html#developer).

Setting a backend layout for a data structure with multiple template objects

The new layout worked great for the newsletter, but we really need to update the main template. We could make a generic template, but how will it handle the multiple template objects? Luckily, the TemplaVoila Page view is already prepared to ignore any markers for content elements that are not active in the current template object. This means that we can create a generic HTML layout that includes the main content area and both the left and right sidebars without worrying about confusing our editors. Let's go ahead and create a new file named belayout_main.html in our templates directory (/fileadmin/templates/) right now with a universal layout:

<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8" />
<link rel="stylesheet" type="text/css" href="/fileadmin/
templates/css/belayout.css">
</head>
<body>
<table style="background-color: #fff;">
<tr>
<td id="logo" colspan="3">
<img src='//dgdsbygo8mp3h.cloudfront.net/sites/default/files/blank.gif' data-original="/fileadmin/templates/logo.png">
</td>
</tr>
<tr>
<td id="left_sidebar" style="background-color: #ddd;">
###field_leftsidebar###
</td>
<td id="content">
###field_content###
</td>
<td id="right_sidebar" style="background-color: #ddd;">
###field_rightsidebar###
</td>
</tr>
</table>
</body>
</html>

Now, we can assign this as the backend layout file for the main template data structure in the TemplaVoila module just like we did for the newsletter data structure. If we load up a few pages in the backend, we can see that the inactive fields are being omitted without showing our markers at all. Without any content elements to be filled, the table cells are simply collapsing. As an example, this template does not use a left sidebar:

This is a template that uses a left sidebar:

Of course, if we had any other information in the cell besides the markers with hash tags, then they would show up. If we want to make it more specific we'll need to set a layout for the individual Template Objects.

Using backend layout files for template objects

Assigning a new layout to a template's data structure is very useful, but we might not want all objects to have to same layout for some reason. Specifically, we might want to assign different layouts to the templates with sidebars without worrying about our modifications showing up for all templates under the Main Template data structure. The good news is that we're not limited to assigning external layouts to Data Structure objects, but we can also assign them to Template Object objects easily. If we want to create a specific layout only for the Left Sidebar Template [Template], we can follow almost the same steps as we did for the Newsletter template:

  1. Create a new HTML file named belayout_left_sidebar.html in the templates directory (/fileadmin/templates/) with a basic HTML layout. We're going to add special instructions for our editors directly into the layout for this particular template. If we put instructions into the left sidebar area in belayout_main.html, they would show up on every page. This is a good reason to assign a special backend layout to just the Left Sidebar Template [Template] object:

    <!DOCTYPE HTML>
    <html>
    <head>
    <meta charset="utf-8" />
    <link rel="stylesheet" type="text/css" href="/fileadmin/
    templates/css/belayout.css">
    </head>
    <body>
    <table style="background-color: #fff;">
    <tr>
    <td id="logo" colspan="3">
    <img src='//dgdsbygo8mp3h.cloudfront.net/sites/default/files/blank.gif' data-original="/fileadmin/templates/logo.png">
    </td>
    </tr>
    <tr>
    <td id="left_sidebar" style="background-color: #ddd;">
    <h3>Only use this sidebar for special links</h3>
    ###field_leftsidebar###
    </td>
    <td id="content">
    ###field_content###
    </td>
    </tr>
    </table>
    </body>
    </html>

  2. Click the edit icon next to the Left Sidebar Template in the TemplaVoila module:

  3. Select our new HTML file, fileadmin/templates/belayout_left_sidebar.html, in the BELayout Template File field using the link icon on the right of the text field.
  4. Now we can save our changes at look at the new Page module in the backend:

TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila
Published: November 2010
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:
        Read more about this book      

(For more resources on TYPO3, see here.)

Using static data structures in TemplaVoila 1.4.2

While we are talking about editing the data structures and backend layout options, we need to look at where TemplaVoila is going in the future. TemplaVoila 1.4.2 introduced static data structures as a new way of working the DS XML files, and the current workflow that we have been using for this article may be deprecated at some point. As of this writing, this feature is still experimental.

In fact, it is the experimental aspect of static data structures that made me almost not talk about it. It is well tested in several environments, though; it's just not going to be turned on by default for a few more versions of TemplaVoila.

For simple websites, you can skip this section. If you build enterprise websites or build a lot of websites with the same template elements, static data structures can be very helpful. I am including it in this article because it will change the way we build backend layout files, but it is not necessary for many simple websites.

What are static data structures

You may not realize this yet, but the current way to create data structures and backend layouts is unwieldy, prone to errors, and hard to backup. Traditionally, the XML of a DS object is stored in the database, and the only way to edit it was through the TemplaVoila module like we have been doing up to now. The major problems with this is that you had to edit only through the control center's text areas, and any custom XML could be wiped out by clicking Modify DS / TO and saving edits through the wizards. Many of us have gotten around this by creating XML documents in a text editor, saving the file as a backup, and copying and pasting the content into the TemplaVoila Control Center text areas. Static data structures save us extra steps and standardize the process.

The concept of static data structures is simple: each Data Structure object is an XML file organized by filename and directory structure. Directories in the fileadmin folder organize static data structures. The main data structure directory is called ds, and it includes a subdirectory for Flexible-Content Elements (fce), which we will talk about in the next chapter, and Pages (page). Inside the directory, each data structure can have an XML data structure file and an optional back end layout HTML file and preview icon using the DS object name to tie them together and extension to assign their purpose:

  • Data Structure: Template Name (page).xml
  • Backend layout: Template Name (page).html
  • Preview icon: Template Name (page).gif

An example data structure for our current website would look like this:

ds/
page/
Main Template (page).xml
Main Template (page).html
Newsletter (page).xml
Newsletter (page).html
fce/

You'll notice that the scope of the template (page) must also be included in the filename. This may change in future versions of TemplaVoila, but it is a requirement right now. This is one disadvantage to static data structures right now for those who don't want spaces or parentheses in filenames on their server, but the new system has a lot of advantages for future template building, such as:

  • Static files are easier to backup and restore on the server. You need to have consistent backups of your database, but actually restoring a broken data structure inside the database can be a monumental task. You can't rollback an entire database on a live site with users, and the only other option is to restore one single field from a large backup file. Static data structures can be backed up with the rest of your site's template files and restored using your default backup software.
  • Similar to backing up, static data structures can be stored in a version control system such as Subversion or Git. This gives us the power to test, deploy, or rollback data structures without performing major operations.
  • You can deploy new templates easier with static data structures. Have a new website that needs a template you built somewhere else? We can copy the data structure files with the Template Object HTML file into the new website, and the only operation left to do in the backend is map the two together.
  • We can work on the XML in the editor of our choice. Many editors such as TextMate can already support TemplaVoila's Data Source XML syntax, and working on a large data structure inside a text area has never been a good option. Just our current main template is almost two hundred lines at this point, so just the ability to have powerful find and replace can save lots of time. If you use snippets like the TextMate bundle, you can save even more time and prevent the frustration of tracking down a simple typo.

Setting up static data structures

To help you understand the static data structures, we will go through an example in our test environment. The TemplaVoila developers are still working on the implementation, so some of these steps may have changed or become more automated through wizards. Remember to check the online documentation (http://typo3.org/documentation/document-library/extension-manuals/templavoila/current/) if you need more updated references. Once we have enabled static data structures, TYPO3 will no longer check the database for our XML, so we need to make sure that we follow of the steps for conversion carefully.

  1. First things first, you need to back up your current database. We are about to change the fundamental way that templates work, so you need to the ability to restore the current data structures in the database. The more current your backup, the easier it is to restore. If you are not sure how to backup your database, MySQL has instructions on their website (http://dev.mysql.com/doc/refman/5.1/en/backup-andrecovery.html).
  2. Now we can create new directory structure for our static templates. The TemplaVoila extension wizard should be able to do this, but some versions do not currently set the permissions correctly so it's easier to create them by hand. Create a directory named ds inside the fileadmin directory. Inside the ds directory, create two subfolders: fce and page. Again, make sure that they are readable and writable by the web server.
  3. In the backend of TYPO3, go to the Extension Manager (labeled Ext Manager) under the Admin Tools section of the left frame. Make sure that Loaded extensions is selected in the main drop-down.
  4. Choose the TemplaVoila! extension in the Miscellaneous folder to edit the extension installation and enable static data structures.
  5. In the configuration section, check the checkbox labeled Enable static files for data struct... to enable static data structures in this installation and click on the Update button to save our changes.

  6. Next, we can start the DS Wizard by clicking on the button labeled static DS Wizard - Step 1: Check paths. This will allow the wizard to check that our new directories are created and have the correct permissions for the static data structure files.
  7. After the wizard checks our directories and permissions, it will try to convert our existing data structures by creating XML files in our ds/page/ directory. If we had not enabled static data structures, we could still use this part of the wizard to save static copies of our XML as static data structure files for backup. We have enabled static data structures, so we need to make sure that we convert all of our data structures to prevent data loss. Once again, TYPO3 will no longer check the database for our XML when static data structures are enabled. With that in mind, we need to go ahead and select all of our data structures for the conversion step.
  8. We need to confirm that we are enabling static data structures and allow the wizard to update our database by checking the box labeled Update database records and enable static data structure. Now is a great chance to double-check that we have a current backup of the database including the pages, tt_content, tx_templavoila_datastructure, and tx_templavoila_tmplobj tables. Once we have verified our backup, we can click on the large button labeled static DS Wizard - Step 2: Update database records and enable static data structures.
  9. After the wizard is done processing, we can see two new files in the /fileadmin/ds/page/ directory named Main Template (page).xml and Newsletter (page).xml. In order to move over the backend layout files, we just need to copy them from the fileadmin directory and rename them to match our new data structures. Copy /fileadmin/belayout_main.html to /fileadmin/ds/page/Main Template (page).html and /fileadmin/belayout_newsletter.html to /fileadmin/ds/page/Newsletter (page).html. To create backend layout files in the future, all we have to do is create an HTML file with a filename that matches the data structure we are modifying. TYPO3 will automatically detect the new layout.
  10. Next, we could add a preview icon to either data structure by adding a GIF file with the name of the DS object. For example, a preview icon for the main template just has to have the filename Main Template (page).gif in the /fileadmin/ds/page folder. Currently, it detects the preview icon by name and extension, so only GIF formatted images are allowed. You may have to convert from PNG if that is what you were using before.
  11. Clear the cache for TYPO3. We have made a lot of changes, so the cache will be inconsistent until we clear it. If any Template Object records lost their association with the data structures during the update, we may need to update them in the TemplaVoila Control Center by selecting them in the Lost TOs tab and updating their Data Structure value.
  12. Finally, we can re-enable our backend layouts by copying the HTML files into the ds/page/ directory. For example, we can use our backend layout file for the newsletter template by copying fileadmin/templates/belayout_newsletter.html to fileadmin/templates/ds/page/Newsletter (page).html. Go ahead and copy the belayout_main.html to ds/page/MainTemplate (page).html as well. The backend layout that we created for the Left Sidebar Template need not to be changed because the changes only affected data structures. From now on, we can create new backend layouts without ever touching the TemplaVoila module in the TYPO3 backend; we just need to make HTML files inside the ds/page/ directory.

Modifying static data structures

After the cache is cleared and any lost templates are updated, we'll be using the new static data structure. Aside from the obvious changes we just made, a lot of our workflow will still be the same. We can still edit the data structures through the Modify DS / TO wizards in the control center, but now we can make a copy of our files before we make any large changes. Of course, we can also now edit the XML directly in an editor if we want.

If we want to create a new data structure, we just need to either make a blank XML file in the /fileadmin/ds/page directory with the name we want and the (page) scope or copy and duplicate one of our existing static data structure files.

Summary

In this article we have covered:

  • Learn about the default rich text editor in TYPO3
  • Learn how to configure the rich text for a single page or a whole page tree
  • Update the CSS in the rich text editor to match what users will see on the frontend
  • Remove unwanted classes and tools from the text editor
  • Add support for extra HTML tags and YouTube video to the text editor
  • Learn how the configure the Page module layout of our templates with backend layouts
  • Learn how to create a backend layout for data structures with multiple template objects
  • Learn about static data structures and the future of TemplaVoila templates

Further resources on this subject:


About the Author :


Jeremy Greenawalt

Jeremy Greenawalt is a full-time developer and part-time writer with close to ten years professional experience in website and application creation. His first love was writing, but programming quickly followed.He is a co-founder of Vintage 56 where he helps develop websites, online shopping carts, web apps, iPhone/iOS apps, and anything else his friends can think up. Jeremy is also the web director of a large ministry, Generals International. Jeremy lives near Dallas, Texas with his wife, Rebekah, and their ever-youthful puppy, Aingeal. He loves spending time at home reading, playing around on the piano, or just relaxing on the couch with his family. You can read more from Jeremy at pocketrevolutionary.com, and you can follow him on Twitter at @jgreenawalt.

Books From Packt


TYPO3 4.2 E-Commerce
TYPO3 4.2 E-Commerce

TYPO3 4.3 Multimedia Cookbook
TYPO3 4.3 Multimedia Cookbook

Apache OfBiz Cookbook
Apache OfBiz Cookbook

CMS Design Using PHP and jQuery
CMS Design Using PHP and jQuery

Mastering phpMyAdmin 3.3.x for Effective MySQL Management
Mastering phpMyAdmin 3.3.x for Effective MySQL Management

Joomla! 1.5 Top Extensions Cookbook
Joomla! 1.5 Top Extensions Cookbook

Drupal 7
Drupal 7

TYPO3: Enterprise Content Management
TYPO3: Enterprise Content Management


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software