Joomla! Documentation - User contributions [en]

J1.5:Creating an Authentication Plugin for Joomla

2011-09-26T18:48:30Z

MTrapp82: None

The new authentication plugin system for Joomla! 1.5 offers a great deal of flexibility and power to the system. Using the new system, it is possible to authenticate users from any source - the Joomla! internal database, the Open ID system, an LDAP directory, or any authentication system that can be accessed using PHP.

This tutorial will present a really basic example of an authentication plugin that demonstrates how to create custom authentication plugins for the Joomla! framework.

== The plgAuthenticationMyauth Class ==

Joomla! 1.5 plugins are created by creating a child class of the JPlugin class. The JPlugin class provides all the infrastructure and basic functionality that is required. All that is necessary is to provide the necessary methods to handle the desired event.

To create an authentication plugin, the name of the child class must begin with <code>plgAuthentication</code>, and must end with the name of the plugin that is being created. In our case, the plugin is called Myauth, so the class will be called <code>plgAuthenticationMyauth</code>.

The class will have two methods. The first method is the constructor. The second method is the <code>onAuthenticate()</code> method. These methods are actually very simple, as will be demonstrated.

== The plgAuthenticationMyauth() Method ==

The constructor should take one parameter, which should be passed by reference. All it will do is pass this parameter onto the constructor of its parent class. We should note that this constructor method should have the same name as the class. The name <code>__construct</code> cannot be used because PHP4 does not support this mechanism and the fix that is used in the Joomla! core will not allow passing the arguments by reference. Therefore, our constructor looks like:

<source lang="php">
function plgAuthenticationMyauth(& $subject) {
parent::__construct($subject);
}
</source>

The parent constructor will handle attaching our event observer (plugin) to the subject (the event dispatcher).

== The onAuthenticate() Method ==

The <code>onAuthenticate()</code> method is the method that will be called when the system is trying to use your plugin to authenticate the user. This method will be passed three parameters: the username, the password, and a reference to an object of type JAuthenticationResponse. This method needs to determine if the username and password are a valid combination for authentication and return the result in the JAuthenticationResponse object.

For our example, the authentication check that we are going to do is very simple. We will simply make sure that the specified username exists in the users table, and if it does, we will check to see if the username is the reverse of the password. So our authentication check will look like:

<source lang="php">
$db =& JFactory::getDBO();
$query = 'SELECT `id`'
. ' FROM #__users'
. ' WHERE username=' . $db->quote( $credentials['username'] );
$db->setQuery( $query );
$result = $db->loadResult();

// to authenticate, the username must exist in the database, and the password should be equal
// to the reverse of the username (so user joeblow would have password wolbeoj)
if($result && ($credentials['username'] == strrev( $credentials['password'] )))
</source>

Although this is very basic in our example, this code can be replaced with any code that is necessary to perform the authentication checking that is necessary for your plugin. The flexibility is only limited by what PHP can do.

Now that we have determined whether or not authentication was successful, we can now create our response:

<source lang="php">
$db =& JFactory::getDBO();
$query = 'SELECT `id`'
. ' FROM #__users'
. ' WHERE username=' . $db->quote( $credentials['username'] );
$db->setQuery( $query );
$result = $db->loadResult();

if (!$result) {
$response->status = JAUTHENTICATE_STATUS_FAILURE;
$response->error_message = 'User does not exist';
}
// to authenticate, the username must exist in the database, and the password should be equal
// to the reverse of the username (so user joeblow would have password wolbeoj)
if($result && ($credentials['username'] == strrev( $credentials['password'] )))
{
$email = JUser::getInstance($result); // Bring this in line with the rest of the system
$response->email = $email->email;
$response->status = JAUTHENTICATE_STATUS_SUCCESS;
}
else
{
$response->status = JAUTHENTICATE_STATUS_FAILURE;
$response->error_message = 'Invalid username and password';
}
</source>

For failed responses, we set two properties of the response object: the status property, and the error_message property. Currently there are three recognized response status value - <code>JAUTHENTICATE_STATUS_SUCCESS</code>, <code>JAUTHENTICATE_STATUS_FAILURE</code>, and <code>JAUTHENTICATE_STATUS_CANCEL</code>. For more information on these status values, consult the libraries/joomla/user/authentication.php file.

The error_message property is set in case the authentication is not successful. In our plugin, we set two possible values to this property: "User does not exist", which indicates that our query did not return any results, and "Invalid username and password", which indicates that the password was not the reverse of the username. <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> It should be noted that these values are not returned to the user. For security reasons, the only thing the user will see is a successful login, or a message that says, "Username and password do not match." The Joomla! system can be configured so that these error messages can be stored in a log file for debugging purposes.

If authentication is successful, we can optionally add information from our authentication source to the response. In this case, we are retrieving the user information from the Joomla! database and storing the email address in the response object. For more information on what data can be stored in the response object, please consult [http://api.joomla.org/Joomla-Framework/User/JAuthenticationResponse.html http://api.joomla.org]. This data can then be used by user plugins in the event it is desired to automatically create users or perform other login tasks.

== The Complete myauth.php File ==

Now that we have completed the two methods that are necessary for our class, we put our class into a PHP file that has the same name as our plugin. Since our plugin is called Myauth, we call our file myauth.php. Here is the complete listing for this file:

<source lang="php">
<?php
/**
* @version $Id: myauth.php 7180 2007-04-23 16:51:53Z jinx $
* @package Joomla.Tutorials
* @subpackage Plugins
* @license GNU/GPL
*/

// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die();

jimport('joomla.event.plugin');

/**
* Example Authentication Plugin. Based on the example.php plugin in the Joomla! Core installation
*
* @package Joomla.Tutorials
* @subpackage Plugins
* @license GNU/GPL
*/
class plgAuthenticationMyauth extends JPlugin
{
/**
* Constructor
*
* For php4 compatability we must not use the __constructor as a constructor for plugins
* because func_get_args ( void ) returns a copy of all passed arguments NOT references.
* This causes problems with cross-referencing necessary for the observer design pattern.
*
* @param object $subject The object to observe
* @since 1.5
*/
function plgAuthenticationMyauth(& $subject) {
parent::__construct($subject);
}

/**
* This method should handle any authentication and report back to the subject
* This example uses simple authentication - it checks if the password is the reverse
* of the username (and the user exists in the database).
*
* @access public
* @param array $credentials Array holding the user credentials ('username' and 'password')
* @param array $options Array of extra options
* @param object $response Authentication response object
* @return boolean
* @since 1.5
*/
function onAuthenticate( $credentials, $options, &$response )
{
/*
* Here you would do whatever you need for an authentication routine with the credentials
*
* In this example the mixed variable $return would be set to false
* if the authentication routine fails or an integer userid of the authenticated
* user if the routine passes
*/
$db =& JFactory::getDBO();
$query = 'SELECT `id`'
. ' FROM #__users'
. ' WHERE username=' . $db->quote( $credentials['username'] );
$db->setQuery( $query );
$result = $db->loadResult();

if (!$result) {
$response->status = JAUTHENTICATE_STATUS_FAILURE;
$response->error_message = 'User does not exist';
}

// to authenticate, the username must exist in the database, and the password should be equal
// to the reverse of the username (so user joeblow would have password wolbeoj)
if($result && ($credentials['username'] == strrev( $credentials['password'] )))
{
$email = JUser::getInstance($result); // Bring this in line with the rest of the system
$response->email = $email->email;
$response->status = JAUTHENTICATE_STATUS_SUCCESS;
}
else
{
$response->status = JAUTHENTICATE_STATUS_FAILURE;
$response->error_message = 'Invalid username and password';
}
}
}
?>
</source>

You will notice that we have to add <source lang="php">jimport('joomla.event.plugin');</source>to the beginning of our file in order to load the JPlugin class definition.

== The XML Install Manifest ==

Now that we have created our JPlugin class, all we have to do is create our XML install file that will tell the Joomla! installer how to install our plugin. This file is simple:

<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<install version="1.5" type="plugin" group="authentication">
<name>Authentication - Myauth</name>
<author>Joomla! Documentation Project</author>
<creationDate>May 30, 2007</creationDate>
<copyright>(C) 2005 - 2007 Open Source Matters. All rights reserved.</copyright>
<license>http://www.gnu.org/copyleft/gpl.html GNU/GPL</license>
<authorEmail>ian.maclennan@help.joomla.org</authorEmail>
<authorUrl>www.joomla.org</authorUrl>
<version>1.5</version>
<description>An sample authentication plugin</description>
<files>
<filename plugin="myauth">myauth.php</filename>
</files>
<params/>
</install>
</source>

You will notice that this file looks very similar to any other Joomla! XML install manifest file. There are a few important things to notice.

The first thing to notice is the group attribute on the root element. For authentication plugins, the group attribute must have the value 'authentication'. This tells the Joomla! system to treat your plugin as an authentication plugin.

It is also important to note that the version attribute of the root element (install) should be 1.5. This will tell Joomla! that your plugin is written for Joomla! 1.5 and will operate without legacy mode.

We entered the name 'Authentication - Myauth' in the name field. Your plugin doesn't HAVE to follow this convention, but it looks better because then it will match the standard authentication plugins that are listed in the plugin manager.

Finally, notice that filename attribute that contains our plugin file has an attribute called plugin. The value of this should be the name of our plugin. In this case, it is myauth.

== Wrapping it All Up and Using It ==

Now that we have created our two files, all we have to do is package them up into an archive file that can be read by the Joomla! installer system.

Once we package and install our plugin, it is ready to be used. The plugin is published using the Plugin Manager. All of the authentication plugins will be grouped together. Plugins are enabled by 'publishing them'. You can publish as many authentication plugins as you want. In order for successful authentication to occur, only one of the plugins needs to return a <code>JAUTHENTICATE_STATUS_SUCCESS</code> result.

== Conclusion ==

We have now created a simple authentication plugin. We have demonstrated the basic process of doing an authentication check and return the results to the Joomla! system.

You can also easily test this plugin by packaging it yourself.

[[Category:Tutorials]]
[[Category:Plugin Development]]

Help15:Screen.users.massmail.15

2011-09-26T18:48:28Z

MTrapp82: None

==How to access==
Select '''Tools &rarr; Mass Mail''' from the drop-down menu on the Back-end of your Joomla! installation.

==Description==
The Mass Mail screen allows Users who are members of the "Super Administrator" group to send an e-mail message to all Users who are members of a specific group.

==Screenshot==
[[Image:Mass_mail.png]]

==Details==
*'''Mail to Child Groups.''' Whether or not to send the E-mail to members of all child groups of the selected <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> group. For example, if this box is checked and the group "Public Front-end" is selected, the e-mail would be sent to all members of the "Registered", "Author", "Editor" and "Publisher" groups.
*'''Send in HTML mode.''' Whether or not to send the E-mail with headers that identify it as an HTML document. E-mail clients that support this will render any HTML codes.
*'''Group.''' Select the group you want to send the E-mail to.
*''' Recipients as BCC. Adds copy to site email.''' If checked, all recipients will be included as BCC entries, so none will see any of the other recipients' E-mail addresses. Because many mail routers treat E-mail without a ''To:'' entry as spam, the site email will be used for the ''To:'' entry.
*'''Subject''' Enter the Subject of the E-mail. Try to make it as descriptive as possible. Any text entered in the ''Subject Prefix'' parameter (see [[#Global Configuration|Global Configuration]] below) will be prepended to (placed in front of) the subject you enter here.
*'''Message.''' Enter the body of the E-mail. Any text entered in the ''Mailbody Suffix'' parameter (see [[#Global Configuration|Global Configuration]] below) will be added to the text you enter here.

==Global Configuration==
This pop-up screen is shown when the User clicks the 'Parameters' button on the Toolbar. Press the Save button to save any changes or Cancel to discard any changes.

[[Image:Screen_massmail_params_15.png]]

*'''Subject Prefix.''' Enter a prefix to be prepended to the Subject of every mass E-mail. This is intended to contain some site identifier, for example, the site name.
*'''Mailbody Suffix.''' Enter a suffix to be appended to the body of every mass E-mail. This is intended to be used as a site signature.

==Toolbar==
At the top right you will see the toolbar:

[[Image:Screen_massmail_toolbar.png]]

*'''Send Mail''' Send the email and return to the main Mass Mail screen
{{toolbaricon|Cancel}}
{{toolbaricon|Parameters}}
{{toolbaricon|Help}}

==Related Information==
*To add or edit Users in the Back end: [[screen.users.15|User Manager]]
*To create a layout to allow Users to self-register in the Front end: [[screen.menus.edit.15#Default Login Layout|Menu Item Manager - New/Edit - Default Login Layout]]
*To send Super Administrators Private Messages: [[screen.messages.inbox.15|Private Messages - Inbox]]
<noinclude>{{cathelp|1.5|Mass Mail|Tools}}</noinclude>

Should PHP run as a CGI script or as an Apache module?

2011-09-26T18:48:26Z

MTrapp82: None

There are two ways to configure Apache to use PHP:

# Configure Apache to load the PHP interpreter as an ''Apache module''
# Configure Apache to run the PHP interpreter as a ''CGI binary''

''(PS: Windows IIS normaly configures as CGI by the way)''

It is the intention of this post to provide you information relating to the configuration and recognition of each method. "In general" historically only one method or the other has been implemented, however, with the architectural changes made to PHP starting with PHP5, it has been quite common for hosting firms to configure for both. One version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will be delivered out of the box.

== What is the difference between CGI and apache Module Mode? ==

An '''Apache module''' is compiled into the Apache binary, so the PHP interpreter runs in the Apache process, meaning that when Apache spawns a child, each process already contains a binary image of PHP. A CGI is executed as a single process for each request, and must make an exec() or fork() call to the PHP executable, meaning that each request will create a new process of the PHP interpreter. Apache is much more efficient in it's ability to handle requests, and managing resources, making the Apache module slightly faster than the CGI (as well as more stable under load).

'''CGI Mode''' on the other hand, is more secure because the server now manages and controls access to the binaries. PHP can now run as your own user rather than the generic Apache user. <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">child carrier</span>]</span> This means you can put your database passwords in a file readable only by you and your php scripts can still access it! The "Group" and "Other" permissions (refer ) can now be more restrictive. CGI mode is also claimed to be more flexible in many respects as you should now not see, with phpSuExec (refer ) issues with file ownership being taken over by the Apache user, therefore you should no longer have problems under FTP when trying to access or modify files that have been uploaded through a PHP interface, such as Joomla! upload options.

If your server is configured to run PHP as an Apache module, then you will have the choice of using either php.ini or Apache .htaccess files, however, if your server runs PHP in CGI mode then you will only have the choice of using php.ini files locally to change settings, as Apache is no longer in complete control of PHP.

== Testing and Reviewing Your PHP Installation ==

''Also known as "Everything you ever wanted and didn't want to know about PHP"''

To find out the PHP interpreter mode and to generally test your PHP installation and to find out a vast amount of information about your PHP environment, supported utilities, applications and settings, you create a single PHP file containing '''only''' the following lines:

<source lang="php">
<?php
phpinfo();
?>
</source>

This single line of code outputs an amazing amount of information, be warned.... [[Image:Icon_wink.gif]]

Save the file as any filename you wish, but with the ".php" extension. FTP it to your server and open it in a browser.

== Other useful information ==

The following are PHP functions, that when run from a PHP File can provide some useful information, '''(less than the above option)''' many should run on most hosts, however many hosts disable some of these functions for security. No guarantees offered...

Again, as above, make a file, name it anything you wish but make sure it has the ".php" extension, copy and paste the following lines in to it and FTP to your server.

<source lang="php">
<?php
echo "Hostname: ". @php_uname(n) ."\n";
if (function_exists( 'shell_exec' )) {
echo "Hostname: ". @gethostbyname(trim(`hostname`)) . "\n";
} else {
echo "Server IP: ". $_SERVER['SERVER_ADDR'] . "\n";
}
echo "Platform: ". @php_uname(s) ." ". @php_uname(r) ." ". @php_uname(v) ."\n";
echo "Architecture: ". @php_uname(m) ."\n";
echo "Username: ". get_current_user () ." ( UiD: ". getmyuid() .", GiD: ". getmygid() ." )\n";
echo "Curent Path: ". getcwd () ."\n";
echo "Server Type: ". $_SERVER['SERVER_SOFTWARE'] . "\n";
echo "Server Admin: ". $_SERVER['SERVER_ADMIN'] . "\n";
echo "Server Signature: ". $_SERVER['SERVER_SIGNATURE'] ."\n";
echo "Server Protocol: ". $_SERVER['SERVER_PROTOCOL'] ."\n";
echo "Server Mode: ". $_SERVER['GATEWAY_INTERFACE'] ."\n";
?>
</source>

The '''Joomla! HISA''' or '''Joomla! Tools Suite''' can also assist to determine which mode your server in running in, also providing a large amount of other related information including recommendations on configuration.

* '''Joomla! Tools Suite''' (JTS) is a complete "Suite" of Tools to help you troubleshoot and maintain Joomla! and includes the "HISA" script.
*: [http://joomlacode.org/gf/project/jts/ Download JTS Here]
* '''Joomla! Health, Installation and Security Audit''' (HISA) is a single standalone script that provides purely configuration information.
*: [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

[http://forum.joomla.org/index.php/topic,136328.0.html Forum Discussion Here]

[http://www.joomlatutorials.com/faq/60.html How to TroubleShoot A Joomla! Installation]

Another '''indirect method''', and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

'''Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server
configurations, it will help those wishing to cause your site harm'''

== How to... ==
'''For those wishing to know more about "How To..."'''

=== Running PHP as an Apache module ===

To configure Apache to load PHP as a module to '''parse''' your PHP scripts, the httpd.conf needs to be modified, typically found in "c:\Program Files\Apache Group\Apache\conf\" or "/etc/httpd/conf/".

Search for the section of the file that has a series of commented out "LoadModule" statements. (Statements prefixed by the hash "#" sign are regarded as having been commented out.) If PHP is running in "Apache Module" Mode you should see something very similar to the following;

<source lang="apache">LoadModule php4_module "c:/php/php4apache.dll"</source>

==== Apache 1.x ====

===== For PHP5 =====
<source lang="apache">LoadModule php5_module C:/php/php5apache2.dll</source>
''or (platform dependent)''
<source lang="apache">LoadModule php5_module /usr/lib/apache/libphp5.so</source>
'''and'''
<source lang="apache">AddModule mod_php5.c</source>

===== For PHP4 =====
<source lang="apache">LoadModule php4_module libexec/libphp4.so</source>
''or (platform dependent)''
<source lang="apache">LoadModule php4_module C:/php/php4apache.dll</source>
'''and'''
<source lang="apache">AddModule mod_php4.c</source>

==== Apache 2.x ====

===== For PHP5 =====

<source lang="apache">LoadModule php5_module C:/php/php5apache2.dll</source>
''or (platform dependent)''
<source lang="apache">LoadModule php5_module /usr/lib/apache/libphp5.so</source>
'''and'''
<source lang="apache">AddModule mod_php5.c</source>

===== For PHP4 =====
<source lang="apache">LoadModule php4_module libexec/libphp4.so</source>
''or (platform dependent)''
<source lang="apache">LoadModule php4_module C:/php/php4apache.dll</source>
'''and'''
<source lang="apache">AddModule mod_php4.c</source>

==== Note ====

Don't worry that you can't find a "mod_php4.c" or "mod_php5.c" file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server.

''If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.''

Now find the "AddType" section in the file, and add the following line after the last "AddType" statement:

<source lang="apache">AddType application/x-httpd-php .php</source>

If you need to support other file types, like ".php3" and ".phtml", simply add them to the list, like this:
<source lang="apache">
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .phtml
</source>

Run a syntax check and if all is ok, restart Apache...

=== Running PHP as a CGI binary ===

To configure PHP to run as a CGI, again you will need to configure the httpd.conf, but confirm that the above settings are not also configured, unless you know what you are doing you can generate yourself "HTTP 500" errors. Search your Apache configuration file for the "ScriptAlias" section.

Add the following line below after the ScriptAlias for "cgi-bin".
'''Note:''' The location will depend on where PHP is installed on your system, you should substitute the appropriate path in place of "c:/php/" (for example, "c:/Program Files/php/").

<source lang="apache">ScriptAlias /php/ "c:/php/"</source>

Apache again needs to be configured for the PHP MIME type. Search for the "AddType" section, and add the following line after it:

<source lang="apache">AddType application/x-httpd-php .php</source>

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

<source lang="apache">
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .phtml
</source>

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the "Action" section.

<source lang="apache">Action application/x-httpd-php "/php/php.exe"</source>

If you notice, we have used the "ScriptAlias" reference, "/php/" portion will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. ''In other words, don't put "c:/php/php.exe" or "c:/Program Files/php/php.exe" in that directive, put "/php/php.exe", Apache WILL work it out if correctly configured.''

=== Configuring the Default Index Page ===

This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the "httpd.conf". Simply search for the line in the file that begins with a "DirectoryIndex" and add "index.php" to the list of files on that line. For example, if the line used to be:
<source lang="apache">DirectoryIndex index.html</source>
''change it to the following if you still wish .html files to be executed before .php files''
<source lang="apache">DirectoryIndex index.html index.php</source>
''or change it to the following if you wish .php files to be executed before .html files''
<source lang="apache">DirectoryIndex index.php index.html</source>

The next time you access the site or a directory within a site without a filename, Apache will "auto-magically" deliver "index.php" if available, or "index.html" if "index.php" is not available.
[[Category:FAQ]]
[[Category:Administration FAQ]]
[[Category:Installation FAQ]]
[[Category:Upgrading and Migrating FAQ]]
[[Category:Version 1.5 FAQ]]

Inserting a list into an Article

2011-09-26T18:48:24Z

MTrapp82: None

{{Review}}
Ordered and un-ordered lists are a very common way of presenting information. To add a list to an article.
#Open the Article for editing either by:
#* Click the '''Content > Article Manager''' menu item to go to the ''Article Manager'', select the Article and click the ''Edit'' toolbar button.
#* Clicking the ''Add New Article'' button in the Control Panel.
#* If logged in to the Front-end, you have appropriate permissions and are viewing the Article you wish to edit: Click the ''Edit'' toolbar button.
#Locate the position in the article where you want to insert a list with the cursor.
#Choose either the ''Ordered list'' or ''Unordered list'' editor toolbar button.
#*The default ordered list begins with the numeral ''1.'' and the unordered list starts with a bullet point.
#Type enter to create a new line and number/bullet.
#Type enter twice to finish the list or start a new line and click the ''Ordered List'' or ''Unordered List'' editor toolbar button.

Note the following:
*Change the list type part way through by clicking the alternate button.
*If you create a new ordered list later in your article the numbering will restart from 1.
*Use the ''Indent'' and ''Outdent'' editor toolbar buttons to create child lists. <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">child carrier</span>]</span> You may change the type of the child list by clicking the alternate button.

J1.5:Creating a submenu

2011-09-26T18:48:22Z

MTrapp82: None

In Joomla!, submenus can be shown either as one menu with two or more levels or as completely separate menu modules. To show how to do this, we will step through creating a two-level menu and then see how to show it either as one large menu or as separate parent and child menus.

==Example Data==
In our example, we will create a menu called "Pets". It will have two top-level menu items called "Dogs" and "Cats". Under Dogs, we will have "Collies" and "Greyhounds". Under Cats we will have "Tabbies" and "Siamese". So the structure of the Pets menu will be as follows:
*Dogs
**Collies
**Greyhounds
*Cats
**Tabbies
**Siamese

==Menu and Menu Items==
To create this structure, we create one menu with two levels of Menu Items. Note that we do this whether we want to have everything shown as one large menu or whether we want to create separate menu modules (one parent menu and two child menus). We'll see how to do this later on, when we create the modules.

Here are the steps to create the Menu and Menu Items.
# Create a new Menu in the Menu Manager called "Pets".
# Add a new Menu Item called "Dogs". For this example, we don't really care what the type of the Menu Items is. For example, you can just create one article called "Pet Menu Test" and then create all of the Menu Items as type '''Article &rarr; Article Layout''' and point to this article.
# Add a second Menu Item called "Collies" (again, Menu Type of Article Layout as above). In the Parent Item box, select "Dogs", as shown below: [[Image:submenu_example1.png|frame|center]]
# Add a third Menu Item called "Greyhounds", again making "Dogs" the Parent Item. (Remember, these can all point to the same article.)
# Add the "Cats" Menu Item. Be sure to make the Parent Item for this "Top".
# Add the last two Menu Items, "Tabbies" and "Siamese", making "Cats" the Parent Item for both.

When you get done, the Menu Item Manager should look like the following:[[Image:submenu_example2.png|frame|center]]

==Menu Modules==
At this point, we've got the Menu and Menu Items done. Now we need to create the Menu Modules. In Joomla!, the Menu Module determines three main things: (1) what the <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> menu looks like; (2) where on the page it will show; and (3) on which pages it will show. We will do two examples. In the first example, we will create one Menu Module that shows all of the items in one menu. In the second, we will create three separate menu modules to show the Pets, Dogs, and Cats menus as separate modules.

===One Menu Module===
To show this as one module, follow these steps:
# Navigate to Extensions &rarr; Module Manager, click the "New" icon in the toolbar, and select "Menu".
# Enter the Title as "Pets Menu" and Position as "left".
# In the Menu Assignment, enter "Select Menu Item(s) from the List" and select "Home" (under "mainmenu"), and all of the Menu Items under the "pets-menu".
# In Menu Name, select "pets-menu" from the drop-down list box.
# If you are using the default "rhuk_milkyway" template and want the menu to look like the other menus, in the Advanced Parameters enter "_menu" for Module Class Suffix.

Now, navigate to the front-end home page. You should see the Pets Menu as shown below:[[Image:submenu_example3.png|frame|center]]Click on the Dogs Menu Item. The selected article displays and the Dogs menu expands to show the two submenu items, Collies and Greyhounds. Note that we can set a parameter in the Module Manager to always show submenu items. Here we have taken the default value of "No".

Click on "Collies" and again the article changes. (Or it would if we had different articles for each Menu Item!) The screen should look like the one below: [[Image:submenu_example4.png|frame|center]]

Notice that the Breadcrumbs now shows three levels: Home, Dogs, Collies. Because we used submenus, Joomla! "knows" that Collies is under Dogs.

===Separate Menu Modules===
Now we will change our example to create three separate menus -- one for the top level (Dogs and Cats), one for the Dogs (Collies and Greyhounds), and one for the Cats (Tabbies and Siamese).

<blockquote>''Note: Make sure that your Menu Items each have a unique Alias value. If you use the Copy command in the toolbar of the Menu Item Manager to create these Menu Items, the Alias will be the same as the item being copied. In this case, just edit the Alias value to make it unique (for example, the same as the Title). If you have duplicate Alias values, the menus will not work correctly if the parameter SEF URLs is set to Yes in Global Configuration.''</blockquote>

To do this:
# Open the Pets Menu in the Module Manager and change the Title to "Pets Menu Top Level Only".
# Select the Left Position.
# Under Module Parameters, select the Menu Name "Pets Menu"
# Under Module Parameters, change the Menu Style to "List".
# Set the Start Level to "0" and the End Level to "1".
# ''This is optional. It allows your template to apply special a menu style to the menu (a border, for example).'' In Advanced Module Parameters put "_menu" in Module Class Suffix.
# For submenu Dog, in extensions menu select Module Manager, click New and select Menu, and set the title to "Dogs Submenu".
# Set the Position to "Left".
# ''Now this part is very important.'' We only want this submenu to show when we are in one of the Dogs Menu Items. So, in the Menu Assignment box, select the three items "Dogs", "Collies", and "Greyhounds", as shown below: [[Image:submenu_example5.png|frame|center]]
# Under Module Parameters, select the menu name "Pets Menu" and change the Menu Style to "List".
# Set the Start Level to "1" and End Level "2".
# ''This is optional.'' In Advanced Module Parameters, set Module Class Suffix to "_menu".
# For the "Cats Submenu", repeat steps from 7 to 12 except step 9. In the Menu Assignment box, select the items "Cat", "Tabbies" and "Siamese" (so this menu will only show under these Menu Items).

At this point, we have three menu modules all pointing to the Pets Menu. The only differences between them are (1) the Start and End Levels and (2) the Menu Item Assignment.

Now, in the front end, navigate to the Home page. The "Pets Menu Top Level Only" menu should show. Select the "Dogs" Menu Item. Now, the "Dogs Submenu" should show as a separate menu, as shown below:[[Image:submenu_example7.png|frame|center]]

Click on the Collies Menu Item and notice that again the Breadcrumbs shows the hierarchy of "Home", "Dogs", and "Collies".

Using this same technique, it is easy to create third-level submenus. You just make the Parent Menu Item a second-level submenu. Then you could use the same technique to create a separate Menu Module with Start Level of 2 and End Level of 3. This would show only the third-level Menu Items.

[[Category:Tutorials]]
[[Category:Menu Management]]

J1.5:Core module-generated CSS

2011-09-26T18:48:16Z

MTrapp82: None

The following information is gathered from the default output for Joomla! 1.5 core modules and assumes that no template overrides are in place.

Note also that core , as generated <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">child carrier</span>]</span> by the ''System'' template, will wrap a module in a defined manner and in some instances apply .

'''mod_archive'''
: None

'''mod_banners'''
* <code>.bannergroup</code> class applied to surrounding <tt><nowiki><div></nowiki></tt>
* <code>.bannerheader</code> class applied to <tt><nowiki><div></nowiki></tt> of header text if it exists
* <code>.banneritem</code> class applied to <tt><nowiki><div></nowiki></tt> for each item
* <code>.bannerfooter</code> class applied to <tt><nowiki><div></nowiki></tt> of footer text if it exists

'''mod_breadcrumb'''
* <code>.breadcrumbs</code> class applied to a <tt><nowiki><span></nowiki></tt> element that holds the path links
* <code>.pathway</code> class applied to a <tt><nowiki><span></nowiki></tt> element that holds the path links
* <code>.pathway</code> class is also applied to each link

'''mod_feed'''
* <code>.moduletable</code> class applied to <tt><nowiki><table></nowiki></tt> of no set width
* <code>.newsfeed</code> class applied to <tt><nowiki><ul></nowiki></tt>
* <code>.newsfeed_item</code> class applied to <tt><nowiki><div></nowiki></tt> element that holds feed item's description under the title.

'''mod_footer'''
: None

'''mod_latestnews'''
* <code>.latestnews</code> class applied to surrounding <tt><nowiki><ul></nowiki></tt>, to each <tt><nowiki><li></nowiki></tt> and to each link

'''mod_login'''
* <code>#form-login</code> id applied to main container <tt><nowiki><form></nowiki></tt>
* <code>#form-login-username</code> id applied to <tt><nowiki><p></nowiki></tt>
* <code>#modlgn_username</code> id applied to <tt><nowiki><input type="text"></nowiki></tt>
* <code>#form-login-password</code> id applied to <tt><nowiki><p></nowiki></tt>
* <code>#modlgn_password</code> id applied to <tt><nowiki><input type="text"></nowiki></tt>
* <code>#form-login-remember</code> id applied to <tt><nowiki><p></nowiki></tt>
* <code>#modlgn_password</code> id applied to <tt><nowiki><input type="text"></nowiki></tt>
* <code>.button</code> class applied to <tt><nowiki><input type="submit"></nowiki></tt>
* <code>.input</code> class applied to <tt><nowiki><fieldset></nowiki></tt>
* <code>.inputbox</code> class applied to <tt><nowiki><input type="text"></nowiki></tt>

'''mod_mainmenu'''
* <code>#current</code> id applied to <tt><nowiki><li></nowiki></tt> for the current page
* <code>.active</code> class applied to <tt><nowiki><li></nowiki></tt> for the current page
* <code>.parent</code> class applied to <tt><nowiki><li></nowiki></tt> if child links exist
* <code>.item##</code> class applied to the <tt><nowiki><li></nowiki></tt>, where ## is the ItemId
* ''Menu-Type Parameters'':
** ''List''
:: <code>#menu</code> id is applied to the <tt><nowiki><ul></nowiki></tt>
:: becomes .menu if more than one menu is present on the page [CHECK]
:* ''Legacy-Vertical''
:: <code>.mainlevel</code> class is applied to each link in a <tt><nowiki><table></nowiki></tt> of 100% width
:* ''Legacy-Horizontal''
:: <code>.mainlevel</code> class is applied to each link in a <tt><nowiki><table></nowiki></tt> of 100% width
:* ''Legacy-Flat''
:: <code>#mainlevel</code> id is applied to the <tt><nowiki><ul></nowiki></tt>
:: becomes .menu if more than one menu is present on the page [CHECK]

'''mod_mostread'''
* <code>.mostread</code> class applied to surrounding <tt><nowiki><ul></nowiki></tt>, to each <tt><nowiki><li></nowiki></tt>, and to each link

'''mod_newsflash'''
* ''Layout-Type Parameters'':
** ''Default''
:: <code>.contentpaneopen</code> class applied to <tt><nowiki><table></nowiki></tt> of no set width
::: Two tables are created, one holds the article title, the second holds the abbreviated article text
:: <code>.contentheading</code> class applied to the <tt><nowiki><td></nowiki></tt> element holding the article titles
:: <code>.contentpagetitle</code> class applied to the article link
:* ''Horz''
:: <code>.moduletable</code> class applied to <tt><nowiki><table></nowiki></tt> of no set width
::: each item is placed in a new <tt><nowiki><td></nowiki></tt> element with default styles
:* ''Vert''
:: <code>.article_separator</code> class applied to <tt><nowiki><span></nowiki></tt> is added after each item if more than one exists

'''mod_poll'''
* <code>.poll</code> class applied to surrounding <tt><nowiki><table></nowiki></tt> of 95% width and centered text-alignment
* <code>.pollstableborder</code> applied to inner <tt><nowiki><table></nowiki></tt> of no set width, which holds the vote options
* <code>.sectiontableentry1</code> class applied to <tt><nowiki><td></nowiki></tt> with valign="top"
* <code>.sectiontableentry2</code> class applied to <tt><nowiki><td></nowiki></tt> with valign="top"
:: ''Note: sectiontableentry1 and sectiontableentry2 alternate each table row to provide for alternate row colors or other formatting''
* <code>#voteid##</code> id applied to <tt><nowiki><input></nowiki></tt>, where ## is the Id of the option
* <code>.button</code> applied to <tt><nowiki><input type="submit"></nowiki></tt> and <tt><nowiki><input type="button"></nowiki></tt>

'''mod_random_image'''
: None

'''mod_related_items'''
* <code>.relateditems</code> class applied to surrounding <tt><nowiki><ul></nowiki></tt>

'''mod_search'''
* <code>.search</code> class applied to surrounding <tt><nowiki><div></nowiki></tt>
* <code>.inputbox</code> class applied to search input box <tt><nowiki><input type="text"></nowiki></tt>. Also there is an id <code>#mod_search_searchword</code> applied to this input box
* <code>.button</code> class applied to search submit button/image <tt><nowiki><input type="image"></nowiki></tt> and <tt><nowiki><input type="submit"></nowiki></tt>

'''mod_sections'''
* <code>.sections</code> class applied to surrounding <tt><nowiki><ul></nowiki></tt>

'''mod_stats'''
: None

'''mod_syndicate'''
: None

'''mod_whosonline'''
: None

'''mod_wrapper'''
* <code>#blockrandom</code> id applied to <tt><nowiki><iframe></nowiki></tt>
* <code>.wrapper</code> class applied to <tt><nowiki><iframe></nowiki></tt>

<noinclude>[[Category: Templates]][[Category: Modules]][[Category: Reference]][[Category:Definition lists]]</noinclude>

J1.5:Custom user groups

2011-09-26T18:48:11Z

MTrapp82: None

{{JVer|1.5}}
''Please note that this article only applies to Joomla 1.5. See [[:Category:Access Control]] for articles on access control in other versions of Joomla.''

I use custom user groups (user roles) within Joomla 1.5. For example under the registered users group I've added several subgroups:

myproject
customers
customer A admin
product manager
product manager admin
etc....

I use these groups within my extension to set the permissions.

When I add the groups into the jos_core_acl_aro_groups table and set the relations correctly the groups in the user management are not displayed correctly (e.q. the administrator groups disappear). For displaying the groups correctly you will have to change the code of :
administrator/components/com_users/admin.users.php line 285:

(Not sure in what version this changed - but in J! 1.5.14 this change is no longer in the administrator/components/com_users/admin.users.php file. This change must now be made to administrator/components/com_users/views/user/view.html.php on line 113.)

<source lang="php">
if ( $userGroupName == $myGroupName && $myGroupName == 'administrator' )
{
// administrators can't change each other
$lists['gid'] = '<input type="hidden" name="gid" value="'. $user->get('gid') .'" /><strong>'. JText::_( 'Administrator' ) .'</strong>';
}
else
{
$gtree = $acl->get_group_children_tree( null, 'USERS', false );
</source>

into

<source lang="php">
if ( $userGroupName == $myGroupName && $myGroupName == 'administrator' )
{
// administrators can't change each other
$lists['gid'] = '<input type="hidden" name="gid" value="'. $user->get('gid') .'" /><strong>'. JText::_( 'Administrator' ) .'</strong>';
}
else
{
$gtree = $acl->get_group_children_tree( null, 'USERS', true);
</source>

If you like to add your self custom groups do the following:

Edit the jos_core_acl_aro_groups table and add your custom groups (for example with <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">child carrier</span>]</span> phpmyadmin). When you add a new group make sure that you assign the correct parent to the added group. For example: the joomla registered group has the ID 18, when you assign a subgroup to it make sure that the parent_id is 18. Dont assign the lft and rght fields yet but use the code below to rebuild the groups tree correctly:

<source lang="php">
<?php

// Put this code in a file in your Joomla root then run it. Don't forget to delete the file when you're done.

require 'configuration.php';
$config = new JConfig;

$user = $config->user;
$password = $config->password;
$db = $config->db;
$host = $config->host;

mysql_connect($config->host, $config->user, $config->password) or
die("Could not connect: " . mysql_error());
mysql_select_db($config->db);

// 0-> parent_id in Joomla this is the value of the parent_id field of the Root record
// 1-> start the left tree at 1
rebuild_tree (0, 1);

function rebuild_tree($parent_id, $left) {

global $config;

// the right value of this node is the left value + 1
$right = $left + 1;

// get all children of this node
$result = mysql_query('SELECT id FROM ' . $config->dbprefix . 'core_acl_aro_groups WHERE parent_id = ' . $parent_id . ';')
or die(mysql_error());

while ($row = mysql_fetch_array($result)) {
// recursive execution of this function for each
// child of this node
// $right is the current right value, which is
// incremented by the rebuild_tree function
$right = rebuild_tree($row['id'], $right);
}

// we've got the left value, and now that we've processed
// the children of this node we also know the right value
mysql_query('UPDATE ' . $config->dbprefix . 'core_acl_aro_groups SET lft = ' . $left . ', rgt = ' . $right . ' WHERE id = ' . $parent_id . ';')
or die(mysql_error());

// return the right value of this node + 1
return $right + 1;
}

echo 'Complete! Go check your Joomla User Admin!';

?>
</source>

When you want to use the custom groups to assign to your articles so that for example only the customers can view specific articles you need to add these groups into the jos_groups, just assign the ID + name of the group whereby the name must be equal to the groups names you added into the jos_core_acl_aro_groups table.

[[Category:Tips and tricks]]
[[Category:Tips and tricks 1.5]]

[[Category:Tutorials]]
[[Category:Access Control]]

J1.5:Adding a new Poll

2011-09-26T18:48:09Z

MTrapp82: None

The Joomla! Poll Manager allows you to create polls using the multiple choice format on any of your Web site pages. They can be either published in a module position using the Poll module or in a menu item using the Poll component.

==How to Create a Poll in the Poll Manager==
# Log in to the Administrator back-end. To learn how to do this read: [[Logging in or out of the Administrator back-end]].
# Click the '''Components> Polls''' menu item. You should see the '''Poll Manager''' screen.
# Click the '''New''' toolbar button to create your poll.
# Type the question that you wish to poll in the '''Title''' field .
# Type an abbreviated title of your poll in the '''Alias''' field.
# Change, if desired, the number of seconds between votes for each user in the '''Lag''' field.
# Select the '''No''' or '''Yes''' radio button to publish or not your poll.
# Type in the '''Options''' fields the possible choices for the answers of your poll.
# Click the '''Save''' or '''Apply''' toolbar button to implement the new settings:
#* The '''Save''' toolbar button will save your changes and return you to the Poll Manager.
#* The '''Apply''' button will save your changes but leave you in Poll [Edit]. You can then click '''Close''' if no other changes has been made or '''Save''' to leave this screen to return back to the Poll Manager.

You should now see the title of your Poll in the Poll Manager table. If you need to edit it, you can either double click the Poll Title or select the Poll by checking the check mark box and then click the '''Edit''' the toolbar button.

==How to Publish Your Poll Using the Poll Module==

In order for your visitors of your site to participate in your poll, you must now publish it in the Front-end of your site. You must first activate a new Poll module.

# Click the '''Extensions> Module Manager''' menu item to view the '''Module Manager''' screen.
# Click the '''New''' toolbar button to activate your new poll module.
# Select the '''Poll''' radio button from the list of installed modules.
# Click the '''Next''' toolbar button

'''Details:'''
# Type the title of your Poll module in the '''Title''' field.
# Select the '''No''' or '''Yes''' radio button to choose if your module title is published.
# Select the '''No''' or '''Yes''' radio button to enable/publish your module to your site.
# Select the module position from the drop down menu.
# Select the order that you want this module to appear on your web site if there are more than one module assigned to this position
# Select the '''Access Level''' as to who is able to see this module on your Web site.

'''Menu Assignment'''
# Select from the '''Menu''' radio buttons '''All''', '''None''' or '''Select Menu Item(s) from the List'''. If you choose this last option, then...
# Select the Menu items to determine which pages you wish to appear your poll.

'''Parameters:'''
'''Module Parameters'''
# Select the Poll from the drop down list
# Type the CSS class (if needed) that is included with your CSS file (Cascading Style Sheet). This class is determined by the author of your template.

'''Advanced Parameters'''
# Select '''Global''' or '''Cashing''' from the drop down Cashing menu.
#* '''Global''' is the setting you have for this module in the Global Configurations section of your Administrator site. (??? to verify)
#* '''Cashing''' is the setting for (??? What is this for?)

# Click the '''Save''' or '''Apply''' toolbar button to implement the new settings:

You can now visualize your work in the Front-end of your site.

==How to Publish Your Poll Results as a Menu Item==

# Click the '''Menu> Mainmenu (or other menu)''' menu item to view the '''Menu Item Manager: [mainmenu]''' screen.
# Click the '''New''' toolbar button to create a new menu item.
# Select '''Poll> Poll Layout''' from the list of '''Select Menu Item Type'''

'''Menu Item Details:'''

# Type the title of your poll in the '''Title''' field.
# Type the abbreviated title in the '''Alias''' field.
# Leave the '''Link''' field as is. (??? - to verify)
# Select the menu from the '''Display In''' drop down menu that you wish to present your poll results.
# Select the parent/child menu item as to where you wish your menu item to be located in the '''Parent Item''' drop down menu.
# Select the '''No''' or '''Yes''' radio button to publish/unpublish your new menu item to your site.
# New Menu Items default to the last place. Ordering can be changed after this Menu Item is saved in the '''Order''' drop down menu.
# Select the '''Access Level''' as to who is able to see this module on your Web site.
# Click from the '''On Click, Open in:''' items:
#* Parent Window with Browser Navigation (creates the link within your site with browser navigation)
#* New Window with with Browser Navigation (creates an external link with browser navigation)
#* New Window without Browser Navigation (creates an external link without browser navigation)

'''Parameters - Basic:'''

# Select the poll from the '''Poll''' drop down menu.

'''Parameters - System'''

# Type (if needed) the page title. (If left blank, the menu item title will be used)
# Select the '''No''' or '''Yes''' radio button to publish/unpublish your page title.
# Type the CSS class of your page if different from the standard CSS class for pages.
# Select from the '''Menu Image''' drop down menu an image that goes to the left or right of your menu item.
# Select the '''SSL Enabled''' radio button '''Off''', '''Ignored''' or '''On'''. This selects whether or not this link should use SSL and the Secure Site URL.

You can now visualize your work in the Front-end of your site.

==How to Show/Hide the Results of a Poll==

Joomla shows the results to the users after they vote on a poll. In order to keep those results hidden, you have edited the file that displays these results. that file is located here: components/com_poll/views/poll/view.html.php<br>
Edit this line of code at the end of the file
<pre>
parent::display($tpl);
</pre>
and changed it to this
<pre>
if ($_REQUEST['poll'] == "SHOW_RESULTS") parent::display($tpl);
</pre>
This will hide the poll results for everybody including you. If you want to see the results <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> yourself, all you need to do is modify the URL to include. Simply follow the steps outlined in "How to Publish Your Poll Results as a Menu Item" above and after you open that page in your web browser, you will need to add this to the end of the URL
* Use this if you have SEF URLs enabled
<pre>
?poll=SHOW_RESULTS
</pre>
* Use this if you do not have SEF URLs enabled
<pre>
&poll=SHOW_RESULTS
</pre>
For example, if your URL looks like this www.domain.com/index.php?option=com_content ... add &poll=SHOW_RESULTS to the end<br>
if your URL looks like this www.domain.com/my-poll ... add ?poll=SHOW_RESULTS to the end<br>

[[Category:FAQ]][[Category:Component Management]]

Development Working Group

2011-09-26T18:47:53Z

MTrapp82: None

{{incomplete}}[[Image:workgroups_development.jpg|right]]

== Introduction ==

'''''"..To develop a cutting edge, state of the art Web Content Management application framework..."'''''

The main responsibility of the [[Development Working Group]] is taking care of the development of the Joomla! application framework and the Joomla! Content Management System (CMS). Besides the development of the Joomla! codebase the development working group defines the Joomla! roadmap strategy, creating (architectural) designs for major and minor versions and of course take care of bug and security fixes in maintenance versions.

The development working group holds two teams: the [[Development Team]] and the so called [[Bug Squad]]. Both teams have a separate responsibility but together they form the development force for the Joomla! project.

Joomla! is as every other open-source project based upon the fundaments of collaborative and is a community-driven project. This means that the software, the documentation, the ever growing number of available the extensions, support (forum, mailing, lists newsletters, user groups are collaboratively produced by users and developers all over the world.

In this section of the documentation wiki we have tried to describe all relevant aspects to Joomla! development. Our effort strives to be as complete as we can be, but we don't rule out that information you are looking for is not (yet) documented. We encourage everyone to help completing the documentation effort and maximize the community effect within the Joomla! project.

== Getting started ==

The amount of information that is available from this page is like a small (e-)book. We tried to organize the information in a logical <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> order, and also structure the information in the most efficient way. To prevent you from reading for some hours, we use a simple documentation method. Per topic we draft a short description on the information that can be found, and in the linked pages we will provide as much as possible detail. Keep in mind that you can use the free-text search or the generated table of contents for this documentation category to find your information. If there is information missing, feel free to add this within this wiki.

* [[First look around]]
* [[Guide to the Development Documentation wiki section]]

== Technical infrastructure ==

For collaboration we have set up an infrastructure like version control, the bug tracker and of course this wiki for documentation. These assets are essential for Joomla! development. Below you will find links to the infrastructure that is used within the Joomla! project.

* [[Mailing lists]]
* [[Version control]]
* [[Bug tracker]]
* [[IRC/Real-Time Chat]]
* [[Wikis]]
* [[Web sites]]
* [[Joomlacode]]

== Social and Political Infrastructure ==

Ready for something more heavy at tea? Then you're in the right place here ;-) In this section we describe the basic organizational structures we have put in place, but probably at least important we describe the code of conduct we follow. For open source projects this is especially important because we have no hierarchical relation with our volunteers, the Joomla! project follows the [[http://producingoss.com/en/consensus-democracy.html Consensus Based Democracy]] model.

* [[Organizational structure]]
* [[Code of conduct]]

== Communications ==

There are several ways to get in touch, or communicate with the development community of Joomla! Within the working groups we try to share as much as possible information, using different media. It is a mix of tools and events we organized, details can be found in the links below.

* [http://developer.joomla.org/section-blog.html Development blog]
* [http://developer.joomla.org/gsoc2008.html Summer of Code blog]
* [http://developer.joomla.org/bug-squad-blog.html Bug Squad blog]
* [http://forum.joomla.org/viewforum.php?f=509&sid=fb99f7b1a81437ff25e8dd707343bae0 Development forum]
* [[Development meetings]]
* [http://www.google.com/calendar/embed?src=calendar@joomla.org Joomla! events]
* [http://community.joomla.org/joomla-user-groups.html Local user groups]
* [http://docs.joomla.org/Pizza_Bugs_and_Fun_2 Pizza Bugs and Fun]

== Packaging, releasing and daily development ==

* Release numbering
* Release branches
* Sandboxes
* Stabilizing a release
* Packaging
* Testing and releasing
* Maintaining multiple release lines (general description, and our current release lines)
* Releases and daily development

== Development community ==

* How to get involved?
* 3rd party development
* Interesting topics to study
* Recommended readings and books

== Licensing and copyrights ==

* General Public License

== How to contribute to Joomla! development ==

== Coding standards ==
A list of Joomla! coding standards as of 13 February 2010 can be found here: [[Coding style and standards]]. There is also a list of [[Core Development Best Practices]].

== Writing secure Joomla! code ==

* [http://developer.joomla.org/tutorials/181-preventing-sql-injections.html Preventing SQL injections]
* [[Secure coding guidelines]]

== Unit testing within Joomla! ==

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits. Unit tests find problems early in the development cycle.

In computer programming, unit testing is a method of testing that verifies the individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class.

Ideally, each test case is independent from the others; Double objects like stubs, mock or fake objects as well as test harnesses can be used to assist testing a module in isolation. Unit testing is typically done by software developers to ensure that the code they have written meets software requirements and behaves as the developer intended.

Ground work on the implementation of unit testing has been done by Enno Klasing during the Summer of Code 2007 project and has been perfected by Alan Langford from the Joomla! [[Development Team]]. The way [[Unit Testing]] is implemented within the Joomla! project has been documented in the [[Unit Testing]] chapter.

* [[Unit Testing]]

== What does a Joomla! development environment look like ==

== Debugging your Joomla! code ==
One way to debug Joomla! code is using the open-source programs Eclipse and XDebug. Instructions for setting up these programs is available in [[Setting up your workstation for Joomla! development]].

== Joomla! organization ==

* An explanation on how the [[Development Team]] is organized.
* An explanation on how the [[Bug Squad]] is organized.

== Joomla! planning process and procedures ==
* Description on the [[Development Strategy of Joomla!]]
* A description of how the [[Joomla! Maintenance Procedures]] are organized
* [[Release procedure and checklist]]
* [[Team member administration]]

== Miscellaneous ==

This is "old" content and needs to be moved to the final location in this wiki, work in progress...

* [[Unit Testing]] within the Joomla! project
* [[The use of Subversion]]
<noinclude>[[Category:Development Working Group]]</noinclude>

[[Category:Working Groups]]

Getting Started with Object Oriented Programming

2011-09-26T18:47:45Z

MTrapp82: None

PHP is an object oriented language, and to use the MVC structure as implemented by Joomla!, a solid understanding of object oriented programming ''(OOP)'' is required. This document explains the reasons for using objects and the way objects are used in PHP.

== Introduction to Objects ==

As we venture into object oriented programming, it is important to note that it is called 'object' oriented for a reason.

Before object oriented programming (OOP), everything was based on ''functions'' and ''variables''. Let's consider an application that calculates a person's BMI. You might have three variables: <code>$height</code> and <code>$weight</code> and <code>$name</code>. These variables would be used to store a person's name, height and weight. You might then have a function called <code>calculateBMI()</code>, which would accept as parameters $height and $weight.

This would look something like:

<source lang="php">
function calculateBMI( $height, $weight ) {
return $weight / $height;
}</source>

But it is very easy to lose track of all these variables in the code, not to mention the fact that only one person is supported at a time. The idea behind objects is to '''encapsulate''' this data '''and''' the functions to manipulate it into one ''package''. The definition of this package is called a ''class''.

So we might have:

<source lang="php">
class person
{
var $name;
var $height;
var $weight;

function getBMI() {
return $this->weight / $this->height;
}
}</source>

Then, if you want to create an object which represents a person, you would do:

<source lang="php">
$person = new person();
</source>

This is called ''instantiating'' the class, because it creates an ''instance'' of the class (an object described by the class).

Now, you can modify the variables (which are called ''properties''), using:

<source lang="php">
$person->height = 2;
$person->weight = 50;
</source>

Then you can invoke its functions (which are called ''methods'') using:

<source lang="php">
$bmi = $person->getBMI();
</source>

Often, many classes are similar, but too different to put into one class. For example, all animals have lungs, and because humans and cats are animals, they could both have a <code>$lung_capacity</code>. However, cats have tails, so should an <code>Animal</code> class have a <code>$tail_length</code>? No, that is not necessary. You can make a class a ''subclass'' or ''child class'' of another, essentially stating that the subclass has everything its parent class has, plus some extensions.

In Joomla, most classes are children of JObject. Now, if we were to make person a child class of JObject, then we would ''inherit'' the capabilities of the JObject class. We would then change the definition to something like:

<source lang="php">

class person extends JObject
{
var $name;
var $height;
var $weight;

function getBMI() {
return $this->weight / $this->height;
}
}
</source>

Then we could ''manipulate'' our person using the <code>get()</code> and <code>set()</code> methods that JObject has:

<source lang="php">
$person->set( 'name', 'Bob' );
$person->set( 'height', 2 );
$person->set( 'weight', 50 );
$person->get( 'weight' );
echo $person->getBMI();
</source>

You will notice the use of <code>$this</code> inside classes a lot. <code>$this</code> is a reference to the '''current''' object. So if I am inside a class, and I use say <code>$this->height = 2;</code>, then that means I am setting the property 'height' of the current object to 2. When we use <code>$this->height</code>, we aren't talking about any height, but we're talking about the current object height.

== More on Objects ==

As I said, Objects are called Objects for a reason. If you have a real life object, say a photocopier, there is an external interface (say, a paper tray, the copier glass, the keypad, etc.). Objects in OOP are designed to approximate that setup.

So, I might have a class called copier. Now, what operations do I generally need to do with a copier? Well, the basic functionality I need is copy functionality. So I need a method called 'copy':

<source lang="php">
class Copier
{
function copy() {
echo 'One copy made';
}
}
</source>

Now, this is a very basic copier. What if I wanted to extend the functionality of my Copier? Well, to extend the functionality, I create a child class. ''A child class will inherit all the functionality of the parent class.''

Let's suppose we wanted to create a copier that would keep track of the number of copies it had made. So, we would need to add a property which would keep track of this number, and then we need to somehow adjust this number each time we make a copy.

So here is our child class:

<source lang="php">
class CopierWithCounter extends Copier
{
var $counter;

function copy() {
$this->counter++;
parent::copy();
}
}
</source>

So we now have a property called <code>$counter</code> that keeps track of the number of copies made. Notice that the method we defined has the same name as the method in the Copier class. What this means is that we don't need to learn anything new to use the copier - it behaves in the same way as our old copier, but it just keep track of the number of copies.

You will see that inside of the <code>copy()</code> method there is a line: ''<code>parent::copy()</code>''. The <code>parent</code> keyword references the parent class, which is in this case Copier. So this line will invoke the <code>copy()</code> method of the Copier class. In this way, we don't have to rewrite the functionality to make a copy - we have already done that in the Copier class.

So we have the exact same functionality as the Copier class, except that anytime a copy is made it will increment the $copies property by 1. Just as in real life, the addition of the counter doesn't change the way that I use the copier - I don't need to know anything about the counter to just make a simple copy.

Now, the question arises: what value does <code>$counter</code> have to start with? We know that it increases by one every time a copy is made, but that is all we know.

This value needs to be ''initialized'' to a certain value.

Initializing values is generally done by what is called a ''constructor''. A constructor does just that - it constructs the object. In PHP4, constructors were functions that always had the same name as the class. In PHP5, constructors are functions with the name <code>__construct</code>. We will use <code>__construct</code> here.

So our class now becomes:
<source lang="php">
class CopierWithCounter extends Copier
{
var $counter;

function __construct() {
$this->counter = 0;
}

function copy() {
$this->counter++;
parent::copy();
}
}
</source>

Now suppose we wanted to create an even more advanced copier. We can do that by creating another child class. Let's create a copier that is able to do multiple copies. In order to do this, we need a way to specify how many copies we want and a way to remember this number. We will add a method called 'setCopies()':

<source lang="php">
class CopierMultipleCopies extends CopierWithCounter
{
var $copies;

function setCopies( $copies ) {
$this->copies = $copies;
}
}
</source>
We now have a way to specify how many copies we want to make.

Now, it is appropriate here to say a word about ''scope''. When we talk about scope, we talk about where a certain variable can be seen. You will notice that in our class, we have a property called <code>$copies</code>. But we also have a parameter called <code>$copies</code> in our method <code>setCopies</code>. How do you tell them apart?

Well, the rules of scope tell us which variable we are talking about. If a method takes a parameter, say <code>$copies</code> (as above), then if I use <code>$copies</code> inside that method, I am referring to <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> that parameter. There may be other variables called <code>$copies</code> that are defined in other places, but I don't care about those - I only care about the one inside of my function. If I want to refer to a property of the current object, I use the <code>$this</code> keyword. So, if I use <code>$this->copies</code>, then I am talking about the <code>$copies</code> property that belongs to my current object.

So that aside, our <code>setCopies()</code> method will allow us to set the number of copies that we want to make using our copier. The method takes one parameter - <code>$copies</code>, and stores it in the object.

You will notice that our current class definition for CopierMultipleCopies doesn't define a <code>copy()</code> method or a constructor. But, because it extends CopierWithCounter, it inherits the <code>copy()</code> method from CopierWithCounter, and also inherits the properties. So, without doing any extra work, we already have a Copier with a counter.

But we still want to extend the functionality of the <code>copy()<code> method so that it actually makes the multiple copies. So, we add a method definition to our class. We will also add a constructor that will add the functionality of initializing the number of copies to 1.

<source lang="php">
class CopierMultipleCopies extends CopierWithCounter
{
var $copies;

function __construct() {
$this->copies = 1;
parent::__construct();
}

function setCopies( $copies ) {
$this->copies = $copies;
}

function copy() {
for ($i = 0; $i < $this->copies; $i++) {
parent::copy();
}
}
}
</source>

So what have we done here? Well, first, in our constructor we initialized the $copies variable to 1. Thus, if we don't tell our copier otherwise, it will make one copy when the <code>copy()</code> method is invoked. Note that we don't have to rewrite the code to initialize the counter - we just call <code>parent::__construct()</code> and our parent constructor will handle that.

Then, we ''overrode'' the <code>copy()</code> method. Inside of our <code>copy()</code> method we have what is called a ''[[http://en.wikipedia.org/wiki/For_loop|for loop]]''.

In the first line of the for loop, you will see three parts divided by semicolons.

The first part is the ''initialization''. We will use $i as a counter variable, and we will start it at 0. $i will essentially keep track of the number of copies we have made out of the total number that we have to do.

The second part is the ''condition''. At the beginning of each run of the for loop, this condition is checked to determine if it is true or not. If the condition is true, we execute the stuff inside of the braces. If it is not, then we are done the loop.

The last part is the ''incrementor''. This is code that gets executed after every pass through the loop.

So it will run something like:
* take our variable i and set it to 0.
* Check if our variable i is less than the number of copies that we have to make
* if it is, then we will make a copy
* we will increment i by 1 and go back to step 2

You can have much more complex for loops than this, but this is the basic idea.

So that is our copier. Now to use our copier, we can add something like this to our code:
<source lang="php">
$copier = new CopierMultipleCopies();
$copier->copy();
$copier->copy();
$copier->setCopies( 10 );
$copier->copy();
</source>

So notice a couple of things:

First, as we made our copier more and more complex, we didn't have to duplicate code. That is, in our most complex copier, we didn't have to worry about creating code to make the actual copy. We just used the method that came with our original copier. Also, in our final copier we didn't have to re-implement the counter - we again just used the method that had already been defined to do this.

Second, our new copier can serve as a drop in replacement for our old copier. Yes, each copier was more advanced than the previous one, but it was still possible with the most advanced one to just create it and invoke the copy() method, and it would create a copy.

If I want to use the more advanced functionality, such as reading the counter or changing the number of copies to be made, I need to know about these features, but I can still ignorantly use the copier as if it was the original Copier. (i.e. the original Copier class had a certain interface that was standard.)

The advanced copiers added more features, but this was separate from the original interface. (just as a car with cruise control has the same basic interface as a car without cruise control, but to take advantage of the cruise control you need to know how to set it).

This idea is an important part of the design of Joomla!.

''**ianmac** put together this OOPs overview for the community; [http://forum.joomla.org/index.php/topic,200185.msg943596.html#msg943596 Post #1] and [http://forum.joomla.org/index.php/topic,200694.msg944114.html#msg944114 Post #2]''

[[Category:Development]]
[[Category:Tutorials]]

Security and Performance FAQs

2011-09-26T18:47:40Z

MTrapp82: None

{{RightTOC}}

= Getting Started =

==Is GNU and Open Source software worth the costs and risks?==

It's difficult, if not impossible, to argue against the value proposition of GNU and Open Source software, although [http://www.catb.org/~esr/halloween/ some have tried]. Due to zero licensing fees, lower administrative overhead, high-quality code, security releases that are distributed in minutes or hours rather than months or marketing cycles, and free online support from thousands of like-minded developers and users, GNU and Open Source offerings are often the best solution. The math is really quite compelling:

{| border="1"
! '''Applications''' !! '''Industry Leader''' !! align="right" | '''Cost'''
|-
| GNU/Linux
| Yes
| align="right" | 0
|-
| Apache Web Server
| Yes
| align="right" | 0
|-
| MySQL Relational Database
| Yes
| align="right" | 0
|-
| PHP Scripting Language
| Yes
| align="right" | 0
|-
| Joomla! Content Management System
| Yes
| align="right" | 0
|-
| Thousands of Joomla Extensions
| Varies
| align="right" | 0
|-
! '''Support''' !! '''Relative Quality''' !! align="right" | '''Cost'''
|-
| Joomla! Project Leadership Team
| High
| align="right" | 0
|-
| Joomla! Forge
| High
| align="right" | 0
|-
| Joomla! Online Forums
| High
| align="right" | 0
|-
| Joomla! Documentation
| Medium
| align="right" | 0
|-
| Thousands of Online Volunteers
| High
| align="right" | 0
|-
| Paid Professional Support
| Widely Available
| align="right" | 0
|-
! align="right" | '''Total''' !! &nbsp; !! align="right" | '''0'''
|}

==What is the Joomla! Administrator's Security Checklist?==

The [[Security Checklist 1 - Getting Started|Security Checklist]] is a concise selection of the best tips and tricks from the many contributors in the Joomla Security Forums. Review this list BEFORE you install Joomla for the first time.

==What are the top 10 stupidest Joomla! security tricks?==
A very good question, and sadly one that many did not ask in time. We proudly present the [[Top 10 Stupidest Administrator Tricks]].

==How do I choose a quality hosting provider?==

The following is a short list of security-related requirements. Depending on your specific needs, you may have many other security requirements such as shell access, cron access, SSL server, etc.

* '''Choose *NIX:''' Joomla! requires at least PHP and MySQL to run. Because Apache/PHP/MySQL run best on UNIX or GNU/LINUX servers, choose a host that offers these options.
* '''Use Secure FTP:''' Choose a host that requires SFTP (Secure FTP) for transferring files. This prevents others from snooping your user name and password from packets as they travel over the Internet.

* '''Set PHP register_globals OFF:''' The most security conscious hosts turn PHP's Register Globals directive OFF by default. The next best allow you to turn it off in local .htaccess or php.ini files. A host that requires you to run a site with Register Globals ON should be avoided. This is true for <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> any PHP enabled site, whether or not you are running Joomla!. There is a legitimate argument to be made by hosts for keeping Register Globals ON for PHP4 sites. This is that it would break too much legacy code. This argument should not be accepted for a PHP5 installation. Beginning with PHP5, the official PHP recommendation was to keep Register Globals is OFF. Note that beginning with PHP6, there will not even be a Register Globals setting, so don't get caught in a Register Globals backwater. Modify your code to work without Register Globals, and choose a host that encourages such practices.

* '''Stay up-to-date:''' Choose a host that stays up-to-date with the latest stable versions of core applications, including the operating system, database, and [http://www.php.net/ PHP].

* '''Avoid cheap shared servers:''' Be sure users on your shared server can't view each others files and databases, for example through shell accounts and cpanels.

* '''Proactive server management:''' Choose a host that provides real information about security compromises, rather than simply shutting your site down. Check their user forums for evidence of how they've responded to cracks in the past. A good host may for example, inform you immediately that a security breach has occurred and will quarantine the problem file for you, while leaving it there for further investigation. A poor host will shut your site down and provide very limited information on why. Watch out! All too many do this.

* '''Require raw log access:''' Be sure you have access to raw server logs. Reading these logs is a vital part of site security and recovery.

* '''Performance matters:''' Choose a host that limits the number of users per machine and the average CPU load per machine to some reasonable number (depending on hardware). Be sure they proactively move user sites as needed to balance load. Check the number of domains on a server using reverse IP lookup.

* '''Data center:''' Choose a host that manages it's own data center. Check the data center infrastructure, such as redundant Internet access, hot swappable backups, full daily backups, environment and access controls, emergency generators, etc.

* '''Know your neighbors:''' Check that your host is not at risk of having its IP addresses blocked because it hosts SPAM sites.

* '''Consider recommendations:''' Check this [http://forum.joomla.org/index.php/topic,6856.0.html list of recommended hosts].

* '''Grow with your site:''' As sites grow in complexity, resource requirements, and security requirements, they may need to be moved off of a shared server environment. At that point, good options include, 1) '''dedicated servers''' offer the best possible security and performance, but at the highest expense, 2) '''virtual servers''' offer almost all the advantages of a dedicated server, but the hardware and configuration cost is shared among multiple virtual servers.

==What are the best practices for site backups?==

: There are three traditional backup types--full, cumulative and differential.

'''Full Backups'''
: A complete backup of all associated files and database at a known point in time.

: Both of these are considered Incremental backups, they can be used independently of each other or in conjunction with each other but always relate back to a FULL backup.

'''Cumulative Backups'''
: This is a backup of the differences since the last FULL backup, so each cumulative backup gets bigger each cycle as it is also backing up data previously backup, since the last FULL backup.

'''Incremental Backups'''
: This is a backup of the changes since the previous backup of any type, i.e., full, cumulative, or incremental.

: If you site is not too large, then FULL backups are the way to go, once a week at least. If your content changes quite regularly or more importantly cannot be recreated or is too costly to recreate, once a night or more may be more effective.

: If time, server resources, or the rate of data change is too high to successfully obtain a FULL backup every night then the incremental backups are needed.

: If you choose to use a cumulative backup following a weekly full, the backups each night will run quicker than a full backup, however as the week progresses, each nightly cumulative backup will increase in size and time, due to not only backing up the changes since last night's backup, but it also backing up all changes each night and previous nights since the last full backup was made. The benefit of this type of backup, in conjunction with full backups is the speed of restoration. To restore, you now only need to recover the most recent full and cumulative backups to fully recover all information.

: If time or server resources are paramount or data change overwhelms cumulative backups, turn to differential backups, this style of backup when used in conjunction with a full backup will provide a very similar level of protection, but restoration will be slower. Differential backups will only backup changed data since the last backup of any type, not since the last full backup, as with a cumulative backup. Thus, when restoring data, you will need to recover the full backup, then each differential backup in turn (oldest first) in order to fully recover all information. This method also has the drawback of recovering any legitimately deleted files, potentially "over-filling" the file-system.

'''Data Protection Best Practice says'''

# You should be able to completely recover from a catastrophic failure from at least two previous full backups. Just in case the most recent full backup is damaged, lost, or corrupt.
# A good backup regime should contain at least one full backup within a chosen cycle, normally weekly.
# A good backup practice is to store backups away from the current data location, preferably off site.
# Dynamic data should be backed up ''offline'' or ''hot'' to avoid ''fuzzy'' backups (data is changing as you back it up, potentially leading to related information not being in sync when backed up.

: For the average Web site, a daily or weekly full backup of both site files and database records is normally more than enough. Keeping a number of backups for a period of time is always a good plan, maybe keep each weekly backup for one month. This allows you to recover an old site in the case of emergencies or if for some reason you have local backup file corruption.

: There are many PHP and Perl scripts on the Web that can be automated through CRONTAB and can either email (if small enough) or FTP the backup files to an off- or cross- server location. Remember that to some degree with Joomla! you already have an instant backup of the core files, if you haven't modified core, the Joomla! distribution files can be easily restored. Then you need only worry about backing up changed files and the database.

==Where can I learn about vulnerable extensions?==
* See the [http://docs.joomla.org/Vulnerable_Extensions_List Vulnerable Extensions List]

==Where can I learn more about file permissions?==

* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/113-joomla-and-unix-file-permissions-explanation.html Unix Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/112-joomla-and-windows-file-permissions-explanation.html Windows Permissions Primer]
* [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/111-permissions-under-phpsuexec.html Using phpSuExec]

==How do I setup a powerful password scheme?==

'''Overview'''

: Most users may not need more than 3 levels of passwords and webmasters no more than 5. Each level must be completely unrelated to the others in terms of which ids and passwords are used.

'''Directions'''

* '''Level 5 (Public)''' - is the password you use on public sites. It is not imperative that you use a different password on every site. In fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

* '''Level 4 (Webmaster)''' - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a separate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

* '''Level 3 (Webmaster)''' - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

* '''Level 2 (Personal Data Access)''' - This password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

* '''Level 1 (Banking!)''' - this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

= Joomla! Core =

==How can I check my Joomla! installation's overall security and health?==

: 1. Use the free Joomla extension, Joomla! Tools Suite (JTS), which is a Joomla! environment audit, maintenance and diagnostic application written in PHP. The JTS suite of tools can diagnose, report and advise on common installation, health and security issues, including performing several common performance and recovery actions.

: Project Home: http://joomlacode.org/gf/project/jts/

==How can I add the Joomla! Security Announcements Feed to the Admin Control Panel?==

# Login to your Joomla! sites Administration site
# From the menu, select Extensions -> Module Manager
# From within the Module Manager, select Administrator
# From the Icon Menu (top right), select New
# From the choices available, select Feeds Display
# At the Feed Module configuration page, enter the appropriate details (Title (EG: Security Announcements) and Feed as a minimum)
# Enter http://feeds.joomla.org/JoomlaSecurityNews in the Feed URL
# Select cpanel as the position
# Optional Select Apply from the Icon Menu (top right) and place the feed in the order where you want to see it in the Admin Control Panel
# Select Save from the Icon Menu (top right)
# Go back to your Admin Site main page (Site -> Control Panel) and you should see your newly built Security Feed.

: You can also use this technique to deliver your own "Customer Updates" to sites that you build for others. It's a great way to communicate with your customers after handing over the site to them. Every time they log in to the Back End, they'll see your latest news.

==Why should I immediately change the name of the default admin user after a new install?==

'''Overview'''

: All new Joomla installations start with a Super Administrator account called, 'admin'. During the installation process, you will be asked to give this account a password. That's great as far as it goes, but because the user name of this highly-confidential account is generally well known, 50% of the security of the username/password combination is already exposed. Now all anyone needs to do is guess the password and they're in.

: By changing the user name to something more difficult to guess, you greatly increase the difficulty of accessing the account. An attacker must correctly guess both the user name and password at the same time to gain access. This is several magnitudes more difficult than simply guessing the right password.

'''Directions'''

# Log into the Back End
# Select User Manager
# Select the 'admin' user record
# Change the value in username. (Good user names contain a mix of letters and numbers.)
# Save
# Remember the new username!

== Why does the Back-End session stay alive even though I set it to expire? ==

: When you edit an item from the Back-End, there is a keep-alive script running that keeps the session active. This is a great convenience in most cases, as it prevents you from losing all your edits if you wait too long to submit the content. However, there are a few potential security issues to be aware of:

# If you walk away from your computer while you are editing content, someone else can use your computer to attack the site.
# Due to the risk of Cross-Site Request Forgery attacks ([http://en.wikipedia.org/wiki/Cross-site_request_forgery CSRF]) it's never a good idea to browse the Internet in another window or tab while an open Joomla! Administrator session is active. Joomla! has been hardened against such attacks, but it's remotely possible that an as yet unknown vulnerability exists in the Joomla! core, a third-party extension, or the browser itself.

==How do I turn off RG_EMULATION? {{JVer|1.0}}==

'''Overview'''

: PHP's ''register_globals'' option was a terrible idea from a security point of view. It encouraged lazy programming and exposed many scripts to needless risk. This is because RG allows variables passed by the user to be automatically passed to the script. This breaks a cardinal rule: Never trust user input.

: Register Globals has been officially deprecated in PHP5, and beginning with PHP6 will no longer even exist. Good riddance!

: Joomla 1.0.x uses RG_Emulation functions which are somewhat safer than standard PHP ''register_globals'', but it's still best not to allow any form of automatic variable assignments. Note that poorly-written extensions may fail with ''register_globals'' turned off. Such failure is a sign that the extension does not check user input correctly. Best advise: Don't use such extensions.

'''Joomla! 1.0.13'''

: Beginning with the 1.0.13 release, Register Globals Emulation has been moved to the main configuration file and can be adjusting in the Back-end Administrator interface.

'''Joomla! 1.0.12 and earlier'''

: Edit the file, ''globals.php'', found in the root directory of your Joomla! site. At about line 23 change:

define('RG_EMULATION',1)

: to

define('RG_EMULATION',0)

==What do Error 1, Error 2, and Error 3 mean?==

'''Error 1 = FATAL ERROR: MySQL not supported...'''

You need to compile MySQL support into PHP or the MySQL server is down.

'''Error 2 = FATAL ERROR: Connection to database ...'''

Joomla! cannot talk to the database, most likly you have a typo in the username or password settings in ''configuration.php'', or you are trying to access a database table with the wrong table prefix.

'''Error 3 = FATAL ERROR: Database not found...'''

The database cannot be found. Check the database settings in ''configuration.php''

The MySQL variables in ''configuration.php'' (found in Joomla!'s root directory) can be modified to correct these problems.

For Joomla! 1.0.xx
$mosConfig_host = 'localhost';
$mosConfig_user = 'accountname__username';
$mosConfig_password = 'userpassword';
$mosConfig_db = 'accountname_dbName';
$mosConfig_dbprefix = 'jos_';

Modifying the ''$mosConfig_host'' to an IP Address of a remote host works for hosts that have separate MySQL servers from the client hosting servers.

==How do UNIX file permissions work?==

Unix/Linux file permissions can be confusing. The basic UNIX permissions come in three flavors;

Owner Permissions : Control your own access to files.
Group Permissions : Control access for you and anyone in your group.
Other Permissions : Control access for all others.

In Unix, when permissions are configured the server allows you to define different permissions for each of these three categories of users. In a Web server environment permissions are used to control which Web site owners can access which directories and files.

'''What do Unix permissions look like?'''

When viewing your files through an FTP client or from the servers command line;

filename.php username usergroup rwx r-x r-x

The first entry is the name of the file, the next entry is your username on the server, the second entry is the group that you are a member of and the last entry is the permissions assigned to that this file (or directory). If you notice, I have intentionally spaced out the permissions section, I have grouped the 9 characters into 3 sets of 3. This separation is key to how the permissions system works. The first set of 3 permissions (rwx) relate to the username seen above, the second set of 3 permissions (r-x) relate to the usergroup seen above and the final set of 3 permissions (r-x) relate to anyone else who is not associated with the username or groupname.

'''Owner (User) relates to username'''

The Owner (User) is normally you, these permissions will be enforced on your hosting account name.

'''Group relates to usergroup'''

The Group permissions will be enforced on other people that are in the same group as you, within a hosting environment, there is very rarely other people in the same group as you. This protects your files and directories from being made available to anybody else who may also have a hosting account on the same server as you.

'''Other relates to everyone else'''

The Other permissions, these will be enforced on anybody else on the server that is either not you or not in your group. So in a Web Serving environment, remembering that no-one else is normally in your group, then this is everybody else accessing the server except for you. Each of the three sets of permissions are defined in the following manner;

r = Read permissions
w = Write permissions
x = Execute permissions

Owner Group Other
r w x r w x r w x

As many of you already know, permissions are normally expressed as a numeric value, something like 755 or 644. so, how does this relate to what we have discussed above? Each character of the permissions are assigned a numeric value, this is assigned in each set of three, so we only need to use three values and reuse them for each set.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Now that we have a value that represents each permission, we can express them in numeric terms. The values are simply added together in the respective sets of 3, which will in turn give us just three numbers that will tell us what permissions are being set. If we are told that a file has the permissions of 777, this would mean that the following was true.

Owner Group Other
r w x r w x r w x
4 2 1 4 2 1 4 2 1

Thus...

4+2+1 4+2+1 4+2+1
= 7 7 7

The Owner of the file would have full Read, Write and Execute permissions, the group would also have full Read, Write and Execute permissions, and the rest of the world can also Read, Write and Execute the file. The standard, default permissions that get assigned to files and directories by the server are normally;

Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories;

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

Now, things can get a little complicated when we start talking about shared Web Servers, the Web Server software will be running with its own username and groupname, most servers are configured for them to use either "apache" and "apache" or "nobody" and "nobody" as username and groupname. Here is the problem. Your Web Server runs as its own user, and this user is not you or in your group, so the first two sets of permissions do not apply to it. Only the world (other) permissions apply. Therefore, if you configure a permissions set similar to 640 on your website files, your Web Server will not be able to run your website files.

640 = rw- r-- ---
Owner has Read and Write
Group has Read only
Other has no rights

The Web server is assigned no permissions at all and cannot Execute, Write or more importantly, even Read the file to delivery its content to a website visitors browser. If a directory was to be assigned 750 permissions, this would have the same effect, because the WebServer does not even have permissions to read files in the directory, even if the files inside that directory had favorable permissions.

750 = rw- r-x ---
Owner has Read and Write
Group has Read and Execute
Other has no rights

Directories have an extra quirk, if a directory does not have the Execute permission set in the World set then even if Read and Write are set, if the program is not run as the user or group, it will still not be able to access the files within the directory. The Execute setting allows the program to "Execute" commands in the directory, so without it being on the program(in our case a Web Server) cannot execute the "Read" command, thus cannot deliver your file to the users web browser.

'''How Does this Relate to Joomla?'''

Good question, well in the first instance this would be important during the Web-Installer process.
If you can remember back to when you ran the Joomla! Web-Installer, we were looking for specific directories to be designated as writable. We see quite a numbers of posts either stating that there were problems during the install with permissions or asking what permissions are recommended. Some even consider the message, asking for "Writable" permissions to be too vague.

Unfortunately, as the Web-Installer does not know how your server is configured, then it cannot be more specific, however, once you understand the permissions settings and you know a little about Web Serving environments, you will actually find that the term ''writable'' is actually very specific and a more than adequate description of what Joomla! needs. Thinking back to the above information, you may remember that there are three places where ''write'' permissions maybe set;

Owner Writable
Group Writable
Other Writable

Also remembering that the Web Server generally doesn't run as your own user or in the same group. When you run the Web Installer from a browser, it is the Web Server trying to access the files, thus it is the "Other" permissions that will apply to it. If the "Other" permissions do not allow the Web Server to Read, Write or Execute commands in the Joomla! directories, you will receive the message saying that the directories are not ''writable''.

In this case, you will need to configure the Other permissions to be "7" on the directories listed in the Web Installer.
So your total permissions might be something like 757, in the worse case you might need to set 777. These very open permissions
maybe reset back to 755 after the installer runs to assist in the security of your directories and files.

757 = rwx r-x rwx
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read, Write and Execute

Just to make things even more confusing, many hosting firms make use of software called phpsuExec or suExec, these tools change the way the Web Server runs, where the Web Server would not normally run as your username, in this case, it does. The use of the ''other'' permissions, may not be required, now you may only need to configure directories to be ''writable'' to your own username and groupname, this allows directory permissions to be set as 755 or 775 instead of 757 or 777.

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute
Other has Read and Execute

775 = rwx rwx r-x
Owner has Read, Write and Execute
Group has Read, Write and Execute
Other has Read and Execute

The Web Server will still need to Execute set for the username and Read, Execute groupname permissions set so that it can Execute the Read command on files inside the directory. Again, these permissions may be demoted back to 755 after the Web Installer completes. Thats the basics for directories covered, what about files? This is where things get a little simpler. Most of the files that Joomla! makes use of will be quite happy with the 644 default permissions.

644 = rw- r-- r--
Owner has Read, Write
Group has Read
Other has Read

This is valid if you do not have a need to Write to the files from the Web Server, the same rules apply as for directories if you do have this need. One file that you may like to have "Writable" to the Web Server is your configuration.php file. This is the Joomla! configuration file, if you plan on changing configuration through the Web Admin interface, then this file will need to be Writable to the Web Server.

If your server needed directory permissions to be set to "Other" Writable for the install then this file will probably also need to be 757 or 777. Leaving this file as 757 or 777 is dangerous though, as you are letting everyone have "Write" access, many Web Site exploits take advantage of this fact, so in general it is not recommended to leave this file with these permissions.

If your Web Server has one of the SU tools installed and you only needed to configure 755 on directories for the installation, then you will probably also only need to set 755 or 775 on this file to allow editing through the Admin interface, and these permissions are generally accepted as more secure than 757 or 777.

In conclusion, what permissions should be set for the Joomla! installation? Well, as you can see, it depends!

I know this isn't as helpful as you would have liked and it certainly is not a definitive answer, but in general, after the installation, any insecure "7" settings can be reset back to something more secure. For example:
Files = 644
Directories = 755

These permissions would allow, for files;

644 = rw- r-- r--
Owner has Read and Write
Group has Read only
Other has Read only

and for directories,

755 = rwx r-x r-x
Owner has Read, Write and Execute
Group has Read and Execute only
Other has Read and Execute only

If you have SSH shell access the following commands can be run from the command line to reset all files and directories back to the server defaults of 755 and 644. Change directories to the top directory (" / ") of your Joomla! installation, then run:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

If you only have FTP access, this can be a very time consuming job, however, unless you changed more directories during the installation that was requested, you should only need to reset about 10 directories and the ''configuration.php'' file.

Keep in mind that to install any extensions or templates after the actual Joomla! installation you may need to elevate the default permissions again on the appropriate directories just for the installation period, you may then demote them again after the add-on is installed.

If you decide to use ''caching'' the cache directory will need to be ''writable'' by the Web server user to allow it to write its temporary files.

==What are the recommended file and directory permissions?==

Depending on the security configuration of your Web server the recommended default permissions of 755 for directories and 644 for files should be reasonably secure.

==How can I avoid using chmod 0777 to enable installs?==

On a private server with a small, controlled set of users, there is no need to use a chmod 777 to make the Joomla! folders writable in order to perform installs. You can set the server up so that both Apache and FTP have control of site files.

'''Directions'''

# Edit the Apache user.conf file and tell apache to run under the FTP account.
# chmod the entire site to 644 or 744. Apache should be able to run just fine that way.

'''Optional'''

# chgrp the entire web space to the FTP group so that only those with FTP access can write to the server.
# chmod the entire web space to 764 or 664 will be possible giving other users write access as well

==Isn't locating all Joomla! files inside public_html a security risk?==

'''Short answer'''

Potentially, yes. Your site can be secure, but you must be careful and vigilant.

'''Long answer'''

A common security principle is to create various security levels and then grant access at each level only as required. On UNIX servers this is done by setting the user, group, and world permissions on directories and files.

Typically, the most insecure directory on a UNIX server is the one serving Web files, usually called public_html. This is because it is publicly accessible, world-readable, and in the case of a CMS-powered site, possibly even world-writable. That status is the very definition of officially, totally, and utterly insecure.

As long as you want the entire world to view your public_html directory there is no problem. After all, that's exactly what it's designed to do. But if you want to hide anything, the plot thickens. If public_html contains configuration files with secret data, or scripts that write to databases, or scripts that modify other files, or scripts that append to logs, or scripts that store temporary data in caches, or scripts that support file and graphic uploads, or scripts that process form input, or scripts that process financial and personal data, this read-only directory becomes a world-accessible, read-write application.

If there are ANY vulnerabilities in ANY files in the public_html directory, the entire server is potentially vulnerable, and not just your Web site but possibly every Web site on your server. Such vulnerabilities give attackers access to the scripting engines used to run your site. PHP, Perl and other Web scripting languages are powerful and easy to use. If programming vulnerabilities allow an attacker to call arbitrary commands, your entire server could be toast.

One good way to block attackers, is to keep potential vulnerabilities behind a secure fence. For this reason, it is often recommended to only place files that require direct access from the Web in public_html. Other files should be loaded into applications using such functions as include and require. To access such files, attackers must first penetrate your server, such as by discovering a root username/password.

'''The incredible lightness of living outside the fence'''

To provide incredibly easy installation, Joomla! follows a different security model. It is possible to perform a complete Joomla! installation using nothing more than a Web browser pointed at the world-readable installation directory. An additional level of security is provided by requiring that you remove this installation directory after completing the install.

Granting a world-accessible installer the ability to write to files outside of public_html would be a huge security hole. Thus, by default every Joomla! file ends up in the world-accessible public_html directory. Not coincidentally, this is also the directory in which an angry planetful of would-be attackers are hoping to find your files.

Currently, most Joomla extensions also have limited support for file locations outside of public_html. This is a legacy of the Joomla! 1.0.x installation model.

'''Joomla! defense'''

Despite it's apparently vulnerable location, Joomla! uses various effective methods for blocking exploits. Chief among them is to add a line of code at the top of any PHP file that requires extra protection. This method is very effective as long as each and every file requiring such protection, has it. One vulnerable file exposes the whole site.

'''The challenge'''

The practice of placing everything in public_html, and then building a little fence inside each file can become an administrative nightmare. One vulnerable file exposes the entire server. This is a glaring example of an allow, then deny security model.

This model requires very careful upgrades, constant log reviews, and proactive plugging of new vulnerabilities as soon as they become known. (Since you have to beat the attackers, you'll be in a hurry, and may inadvertently do something stupid, potentially creating other vulnerabilities.)

During installations and upgrades, you must verify (or trust someone else to verify) every line of code, of every new file, for every known vulnerability. And because scripts can have unintended consequences on each other, you cannot forget to test, test, test. Of course this is generally true for all software, but placing the entire application in public_html makes the issue extremely critical.

The recent wave of URL injection attacks against poorly-written third party extensions would have been much less successful if those files had been stored outside of public_html, and thus simply unavailable through URLs. Note that in many cases the actual vulnerabilities could still exist within the files, but being inside the fence (outside of public_html) they would not be exposed to URL injections.

To (Deny, then Allow), or (Allow, then Deny)?

The real problem with the above "all known" qualifier is that it is an allow, then deny model. In other words, we first give everyone access to every file and then deny access to specific files by adding a line of code.

Consider the logic for a password authentication script. We have essentially two choices:
# First allow all access, then deny any username/password combination that DOES NOT match the approved list.
# First deny all access, then allow any username/password combination that DOES match the approved list.

Obviously the second method is better. A passing familiarity with regular expressions shows that the first method is much more difficult to write securely. It fails anew each time a new variation of some attack is developed, and tends to require constant revisions. Over time, such revisions become so complex that the authentication system itself becomes a source of vulnerabilities.

Conceptually, the second method is an example of building a strong fence around your site (deny), and then granting access using a limited and well-defined set of criteria (then allow). If the script fails, the most likely result is that someone who should have access is blocked. That may be highly inconvenient, but it's not usually a security breach.

'''The good news'''

# In Joomla! 1.0.x, some extensions, and the Joomla! framework, give you the option of locating critical directories outside of public_html after you have completed the installation. Whenever possible you should do this.
# Joomla! 1.5 goes far in the right direction. It provides several new constants for specifying the location of particularly sensitive directories, including configuration, administrator, libraries, and installation.
# Joomla! 1.5 is able to run as an FTP account. This provides another method for protecting files on a file by file and directory by directory basis.

==How do I adjust Joomla 1.5 defines {{JVer|1.5}}==

There are two defines files that will generally need to be edited. /includes/defines.php file is for the front end and /administrator/includes/defines.php is for the Joomla administrator end. Below is the relevant code.

define( 'JPATH_ROOT' , implode( DS, $parts ) );
define( 'JPATH_SITE' , JPATH_ROOT );
define( 'JPATH_CONFIGURATION', JPATH_ROOT );
define( 'JPATH_ADMINISTRATOR', JPATH_ROOT . DS . 'administrator' );
define( 'JPATH_LIBRARIES' , JPATH_ROOT . DS . 'libraries' );
define( 'JPATH_INSTALLATION' , JPATH_ROOT . DS . 'installation' );

.DS. = Directory Seperator

==Moving sensitive files outside the web root==
{{:Moving sensitive files outside the web root}}

==How do I block direct access to critical files using .htaccess?==
# Make a backup copy of your .htaccess file. Use your backup file to recover if the following fails. Be sure to delete the backup file once you are finished.
# Add the following to your .htaccess file. This example will protect both the configurtation.php and .htaccess files.

<Files .htaccess>
order allow,deny
deny from all
</Files>

<FilesMatch "configuration.php">
Order allow,deny
Deny from all
</FilesMatch>

You can also protect a lot of file extensions in one single rule. Exemple (the file names between ' '''(''' ' and ' ''')''' ' in this rule are the file extensions to protect ):

<FilesMatch "\.(htaccess|htpasswd|ini|phps|log|sh|conf)$">
Order allow,deny
Deny from all
</FilesMatch>

==How do I recursively adjust file and directory permissions?==

'''Using Joomla! Administration'''

In the Back-end, go to Site --> Global Configuration --> Server.

'''Using the UNIX shell'''

'''Note:''' The find command automatically assumes that it should start from the current directory. To be safe, go to your public_html directory and specify a path as the first argument. Some shells, such as bash on Apple OS X, must have a path specified in the find command.

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 707 images
chmod 707 images/stories
chown apache:apache cache

'''Notes:'''
# Test all third party extensions after changing permissions.
# You may need to reset write permissions to install more extensions.

==How can I set the administrator directory to use an SSL server (https)? {{JVer|1.0}}==

Use Joomla version 1.5 or newer

A standard Joomla! 1.0.x installation does not support SSL for individual directories, however there are various (elegant and not so elegant) hacks posted in the forums.

Note that earlier techniques involving the variable $mosConfig_live_site are deprecated, and will not work with current Joomla! versions due to increased security enhancements.

'''More Help'''
# [http://www.netshinesoftware.com/security/using-an-ssl-certificate-with-your-joomla-website.html Netshine Software, Ltd: Using an SSL Certificate with your Joomla Website]

==Why isn't restricting access by IP recommended?==

Restricting site access by IP address is not particularly effective longterm as many exploits are enacted from hijacked machines or via proxies, masking the real attacker's actual IP Address. Attackers can attack from many different compromised machines. Blocking them will block the legitimate owners of that IP, but may not block the attackers.

= Joomla! Extensions =

==Why are there vulnerable extensions?==

A list of currently known [http://docs.joomla.org/Vulnerable_Extensions_List vulnerable extensions].

: Anyone may write and distribute a Joomla! extension. As a service to the global community, this freedom is actively encouraged and supported by the Joomla! Core team. Due to the openness and popularity of the Joomla! project, there are a wide variety of extensions offering a vast array of features. The quality and breadth of Joomla! extensions is one of the main advantages of Joomla.

: However this freedom comes with a price. It requires individual responsibility, and can survive only where a majority of participants act responsibly. Joomla's success has led to unwanted attention from malicious types, such as script kiddies who run simple, automated scripts in an effort to find and deface others' Web sites.

: It is important to note that, script kiddies unintentionally perform a valuable service. They help us identify vulnerable extensions and poorly configured servers that might otherwise remain open to more serious threats.

==What is a vulnerable extension?==

A vulnerable extension is one that has been found to contain (or contribute to) a security vulnerability.

Vulnerable extensions are not necessarily poorly-coded. As the Web evolves, technical requirements and commonly accepted coding practices change. Active projects release new versions of their extensions as requirements change. For this reason, it is important to:

# Know the version numbers of all installed extensions.
# Use only the latest stable version of all extensions.
# Completely remove all files of insecure or unused extensions.

==How do I choose secure extensions?==

: The most important thing anyone can do is make good decisions regarding the extensions they choose to use on a site. Once an insecure or malicious extension is installed you should consider your entire site compromised. There is NO POSSIBLE WAY to protect or stop a component from accessing database tables it should not be accessing. There is no possible way to stop a component from sending all of the information it found back to a cracker website. Once an insecure or malicious component is installed, your entire site is insecure.

: With all of that said, here are some pretty easy tips for making good choices regarding the extensions you install:

1. When was the last version released?

: If it has been over a year, consider the project abandoned and find something else. Do not install old components.

2. What kind of release is it? (Stable, Release Candidate (RC), Beta, Alpha)

: For production sites you should be sticking to Stable releases as much as possible. If you cannot wait until a Stable release has been made available, Release Candidates are the only other option you should consider. I would not suggest anyone install any Beta or Alpha extensions on a production site. This means they still have bugs, they have not been tested enough, and could have any number of inconvenient bugs or security issues that have not been fixed or worse, found.

3. Does the extension have a history of good security practices?

: This is obviously a bit more subjective but it is still a very valid gauge of future trustworthiness. It requires a bit of investigation and research. Look around their download pages and archives, are there many security release or patches? Are there a lot of reports of cracking activity through this extension? Are the developers experienced and security conscious? What do other community members think of this extension? One example that comes to mind that has little to do with Joomla itself (which makes it a fair example) is phpBB. This script has had more security issues than I could get my head around and there routinely seems to be newly disclosed issues. Because of this, I would never use phpBB. In my opinion its is not trustworthy and there is a high probability that there will be more major security issues.

4. Is there a support community for this extension?

: This is very important for usability and security awareness. If there is a support community for an extension there is a better chance of security issues being known and dealt with. A support community means that people would like to continue using the extension and that they care about the extension. This furthers the chance that security issues will be found, disclosed, and dealt with promptly.

5. Is there only a Mambo version of this extension?

: While this does not in itself make an extension insecure but is rather a gauge of support, how recently the last realease was, and future support. There is a pretty narrow chance that Mambo components will be supported in 1.5 so save yourself the trouble and find a component made to work with Joomla. It will make your life easier.

6. Is the extension generally bug free?

: I hinted on this a little bit in number three but I think it is worth discussing in more depth. While it is almost impossible for an extension to be completely bug free, the smaller the number of bugs, the better. If there are bugs in the software it means there are mistakes in the software. The more mistakes, the higher risk of usability issues and security issues. Security issues are often a result of not one bug, but several bugs or bad practices. For example, the recent 3rd party vulnerabilities that allow for remote file inclusion are a result of:

'''Bad Practices:'''

# Having PHP's Register Globals enabled.
# Using out of date or abandoned extension.
# No other security checks enabled for PHP. (url_fopen off, open_basedir restrictions, disabled PHP functions)
# Poorly configured file permissions.
# No request filtering or software "firewall". (such as mod_rewrite rules or mod_security Apache modules)

'''Bugs:'''

# Not including defined('_VALID_MOS') or die... statements
# Poorly constructed include() statements.

'''Although the Joomla! core is secure when configured correctly, third party extensions come in all flavors of age and quality. Unless you absolutely trust the extension developer, always review the code should before installing. The following is a list of typical areas of concern.'''

1. How complex is the extension?

: The larger it is, the more likely it is to have problems, and the more carefully you should review it. If you can't tell what it's doing, you should not trust it.

2. Does the extension read or write files to your server?

: Programs that read files may inadvertently violate access restrictions you've set up, or pass sensitive system information to crackers. Programs that write files have the potential to modify or damage existing files, or introduce trojan horses.

3. Does the extension interact with other programs on your system?

: For example, many extensions send e-mail in response to a form input by opening a connection with the sendmail program. Is it doing this in a safe way?

4. Does the extension run with suid (set-user-id) privileges?

: In general this is very dangerous; extensions need an excellent reasons for doing this.

5. Does the extension validate all user input, such as in form fields and in the URL?

6. Does the extension use explicit path names when invoking external programs?

: Relying on the PATH environment variable to resolve partial path names is a dangerous practice.

7. Is the extension secure against direct access throught the URL?

: For example: www.yoursite.com/components/com_bad_extension.php?lots_of_bad_code_here

8. Is the extension secure against remote file inclusions?

9. Is the extension secure against SQL injections?

10. Is the extension secure against Cross Site Scripting (XSS)?

11. Does the extension need PHP register_globals ON, or Joomla! RG Emulation ON?

: If so, then it is probably violating number 7 above.

12. Does the extension provide higher database access to less privileged users?

: For example does it allow guests or registered users to view data that only publishers or administrators should be able to see?

==Why does the Extensions site include insecure extensions?==
'''
Overview'''

The Joomla! Extensions site exists as a free service to the community. Anyone can post extensions there and extensions exist at all levels of quality and maturity.

If an extension is found to contain vulnerabilities, it will be removed from the site until a safer version is released, but there is no guarantee that the vulnerabilities of every extension have been discovered or reported.

To be safe, you must verify the security of every extension you install.

Below is the text of the Joomla! Extensions site disclaimer. Ignore it at your peril.

'''Disclaimer'''

: The extensions and reviews listed in this area have been submitted by the community and their listing does not constitute or imply endorsement, recommendation, or favouring by Joomla!/OSM.

: This content is provided as a free service to our visitors, and, as such, Joomla!/OSM cannot be held liable for the accuracy of the information. Visitors wishing to verify that the information is correct should contact the parties responsible for authoring the content and/or development of the extension.

==Why is there a warning in the extensions install screen?==

It's just a warning! You are of course free to install any extension you want onto your own site, but remember that '''YOU''' are responsible for the safety of your site and the quality of the applications you install.

The vast majority of reported Joomla! vulnerabilities are through poorly-written or obsolete versions of third party extensions that should not have been left on the server. Therefore, before installing anything carefully evaluate the quality of the extension's code.

The [[Vulnerable Extensions List]] is a valuable source of information on what '''NOT''' to install.

==Why isn't un-publishing a vulnerable extension enough to protect my site?==

'''Overview'''

: Simply removing the menu links to an extension, or unpublishing a module is NOT enough to protect your site! As long as the extension's files exist on your server, you are vulnerable. Note how in the following examples an attacker can bypass the Joomla! index file to directly target any file, of any extension.

www.your_site.org/components/com_bad_component/vulnerable_file.php
www.your_site.org/modules/mod_bad_module/vulnerable_file.php

'''Directions for removing a vulnerable extension'''

1. Make a list of files to remove

: If you can locate it, read the extension's xml file to determine exactly which directories, files, and database tables were added to your system. The xml file is in the original zip archive used during the extension install process. For example, the zip archive for an extension called mod_vulnerable, would contain an xml file called, mod_vulnerable.xml, and might contain a list of files such as the following:

mod_vulnerable.php
mod_vulnerable/vulnerable_file.txt
mod_vulnerable/another_vulnerable_file.txt
mod_vulnerable/yet_another_vulnerable_file.txt
mod_vulnerable/index.html

2. Uninstall via the Joomla Installer:

: Using the Installer in the Joomla! Administrator backend, uninstall the vulnerable extension. You may also need to uninstall related modules, components, or plugins.

3. Check that the uninstall process was complete:

: Don't trust the extension to safely remove all of it's files. Compare directories and files on your system to the extension's xml list to ensure that all related files were actually removed.

4. Optionally, remove related database tables:

: Check your database and remove any tables created by the extension. To ease the upgrade process to new versions, many uninstall scripts do not remove related database tables. You can find the list of tables in each extension's xml file. (If you plan on installing a safer, compatible version of the same extension and you want to reuse existing data, you can usually leave the database tables as they are.)

= Apache =
'''Covers information on Apache Web server, Apache modules, .htaccess files, etc.'''

==What is Apache modSecurity?==

'''Overview'''

ModSecurity is an Apache module that functions as an embeddable web application firewall. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with no changes to existing infrastructure. It is also an open source project that aims to make web application firewall technology available to everyone.

When configuring ModSecurity, it is important to know that it is not only the Joomla! application that may require unique rules, but also the data that the application processes.

Quality hosting providers customize mod_security rules to suit each customer.

If you have a conflict between Joomla and ModSecurity, it is often third party components, and sometimes even contact form submissions that trigger the problem. Joomla out of the box ''usually'' works with typical ModSecurity settings, but this is dependent on each hosting provider's unique configuration.

Overall, mod_security is a excellent tool, but this is really something your host should manage.

One specific error is the failure of file uploads, this is often caused by SecFilterScanPOST being enabled. If you get an internal server error while using the flash upload in the Media Manager this is a good place to start. You can disable this setting by adding '''SecFilterScanPOST Off''' to your .htaccess file.

ModSecurity configurations are far too varied and complex to describe here. To learn more, see the following resources:

'''Resources'''

# [http://www.modsecurity.org/ Official ModSecurity Site]
# [http://www.modsecurity.org/projects/modsecurity/apache/index.html ModSecurity and Apache]

== How do I block directory scans using .htaccess? ==

'''Directions'''

Add one of the following Apache rewrite rules to your .htaccess file. The first example will internally rewrite all attempts to access files with names starting with "phpMyAdmin" to index.php. Be wary of using this as it allows a seemingly valid duplicate URL for your homepage. The second rule is more safe. It simply returns a 403 response.

'''Sample Apache Rewrite Rule'''

RewriteRule ^phpMyAdmin /index.php [L]
RewriteRule ^phpMyAdmin - [F]

'''Some Regular Expression Tips'''

^ Means start of pattern
. Means any character other than newlines
+ Means one or more of the previous character
* Means zero or more of the previous character
$ Means end of pattern
\. Literal periods must be escaped with a leading \

==How can I change PHP settings using .htaccess? ==

'''Introduction'''

This FAQ explains how to set boolean PHP configuration directives using php_flag. The format for php_flag is: php_flag name on|off

'''Directions'''

1. Open the .htaccess file located in your site's home directory, or if you don't have one, create a blank one now. Note the period character (.) at the beginning of the file name.

2. Add any of the following code samples to your .htaccess file, each on it's own line. These sample commands will prevent common global variable injection attacks, cross site scripting (XSS) sttacks, and code injection attacks.

php_flag register_globals off

php_flag allow_url_fopen off

php_flag magic_quotes_gpc on

''Note that although the magic_quotes_gpc directive adds a layer of security, for performance reasons it is not considered a best practice. If you have verified that your site correctly filters and validates all user data (and every production site really should), then there is no need to add this directive. If you have any doubt, add it.''

3. Save the .htaccess file in your site's home directory.

4. Test your site's front end and back end.

==How does FastCGI effect Joomla?==

When PHP runs from FastCGI, your server runs the PHP interpreter like an Apache module, but with the rights of your user account. Usually, the PHP interpreter is either running as the user of the webserver (which is fast, but insecure, since everyone's scripts run with the same rights), or as a CGI program, which is slow. Thus, FastCGI is a good solution for shared hosting.

Since the PHP interpreter runs as a single instance, it does (AFAIK) not parse the .htaccess or php.ini files per directory. To change php.ini settings, your host must offer you a method to set up or modify your own php.ini, or at least parts of it. Here is how one of host does this: it parses one php.ini file (which the user can modify) once an hour, and puts some well-defined settings into the web server's main php.ini file. Thus, users are able to change some settings for their site only, such as turning register_globals off, switching between PHP4 and PHP5.

If your server uses FastCGI, you can ask them to enable a method such as the above example, or you may be able to ask them adjust some settings for you.

==How can I check if mod_rewrite is enabled?==

Many problems with search engine optimization (SEO) arise from the fact that a host has not enabled mod_rewrite on the server.

1. Enable SEO in your administrator! (administrator > SEO > Enable > Save)

2. Rename your htaccess.txt to .htaccess, or use your existing .htaccess file.

3. Place ONLY the following lines in your .htaccess file in the domain root folder.

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^joomla\.html http://www.joomla.org/ [R=301,L]</source>

4. Point your browser to: http://www.example.com/joomla.html

(Replace 'example.com' with your site's actual URL.)

5. If you are redirected to www.joomla.org, mod_rewrite is working. If you get an error, mod_rewrite is not working.

6. Note: if your site is located in a folder, for example "test" you will need to modify the .htaccess file as follows:

<source lang="apache"> Options +FollowSymLinks
RewriteEngine On
RewriteRule ^test/joomla\.html http://www.joomla.org/ [R=301,L]</source>

== How do I switch to PHP5 using .htaccess? ==

'''Overview'''

Many shared server environments currently run .php scripts using the PHP4 interpreter and .php5 code using the PHP5 interpreter. Rather than changing all your file extensions, and perhaps breaking many links, use a .htaccess file to dynamically map one extension to the other.

'''IMPORTANT CAVEAT:''' One common reason for doing this is that hosts leave PHP4 configured with register_globals ON in order to support legacy code while offering PHP5 with register_globals OFF. If you are on a shared server at a host that has configured register_globals ON server wide, you should be very worried!

Turning register globals OFF via a local php.ini or a .htaccess file will NOT offer you any extra protection. Another exploited account on your server can simple hack yours. For server security, and since php 4.2, register globals is OFF server wide by default (php default). Any host overriding this is inviting trouble. If you need register globals ON for a specific site, simple use a .htaccess file for that specific directory, and server wide security will not be compromised. Of course, if you do this be sure all effected scripts fully sanitize input data.

'''Requirements'''

1. Your Apache server must be configured to use .htaccess files. If not, you may be able to request this from your host.
2. Your Apache configuration must allow the following setting. If not, you may be able to request this from your host.
3. Your host must have configured the .php and .php5 file extensions as described above. If not, they may possibly have chosen other extensions. Check with your host.

'''Directions'''

1. Check to be sure your site is configured to use .htaccess files.

2. Make a backup of the .htaccess file in your root public_http directory. If you don't have a .htaccess file at this location, create one now.

3. There are various ways to set the comman, depending on your server configuration. One of the following will probably work. Add ONE the following lines at the end of your .htaccess file. If unsure which to use, check with your hosting provider on which version works best for your configuration.

AddType x-mapp-php5 .php
AddHandler application/x-httpd-php5 .php
AddHandler cgi-php5 .php

4. Carefully test.

5. Delete the backup .htaccess file. Don't leave backups of .htaccess files in public directories.

==How do I password protect directories using .htaccess?==

'''Overview'''

This FAQ explains how to protect the Joomla! /administrator/ directory on Apache servers using the htpasswd utility. You can easily adapt these instructions to protect other directories. If you need help finding or creating your .htaccess file, start here.

'''Caveat (From Apache.org)'''

Basic authentication should not be considered secure for any particularly rigorous definition of secure.
Although the password is stored on the server in encrypted format, it is passed from the client to the server in plain text across the network. Anyone listening with any variety of packet sniffer will be able to read the username and password in the clear as it goes across.

Not only that, but remember that the username and password are passed with every request, not just when the user first types them in. So the packet sniffer need not be listening at a particularly strategic time, but just for long enough to see any single request come across the wire.

And, in addition to that, the content itself is also going across the network in the clear, and so if the web site contains sensitive information, the same packet sniffer would have access to that information as it went past, even if the username and password were not used to gain direct access to the web site.

Don't use basic authentication for anything that requires real security. It is a detriment for most users, since very few people will take the trouble, or have the necessary software and/or equipment, to find out passwords. However, if someone had a desire to get in, it would take very little for them to do so.

Basic authentication across an SSL connection, however, will be secure, since everything is going to be encrypted, including the username and password.

'''Directions'''

1. If you are unfamiliar with the Apache htpasswd utility, you may want to read the following link first.
Apache Authentication, Authorization, and Access Control

2. Check to be sure your site is configured to use .htaccess files. If not sure, ask your host.

3. Decide where to put your .htaccess file. Because Apache recursively searches all directories in a path for .htaccess files, the higher in your directory structure you place this file, the more directories it will control. If there is already an .htaccess file in the directory you choose, it's probably best to add the new code to it.

4. Decide where to store your.htpasswd and .htgroups files. These files should NEVER be publicly accessable through the Web. Below is an example directory structure showing good locations for each file. Note that the /auth/ directory in this example is NOT accessible from the Web.

/home/mysite/public_html/.htaccess
/home/mysite/auth/.htpasswd/
/home/mysite/auth/.htgroups/

5. Create the .htpasswd and .htgroups files as explained in the official Apache HowTo, referenced above. (Since you've read the always current and official documentation at Apache.org, we'll spare you the trouble of displaying it again here.)

6. If a .htaccess file already exists in the directory you have chosen, make a backup copy. If the file does not exist, create a new file with that name now. (Don't forget the dot at the beginning of the name.)

7. Add the following code to the .htaccess file. Adjust the example paths (marked in red) as needed for your server. Adjust the group name that you created in step 5 if it differs from the below example.

AuthUserFile /home/auth/.htpasswd
AuthGroupFile /home/auth/.htgroups
AuthType Basic
AuthName "LWS"
require group admins

8. Test carefully.

9. Remove all backup .htaccess files from public_http directories.

10. If you cannot use the Apache htpasswd utility, here's a free, online script that creates the necessary files for you. You'll need to know the user name, password, and path. The script does the rest for you. Note that for more advanced configuration, such as the use of groups, you'll need to edit the resulting files.

'''.htaccess Generator:''' http://www.webmaster-toolkit.com/htaccess-generator.shtml

== How do I restrict directory access by IP address using .htaccess? ==

'''Overview'''

This can be a very effective way to protect your Joomla! administrator directory. Any other directory in public_html can be protected in the same way. This method only works if you have a static IP address assigned to you. Anyone attempting to browse such directories using a different IP Address will get a 403 Forbidden error.

'''Directions'''
# In the directory you wish to protect, open (or create) a file called, .htaccess. (Note the dot at the beginning of the file name.)
# Add the following code to this file, replacing 100.100.100.100 in this example with the static IP address you plan to allow:

Order Deny,Allow
Deny from all
Allow from 100.100.100.100

* Optional: You can enter partial IP Addresses, such as, 100.100.100. This allows access to a range of addresses.

* Optional: You can add multiple addresses by separating them with comma's.

100.100.100.101, 100.100.100.102

==How do I convert an htaccess.txt file into a .htaccess file?==

'''Introduction'''

When using PHP as an Apache module, you can change the configuration settings using directives in Apache configuration files (e.g. httpd.conf and .htaccess files). You will need "AllowOverride Options" or "AllowOverride All" privileges to do so. If you control your own Apache configuration, you can and should use httpd.conf. If you do not control your Apache configuration (such as on a shared server), you must use .htaccess files.

'''Directions'''

# First look for the file, htaccess.txt in your root directory. It should have been installed during the Joomla! installation. (Note that this file name does not begin with a dot.) Open and carefully read htaccess.txt. It contains important suggestions on how to protect your site.
# Make any adjustments to this file as appropriate for your site, and then save it in your site's home directory as, .htaccess (including the dot).
# Test your site's front end and back end. If it produces errors, rename the file back to htaccess.txt, and troubleshoot your edits. If you are unable to get this working, you may have to leave the file named htaccess.txt.
# Use phpinfo() to ensure that all configurations set as you intended. Note: Web-accessible files that include phpinfo() are potential security risks they offer attackers lots of useful information about your server. Always remove such files after use.

'''More Information'''

* [http://us2.php.net/configuration.changes Official PHP Manual: How to change configuration settings]
* [http://us2.php.net/manual/en/ini.php#ini.list Official PHP Manual: List of PHP INI directives]

== How do I block direct hot linking to image files using .htaccess? ==

'''Caveats'''

# Your server must allow .htaccess files for this technique to work.
# If you do not have a .htaccess file in your root directory, see the related FAQ first.
# Do not use this method to redirect image hot links to HTML pages or to servers that are not your own.
# Hot linked images can only be replaced by other images, not with HTML pages.
# As with any .htaccess rewrite, you may block legitimate traffic, such as users behind proxies or firewalls.

'''Directions'''

# Create a jpeg image called no_hot_link.jpe. Note that the odd file extention (.jpe) is intentional and important. Place this file in your images directory.
# Place the following code in the .htaccess file of your root directory.

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://([^.]+\.)*your_site\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/no_hot_link.jpe [L]</source>

'''Explanation'''

The first line begins the Apache rewrite rule. The second line matches any requests from your own site, here called your_site.com url. The [NC] flag means "aNy Case", which means, match any and all upper and lower case characters. The third line allows empty referrals such as when a user is behind a caching proxy. The last line matches any files ending with the extension jpeg, jpg, gif, bmp, or png. This is then replaced by the no_hot_link.jpe file in your images directory. This JPEG file uses the extension jpe instead of jpg to prevent these rules from blocking your replacement image.

'''Block hot linking from specific domains'''

To stop hotlinking from specific domains only, such as myspace.com, blogspot.com and livejournal.com, while allowing other web sites to hotlink to your images, use the following code:

<source lang="apache"> RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*myspace\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*blogspot\.com/ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://([^.]+\.)*livejournal\.com/ [NC]
RewriteRule \.(jpe?g|gif|bmp|png)$ /images/nohotlink.jpe [L]</source>

You can add as many different domains as you want. Every RewriteCond line except the last one should end with the [NC,OR] flags. NC means to ignore case. OR means "Or Next", as in, match this line OR the next line. The last RewriteCond omits the OR flag to stop matching after the last RewriteCond.

'''Display a 403 forbidden code'''

Alternatively, you can display a 403 Forbidden error code. Replace the last line of the previous examples with this line:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]

= PHP =

== Why is Joomla! written in PHP? ==

: Might as well get it from the horse's mouth. In [http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html Do you PHP?], Rasmus Lerdorf, the originator of PHP, sums up how and why PHP developed as it did.

: ''"What it all boils down to is that PHP was never meant to win any beauty contests. It wasn't designed to introduce any new revolutionary programming paradigms. It was designed to solve a single problem: the Web problem. That problem can get quite ugly, and sometimes you need an ugly tool to solve your ugly problem. Although a pretty tool may, in fact, be able to solve the problem as well, chances are that an ugly PHP solution can be implemented much quicker and with many fewer resources. That generally sums up PHP's stubborness."''

== What is the latest stable release of PHP? ==

Check the [http://www.php.net/downloads.php official PHP download page] for information on the latest PHP release.

== How do I tune for speed with PHP5 and MySQL5? ==

: This is just a point by point summary of how I've been tuning and tweaking our Joomla sites to get them running as quickly as possible. For reference, we run all our sites off a Rackspace dedicated server, with 1Gb RAM, a 2Ghz dual core Athlon, running Apache 2.0.x (current revision), PHP 5.0.x (current revision) and MySQL 5.0.18.

: These are listed in terms of apparent speed increase - that is, not the sheer speed for the full page, but the speed before the page is usable to view content, even if not all features are loaded.

# PHP caching. I had been running eAccelerator, but switched to APC today, and it has made the system even faster than before, and eAccelerator was a big boost over uncached PHP. Joomla is a big complex system, so using precompiled code is a big time saver. I use a 128Mb in-memory cache, which is plenty for our needs.
# MySQL Query Caching. This one will vary depending on how dynamic your site is, and you can really kill the benefits by using the wrong extensions (any date/time based will need checking), but if you are serving pretty much the same queries each page load, it will drop the load times noticably.
# Template Image optimisation - template images really slow down the initial page load for first time visitors, so optimising the hell out of them makes sense. Remember that your template is probably not going to change as often as your story content, so you can afford to spend more time on optimising the images for it that you would otherwise. I recommend Irfanview, with the pngout plugin active for PNG images, and it isn't bad for JPG and GIF images either. Don't forget to ramp up the compression level of PNGs, and, if possible, reducing them to indexed pallettes.
# CSS compression. Easy one this - put a little script to output a gzipped version of your CSS file(s) and point your index.php at it. Example script below - I didn't write it, but it's short, to the point, and works.

ob_start ("ob_gzhandler");
header("Content-type: text/css");
header("Cache-Control: must-revalidate");
$offset = 60 * 60 ;
$ExpStr = "Expires: " .
gmdate("D, d M Y H:i:s",
time() + $offset) . " GMT";
header($ExpStr);

# Strip unneeded modules, components, mambots from Joomla. If you haven't used them, the impact on your loading time is minimal, but with more components/modules active, there are more points of failure, and Apache errors are slow!
# Scrutinise the Apache error log. It is amazing how many errors can crop up even with a fairly minimal Joomla install, and they don't necessarily affect the appearance of the page. Check your error log, especially if you are using custom components/modules, or any non-standard config settings. Once you've noticed any problems, it's time to fix the code creating them, and test thoroughly before uploading the fixed versions.
# Keep rechecking as you add/remove features, redesign or change any server configuration options. Even things like adding virtual servers in Apache can affect speed of the server, as a missed config setting can cause general Apache delays.

== Should PHP run as a CGI script or as an Apache module? ==

There are two ways to configure Apache to use PHP: <br />

# Configure Apache to load the PHP interpreter as an <i>Apache module</i>
# Configure Apache to run the PHP interpreter as a <i>CGI binary</i>

<i><span style="color: navy">(PS: Windows IIS normaly configures as CGI by the way)</span></i><br />

It is the intention of this post to provide you information relating to
the configuration and recognition of each method. &quot;In general&quot;
historically only one method or the other has been implemented,
however, with the architectural changes made to PHP starting with PHP5,
it has been quite common for hosting firms to configure for both. One
version running as CGI and one version running as a Module. It is
generally accepted more recently that running PHP as a CGI is more
secure, however, running PHP as an Apache Module does have a slight
performance gain and is generally how most pre-configured systems will
be delivered out of the box.

<span style="color: navy"><b>What is the difference between CGI and apache Module Mode?</b></span><br />

An <b><span style="color: blue">Apache module</span></b>
is compiled into the Apache binary, so the PHP interpreter runs in the
Apache process, meaning that when Apache spawns a child, each process
already contains a binary image of PHP. A CGI is executed as a single
process for each request, and must make an exec() or fork() call to the
PHP executable, meaning that each request will create a new process of
the PHP interpreter. Apache is much more efficient in it's ability to
handle requests, and maaging resources, making the Apache module
slightly faster than the CGI (as well as more stable under load).<br />

<b><span style="color: blue">CGI Mode</span></b>
on the other hand, is more secure because the server now manages and
controls access to the binaries. PHP can now run as your own user
rather than the generic Apache user. This means you can put your
database passwords in a file readable only by you and your php scripts
can still access it! The &quot;Group&quot; and &quot;Other&quot; permissions ( refer <a href="component/option,com_easyfaq/task,view/id,73/Itemid,268/" target="_blank">Permissions FAQ</a>

can now be more restrictive. CGI mode is also claimed to be more
flexible in many respects as you should now not see, with phpSuExec (
refer [http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html" target="_blank Permissions under phpSuExec]
issues with file ownership being taken over by the Apache user,
therefore you should no-longer have problems under FTP when trying to
access or modify files that have been uploaded through a PHP interface,
such as Joomla! upload options.

If your server is
configured to run PHP as an Apache module, then you will have the
choice of using either php.ini or Apache .htaccess files, however, if
your server runs PHP in CGI mode then you will only have the choice of
using php.ini files locally to change settings, as Apache is no longer
in complete control of PHP.

<hr />

<span style="color: navy"><b>Testing and Reviewing Your PHP Installation</b></span> <i></i>

<i>Also known as &quot;Everything you ever wanted and didn't want to know about PHP&quot;</i>

To
find out the PHP interpreter mode and to generally test your PHP
installation and to find out a vast amount of information about your
PHP environment, supported utilities, applications and settings, you
create a single PHP file containing <i>only</i> the following lines;<br />
</p>

phpinfo();<br />

This single line of code outputs an amazing amount of information, be warned.... <img src="http://forum.joomla.org/Smileys/joomla/wink.gif" alt="Wink" border="0" />

Save the file as any filename you wish, but with the &quot;.php&quot; extension. FTP it to your server and open it in a browser.

<span style="color: navy"><b>Other useful information</b></span>

The following are PHP functions, that when run from a PHP File can provide some useful information, <i>(less than the above option)</i> many should run on most hosts, however many hosts disable some of these functions for security. No Guarantee's offered...

Again,
as above, make a file, name it anything you wish but make sure it has
the &quot;.php&quot; extension, copy and paste the following lines in to it and
FTP to your server.<br />

&lt;?<br />echo &quot;Hostname: &quot;. @php_uname(n) .&quot;&quot;;
if (function_exists( 'shell_exec' )) { echo &quot;Hostname: &quot;.
@gethostbyname(trim(`hostname`)); } else { echo &quot;Server IP: &quot;.
$_SERVER['SERVER_ADDR'] .&quot;&quot;; }
echo &quot;Platform: &quot;. @php_uname(s) .&quot; &quot;. @php_uname(r) .&quot; &quot;. @php_uname(v) .&quot;&quot;;
echo &quot;Architecture: &quot;. @php_uname(m) .&quot;&quot;;
echo &quot;Username: &quot;. get_current_user () .&quot; ( UiD: &quot;. getmyuid() .&quot;, GiD: &quot;. getmygid() .&quot; )&quot;;
echo &quot;Curent Path: &quot;. getcwd () .&quot;&quot;;
echo &quot;Server Type: &quot;. $_SERVER['SERVER_SOFTWARE'] . &quot;&quot;;
echo &quot;Server Admin: &quot;. $_SERVER['SERVER_ADMIN'] . &quot;&quot;;
echo &quot;Server Signature: &quot;. $_SERVER['SERVER_SIGNATURE'] .&quot;&quot;;
echo &quot;Server Protocol: &quot;. $_SERVER['SERVER_PROTOCOL'] .&quot;&quot;;
echo &quot;Server Mode: &quot;. $_SERVER['GATEWAY_INTERFACE'] .&quot;&quot;;<br />
?&gt;

The <span style="color: blue">Joomla! HISA</span> or <span style="color: blue">Joomla! Tools Suite</span> can also assist to determine which mode your server in running in, also
providing a large amount of other related information including recommendations on configuration.

<b>Joomla! Tools Suite</b> (JTS) is a complete suite of Tools to help you troubleshoot and maintain Joomla! and include the &quot;HISA&quot; script. [http://joomlacode.org/gf/project/jts/ Download JTS Here]

<b>Joomla! Health, Installation and Security Audit</b> (HISA) is a single standalone script that provides purely configuration information. [http://joomlacode.org/gf/project/hisa/ Download HISA Here]

[http://forum.joomla.org/index.php/topic,136328.0.html Forum Discussion Here]

[http://www.joomlatutorials.com/joomla-tips-and-tricks/40-miscellaneous-joomla-tips/114-how-to-troubleshoot-a-joomla-installation.html How to TroubleShoot A Joomla! Installation]

Another <span style="color: navy">Indirect method</span>, and possibly not 100% reliable, is that if you are unable to make use of .htaccess on Linux hosting and Apache based servers then you are either running in CGI mode or your host has disabled the use of .htaccess even if your server is running PHP as an Apache Module.

<b><span style="color: maroon">Remove these files immediately after use, the information contained in their output is extensive and explicit regarding your PHP and server configurations, it will help those wishing to cause your site harm</span></b>

<span style="color: navy"><b><span style="text-decoration: underline">For those wishing to know more about &quot;How To...&quot;</span></b></span>

<span style="color: navy"><b>Running PHP as an Apache module</b></span><br />
To configure Apache to load PHP as a module to <i>'parse'</i> your PHP scripts, the httpd.conf needs to be modified, typically found in &quot;c:\Program Files\Apache Group\Apache\conf\&quot; or &quot;/etc/httpd/conf/&quot;.

Search for the section of the file that has a series of commented out &quot;LoadModule&quot; statements. (Statements prefixed by the hash &quot;#&quot; sign are regarded as having been commented out.) If PHP is running in &quot;Apache Module&quot; Mode you should see something very similar to the following;

LoadModule php4_module &quot;c:/php/php4apache.dll&quot;

<b><span style="text-decoration: underline">Apache 1.x</span></b>

<b>For PHP5</b>
LoadModule php5_module C:/php/php5apache2.dll<br />
<i>or (platform dependant)</i><br />
LoadModule php5_module /usr/lib/apache/libphp5.so<br />

<b>For PHP4</b>

LoadModule php4_module libexec/libphp4.so<br />
<i>or (platform dependant)</i><br />

LoadModule php4_module C:/php/php4apache.dll<br />

<i><b>and</b></i>
AddModule mod_php4.c<br />
<i>or</i><br />
AddModule mod_php5.c<br />
<br />
<b><span style="text-decoration: underline">Apache 2.x</span></b><br />

<b>For PHP5</b>

LoadModule php5_module C:/php/php5apache2.dll<br />

<i>or (platform dependant)</i>

LoadModule php5_module /usr/lib/apache/libphp5.so<br />

<b>For PHP4</b><br />

LoadModule php4_module libexec/libphp4.so<br />
<i>or (platform dependant)</i><br />
LoadModule php4_module C:/php/php4apache.dll<br />

<i><b>and</b></i><br />
AddModule mod_php5.c<br />

<i>or</i><br />
AddModule mod_php4.c <br />

<b>Note:</b><br />
Don't worry that you can't find a &quot;mod_php4.c&quot; or &quot;mod_php5.c&quot; file anywhere on your system. That directive does not cause Apache to search for the file on your system. For the curious, it specifies the order in which the various modules are enabled by the Apache server.<br />

<i>If you're using Apache 2.x, you do not have to insert the AddModule directive. It's no longer needed in that version. Apache 2.x has its own internal method of determining the correct order of loading the modules.</i>

Now find the &quot;AddType&quot; section in the file, and add the following line after the last &quot;AddType&quot; statement:

AddType application/x-httpd-php .php<br />

If you need to support other file types, like &quot;.php3&quot; and &quot;.phtml&quot;, simply add them to the list, like this:<

AddType application/x-httpd-php .php3<br />
AddType application/x-httpd-php .phtml<br />

Run a syntax check and if all is ok, restart Apache...<br />

<hr />
<span style="color: navy"><b>Running PHP as a CGI binary</b></span><br />
To configure PHP to run as a CGI, again you will need to configure the
httpd.conf, but confirm that the above settings are not also
configured, unless you now what you are doing you can generate yourself
&quot;HTTP 500&quot; errors. Search your Apache configuration file for the
&quot;ScriptAlias&quot; section.

Add the following line below after the ScriptAlias for &quot;cgi-bin&quot;. <br />

<b>Note:</b>

The location will depend on where PHP is installed on your system, you
should substitute the appropriate path in place of &quot;c:/php/&quot; (for
example, &quot;c:/Program Files/php/&quot;).<br />

ScriptAlias /php/ &quot;c:/php/&quot;<br />

Apache
again needs to be configured for the PHP MIME type. Search for the
&quot;AddType&quot; section, and add the following line after it:<br />

AddType application/x-httpd-php .php<br />

As in the case of running PHP as an Apache module, you can add whatever extensions you want Apache to recognise as PHP scripts, such as:

AddType application/x-httpd-php .php3<br />
AddType application/x-httpd-php .phtml<br />

Next, you will need to tell the server to execute the PHP executable each time it encounters a PHP script. Add the following below any existing entries in the &quot;Action&quot; section.

Action application/x-httpd-php &quot;/php/php.exe&quot;

If you notice, we have used the &quot;ScriptAlias&quot; reference, &quot;/php/&quot; portion
will be recognised as the scriptAlias configured above, this is sort a path alias which will correlate to your PHP installation path configured previously. <i>In other words, don't put &quot;c:/php/php.exe&quot; or &quot;c:/Program Files/php/php.exe&quot; in that directive, put
&quot;/php/php.exe&quot;, Apache WILL work it out if correctly configured.</i>

<span style="color: navy"><b>Configuring the Default Index Page</b></span><br />
This section applies to all users, whether you are loading PHP as a module or running it as a CGI binary, and has been seen often enough to warrant a mention.

If you want to make your PHP script execute as the default page for a directory, you have to add another line to the &quot;httpd.conf&quot;. Simply search for the line in the file that begins with a &quot;DirectoryIndex&quot; and add &quot;index.php&quot; to the list of files on
that line. For example, if the line used to be:

DirectoryIndex index.html

<i>change it to</i>

DirectoryIndex index.html index.php<br />
<i>If you still wish .html files to be executed before .php files</i><br />
<br />
<i>or</i><br />
DirectoryIndex index.php index.html<br />
<i>If you wish .php files to be executed before .html files</i>

The next time you access the site or a directory within a site without a
filename, Apache will &quot;auto-magically&quot; deliver &quot;index.php&quot; if
available, or &quot;index.html&quot; if &quot;index.php&quot; is not available.

== Why shouldn't I use PHP safe_mode? ==
'''Overview'''
Enabling safe_mode is not needed if other reasonable security precautions are followed. Using safe_mode for web site security is a poor compromise in a bad situation. It may make sense in some situations, but there is almost always a better way. Because safe_mode in some sense only gives the illusion of safety, it will be removed from PHP starting with version 6.0.

The Joomla! core works fine with or without PHP safe_mode. The one exception to this rule is the installation script. This is because safe_mode, by design, turns off the PHP functions that enable easy uploading via a Web browser. If you do use safe_mode, and need to perform installs via the Web browser, temporarily turn safe_mode OFF, and turn it back ON when finished.

Some third-party extensions may require the specific PHP functions that are blocked by safe_mode. Such extensions should be carefully evaluated to be sure you understand exactly why they require such powerful and potentially dangerous functions.

'''From the official PHP site'''

''"The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now."''
'''More Information'''

# [http://us3.php.net/manual/en/features.safe-mode.php#ini.safe-mode Official PHP Manual: PHP Security and Safe Mode Configuration Directives]
# [http://us3.php.net/manual/en/features.safe-mode.functions.php Official PHP Manual: PHP Functions restricted/disabled by safe mode]

= Development =
== How do I setup a secure demo site? ==

In /includes/version.php look for:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 1;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 0;

For a demo site it is advised to following:

/** @var string Whether site is a production = 1 or demo site = 0 */
var $SITE = 0;
/** @var string Whether site has restricted functionality mostly used for demo sites: 0 is default */
var $RESTRICT = 1;

$SITE = 0
// Allows multiple user logins with only one account. By default Joomla!
// allows only one active session per account as a security feature.

$RESTRICT = 1
// Disables those logging in, both Front-end and Back-end from changing
// user details - like password and username

These settings are used on the official demo site http://demo.joomla.org

You should also make all files and folders nonwriteable - especially the configuration.php file. Also recommend you setup an automatic cron job that refreshes the database at a set interval (in our case 60mins) from a db script.

== How can I view a live site while developing, but hide it from others? ==

'''Introduction'''

The method described below should be used for relatively minor modifications, such as adjusting menus or quickly reorganizing content sections. More complex tasks, such as installing new components or adjusting complex configuration settings should be performed and tested on a development server first. Not only does this keep your public site up and running, but it also lets you test at your leisure, thus reducing errors. One way to do it is to create a sub-domain (i. e., dev.yourdomain.com) and install Joomla! there just as it is installed on your public site.

'''Directions'''

1. Login to the administrator section, and choose: Site > Global Configuration.

2. The first option you'll see is is to set the site offline. Choose "Yes" and press the Save button. This will hide prevent display of all site pages, and replace them with the following message:

"This site is down for maintenance. Please check back again soon. message instead."

3. While you are logged into the "back end" administrator system, you can still view the "front end," by choosing Site > Template > Preview. This will display the site as it would appear to users along with a warning at the top that the site is down for maintenance.

= Site Recovery =

== Help! My site's been compromised. Now what? ==

'''Directions'''

# '''Change all relevant passwords:''' Assume your passwords have been harvested and immediately change all critical passwords, including shell access, FTP access, Joomla! Administrator accounts, and the database account.
# '''Check raw logs:''' Identify when and how the attackers gained access to your site by carefully reviewing your raw server logs. Make careful note of the date/time and names of attacked files. Note that these logs may have been deleted or altered, so a lack of evidence does not prove a lack of activity.
# '''List recently modified files:''' Before making any changes to your site, generate a list of recently modified files. Here's a php script that will list the files for you. Remove this script as soon as you have your list and don't publish a link to it!
# '''Note suspicious newly-created files:''' Use this list to identify new files that don't belong. Pay particular attention to their creation and modification dates, and correlate them to the dates of attacks shown in your log files.
# '''Note suspicious recently-modified files:''' Check the modified files list for any files that were recently changed. Pay particular attention to the modification, and correlate them to the dates of attacks shown in your log files.
# '''Check for bogus CRON Jobs:''' Hacked cron jobs can be setup to reinfect your site over and over again.
# '''Coordinate with your host:''' If you have identified how you were cracked, report the method to your host. If you are on a shared server, you may habe been attacked through another vulnerable site on your server. Report this to your host. A reputable host will appreciate your efforts in this area.
# '''Delete the entire public_html directory:''' This is the best way to guarantee that every potential vulnerability in that site is removed.
# '''Delete related database records:''' This step may only be possible if you have good backups. Simple script kiddies, who are only trying to mark your index page, may not attack your database, but professionals are usually very interested in confidential data, such as passwords. They may pose as script kiddies to avoid suspicion while repeatedly harvesting confidential information from your database.
# '''Reinstall everything:''' Use pre-crack backups. If you don't have good backups, go on to step 10.
# '''Reset critical passwords again:''' You must reset your passwards again now that your server is finally cleaned of any possible, hidden trojan horses.
# '''Rebuild site:''' If you are unable to rebuild from clean backups, rebuild your entire site using original, pre-crack installs. Use only the latest stable versions of all software, and check the List of Vulnerable Extensions
# '''Review security processes:''' Follow standard security precautions for important settings in php.ini, globals.php, configuration.php, .htaccess, etc.
# '''Review backup processes:''' If you don't already have one, add a dependable backup process to your site administration practices.
# '''Stay watchful:''' Attackers often return repeatedly. Closely monitor your raw logs for suspicious activity.

==How do I reset an administrator password?==

'''Introduction'''

'''Note:''' This method is for Joomla versions up to and including 1.0.12. For later versions of Joomla and Joomla 1.5.xx versions please use this '''([[How_do_you_recover_your_admin_password%3F|FAQ]])'''

Because passwords are stored using a one-way MD5 hash which prevents recovering the password, you cannot recover an existing password, but you can reset it to a new password by editing the password field in the database. In the following directions, you will set the password MD5 value to a known value and then log-in using the password that matches that value. Once logged in, you can change the password again using normal Joomla! user access screens.

'''Enhanced Password Encryption Note Joomla! 1.0.13+ and Joomla! 1.5.x'''
This method works with the new salt-enhanced passwords. This is because Joomla! will automatically update passwords in the earlier format.

'''Directions'''

1. Use a MySQL utility such as phpMyAdmin or MySQL Query Browser .

2. Open the correct database and select the table, jos_users . (Change default table prefix, 'jos_' to your table prefix if it is different.)

3. Select the record (or table row) for your administrator account. (The default Super Administrator is user number 62.)

4. Copy and paste a known MD5 hash into the password field. You can use one of the below examples.
'''Warning:''' You must paste the password's hash value, not the password itself. You can use any of the following hashs, or create your own using one of the MD5 tools listed below.

password = "MD5 hash of password"
------------------------------------------------------
admin = 21232f297a57a5a743894a0e4a801fc3
secret = 5ebe2294ecd0e0f08eab7690d2a6ee69
OU812 = 7441de5382cf4fecbaa9a8c538e76783

5. Save the user record.

6. Point a browser to your site and log in using the Super Administrator account you just modified.

7. '''IMPORTANT:''' Once logged in, use the Joomla interface to change the password to one that only you know. This step is vital as it will 'salt' your new password, thus adding an additional level of security on top of the MD5 hash.

Note: This technique can be used to modify any other accounts password. You can also use it to change Usernames.

'''Generating your own MD5 hash from a password of your choice'''

Alternatively, you can set the password to a value of your own choice. Use tools, such as the following, to create your own strong hashed password. Use the above directions once you've generated a hash with these tools.

'''Online MD5 hash creation tools'''
* JavaScript MD5 - http://pajhome.org.uk/crypt/md5/
* MD5er - http://www.md5er.com/

'''Free MD5 utilities for download'''
* MD5 & Hashing Utilities - http://www.digital-detective.co.uk/freetools/md5.asp
* SlavaSoft HashCalc - http://www.slavasoft.com/hashcalc/overview.htm

'''Other MD5 tools'''
* There are many free online and downloadable MD5 utilities. Google "MD5 hash tool"

== How do I find exploits using the *NIX shell? ==

'''Check the active processes'''

Use the "ps" command to look for odd or unknown processes, if you aren't sure what to look for there, user "netstat -ae | grep irc" and/or "netstat -ea | grep 666" and look for ports 6666, 6667, 6668, 6669, these are common ports used for running IRC bots, they may have the name "irc" listed against them, or may have "httpd" or sometimes other regular services names.

'''Check crontab'''

Check your crontab and see if there is a strange entry, these are used in many exploits to restart IRC bots, even when admins or automated process monitors are used to kill a rogue process.

'''Check for hidden files or directories'''

Check for hidden files or directories you dont expect to see, those starting with "." (dots) and also look for ". " (dot, space) often favored to try and catch searches for hidden directories.

Other examples of searches that may help pin down exploits and/or unexpected files and folders:

find /home -type f | xargs grep -l MultiViews
find . -type f | xargs grep -l base64_encode <<< this can produce false positives, it is valid in many mail/graphics scripts
find . -type f | xargs grep -l error_reporting
find / -name "[Bb]itch[xX]"
find / -name "psy*"
ls -lR | grep rwxrwxrwx > listing.txt

== What are these strange (URL-Encoded) characters doing in my code? ==

Overview

Attackers sometimes hide code away from prying eyes by URL Encoding it.

The purpose of URL Encoding is to allow non-URL compatible characters to be passed via the URL. There are many legitimate reasons for doing this, such as hiding email from spammers, dealing with spaces in file names. etc.

However, if you find odd, URL-encoded text in your site's files, you should investigate immediately. URL encoded text is very easy to translate using PHP, javascript, or one of the many free, online translators.

Here are some trivial, non-functioning examples of URL Encoded text:

<table border="1">
<tr>
<th>Original</th>
<th>URL Encoded</th>
</tr>
<tr valign="top">
<td>this line has spaces</td>
<td>this%20line%20has%20spaces</td>
</tr>
<tr valign="top">
<td>eval(evil_script(http://www.evilsite/?evilscript.pl"));</td>
<td>%65val%28%65%76il_%73cri%70t
%28%68tt%70%3A//%77%77%77.
%65%76il%73ite/%3F%65%76il%73
cript.%70l%22%29%29%3B</td>
</tr>
</table>

'''Resources'''

# [http://www.linkedresources.com/tools/unescaper_v0.2b1.html Text Unescape Utility]
# [http://www.w3schools.com/tags/ref_urlencode.asp HTML URL-encoding Reference]

== Edited by==
[http://forum.joomla.org/memberlist.php?mode=viewprofile&u=39784 rliskey]


[[Category:Security]]
[[Category:FAQ]]
[[Category:Security_FAQ]]

Creating clickable background images using CSS

2011-09-26T18:47:36Z

MTrapp82: None

== What this is about ==

Okay, lets say you have a mostly finished template, with a typical corporate layout: A header, a content body area, and a footer. In the header you have placed a background image with a big company logo and some nice artwork next to it, with some dynamic content on top of the bottom right corner of the background image.
Suddenly you realise that a click on the company logo part of that background image <span class="plainlinks">[http://www.thepiggybackrider.com/ <span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;/*CITATION*/">kid carrier</span>]</span> should bring the user back to the homepage. Usually you would cut out the image and place it directly inside the link. However you don't have enough time to cut up the image and re-work your template accordingly, so what you need is a quick-fix.

At this point your HTML structure might look something like this:
<pre>
<div id="site">
<div id="full-width-header">
<div id="header-content">We love using Joomla!</div>
</div>
<div id="body-content">OSM saves the world!</div>
<div id="footer-content">(c) the really cool web-designer</div>
</div>
</pre>

And your CSS like this:
<pre>
#full-width-header {
background: url(header-logo.jpg);
width: 800px;
height: 172px;
}
#header-content {
position: relative;
float: right;
width: 400px;
height: 172px;
vertical-align: bottom;
text-align: right;
}
</pre>

Note: Legitimate uses for the following technique might include things like tab-interfaces where the tabs should be able to stretch and still have a background image, or blog-skins which only differ in CSS.

== How to do it ==

First: You can't just copy the #header-content div, position it over the logo, make the content invisible and enclose it in an anchor-tag. That would be broken HTML, because you can't place block-level elements like div inside anchor tags.

You can however enclose a stretched, one-pixel, transparent GIF image in anchor tags (as per example one) if you have to support old browsers. Otherwise you can simply turn the anchor itself into an inline-block using CSS 2.1 (as per example two).

Example 1 (pre CSS 2.1) HTML:
<pre>
<div id="site">
<div id="full-width-header">
<a href="/"><img src="transparent.gif" id="home-link" alt="Nav: Home" /></a>
<div id="header-content">We love using Joomla!</div>
</div>
<div id="body-content">OSM saves the world!</div>
<div id="footer-content">(c) the really cool web-designer</div>
</div>
</pre>

Example 1 (pre CSS 2.1) CSS:
<pre>
#full-width-header {
position: relative; /* necassary to
absolute-position the child-element
#home-link relative to the header */
background: url(header-logo.jpg);
width: 800px;
height: 172px;
}
#home-link {
position: absolute;
width: 200px; /* width of the logo */
height: 172px; /* height of the logo */
top: 0; left: 0; /* top-left corner of logo */
border: 0;
float: left;
}
#header-content {
position: relative;
float: right;
width: 400px;
height: 172px;
vertical-align: bottom;
text-align: right;
}
</pre>

Example 2 (CSS 2.1) HTML:
<pre>
<div id="site">
<div id="full-width-header">
<a href="/" id="home-link">Home</a>
<div id="header-content">We love using Joomla!</div>
</div>
<div id="body-content">OSM saves the world!</div>
<div id="footer-content">(c) the really cool web-designer</div>
</div>
</pre>

Example 2 (CSS 2.1) CSS:
<pre>
#full-width-header {
position: relative; /* necassary to
absolute-position the child-element
#home-link relative to the header */
background: url(header-logo.jpg);
width: 800px;
height: 172px;
}
#home-link {
position: absolute;
display: inline-block;
width: 200px; /* width of the logo */
height: 172px; /* height of the logo */
top: 0; left: 0; /* top-left corner of logo */
border: 0;
float: left;
visibility: hidden;
}
#header-content {
position: relative;
float: right;
width: 400px;
height: 172px;
vertical-align: bottom;
text-align: right;
}
</pre>

[[Category:Tutorials]][[Category:Templates]]