Cast Iron Coding Blog
Posted December 21, 2011 by Zach Davis
This blog post has been floating around in the back of my mind for many weeks, along with another, more technical post on ExtBase, which I hope to compose over the holidays. The prompt for this post has been the question "why do we continue to use TYPO3?"—a question I often ask myself during my day at Cast Iron Coding.
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?
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.
Posted October 13, 2011 by Lucas Thurston
It's a blessing—and sometimes a curse—that TYPO3 is highly configurable. Many fields, buttons, and UI widgets can be turned on or off for different types of backend users, and at CIC we pay a lot of attention to the backend user experience. Read on to see an example of the TSConfig that we use in our starter package that serves as the foundation of most new TYPO3 sites we build.
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.
Posted September 7, 2011 by Zach Davis
This post goes out to @dstankowski who asked me to follow up on the ExtBase talk I gave at the 2011 San Francisco TYPO3 conference. During my presentation, I mentioned that we had written an importer task that relied heavily on ExtBase, although I didn't go into too much detail about how it worked. Time is short today, so I'm going to keep this post as brief as I can. If I forget to cover anything, let me know in the comments and I'll try to clarify.
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.
Posted May 15, 2011 by Zach Davis
Regular readers of the blog know that we've really embraced ExtBase, TYPO3's new MVC framework, and its new templating system, Fluid. Not only is it ultimately more rewarding to develop with ExtBase than with the older, more procedural methods for building TYPO3 plug-ins, it's also more efficient. Because ExtBase encourages object-oriented development and strong separations of logic and presentation, we end up with more modular code that we can reuse across projects. This modularity helps drive revenue growth for CIC while reducing the time (and costs) associated with developing custom TYPO3 extensions for our clients. Win win!
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!
Posted May 11, 2011 by Michael McManus
The TYPO3 page tree is a powerful feature and is one of the keys to TYPO3's adaptability. It's true that other open source CMSs available today represent site content in hierarchical lists, but there are a couple of reasons why I think TYPO3's approach stands out: 1) The page tree's intuitive layout and edit features helps you stay organized so that you can focus on developing content for your site; 2) The site tree is flexible and isn't limited to only displaying "pages"; 3) Automatic menu generation is remarkably simple. Let's walk through each of these items and when we're done I think you'll agree that the site tree is one more reason why TYPO3 succeeds in delivering complex capability and flexibility at the same time.
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.
Posted April 24, 2011 by Zach Davis
Welcome back, TYPO3 true believers! This post is the conclusion of a three-post series on creating custom content elements with ExtBase. The first post in the series explained how to customize the back-end content wizard with the aim of making the content choices more organized and apparent to non-technical users. The second post explained how to kickstart a new content element and hook that content element up to extBase. This post will show how to actually render some content on the frontend using our ExtBase controller and our Fluid view.
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.
Posted February 23, 2011 by Michael McManus
Our short-list of common Extbase development problems and tips about knowing where to look for answers when you encounter a problem not mentioned here.
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.
Posted November 12, 2010 by Michael McManus
We spend a lot, if not most, of our time at Cast Iron Coding developing code for various TYPO3 implementations. Yet, we also spend a fair amount of time developing for other platforms as well, like WordPress. Recently, we had the opportunity to develop a very robust plugin for a project we've been involved with for quite a while now. The project is the City University of New York's Academic Commons, an academic social network powered by WordPress, BuddyPress, and MediaWiki. Read on to learn about the plug-in we developed that helps content editors easily feature content from across the entire 400-plus blog network.
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.
Posted November 4, 2010 by Zach Davis
In my previous post, I covered how to customize the new content wizard and showed you a preview of the kind of interface I'm trying to accomplish in this tutorial. In this post, I'll show you how to render content elements using extBase and Fluid. This approach is still rough and while we're aiming to use it on a production site, I envision us refining and simplifying the approach over time. Also, please be aware that the kind of work I'm outlining in this post can break a site. Be responsible: don't do this on a live, production site.
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.
Posted October 28, 2010 by Zach Davis
One of our goals in writing 100 posts on why we continue to stick with TYPO3 over other content management systems is to reach a number of different audiences. Choosing a CMS often involves a number of stakeholders including folks from the Marketing group, IT, and the web developers and designers who will actually build the system. To connect with these different audiences, we're trying to write a variety of posts, some more technical, some less technical. So, fair warning: this post will be one of the technical ones.
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: