Let me show this on an example. Let’s say you have a category called Animals, under that a subcategory called Birds and finally two items there: Eagle and Hawk. The parent category Animals is linked to menu.

The regular K2 SEF URLs are right now like:
Animals (category): http://domain/animals
Birds (subcategory): http://domain/animals/itemlist/category/4-birds
Eagle (item): http://domain/animals/item/3-eagle
Hawk (item): http://domain/animals/item/4-hawk

With the new extension for SEF Advance you get:
Animals (category): http://domain/animals/
Birds (subcategory): http://domain/animals/birds/
Eagle (item): http://domain/animals/birds/eagle/
Hawk (item): http://domain/animals/birds/hawk/

It works for unlimited category depth. As you can see there are no IDs nor strange words in the URLs and they are far more logical reflecting your content structure. The other K2 views are also covered with improved URLs.

You will notice there is no “k2″ component prefix in the URLs either which was the case in all previous extensions for 3rd party components. This is possible thanks to a new API format in SEF Advance which allows for this to be skipped (will require SEF Advance v2.3.1 or later). As K2 is often used as a replacement for Joomla’s own content component and tightly connected to the core, I figured you will appreciate this feature as URLs become far more advanced and simple.

The extension is almost completed and will be available soon for free download to all SEF Advance users. I would appreciate your help through this testing phase though.

How can you help?

If you have a well developed K2 site (preferably the latest version 2.3) with many categories and content and wouldn’t mind me testing the extension there please contact me with your admin password and FTP info. You will most certainly get the access to the extension first in that case.

Join the discussion on forum and help improving it.

The pattern is the same: someone would register on the site, passing the visual CAPTCHA, activating the account, commonly with Yahoo or Gmail account and immediately begin to edit the profile adding links to their signature, URL, even profile pictures. Some would also enter more or less meaningless posts to give their spam links more exposure. The registrations come from different IP addresses, mostly from Asia but also from USA and Europe.

To fight this I first started deleting the posts and banning the IP addresses but I soon realised that they change IPs and find proxies faster than I can ban them. A new registration would come every 5 minutes so I thought it must be some kind of smart script or bot doing it. I changed the visual verification to reCAPTCHA and added anti-bot question on registration. The attacks decreased a bit but quite a few were still able to get through. I even received an email from someone complaining that the reCAPTCHA was hard to solve! The same person then created a spam account.

Since this proved to be not just simple bot attack but a massive spam with human intervention, I switched to manually approving new registrations. A new user will now have to enter a reason for registration. I will then review the application based on this input, email and the IP address. The spammers are still trying, entering pretty smart inputs, but I can at least eliminate them effectively before they can contaminate the forum. The manual approval will unfortunately reflect on regular users making it more difficult to participate.

The spammers get more advanced switching from automatic bots to hiring humans to make fake registrations and enter spam links. How they manage to pull off such a massive attack using real man power so it pays off is still mystery to me.

EDIT (Oct 31st 2009): The server move has been completed. Hope everything went smoothly and you haven’t noticed it. Please leave a comment about how the new host feels: is the site faster, slower and where you surf from.

Things to get worse they are even publishing a module for their rip-off component on Joomla Extension Directory (JED) which is sold under the same proprietary license but claiming to be GPL. A week ago I submitted a report to JED team but they did nothing to remove this module, which is used by visitors to find this pirated component and their site, not even to reply my email. The same JED team who swear on GPL, were quick to remove all my non-GPL extensions, checked my site and manually examined the code for all my commercial GPL products.

Of course there is no way for me to do anything about this component. Complaining didn’t help and legal action is of course not feasible. It’s people like this that make me reluctant to release anything GPL or open source any more. It also confirms why encoding my commercial products has been a good idea.

Namely, a similar thing happened several years ago when I released SEF Advance, the first SEF component for Joomla and Mambo which later became widely popular and followed by many other extensions. At first, the script was not encoded but had a simple protection instead. It got easily broken and the component, being so wanted, started appearing on warez sites. About that time the first open source SEF components started to appear as well. Examining their code I could find the same principles, copies of my code, same variable names and comments as found in SEF Advance. I didn’t want to make a big deal out of it so I just let it go and started encoding SEF Advance. However, these open source components had been picked up by others who continued the project as per GPL nature. Later on I could find bigger portions of my code even in OpenSEF. I personally know the OpenSEF author, a great guy. He acted in good faith taking over the previous GPL projects and had no idea they contained pirated code. This project later evolved and was recoded, picked up by other projects but it’s interesting that many SEF components for Joomla originate from SEF Advance and its code, even though it never was open source.

There has been a lot of buzz around GPL and encoding for Joomla extensions recently, both for and against. Why I am doing it is not because of some script kiddies who would find it on warez sites, who would never have bought it anyway. I do it because of authors without honour like the one from the beginning of this text. The authors that would breach your copyright, take the credit for themselves and try to earn some money out of your work. Other authors and users will then be unknowingly using illegal code and, in worst case, even ask you for support. Encoding is the easiest way to protect your customers, be able to give them support they deserve and clearly separate your work from the competition.

CakePHP framework provides a great pagination helper but its default URLs aren’t that great. By default it generates URLs that look like: http://domain/news/page:2. I spent a long time looking for a way to skip “page:” part in URLs and in links generated by the helper, or even just change the string “page” to something else. It showed up that there’s no easy way to configure the paginator that way. So I came up with a workaround that will change your CakePHP pagination URLs to: http://domain/news/2

Assuming that you already created pagination on your site according to CakePHP instructions we will start making a few changes. We begin with the view where we want to modify automatically generated links into the new ones:

$prev_link = str_replace('page:', '', $paginator->prev('« Prev'));
$prev_link = preg_replace('/\/1"/', '"', $prev_link);
$next_link = str_replace('page:', '', $paginator->next('Next »'));
echo $prev_link;
echo $next_link;

This will take out “page:” part from the prev/next links and make them only contain the page number instead. Also, we replace  http://domain/news/1 with only http://domain/news in order to avoid alias URLs and penalties for duplicate content by search engines. Be sure to apply the same method to the rest of your links such as those generated by numbers() method etc., if you are using them.

Now we need to make sure that the Cake makes correct interpretation of the passed argument. In our router file we add something like:

Router::connect('/news/*', array('controller' => 'news', 'action' => 'display'));

This will forward our pagination links to news controller and its display() method. Our page number parameter will be passed as argument to this method. Let’s take a look at the code in news_controller.php:

public function display($option='') {
if (is_numeric($option)) {
$this->passedArgs['page'] = $option;
}
$items = $this->paginate('News');
...
}

As we can see we take the passed argument and assign it to the passedArgs array under the ‘page’ key where all named URL parameters are held. This way the paginator will understand that we are on the page passed by our URL.

That’s it. If you’ve done it correctly you now have nice pagination URLs like:
http://domain/news
http://domain/news/2
http://domain/news/3
instead of:
http://domain/news
http://domain/news/page:1 (duplicate)
http://domain/news/page:2
http://domain/news/page:3

1. Download AJAX Scroller. There is a free trial available for testing.
2. Install the module on your Joomla site. Doesn’t matter which version you use, the same package will install and work both on Joomla 1.5 native and Joomla 1.0.
3. After the installation go to the Module manager and edit the module to adjust its parameters. The images below show the optimal settings:
   Important settings

   Type: select Twitter
   Max chars: limits the item text
   Max number of items: Limit number of displayed updates, set 0 for unlimited, in this case it will mean 20 as per Twitter API feed limits
   Display image: shows the Twitter profile image
   Max image width: resizes the profile image

   Important settings

   Twitter timeline: select if you want to show only your own updates (user timeline) or also your friends updates (friends timeline), mentions of your username or search by keyword.
   Twitter username: enter your username on Twitter
   Twitter password: only needed if friends timeline selected
   Cache / Time: because Twitter limits number of API calls to max 100 per minute it’s crucial to use caching. Select minimum of 60 seconds cache time. Otherwise Twitter may temporarily ban you and the module won’t be able to connect.

4. That’s it. Save the module, publish it to selected position and it will display and smoothly scroll your Twitter updates. The updates will be pre-fetched asynchronously from cache and Twitter servers will be contacted as often as you specified.

Check out our DEMO site to see how it looks in action. You will see Twitter module working both for user timeline and friends timeline. If you need help with installation, styling and troubleshooting AJAX Scroller check out the FAQ and visit our Forums.

Have fun with Twitter on your Joomla site!

However, more and more Joomla users require native 1.5 extensions only and won’t bother turning on the legacy mode. The developers convert their old extensions to new ones but they are forced to distribute them separately for different Joomla versions. Here is how you can fit them together so that the same package can be installed both on Joomla 1.0 and 1.5, without legacy mode needed.

Why a single installation package?

It’s convenient both for the user and the developer to only deal with a single installation file which works for any Joomla version. However, users wanting legacy-mode free plugins complicate the situation. Even if developer manages to solve the incompatibilities on the code level he will still be faced with installation obstacles. Namely, Joomla 1.5 has a new manifest format and won’t install an old extension without legacy mode being turned on.

I’ve seen some devs instructing their users to temporarily turn on the legacy mode just for installation to be turned off immediately after. This is not ideal solution as users do not often read the instructions and, after they have been presented with a message “This extension is written for old version of Joomla” they may be giving up. So what can we do? Well, here is a solution that elegantly solves this problem creating a single package which installs on both Joomla versions with no legacy mode needed at any time.

Solution

The trick is to use two different manifest files, one for Joomla 1.0, and other for Joomla 1.5. We need to package our extension in a special way to fool the installers to load the appropriate manifest. Here is an example for packaging a simple Joomla module in a file installable on both Joomla versions with no legacy mode. The same example can be analogously applied to components, plugins etc.

I call my module mod_example and structure it as follows:

As you can see, I have files and folders for Joomla 1.0 directly under the root, but I create a new folder called “1.5″ in which I put files and folders for Joomla 1.5. You can call this folder differently but the name has to start with a character that comes before “m” in the alphabet. The trick is that Joomla 1.5 installer will take the first manifest it finds in the package, which in this case will be: 1.5/mod_example.xml, while Joomla 1.0 installer will take the manifest that resides on root: mod_example.xml.

This way we can nicely separate files for Joomla 1.0 and Joomla 1.5. Of course, we have in fact two modules in one package so we must maintain both but it’s worth it since we can take advantage of Joomla 1.5 framework and we avoid mixing things together if we would to have everything in same files. If we now zip it together we get a single package that installs both on Joomla 1.0 and 1.5!

Finally, I attach the zipped example module that you can play with and try to install on both Joomla 1.0 and Joomla 1.5 without legacy mode.

mod_example.zip