WordPress Programmer Learns TYPO3
Embracing a new technology requires your mind to expand to encapsulate it. Whether you’re mastering the timer on the boiler or plotting re-entry trajectories of a dragon capsule, at the end of that journey, you’ll be in a better place. This alone is reason enough to pick up a new skill as often as your free time allows.
But how many of us have the time to plough into a new technology just for the fun of learning it these days? If you do, lucky you! Why not share your journey in the comments section? In case you don’t… read on to learn from my journey from fuzzy, WordPress comfort zone and into the unknown abyss of TYPO3.
Installation
I made my first foray into the world of TYPO3 by installing on a local MAMP server. WordPress has the famous five minute install but TYPO3 didn’t take long either.
Even if you don’t know what the commands mean, keep working through them and you should get there with relatively little problem. Alternatively, you may well find that your web host platform has a one click installation of TYPO3, just like they do for WordPress. Once the commands take care of the base install, the wizard helps with installation/setup from this point and I found my way into a new TYPO3 install without issue.
First Impressions of TYPO3
It’s colourful but the UI isn’t as clean or uncluttered as WordPress (TYPO3 could embrace this challenge - more on this later). There’s some initial clicking around the icons to find what they do but the tooltips that are baked into any site do make familiarisation just a few clicks away.
It took some time to get to know what each part’s use was and there’s a great deal of detail. For example, clicking on the page icon gives info pertaining to the page as a container - its title, whether or not it shows in the menu, its categorisation (I’ll come back to this) whereas you get a different layout and set of options when clicking on the page’s name.
This is where you get to use the flexible content area wizard to populate the content of the page. It gives you the option of adding different types of content into an intuitive interface that provides for flexible content boxes and different sorts of content elements, right out of the box.
Breaking down TYPO3 functionality - a brief tour
The sidebar menu shows all the different major working areas within the site. It’s really quite similar to the organisation that WordPress developers will be used to, although there’s no emphasis on Themes, Plugins or Widgets, no ‘Appearance’ tab and, crucially, there’s no ‘Settings’ pages (a major difference, I will return to, see notes on TypoScript below). To the right of the sidebar menu, the ‘page tree’ shows the hierarchy of pages, as they appear in the site menus, which is different from WordPress, where the Pages and Menus are separated from one another. The page tree also shows resources, which are XYZ, and are hidden from the site navigation by convention. Liquid Light, uses this area as the repository for records, categories and page content that isn’t part of the main site navigation and is hidden from the front end view.
Page Mode
Allows you to see the content in the page and the content elements that it is made up of. You can copy them and paste them in the place you want, or drag them around to change the order: very much like ‘Divi’ sites, ‘Visual Composer’ and now the native ‘Gutenberg’ can do with WordPress. Unlike WordPress however, TYPO3 didn’t require a plugin or theme to do this.
Records
Are similar to WordPress’ “Posts” - but this is where the two platforms start to diverge a bit more. Creating Custom Post Types in WordPress is a well trodden (and documented) path — Extension architecture on TYPO3 consists of a fair bit more. Each extension needs to be built out with structure in the database, writing real (if fairly unthreatening) MySQL, and several separate configuration php files, which of course, must be configured correctly to work at all.
Categorisation & URL structure
Categories are often misused in the WordPress environment as a cure-all solution to separating content of different kinds. With WordPress, categorising your blog posts is straightforward enough but it’s often better to create a Custom Post Type and custom taxonomy, which needs code to initialise and whole page templates of extra markup to deal with the taxonomy, not to mention some occasionally tricky tax_querys. TYPO3 seems to have some advantages to the way it deals with categories and URL structure.
For example: A WordPress page summarising a client’s services and a custom post type, detailing those services, could easily end up with a permalink conflict that needs some custom rewrite rules to be applied to get around it. It’s messy and can be fairly complicated. If you were then to detail those services in a case studies catalog, it could get even more complex.TYPO3’s ability for a page to also be a category makes it quite a powerful solution for things like permalinks conflicts problems.
TypoScript
To configure the fine tuning of a site’s functionality, WordPress uses Page Templates, Settings Pages and Shortcodes. These give flexibility to functions and allow the developer to maintain tight control of what functionality appears within which part of their site. Conversely, TYPO3 makes minimal use of settings pages within the CMS itself but instead has its own configuration language called TypoScript, (not to be confused with Microsoft’s TypeScript!). TypoScript allows the developer to configure the site’s extensions (plugins) with extreme precision. Each element of the markup can be manipulated, added to, removed from and restricted from the scripting language, so it gives a very high degree of control to the functional building blocks of the site and it does so while keeping these configuration options separated from the content area of the site. TYPO3 in fact, does a much better job of ‘separation of concerns’ than many other CMS options available. The downside is, non-programmers may be frightened silly by it, and perhaps understandably so.
Documentation
Sadly, the documentation of TYPO3 leaves quite a lot to be desired. Maybe WordPress developers are a bit spoiled. TYPO3 documentation does exist, of course, but if we’re talking comparisons, there isn’t one. WordPress’ documentation is legendary, extensive and has its own name: the WordPress Codex (Ironically enough, it isn’t a codex). Each topic is broken down into myriad parts to make it easily digestible, has numerous examples and, being WordPress, has literally thousands of people writing about it all the time. It’s constantly revised and updated and because there’s a WordPress way to do things, there’s little variation in the application.
To be fair to TYPO3, it’s used in so many ways, that it is genuinely difficult to document adequately, dependant on your chosen configuration. Much is left to the user to figure out, by necessity, as it’s perfectly possible few, if any, have tried to build with it in the same way you will. As a consequence of this, You simply can’t dive into TYPO3 without knowing how to wrangle PHP and being able to pick up the basics of TypoScript (hence having experience thinking like a programmer). So, partly because approaching any given problem has a very broad scope, and partly because it simply doesn’t have the number of enthusiasts, TYPO3 doesn’t compare favourably when it comes to documentation.
Extending core functionality
TYPO3 can be configured to come out of the box with a great deal baked-in. WordPress needs to have it built-on, usually in the form of a plugin. Running your own version of the core of TYPO3 seems quite common, whereas in WordPress one of the cardinal rules is that you don’t edit the core. Both structures are extendable and both very specific in the way they must be approached. Both systems can be extended by installing plugins and the risks and rewards of using a third party’s technology must be weighed up carefully. If you’re rolling your own solution, the documentation provided by WordPress can help you create but you’re constrained to do things the WordPress way. TYPO3 won’t impose limits on the way you build in the same way but because of the nature of the documentation, you’ll be doing it without having your hand held.
UI/UX
The back end user often is not a technical person at all and may need all the help they can get. Even in the stripped down version with lower levels of permission, TYPO3 Page layout is comparatively cluttered and could be clearer, certainly when compared to WordPress’ brand new Gutenberg editor. Removing unwanted variables from the back end user takes some of the excess away (and it’s true to say that a strength of TYPO3 is it’s granularity of control over permissions, so you can easily turn off unwanted sections) but this doesn’t improve the GUI, which is practical in nature (beauty is not its strong point). It’s understandable that there’s complexity, since there’s a huge number of variables given to the user - it all goes along with the flexibility of TYPO3 - it would seem the main focus of the TYPO3 developers has been on functionality, rather than design, and as such its whole UI (especially the page editor) could use some attention.
What kind of developer are you?
Dealing with WordPress, it’s possible - encouraged, even - to install a site from your web host and poke about until you’ve got a website. You can use one of the excellent built in themes, or surf around to find free or paid themes. Then, you can use the Appearance tab to change parts of your site, to get you to a tinkered equilibrium. If there’s some functionality you’d like your site to do, it’s meant to be really easy to install a plugin, test it out on your site and then delete it and try another, just for fun. This approach has launched the interest and learning journey of many full fledged developers (yours truly included). Progress a little further in WordPress and you might start to edit your installed themes with child themes and plugins, using the hooks and filters. Often, due to its excellent documentation, it’s possible to copy a block of code and paste into the “functions” file without knowing quite how or why it does what it does.
...Web development magic!
~ Magic always comes at a price though, doesn’t it?
Some of the criticisms I’ve heard levelled at WordPress are that it’s slow, full of code bloat and insecure - risks associated with such a low bar to entry; Building poor code on top of a poor template can easily appear to work for your immediate needs and look great but that doesn’t mean it will be robust, secure and stand the test of time. It’s easily possible to know just enough to be dangerous, without even necessarily knowing you’re dangerous.
If you’re running WP sites, be sure at the least that you’re always up to date and only using plugins and themes from trusted and well maintained sources.
The principal difference for me, between TYPO3 and WordPress is this: TYPO3 has plugins and themes too but they’re way less popular purely because the people using them are brewing their own. It’s really not possible to step into development with TYPO3 until you know your hawk from your handsaw, so the people involved in building with it have already progressed past the perceived magic of development and are well into building their own empires of code. Beyond the structure of the directories and keying your functions into the core of the site in a seamless way, you’re left to your own devices much more with TYPO3.
The truth is, It’s always a daunting path into the unknown, a learning curve, stepping into a new piece of technology, whether we’re talking about websites or the aforementioned settings on the new boiler. If you already have a practical application for the new skill, then the leap of faith is much shorter, but there’s always a spell at the beginning where you’re out of your element. Embrace it! …breaking through that spell takes tenacity, courage and (particularly in the case of programming, where computers never say, “well done!”) a thick skin.
Each CMS has its pros and cons - if you’re after a scalable and robust solution that can cope with anything you care to build into it, TYPO3 is an excellent enterprise solution. It’s necessarily complicated, with more sections to configure and learn but the payoff is that you can configure your site with intimate control of almost everything.
If you don’t need quite that level of sophistication but have the expertise and can still spend the time to streamline the code, WordPress can be a very efficient and elegant solution but beware the middle ground between your own bespoke themes/plugins and off-the-peg solutions. Attempting to extend core or plugin functionality without appreciating the possible pitfalls, especially those related to security, could do more harm than good. Choose themes and plugins from reputable builders, recently updated, with plenty of reviews and stars. You often get what you pay for but there’s no real regulation on theme and plugin marketplaces, so do your research thoroughly for each addition you make, or maybe talk to one of us here at Liquid Light… we’re always happy to help and we’d love to hear from you.
Have you had to wade through the minefield of which CMS to choose? Did you find that one had advantages over another for your application? How about the learning curve... which CMS was the easiest to pick up and why? Which is the best value system compared to the learning time you put in?
