sh404 – The Worst Joomla Extension

We don’t like to attack Joomla extensions, especially prominent ones. In fact, we can’t remember if we ever did attack an extension on our blog (if you know that we did that before, then please let us know in which post). But this morning something happened, something that made us choose sh404 – the famous extension for redirecting pages on Joomla websites – as the holder of the worst Joomla extension of all time title!

Let us now narrate what happened today… It was about 10 AM EST, one of our regular clients, let’s call him Steve, called us and told us that he was getting a 404 error on one of the pages on his website. Here’s Steve’s briefing about the issue:

  • The page exists.
  • He already created a menu item pointing to that page.
  • Both the page and the menu item are published.
  • He was trying to reach the page on his Joomla website based on its alias.

What Steve forgot to mention about his website is that he has sh404 installed. We knew this because we have worked on his website many times before. So, we logged in to the backend of his Joomla website, we then loaded the URL Manager page in sh404, and we purged all the URLs on the website, and left only the hard coded ones (sh404 doesn’t delete the manually inserted URLs – which is, to be fair, the right and expected behavior). We scanned the hard coded URLs for an entry that was relevant to the page in question but we found none.

We then went to the website and we tried to reach that page, but we still got a 404 error – even trying to load the page based on its non-SEF URL returned a 404 error. We double checked if everything was OK (the article exists, the article is published, the menu item exists and is published, the menu item’s alias is correct, etc…) – and it was. We then spent a lot of time beating around the wrong bushes! We knew that the problem was with sh404 (disabling sh404 solved the problem), but we just didn’t know why this was happening! A while later, someone from our team said, why don’t we just check phpMyAdmin, maybe sh404 has the link there somewhere – and so we did. We logged in to phpMyAdmin and we saw that the table #__sh404sef_aliases had an entry where the newurl was the non-SEF link of the article, and the alias was set to empty. Deleting that row solved the problem, but for some reason, we didn’t feel that we really solved the problem… We started wondering what created that wrong entry and what is the guarantee that this exact same issue will not happen again? In our opinion, we just cleaned the mess caused by sh404, but unfortunately, we didn’t solve the problem, as the problem lies somewhere in the core of sh404, and probably fixing it will have side effects elsewhere!

Now you might be thinking, OK, but does that really make sh404 the worst Joomla extension ever? Isn’t that a bit harsh?

If it was the first time that we see a problem that is caused by the instability of sh404, then we’d agree with you, but there isn’t a week that goes by where at least one client comes to us with an sh404 problem, and let us tell you something, all sh404 issues are extremely weird and very hard to solve!

But isn’t sh404 a very complex extension, which means that it’s allowed to have a few bugs here and there? Maybe, but let’s examine, in one sentence, the basic and main job that sh404 has to do:

sh404 is an extension that redirects on-site non-SEF URL’s to well formatted SEF URLs.

That’s its basic job, and we know, as programmers, that once you have the rewriting rules right then it’s a very simple process – yet after years and years of development, sh404 is still (in our opinion) an unstable extension that should not be installed on production websites – unfortunately though, there is no alternative to this mess, and so many Joomla website owners/administrators are stuck with it.

On a closing note to this rant, think about the following:

  • How come your Joomla SEF links always work when you only have Joomla’s native System SEF plugin running, while you have to routinelypurge links on sh404 to fix redirection issues?
  • How would have solved the above issue (if it happened to you) if you didn’t have access to phpMyAdmin?

  • How come sh404 has not reached stability yet, even though it’s a commercial extension with a huge community and even though it has been there for years?

  • Why can’t the developers of sh404 focus more on the development of the main functionality of the extension rather than working on the development of bells and whistles (such as analytics and shURLs). Don’t they think that people will appreciate a solid extension with less (mostly unneeded) functionality more than a very large extension with (mostly) broken functionality.

Now don’t take us wrong, we think that the people who are working on the development of sh404 are very intelligent people and that sh404 was, at one point, an excellent plugin and that’s why it has so many adopters, but it has since grown into a monster that nobody is able to tame, which is why we consider it now the worst Joomla extension ever.

By the way, if you’re having sh404 problems like our client Steve, then feel free to contact us, and we’ll sure fix them! Our rates are extremely competitive, our work is professional and fast, we are very friendly, and we always welcome new customers!

8 Responses to “sh404 – The Worst Joomla Extension”
  1. Comment by Thangaraj — March 1, 2013 @ 10:48 am

    Title is a little harsh, but I agree sh404sef is focusing on all the wrong things. I’ve been using it for about 5 years now & still install it on a site only when absolutely needed (fear of unknown bugs!)

  2. Comment by Fadi — March 1, 2013 @ 1:51 pm

    Hi Thangaraj,

    The title might sound a bit extreme – but the number of issues that we get that are strictly caused by sh404 is unbelievable.

  3. Pingback by Top 8 Reasons Why You Should Use K2 | itoctopus — April 15, 2013 @ 7:46 am

    […] we don’t like sh404, we have to admit that it’s one of the most used and one of the most prominent Joomla […]

  4. Pingback by K2 And Setting the Wrong Open Graph Description Meta Tag | itoctopus — June 7, 2013 @ 10:11 pm

    […] meta tag. It must be a plugin, but which? We immediately thought about sh404 (it’s, ahem, favorite suspect), so we checked all its code and we discovered that it was innocent. Yes, there is a place where […]

  5. Pingback by Articles Appearing Under the Wrong Category in Joomla – How to Solve | itoctopus — June 21, 2013 @ 1:58 pm

    […] Now we have been working with Joomla for many years – and this is the first time that we see such a problem. So we started investigating, and our investigation lead us to our usual suspect – sh404SEF. […]

  6. Pingback by sh404SEF: How to Re-Generate All the Links on a Migrated Joomla Website | itoctopus — July 5, 2013 @ 12:49 am

    […] have already expressed that we are not very big fans of sh404SEF – we think that this extension does more harm than good for what it does. But, the fact of […]

  7. Pingback by JComments Captcha Not Working on Refresh | itoctopus — October 5, 2013 @ 10:30 am

    […] did a long investigation and we finally discovered that the reason behind this issue was the usual Joomla suspect, sh404SEF – no surprise there! Solving the problem consisted of disabling sh404SEF for the JComments […]

  8. Pingback by Script to Mass Update sh404SEF Links and Add the Original Links as Aliases | itoctopus — March 30, 2014 @ 11:16 pm

    […] you’re using sh404SEF, then, first, we feel sorry for you! But second, we have good […]

Leave a comment