The Case of the 500 Errors

9 minutes to read

Chapter 1 – Google

My good friend Leroy was performing SEO on a website and discovered a couple dozen pages that produced 500 pages that Google did not like. The URLs for these pages had a common similarity in that ?format=feed&type=atom or ?format=feed&type=rss were appended to them. Some were legitimate URLs that would serve up perfectly well-formed HTML pages if you eliminated the format and type parameters at the end of the URL. Others would serve up 404 pages if the parameters were removed. Time to investigate.

Chapter 2 – Joomla

The site was built using Joomla and nothing during the development of the site was deliberately configured to append the format and type parameters to the URL. Joomla’s 500 page message was very specific:

500 - View not found [name, type, prefix]: article, feed, contentView

I suspected that a component was creating these extra URL parameters, but I couldn’t disable components on the production environment without negatively affecting the end-users. I needed a way to test my theory without disturbing the live site.

Chapter 3 – WAMP

My good friend Dwayne recommended WAMP. After helping me with some of the nuances of the installation, I restored an Akeeba Backup ZIP file of my website using Akeeba Kickstart, but the search engine friendly (SEF) URLs weren’t working. To get Joomla SEF URLs working in WAMP, follow these steps:

  1. Use your favorite text editor to edit httpd.conf in C:\wamp\bin\apache\apache2.4.9\conf
  2. Search for the term “rewrite”. The line should read as follows:
    LoadModule rewrite_module modules/mod_rewrite.so
    If that line is commented with a “#” symbol, delete the “#” symbol.
  3. Search for the term “<Directory />”. The code snippet reads as follows:
    <Directory />
        AllowOverride none
        Require all denied
    </Directory>
    Change AllowOverride none to AllowOverride All
  4. Save the file.

Chapter 4 – HTACCESS

Since I created a local copy of my website using a backup and Akeeba Kickstart, the site was still using the production version of .htaccess. This was still prohibiting SEF URLs to work. I suspect it was because RewriteBase / was uncommented in production, so I used the default htaccess.txt file that comes with Joomla. However, Windows is stupid and won’t let you rename the file to .htaccess through the GUI. To rename htaccess.txt to .htaccess, follow these steps:

  1. Access the Windows command line.
  2. Navigate to the location of your local site. For example:
    cd C:\wamp\www\joomla
  3. Enter the command:
    rename htaccess.txt .htaccess
  4. Now, Restart All Services for your WAMP server.

At this point, I was able to replicate the 500 pages. Now I can disable Joomla components with reckless abandon.

Chapter 5 – Solution, kind of…

Truth be told, I have been unable to determine what is appending the format and type parameters to the end of the URL. I uninstalled every component, module, and plugin that was not part of the vanilla installation, but the 500 pages remained. I was able to classify the 500 pages into 2 categories:

  1. Single article menu item types
  2. Top level menu items whose only purpose was to facilitate a dropdown menu

Resolving the single article menu item types was a nasty affair. Looking at Joomla’s 500 page message literally—500 - View not found [name, type, prefix]: article, feed, contentView—Joomla does not provide a feed view for single articles. Looking in /components/com_content/views/article, Joomla only provides an HTML view (view.html.php). I created an empty view.feed.php file and placed it in the same directory. I also set the Error Reporting in Global Configuration > Server to Maximum. When I refreshed the 500 page, I got a series of very specific errors about functions within view.feed.php not being defined. Ultimately, my view.feed.php file contained several empty classes and functions. The entire contents of view.feed.php follows:

<?php
defined('_JEXEC') or die;

class JViewArticlefeed { }

class contentViewarticle extends JViewArticlefeed {
    function setModel() { }
    function display() { }
}

That was the minimum amount of coding required to not produce the 500 pages. Instead, it displays a feed with the article metadata. This may not be useful to the end-user, but it eliminates those 500 pages.

For the top level menu items, I had created External URL System Links and specified the Link as “#”. This was storing an alias and it is the path to that alias that was generating the 500 pages. Instead, I edited those top level menu items and changed them to Menu Item Aliases, having them reference the first menu item within the dropdown. However, on mobile devices in which a finger tap facilitates the dropdown menu to appear, I had to disable the links of the top level menu items so user’s would not get directed to the menu item alias.

jQuery to the rescue. To differentiate the top level menu items, I gave them a Link CSS Style of “dormant”. Then, I added a little jQuery:

$('.moduletable_mainnav a').on('click', function(e) {
    if ($(this).hasClass('dormant')) return false;
});

This negates the mouse click or finger tap on the top level menu items. If Javascript is disabled, it gracefully degrades by linking to the first menu item within the dropdown.

Now that the top level menu items were going to legitimate pages, I got 404 pages instead of 500 pages. Much better. Now I can use 301 redirects and Google will be happy.

That’s the end of my adventure for now. I’m unhappy that I couldn’t figure out what was appending the format and type parameters to the end of the URL. All of this stuff was just a workaround. I don’t like it when the machines win, so when I have time, I intend to investigate further. If you have any insight, please contact me.