I was recently asked if there was a way to get the topmost menu item in which a page sits. Let's say you have a menu like this:

Item 1
--Item 1.1
--Item 1.2
----Item 1.2.1
Item 2
--Item 2.1
--Item 2.2

Let's say you wanted to do something special with all the menus in the 'Item 1' tree and something slightly different for all the items in the 'Item 2'  tree. You'd want to know which tree you were on. Here is a bit of simple php code you can use the get the top most menu item no matter where in the navigation you are (see php 4 version further down):

We've been working on a rather largish site recently and over the course of recent weeks, I have been reminded of a lesson learned way back in my dark ages when I was designing desktop database applications.

When developing any application but especially a customized application designed for a specific person or company, it can be easy to confuse problems with solutions. In that database I designed so many years ago, the client had been doing things largely on paper for a very long time. By the time I came along they had graduated to using was really not much more than a spreadsheet on steroids. A very rudimentary database system some board member had created in her idle moments.

They had developed ways of thinking about their processes and data that had evolved over decades based on their paper system. And that was translated into the board member's simplistic application. Conversations initially involved them telling me very specifically what my new program needed to do. But as I would look into simply doing what they told me, I would find a number of questions that needed asking. And as I asked questions, they (and I) started to see that what they wanted was actually a solution to a more interesting problem and not at all the best way to address that problem. With practice and attention, it has become almost second nature for me to recognize the difference.

Recently, based on recommendations from Jen and myself, another web designer of note moved her hosting to Liquidweb. I'm sorry to say she had an agonizing period of adjustment. It was all about the dreaded file permissions and ownership.

In Mambo and J10, it was often necessary to set certain files and directories to be writable by anyone. Due to the way web servers have traditionally been set up, the only way a system like Joomla could upload files and modify the website's directory structure (when installing an extension for example) was by making the file system, even if only temporarily, writable by the whole world.

We were pleased to see the addition of the ftp layer in Joomla 1.5. It meant not having to open up the file system like this. But even in J15, certain 3rd party extensions require a directory here and there to be set world writable. It has recently come to my attention that some webhosts will shut down your account if any files or directories are set this way.

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.

There has been some buzz lately about Flash version 10 breaking the media manager in Joomla. This won't be fixed until after 1.5.8 so what to do in the meantime? Since it only affects the media manager in the administrator, at least the problem only affects your staff. Your choices are to either wait to upgrade Flash until Joomla fixes the problem. If it's too late for that, all you need to do is disable the media manager's flash uploader. Go to "Global Configuration/System" and right at the bottom set "Enable Flash Uploader" to no. Who knows? Maybe you'll prefer this setting anyway!

If you would like to know what version of Flash you are running:

 http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15507

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.

Creating a template override can be very simple or highly complex. It will depend on the Joomla core generation code you want to override and what you want to do. A relatively simple example that has been requested often in 4Web's work removes those pesky row numbers in the weblinks listing.

Normally, the listing of weblinks within a category will display something like this:

#	Web Link	Hits
1	Joomla! Home of Joomla!	3

Most of the elements in this display can be shown or hidden. The exception is the '#' column. First we identify the generation code.

You've been designing your new website, creating a template to your client's specifications. All is going well. They are making use of the weblinks component for publishing their list of favorite links. They call up and say, "we really don't like seeing those numbers in the left column, please take those away." Looking for all the available configuration options, you discover that you can do anything you want on that page except get rid of those pesky numbers!

Template overrides to the rescue!

Every component and module in Joomla has a particular snippet of code called a template, whose job is to generate HTML and nothing else. The Joomla framework is designed to allow templates to replace those snippets as needed. You can build a template that completely takes over the writing of almost all html on the site using these overrides.