The MODX Blog: Brett Florio from FoxyCart

Brett Florio from FoxyCart

Web developer by day. Rock star inventor of foxiness by night. And, he loves him some good fish tacos.

You & Your Business

MODX: Tell us about your web skill set?

Brett Florio: My core competency is web design and development, but with a serious emphasis on usability and sales & marketing. I don’t consider myself a designer, though I do a fair amount.

How foxy! What about your business?

FoxyCart is an ecommerce platform built by web developers, for web developers. Most critically, it is not a CMS, but rather is built to integrate with other systems. The issue we kept running into while building ecommerce sites for clients was trying to get an “all-in-one” system to match the best of MODX (CMS/CMF), CampaignMonitor or MailChimp (email marketing), Quickbooks (accounting), whatever crazy inventory system may be needed, Google Analytics, and etc. It’s hard enough to do one thing great. Doing all things excellently has never been achieved, as far as we know.

So we decided we’d focus on the most core pieces of ecommerce (the cart, checkout, and receipt), and build FoxyCart to integrate with the great systems that are already available, like MODX.

What needs motivated you to look for a content management solution?

Static HTML and includes only goes so far. Many developers consider using a CMS limiting, and prefer to roll their own on a consistent basis. I don’t think those developers have ever used MODX. Once you start to realize the flexibility and power underneath the hood there’s just little reason to look elsewhere. It may not be the best tool for every job, but it’s darn close.

The biggest thing that prompted me, personally, to start playing with CMSs was the need to have larger sites. Whether it’s a site that has a FAQ or a product catalog or a blog or etc., there comes a point where doing things without a CMS just doesn’t make sense. Imagine trying to do what we do on www.foxycart.com without a CMS. We have a blog with comments, a site gallery, dozens of “static” pages, forms, changelog updates, and etc. Trying to do that without a solid CMS is a waste of time, energy, and money. We love MODX.

How many MODX sites have you built?

Probably upwards of 70, since 0.9.0.

Workflow History

How did you build sites prior to MODX?

Probably about 30, using (or attempting to use) systems including Mambo/Joomla, Typo3, ezPublish, Wordpress, Etomite, and a whole host of others. (I still use Wordpress occasionally, but am otherwise monogamous with MODX.)

What were you looking for when you found MODX?

In a word: Template Variables. I’d been using Etomite for a while, and found it to be very close to ideal, but I needed the ability to set new and specific content fields on a per document or template basis. TVs were what made me end my quest for “the holy grail of CMSs”. I’d found it in MODX.

If you switched to MODX, why?

TVs.

In your experience, how does MODX compare to other content management systems?

Kicks their asses. A good friend and security consultant of ours had this to say:
“Joomla will make your website. MODX will make your website your bitch.”

Enter MODX

What's your typical workflow when building out a site in MODX today? How many people are involved?

Note that FoxyCart.com is not in the site construction business, but when we do need to build sites (for ourselves, for non-profits that we support, etc.) we tend to do the following.

  1. I generally sketch out the sitemap from start to finish, trying to be as thorough as possible.
  2. Once I have the sitemap done I map out how many templates will be needed.
  3. Then I map out what TVs will be needed on a per template basis.
  4. Then on a per page basis I attempt to determine what functionality will be needed. Most of it comes down to Ditto and PHx. If Ditto + PHx can’t handle things it’s generally going to involve some custom code.
  5. Somebody else on the team then generally gets to work setting things up.
  6. Once the documents/sitemap is set up, we then install Customize Manager Fields or ManagerManager to “idiot-proof” the manager.
  7. We then start building out the templates and chunks, usually starting with the homepage and working our way down the sitemap.

A few things to note:

  1. Don’t go crazy with templates. Often you can get by with using only 2 or 3 templates for a site. If 2 pages have the same basic layout, they probably don’t need 2 separate templates unless they have such radically different TVs that it’d make more sense to do that.
  2. If you find yourself re-typing the same code even just once you should probably use a chunk or snippet.
  3. Don’t open a <div> in a chunk and close it in a template (or vice versa).
  4. We almost always set up the following TVs before we do anything else:
    • head_extra (where you can stick extra script calls and such; lock it down to admin access only)
    • foot_extra (where you can stick extra script calls and such; lock it down to admin access only. useful for tracking scripts, generally, like setting specific page views for Google Analytics or CrazyEgg.)
    • content_2 (admin access only; this is where any snippets or code go, so your clients can’t screw stuff up)
    • image_01 (because it’s quite common for a document to need at least one image; sometimes we go up to image_10 or _15)
  5. PHx is your friend. Learn how to use it. You can often handle layout changes that would otherwise require a separate template using PHx alone. For example, if you have a [*column_right*] but you don’t want to show it unless there’s content in it, you’d just add [+phx:if=`[*column_right*]`:ne=``:then=`[*column_right*]`:else=``+]. You could then add/remove classes on your main content div to resize it accordingly.
  6. RTE/WYSIWYG editors like TinyMCE and FCKeditor can very often create more problems than they’re worth, so we generally force all our users to use Textile. It make it borderline impossible to screw up (unless they’re trying really hard), it’s easy to learn, and there’s no way they’ll be able to destroy your beautiful design with a blinking 48pt Comic Sans bullet list.
  7. More advanced, but the @SELECT binding is amazing. If you have a TV that needs options from MODX documents itself you should take the time to figure this out, as it can further help idiot-proof sites, and prevent the need for additional TV configuration that won’t be synched to the MODX document structure.
What is the biggest difference for you from what you were using before MODX?

Biggest differences:

  1. NOTHING is output unless we tell MODX to output it. No tables, no classes or wrappers. It’s a dream come true.
  2. TVs make all things possible.
  3. When TVs aren’t enough, you have snippets, PHx, and plugins.
How much time were you spending building out a site before MODX, even if in other CMSes? After implementing MODX?

I can barely remember life before MODX, but I don’t think it was so much an issue of “time” but rather “sorry, we can’t do that.” With MODX we’ve tended to build much, much larger, more feature-rich sites that we couldn’t have dreamed of before.

What have you found since you switched? (faster deployments, less hacking, easier to turn over to client/users) Are there any quantifiable estimates of improvements since using MODX?

Easier to turn sites over to clients without fear of getting frantic calls the next day, certainly. And the ability to build very large (1,000s of pages, dozens of content editors, custom functionality, etc.) in ways that were previously impossible has helped and is quantifiable: bigger projects == more money, more fun, and continued learning.

What are the key benefits of MODX?

Same as the “biggest differences”:

  1. NOTHING is output unless we tell MODX to output it. No tables, no classes or wrappers. It’s a dream come true.
  2. TVs make all things possible.
  3. When TVs aren’t enough, you have snippets, PHx, and plugins.

In addition, the biggest benefit of MODX is that you have complete control over nearly everything. There’s just no comparison to a system that locks you down to a specific structure.

What do your clients say about your sites made in MODX?

Nothing but praise.

Has your company grown as a result of MODX?

Definitely.

What's your favorite thing about MODX?

I’m pretty sure I’ve answered this a few times already ;)

What do you find most-lacking about MODX?
  1. User management can be awkward, and some things related to webusers have never really been brought current. (Newspublisher can’t handle TVs; Weblogin is temperamental and not easy to customize; Webusers need “TVs” for additional fields.)
  2. Documentation ;) (though the wiki’s helped quite a bit)
  3. Cached/uncached parsing and nested tags. (Fixed in Revolution.) Not the end of the world once you get used to it, but it could be better.

Final Feedback

What words would you use to describe MODX?

Brilliant, flexible, powerful.

If you were to recommend MODX to someone else, what would you say?

I’ve actually converted just about everybody on my iChat buddy lists to use MODX. I think my usual spiel is:
“Trust me, once you take the time to learn how to use it you’ll never use anything else. There’s almost nothing you can’t do with it. I haven’t even looked at another CMS since I found it 3 years ago.”