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!

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.

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

1. 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)

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

3. 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)

4. 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)

5. 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)

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

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

8. 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).

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

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

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

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!

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!

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?

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!

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.

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

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!

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!

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…

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?

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 3^rd 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!

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?

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?

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!

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!

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!

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.

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 3^rd 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!

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?

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!

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!

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

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!

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

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 3^rd 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 3^rd 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!

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 3^rd 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!

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

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!

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

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!

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!

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!

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!

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!

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
pos_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!)

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 3^rd 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!

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!

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!

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!

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?

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?

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 3^rd 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

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!).

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 3^rd 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 3^rd 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.

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:

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!

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 3^rd party companies such as itoctopus supporting Joomla?

Well, Joomla’s complexity is proportional to the number and the complexity of the 3^rd 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 3^rd party extensions installed, and it’s unrealistic to expect Joomla, as an organization, to issue a certification that will take complex 3^rd 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!

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

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!