Dancing Bear Syndrome is a term coined by Jared Spool and Alan Cooper (among others in the usability community). Someone says, "Look! A dancing bear!" And you are amazed! The bear is dancing! How cool is that?

Of course, bears don't dance well. It's just amazing that they dance at all. The novelty of it all is what catches our attention, not the quality of the dancing.

Alternative Joomla administrator templates are dancing bears.

I am not a graphic designer. I can't draw stick figures well, and I always wear jeans, khakis, or black pants because I've been told they match everything.

But I've worked with enough graphic designers through the years to know that there are rules to working in a given medium, and there are limitations to that medium as well. For example, if you're making a rack card, those are a certain fixed dimension. You may want to make a bigger design, but you have to work within the limitations of the medium - in this case, the paper, which must fit in the spot on a rack. Perhaps your client only has enough money to afford 2 colors, or 4 colors on one side and black and white on the other. Again, a medium limitation. Yet you never hear print designers complaining about these limitations. They're part of the job; they go with the territory.

I also assume, as a code geek, that I don't know a darn thing about working in print. I hear terms like "4 color" or "bleed" tossed around, and I eventually figure out what they mean. I own a copy of InDesign, and I know where the text tool is. These things absolutely do not make me a print design expert. If I need something printed, I always hire someone who knows what they're doing, like Meg McCarthy.

With the impending end of official support for Joomla! 1.0 and as I prepare for my session at the upcoming CMS conference, I've found myself revisiting the ongoing question of whether to build sites in 1.0 or 1.5.

As a developer who has enthusiastically embraced 1.5, my knee jerk reaction is that of course (!) we should all be building new sites in 1.5 and drop 1.0 like a hot potato. How could anyone even question this? Some of the comments to the official annoucement (see here) served to remind me that there are other perspectives well worth consideration. Although I have to say, I find the comment that  "I realy[sic] hate 1.5. Its[sic] just so messy that I would send the programmes[sic] back to school and scrap the whole code" pretty much impossible to warm up to on any level. I'll just vehemently disagree with that assessment and move on to my main points.

Other, more thoughtful comments made me reconsider that knee jerk reaction. Here at 4Web, our focus is on high end, custom Joomla sites for large companies. As a developer writing the custom extensions, I have rarely seen a better - or even equally - congenial environment and API for extending and customizing a code base as I see in J!15. Things that were difficult or a struggle in J!10 are a breeze. For us and our goals, there is no question that J!15 is the way to go. Thus the knee jerk.

Once we had decided against using sh404sef, we were still left with the need to handle '404 Page Not Found' errors. Clear and explicit information on this wasn't particularly easy to find, so I thought I'd document how we did it here.

 In J!15, errors are normally handled by - surprise! - a template file. Look in the the system template folder for the file error.php. Standard J!15 error handling sends the user to this page for any unrecoverable error. Including 404 errors. If you copy this file to the root folder of your own template, you can then modify it to your needs.

In very simplified form, here is what we did:

My last entry here was inspired by the possible use of sh404sef in the site we just launched (YAY!). We ultimately decided against using it for this site. Despite many great features that would make it a valuable addition to any site there were just too many issues I couldn't address in the time frame available before launch.

The initial motivating factor that made us  look into it was a need to handle "404  page not found errors". Joomla 1.5 (J!15) does have the ability to handle these, but the additional facility to handle sef urls and reporting on site activity related to hack attempts and failed page access attempts are really exciting.

Unfortunately, the sef urls require specially written  functions for any extensions in use on the site through a sef_ext file. On this site, we are using Virtuemart and Azrul's MyBlog, both of which are supported out of the box by sh404sef. rsGallery2, another extension we are using might be supported through an older sef_ext written for the J!10 version, but I didn't have a chance to pursue this. And from what I could tell on their forum, rsg2 isn't yet supported in J!15. Additionally, there are a couple extensions I wrote for this site in addition to JoomSuite, none of which are supported at all.

Oh gosh! Been awhile since I wrote here.  We've been completely swamped by the impending launch of one of the most complex sites I've worked on. We're using a bunch of extensions with a variety of compliance to Joomla 1.5 coding standards. None of them perfect, but some pretty darn close.

Joomsuite has been a mixed blessing. Having the code encrypted makes it more difficult for me to be excited about it. The idea is fantastic, but I'm finding it's capabilities - at least for our purposes - quite limited. And it's buggy. And it has a long way to go to meet my standards for a fully Joomla 1.5 compliant extensions.

Given the desires of the client, and Joomsuite's limitations, I ended up writing a component to fill in the the gaps. This is where the blessing gets really mixed. I've been pretty surprised what I've been able to do, but it's created a number of nightmares for maintaining control over how and where to display content. But overall, I'm pretty impressed with some of the things I can do with Joomsuite and in the ways I've been able to get my component to cross-talk with it.

Bill and I have been working together for years now. We've pretty much figured out what each other loves doing and what ticks the other person off. We've also gotten pretty good at picking out work together. One of the things we're getting Sam up to speed with is Jen and Bill's Coding Theorem.

These days, clients call up Sam to chat, but in the old freelance days, generally the call would come in to me. They have an old site, and they'd like us to do a redesign.  Maybe there's a small database driven component to the site, or some script, or even some full-blown (but old and creaky) content management system involved.

First, I take a look at the HTML, and the CSS if there is any, on the website. I try to judge the code by the era in which it was written.  If it was a site from 2000, I don't expect to see any CSS at all.  But sites built in 2004 or later, I definitely expect to see CSS.  (Sites between 2000 and 2004 vary widely -- they should use CSS, but many still don't.)

Following in Jen's footsteps on her recent rant about dropdown menus, it's time I got something off my chest about programming styles and standards. There are many levels of coding standards. But the one I'm on a tear about today involves writing Joomla! 1.5 extensions.

I was asked to look into an issue regarding an extension we are using here at 4Web. This is the first time I've looked into the code and I was pretty disappointed at what I saw. One of the reasons I so love writing extensions for J!15 is because the core team has done what I consider a fabulous job of creating a flexible, organized, easily understandable (even by me!) extremely extensible structure and API for creating components, plugins and modules. It has been rare (and increasingly so) in my thirty eight years of experience to find code this well structured.

Programming is, or can be, an art. We each have a style and an approach to coding unique to ourselves. And if we're paying attention, our own style evolves. Heck, half the time I look at code I wrote five years ago and can't figure what in the world I was thinking. Looking at someone else's code can be a nightmare of galactic proportion. This creates difficulties in maintaining code and is one reason standards have come to be seen as important in some circles.