Cast Iron Coding Blog

There are, after all, lots of reasons not to use TYPO3. During meetings with current and prospective clients, I often find myself cast as the defender of TYPO3. I suspect that just about anywhere that's not Germany, clients want to know why they should be looking at TYPO3 when their colleagues and peers are only talking about Drupal, Wordpress, and occasionally Joomla. If TYPO3 is so great, the argument goes, why have I never heard of it?

As a developer (most of this blog's readers know that I wear many hats at CIC, my favorite of which is actually sitting down at my desk and writing code), I often end up defending TYPO3 against a few common lines of questioning. There's the anti-PHP crowd that I sometimes run into. For the most part, talented developers in 2011 don't select PHP as their language du jour. Because of its early accessibility, its ubiquity in hosting environments, and the lack of support for real object-orientation in its early days, a lot of really awful procedural code has been written in PHP, and its been hard for the language to escape the legacy created by that code as its aged. Many really smart developers shy away from PHP on principal, and I can't say I always blame them. If PHP has declined in popularity, so has the concept of the CMS. These days, skilled developers want to work in frameworks like Rails, not content management systems that began production over ten years ago. Age brings features and functionality, but it also brings baggage. Sometimes, it brings lots of baggage. I'm thinking of Moodle, Mediawiki, and a whole host of other open source PHP apps built on codebases that now seem desperately outdated.

In short, I find that I'm constantly forced to question our commitment to TYPO3 in the face of its waning popularity (which creates doubt in the minds of marketing people) and its questionable technical pedigree (which creates doubt in the minds of developers and IT people). The lack of adoption in the US creates a feedback loop in which the lack of adoption is used as justification for the continued lack of adoption. Yet somehow, in spite of these questions, my team and I keep using TYPO3. We keep coming back to it year, after year. Why?

Well, unlike some other agencies, it's not because TYPO3 is the only system we're comfortable with. CIC is fundamentally a development agency (not a design agency), and the people on the CIC team understand how to code. We're a group that's always interested in a variety of technologies—I've seen people in this office working with Ruby, Python, PHP, shell scripting, Java apps, all sorts of Javascript tools (Coffeescript, Sencha libraries, the Knockout MVVM framework, Node, and more). We're a pragmatic, pick-the-right-tool-for-the-job, kind of shop and we're not unquestioningly married to a single technology. And yet, we keep using this PHP based CMS that's over ten years old. Why?

As I've been trying to think through and articulate an answer to this question, I'm reminded that there are truly unique aspects of TYPO3 that convince us to stick with it. To hear my thoughts on these aspects of TYPO3, click on the "continue reading" link, below.

TSConfig, for those of you who aren't familiar with it, it used to control the back-end experience. Now, TSConfig isn't exactly one of TYPO3's proudest features. There are some real problems with how TSConfig was originally implemented. For one, there's an artificial distinction between User TSConfig and Page TSConfig, and it's time consuming and irritating to try to track down whether a setting belongs in User or Page configuration. Similar to Typoscript, there are also a number of naming inconsistencies in TSConfig, which hopefully the project will one day bite the bullet and clean up. That said, it's still an important part of TYPO3, and an essential part of configuring the backend. Also, if you're smart and reuse configuration between TYPO3 projects, then you really only need a solid TSConfig starting point that you can use on multiple sites.

Nobody ever accused TYPO3 of lacking features—it is without a doubt the most feature-complete open source content management system. The downside to this strength, however, is that for many sites there are a number of features enabled that are really not needed. For example, sites that aren't localized into multiple languages or that don't use workspaces or versioning suffer from extra UI elements in the backend that should simple be turned off. Moreover, TYPO3 has a history of providing users with multiple ways of doing the same thing, which—in my view—is more often a problem, as users struggle to find the correct way to accomplish a task. At CIC, we try to solve this problem by starting with a backend that has a lot of functionality turned off. For example, we disable the new page and new content icons at the top of the page module and instead encourage users to use the page tree to create new pages and the content areas in the page module to create new content elements.

We accomplish these small changes to the backend with a TSConfig file that we include on most sites we build. For anyone who's interested, I'm including the file below the fold. Let us know in the comments if it helps, or if you have any little TSConfig gems of your own to add.

The work that this post describes was done for a client that needed to display project records on the front-end of their site. These projects are fairly complex records, with a handful of many-to-many relations to categorization records (constituents, services provided, category, geographic scope, etc). There are probably 15-20 fields on the project record, in addition to five or six relational fields and a geocoding component. A big part of the project was creating a front-end interface for searching the projects based on seven or eight criteria, as well as a single view for when users drill down to a single project and a map view. To get all this to work, we spent some time developing a fairly robust project model, as well as models for the various supporting records.

One twist on this project, however, was the fact that the project records did not live in TYPO3. The client's project intake process took place in Salesforce, where projects were represented by Salesforce Account objects. In addition to building out the models and the UI, our job was to provide a mechanism to pull project data from Salesforce into TYPO3 every hour or so using Salesforce's web services. We've been down this road many times, and we usually end up writing import scripts, which are mostly one-offs, to get the job done. Those import scripts tend to contain logic for handling database updates and, to some degree, for working with the various data models. In this case, budget was tight and we wanted to reduce code redundancy, so we set about finding a way for our import mechanism to take advantage of the ExtBase models that we'd already developed as well as the code we'd written for each model's storage repository. Why write a bunch of database queries in the import script if we could take advantage of existing ExtBase classes? The first step was setting up a scheduler task. Now that we have a scheduler in TYPO3, we rarely write scripts that use TYPO3's CLI interface anymore (did you know TYPO3 has a CLI interface? Well, it does!), as it's easier to just write tasks. When we built this site (maybe 6 months ago), there was some hackery involved in utilizing ExtBase within a scheduled task. This hackery may no longer be necessary; I haven't gone back to look at this code in relation to recent versions of ExtBase so I'm not entirely sure.

Over the past month or two, as we’ve finished transitioning from our own MVC framework (CICMVC) to ExtBase, and as we’ve fully incorporated Git and Phing into our release processes, we’ve made a number of architectural changes to the starter package we use for new sites. One of the biggest changes that we’ve made is to finally abandon TemplaVoila in favor of fluid-based page templates and back-end layouts.

Unlike many agencies that have embraced TemplaVoila wholeheartedly, we’ve never quite been comfortable with it. We’ve always felt that the mapping process required by TemplaVoila is tedious (and error-prone). TemplaVoila templates also aren’t very portable, and because parts of them are stored in the database, they’re difficult to track in version control, which causes a number of problems for us. Nonetheless, we’ve kept coming back to TemplaVoila over the years because of the obvious shortcomings of the TYPO3 page module, which has traditionally been limited to four content areas.

But all that has changed now, hasn’t it? After all, we no longer need TemplaVoila for FCEs, since we can simply create custom content objects using ExtBase and the approach I outlined in previous posts on this blog. It may take a few minutes longer to make a custom content element (unless you’ve had some practice at it), but the payoff in standard TCA user interfaces (come on, admit it: FlexForms suck!) is worth the added trouble. More important, we no longer need the TemplaVoila page module because we now have back-end layouts.

Like TemplaVoila templates, back-end layouts make it possible to create a tailored editing interface that contains as many or as few content areas as needed, thereby addressing the limits of the classic page module. It also provides the editor with a clear interface on the page module for selecting a template for pages and child pages. Finally, it can be used without any of the tedious mapping process and the added XML abstraction layer that TemplaVoila requires.

We’ve written an extension called "Fluid Pages" that incorporates backend layouts with Fluid templates and solves the problems described above (you can download the t3x file herefileadmin/media/blog_images/reason__9/T3X_fluidpage-0_0_0-z-201105241317.t3x). I think it’s a viable approach to page templating in TYPO3, one that’s easier for both editors and developers, and I’d love to know what you think.

Read on for specifics about how to get up and running with Fluid Page templates!

When Hierarchies Just Make Sense

I'm just as inclined as anyone else to believe that there might be a way to organize website content in non-hierarchical lists. But, until the day comes when the folder and files are no longer the dominant metaphors for organizing digital information, there's a lot to be said for how hierarchies encourage intuitive user interactions when dealing with large amounts of information. Have a look at the page tree in the image to the left. That's the tree for this site, castironcoding.com. As you can see, there's nothing too complicated going on here, and that's the point. The page tree aims to be a simple, straightforward representation of your site's content. It's easy to find any page you need to edit because it's just a matter of drilling down through the tree until you get to where you need to be. Once you start working with TYPO3 you'll quickly notice that the URL of a page mirrors the page's position in the tree. So, for instance, if I wanted to edit the page at castironcoding.com/resources/case-studies.html I'd start at the root of the tree, expand the Resources page and then click on the Case Studies page to edit its contents. Couldn't be simpler! It's true that I'm using a pretty basic example and your site may need something a little more intricate, but the fundamentals will remain the same: where you put your content in the tree quickly tells you where you'll find that content on the front end of your site. Surprisingly, when looking at other popular open source CMSs and web-publishing platforms, content trees are not always standard practice. Whenever I have to work in Drupal or WordPress, the page tree is the first thing I find myself missing. I think this points to TYPO3's ability to serve as a content-agnostic CMS. Other web publishing platforms, like WordPress and Drupal, while not completely devoid of any sort of hierarchical content organization, will more often than not force you to arrange your content according to that platform's specific idea of what website content is ("blog posts" in the case of WordPress and "nodes" in the case of Drupal, for example ). TYPO3, on the other hand, doesn't force you into any "content paradigm" but rather works with you as you customize and tailor your website's needs and goals.

Boy, it's been a dog's age since we last put up a blog post! If only writing blog posts were as easy as making TYPO3 sites! Apologies for the wait on this last post; better late than never, right?

At the end of the last post, we had arrived at the point where our custom ExtBase content element was appearing on the page. You should be seeing something like this:

If you've made it this far, you've made it past the hard part—configuration—and you're ready for the fun part: implementing your content element.

When getting started with a new development framework it takes time to learn all the little tricks that help you work quickly and efficiently. This can certainly be the case with Extbase, TYPO3's powerful extension and application platform.

At Cast Iron Coding we've been working with Extbase long enough now that we've put together a list of things to be aware of or check when you encounter trouble while writing Extbase-based extensions.

All of the items mentioned here are readily available in some form of official documentation. If you're new to Extbase, it may take some time before you become familiar with all of the existing resources and so we're making this resource available so that you can (hopefully) save some time and avoid some frustration when getting started.

The CUNY Academic Commons serves as a collaboration and meeting hub available to the thousands of students, faculty, and staff that make up the CUNY network of schools, spread across the greater New York City area. The CAC Featured Content plug-in was written to address a simple yet subtly complex need identified by the project's organizers. Even though WordPress and BuddyPress together enable users to produce lots of content, there was no built-in tool that allowed the site editors to easily highlight individual blogs, blog posts, members, groups, and other types of content. An important goal of the project is to promote the best work occurring across the site so that users can be inspired by their peers. It seemed like there ought to be a content tool that would help further this goal.

With this in mind, we set out to develop a WordPress plug-in that would offer editors a widget that could be used to render previews of various types of content produced across the Commons blog and user/group profile network. Let's have a more specific look at how the widget works.

Enough throat-clearing! Let's get going. As I mentioned in the last post, we're going to try to create a content element that looks like this:

The content element should be rendered from a clean, simple interface that looks like this:

Because this record is a tt_content record, we want to use as many of the available fields on the tt_content record as possible. Type, header, and text are all standard fields on the tt_content record. There is one additional field, however, and that is box color. In general, I don't recommend adding a bunch of additional fields to tt_content, but adding one or two won't hurt and it's not, in my view, inappropriate to add a new tt_content field for a new content element type, since that's where TYPO3 stores data about content.

Before getting too technical, however, I want to provide a little background. For those of you who don't know, ExtBase is TYPO3's Model-View-Controller framework that was introduced in TYPO3 4.3. In the old days (prior to about 2009), TYPO3 extensions were based on a class called piBase. Extensions that rely on piBase tend to be procedural and difficult to modify and maintain. Take any popular extension in the TER as an example; many of them will contain thousands of lines of code in a single pi1 class. ExtBase follows the lead of other popular MVC frameworks that are on the market now and forces extension developers to write much cleaner, more object-oriented code that is easier to scale and maintain. Before ExtBase came out, developers at Cast Iron Coding realized that piBase extensions were simply too difficult to write and there was too much infrastructure code that had to be written each time. We developed our own MVC framework in-house back in 2008, and we've used it on numerous projects since then. As ExtBase becomes more stable and more feature-complete, we're slowly phasing out our own MVC extension and replacing it with ExtBase.

The goal of this post is to describe and document how we currently use ExtBase (and other parts of TYPO3) to provide users with a customized, more intuitive backend interface for editing content. It's an approach that we've only recently started using, and I expect we'll be improving it and iterating over it on future projects. When you're done working through this post, you should be able to accomplish the following: