Out of Typo3

Typo3 is a powerful content management system (CMS) in wide spread use. It encompasses user administration, front end and back end. It enforces design and layout rules. All is held on the server in a data base system. Additionally Typo3 needs PHP and a web server (Apache e.g.), requiring some freedom of configuration there.

Typo3’s advantages are well documented. It is always emphasised that authors would need no knowledge on neither web technologies nor languages (HTML, CSS, JS etc.).

Why should anybody want to leave Typo3?

Despite its enormous popularity there are cases of dislike and reluctance by users. Main reasons are

too less freedom by administrative or programmed restrictions via layouts, templates and designs. One can not, for example, get rid of navigation bars not adequate for the page content. Multilingual pages with “switch language buttons” are not feasible, if that’s not chewed for from the beginning.
no (real) test preview
no version control (worth the name)
page authors just can’t get into gear with the back end.

The last and prevalent reason to leave may seem astonishing. Often, the assertion of sheer simplicity for page authors was the main reason (or pretence) for introducing Typo3. The back end can be configured or programmed in great freedom – and hardly two different installations are found with the same beck end / editor behaviour.

So voluminous and good text books for Typo3 administrators / programmers are found but nothing comparable for the poor web authors. As a substitute, after going Typo3 some institutions offer multipart trainings for page authors, of almost the size of a good basic course for HTML and CSS. In the latter something of common value and with good text book support would have been learned.

Additionally, fearing the complications of installing Typo3, institutions use external service providers therefore. In the long run this may cause additional costs, inflexibility and problems with responsibility and delays.

Away, but whereto?

If you think you must leave “Whereto” is the hardest question. In the given circumstances the new solution has to be “better” in the sense of less pain. Basically, the posibilities are

another CSM newly set up (with PHP, Database system and back end)
directly made static HTML (CSS, JS)
generating a static site using simple page languages, like e.g. markdown

Goal 1, i.e. again a CMS, no matter if new Typo3 installation, Wordpress or consorts is often considered a no go after a painful journey and is not considered here as alternative. If, nevertheless, going that way looking for and testing tools for conversion or import and export is crucial – when not wanting to newly set up a tiny site.

Goal 2 means maintaining directly static HTML, CSS und JS. With adequate tools, syntax support and version control (with Eclipse and SVN e.g.) astonishing good and fluent work is possible alone or in a small team.

Especially, when wanting authors providing or maintaining content with (almost) no encounter with HTML, one will go for goal 3. One approach is generating a static site with Jekyll from pages written in Markdown. The best way thereto is via a complete, consistent – repaired – static web site.

Goal 3 necessitates goal 2 in most cases, avoiding the ongoing maintenance of HTML pages.

Go static – goal 2

When having the complete (CSM) web site as static HTML and FTPing it to the same server / domain one is rid of Typo 3 (and of DBMS and of PHP) and no visitor will see a difference putting – except, perhaps, better performance.

Fortunately, to get a complete static copy of the Typo3 generates site on your development workstation you neither need special conversion tools nor DBM or administrative access. One installs the free tool WinHTTrack.exe – as of now version 3.49-2 – and runs it. Important settings:

Local structure: site structure
rewrite links: Relative URI / Absolute URI
do not obey robot.txt

The result should show up by a file://-URL locally – oops we’ve got local test preview – and after uploading to the server one is, as said, ready. Well, not really.

In most cases, on a closer look, the whole delivery from Typo3 is a giant mess with horrible directory structure and disgusting file names as well as a load full of redundant unused things. Using an Eclipse and bulk search and replace, this should be cleared and honed step by step. This will be hard work but rewarding in many respects; in the end one has a clear view of the site’s structure and layout.

And when on it, one should start by collecting style sheets, scripts and important images in this structure (from site root).

├── assets
|   ├── css
|   ├── images
|   └── js

That’s customs and conventions with Jekyll.

Dr. Jekyll’s markdown

After having gained that order, consistency and insight on can switch to generating a static site with Jekyll and Markdown with relative ease. The background and installation is very well documented. And when using Github server pages – perhaps for a blog like this one – one has all that anyway.

The whole thing works as well without Github and without having blog. And the best of it is the local preview function.

The Transformation is simple and can be made fluently in small steps, as Jekyll

a) just copies all things being statically present 1:1 and
b) a .html-page being syntactically correct is also a syntactically correct template (in Jekyll’s template language Liquid).

Such template makes per se no sense as just generating this single page. But, when finding n .html pages being equal except for title and a content block, one easily can convert them to one template plus n markdown (.md) files. When coping with that the ice is broken.

Dr. Jekyll’s site generator

The command

  jekyll serve              or  
  bundle exec jekyll serve  

depending on installation generates the static site in the directory _site where it can be viewed from by jekyll’s build in web server at
http://127.0.0.1:4000/
Any changes in templates, assets or markdown automatically regenerates the site in directory _site.

That is real local preview. And, when content with the result, just ftp the content of directory _site to your web server. With Github server pages you would just commit and push and Github’s jekyll will generate the site changes on its server. But, as said, the whole thing works with normal web servers which one can upload files to, too.
See also the post on Jekyll Tipps.