A Cross Site Request Forgery (CSRF) attack relies on the trust a website has for a user to execute unauthorized requests and or transactions. For example, say a user is logged into their Joomla! websites' administrator interface in one tab and is browsing a compromised site in another tab.

You just finished a development of a new component/module/plugin, which has multilanguage support, or just finished a translation of such a Joomla addon and want to doublecheck the result, and don't know how to do it? Don't look further, Joomla supports some useful debugging mechanisms that can make it easier to locate untranslated strings and diagnose problems with language translations in installed extensions.

As you may experienced already, Joomla 1.7 has simplified much of the Joomla content work-flow, making things easier and faster to do. However, one of the things that has gotten slightly more complicated is finding and emptying the trash.

Sometimes, if more people work on the site, you can get locked out of a certain module or article because the site thinks someone else is still editing that item. When opened, each Joomla item is checked out, this way Joomla protects each editable item from being edited by two separate users at the same itme, and this way avoiding potential confusion and other obvious problems.

Sometimes you need to allow a user to access and manage only one (or a few) Joomla! component in the backend. This is quite easy to set up, you need to use cleverly the ACL sytem Joomla has allready in.

Despite claims to the contrary Joomla 1.5 does have an ACL system. It may be rudimentary but when fully understood can be very useful.

Recently in more (usually cheap) hosts more of my clients reported a strange error, wich showed up recently, withouth notice.

The error message is like this:

1104 The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay

followed by the failing query.

Most of attacks on the web - and Joomla sites aren't an exception - are made fully or in first phase at least by automated robots. These are using known entrance points as administrator logins to most used software solutions to try they chances to break in. So it's a wise move to change these well known locations. But wait! The need to upgrade compatibility may made this difficult, so, how we can do this without changing a line in Joomla code?

When I have seen first time this error on Joomla 1.6 while tried to save a new article in Article Manager I was lost:

By default, across all Joomla versions from Joomla 1.0, through Joomla 1.5, Joomla 1.6 to the Joomla 1.7 the basic structure of default user groups is unchanged. The users are generally sorted in 3 main categories, the unregistered/not logged in users, the registered users with frontend only access and the backend users. The exact naming of these main groups are varying across the different Joomla versions, but the default end level groups are the same. The groups and their core permissions are as follows: