Four different server technologies must work in concert for Joomla to function properly. If Apache can't execute PHP, or PHP can't connect to MySQL, or Joomla can't write into the MySQL database, the system fails. This chapter will help you configure each interlocking server system to work properly in unison. Each server is controlled by a list of directives or configuration settings, and making sure those settings are optimal will ensure that the system functions properly.
Additionally, various techniques describing the fine-tuning of each aspect of the system will help your server respond to Web requests most efficiently to create the best user experience. By customizing these settings to suit the needs of your Joomla system, you will be able to squeeze a great deal more performance out of the same hardware.
In the Joomla server constellation (see Figure 2-1), there are four servers that dynamically interact: the Web server, the PHP execution engine, MySQL database server, and the Joomla server itself. I'm using the term server loosely in this definition because PHP and Joomla don't execute as independent servers. However, my broader definition will help you understand how to approach operation and configuration, since both PHP and Joomla effectively serve Web pages and require independent configuration.
The foundation of the system is the Web server that supplies the HTTP hosting capabilities. Joomla can run successfully on either Apache Web server or Microsoft Internet Information Server (IIS). While Apache can execute on dozens of operating systems (Windows, MacOS, and dozens of UNIX variants), IIS only runs on the Windows platform. Aside from providing the HTTP serving foundation, the Web server also plays host to the PHP engine and the Joomla server.
Within the Joomla system, the PHP engine executes the Joomla application. Joomla uses the PHP plug-in to address the MySQL server where all of the Joomla data is stored. While Joomla configuration settings are stored in the configuration.php
file, almost all other data (including content, sections, categories, extension installation information, and so on) is stored in the MySQL database.
The minimum requirements for the servers that Joomla requires are:
PHP 4.3.x or above with the MySQL, XML, and Zlib modules activated
MySQL 3.23.x or above
Apache 1.13.19 or above
Your choices regarding how these servers will be deployed will have far-reaching implications for the success of your Joomla site.
You have probably already had some experience with Joomla installation, but I'll provide a short overview so that you may consider the different installation possibilities. When you are making choices about the configuration, you must decide between local or remote deployment, select the platform Joomla will use, determine the method of performing the installation, and pick which Web server to use.
Although most of the options will hinge more on the target deployment conditions than personal preferences, you should evaluate the positives and negatives so that you can understand the ramifications of each selection. You should pay attention to the differences in deployment when performing your evaluation, since it is not unusual to use a different platform for development and testing than will be used for the final deployment. It is common to use Windows or Mac OS for the staging server, while the final site will be launched on a Linux Web server. By noting the variations at the start, you will have an easier time making the deployment transfer.
The first installation decision is whether Joomla will be installed locally or remotely. You may have a Web service provider such as GoDaddy.com
or SiteGround.com
that will be serving your Web site. In these cases, all of the primary server software, including PHP and MySQL, are already installed and available for use. Activating Joomla is simply a matter of uploading the Joomla installation image and completing the process. If you're installing locally, you have much more to do.
Following are some of the advantages of a local installation:
Configuration freedom — You can set up each Joomla server to exactly match your needs. The Web host providers for a remote installation will only rarely allow access to root configuration settings because of the potential danger to their system and other users.
Thorough system knowledge — You will almost "certainly have more knowledge of the system if you perform the setup and maintenance. That knowledge can translate not only to better system performance but also to a greater understanding of the possibilities and limits of the system when it comes to the development of extensions, components, and plug-ins.
Potential server performance — Running your own system gives you complete control to dedicate the maximum amount of resources to the Joomla site. When you use a remote installation, it is likely you'll be sharing database execution and Internet connectivity with a great number of fellow subscribers. That can lead to servers bogging down, and your performance will suffer in peak usage times.
Backup flexibility — With a local installation, you have the option of implementing backup procedures that can include everything from a simple manual backup to a mirrored server drive. On a remote installation, creating a backup of the current site installation and content can be tedious and require separate manual procedures for the files (through FTP) and the database (through some type of administration interface).
Following are some of the disadvantages of local installation:
More work — With a local installation, you are also responsible for the setup and maintenance of the server. That includes configuration to most effectively divide the server resources among the various servers executing on the machine.
Potential server performance — Although having your own dedicated server is likely to give you better performance than a remote installation, this is not always the case. Web host providers spend a great deal of energy ensuring that their servers are optimized for peak performance. They also tend to use more expensive equipment because of the load being placed on it.
Failover safety — Most host providers implement some type of redundancy in the system to ensure that their client's Web sites don't go down. This may include backup Domain Name System (DNS) servers, automatic failover hard drive mirrors, clustering, battery backups, and a number of other technologies that ensure that a client site continues to function properly in the event of a system failure. It is difficult and expensive to implement this type of safety net for an individual local server.
If you would like to have a local installation but don't have a business-grade Internet connection, look into co-location options provided by your local Internet service providers (ISPs). Many ISPs have excellent pricing that allows you to locate your server on their premises and hook into their Internet backbone for a fee.
The choice of a platform can be a difficult one, and there are too many variables involved in the decision that will be particular to your situation to list here. It may boil down to your comfort level with a given operating system, or the consideration of licensing fees (Linux is free, while Windows and MacOS both require licensing fees). While the platform choice may affect performance, it shouldn't have a significant effect on the Joomla installation process. Most Joomla administration occurs through the Web interface, so the platform is immaterial to the interaction with the system.
Further, Joomla uses the PHP and MySQL technologies, which are very nearly identical on all of the platforms. Therefore, you are going to be interacting with the system in much the same manner regardless of the platform.
You can choose to individually install each piece of server software or use a combined installer such as XAMPP (pronounced as either "x-amp" or "zamp"). When describing an installation setup, administrators often use acronyms such as WAMP, LAMP, or MAMP. These acronyms indicate the target platform providing the first letter (W = Windows, L = Linux, and M = MacOS) of the operating systems, and the other three letters representing the servers to be installed (Apache, MySQL, and PHP). The most popular combined installer is called XAMPP, where the X represents a variable, since the installers are available for all three operating systems. The two "PPs" in "XAMPP" indicate PHP and Perl software, both of which are included with the installation. Although Joomla doesn't use Perl, it won't affect server performance.
XAMPP installers overcome one of the major obstacles to open source deployment: packaging. Open source developers are notorious for releasing software that, while stable when executing alone, breaks integration with existing versions of other necessary software. (For example, a new Apache version will no longer work with the stable version of PHP.) An XAMPP installer avoids these problems by shipping only fully compatible versions together. That means that you can download a single installer, execute it, and have an integrated server system up and running in very little time.
While the XAMPP installer provides easy and quick installation for staging or testing, it has some serious disadvantages. Central among those is the problem of security. The default installations of the servers in the XAMPP package leave all avenues of security penetration wide open. Further, there are many unneeded applications (such as Perl), extensions, and modules included in the install that can bog down your system. In fact, the amount of space used on your local drive will be more than three times greater than if you installed the servers needed for Joomla separately.
If you are a beginner, an XAMPP installer is fantastic to get you up and running in a short time. If you're slightly more advanced, even though you're sure to run into a problem or two, individual installations may be the way to go.
Keep in mind that the platform may also help determine how you want to perform the installation. For example, on the MacOS, Apache server is already natively installed—it needs only to be activated. Likewise, if you're going to use IIS as your Web server on the Windows platform, it is likely already installed. The servers included would create redundancy for the existing technology, and at worst they may conflict with servers already in place.
If you are running on the Windows platform, you have a choice to make for the Joomla Web server: You can run either Apache or Microsoft Internet Information Server (IIS). The choice is a difficult one for several reasons. The primary reason to use Apache on Windows is that compatibility between Joomla and Apache is well tested and understood. However, there are several reasons why you might want to choose IIS instead:
Native SSL support — SSL security is natively supported in IIS on Windows. As of this writing, an Apache user would have to do a custom compilation of the Apache server to obtain Secure Sockets Layer (SSL) capabilities. The distribution binaries do not include this security.
Tuned performance — Microsoft spends a great deal of time and money making sure that IIS is optimized for maximum performance on Windows. While Apache runs well, it is truly optimized for the Linux platform or another UNIX variant.
Integrated directory security — IIS understands the directory security native to Windows and even works with Microsoft's Active Directory infrastructure. Using Apache requires a partial integration of Windows security permissions with the Apache system.
Bundled FTP server — The default installation of IIS includes a File Transfer Protocol (FTP) server that can be useful for administration of both the central Joomla system as well as provided extra capabilities to a variety of Joomla extensions (such as upload/download capabilities to an image gallery component).
Most IIS components already installed — On the Windows platform, most of the components needed for executing IIS are integrated into the operation system. This means that the install footprint of IIS is very small, since only a few extra pieces of technology need to be placed on the system.
To install Joomla on the Windows platform, first ensure that IIS is running properly. You can test for IIS by going to the Control Panel
http://localhost
Before you can run Joomla, you must install PHP and MySQL so that the execution and database technology is available. You can obtain PHP from the following URL:
http://www.php.net
Follow the PHP installer as you normally would. At the Web Server page of the Installation Wizard, choose your version of IIS, as shown in Figure 2-2. The PHP installer will automatically configure IIS to work with PHP.
That's about it! Even though PHP doesn't notify you that a reboot is required, it is. You must reboot your machine for the Path variable to be set to address the new PHP directory. If you have any problem getting PHP working, check the Path variable by opening the Control Panel
If the PHP engine still isn't running properly (see the next section for a way to test it), try checking if there is a PHP.ini
in your Windows directory. If so, ensure that it is configured to point to the proper directory. If not, try copying the PHP.ini there. You should stop and restart the server to make sure the PHP extension is reset after any change.
Joomla installation is relatively easy for an experienced computer user. This section summarizes the installation steps, so if you haven't gone through the process, this will familiarize you with the basic features.
Start the installation by downloading the current Joomla image (from www.joomla.org
) to a local drive. Expand the archive (either a .zip, .tar.gz
and .tar.bz2
file), and place the Joomla files in your Web server directory. In a remote installation, you can use an FTP program such as the free FileZilla to upload the files in the root directory on the Web server.
Before you begin installing on a remote server, you should check to ensure that PHP is functioning properly. You can easily perform this test by creating a file with your text editor (such as Notepad) named test.php and putting in a single line that reads
<?php phpinfo(); ?>
. Save the file and upload it to the remote server. When you access the file (with a URL such ashttp://www.example.com/test.php
), you will be presented with a multipage screen of PHP configuration parameters. If PHP isn't executing properly, contact your ISP. Be sure to delete this file after it has executed properly because it can reveal a great deal about your Web server to a potential hacker. Additionally, aphpinfo()
page is securely included in the Joomla Administrator interface, so you can obtain the information there.
Once the files have been copied on the Web site directory, access the index.php
file through your Web browser. You should see the first Joomla installation screen shown in Figure 2-4. The first screen holds a list box that shows all the languages available for installation. You can select the desired language and click the Next button to proceed with the installation.
The next screen (see Figure 2-5) enables you to do a pre-installation check to ensure that all of the necessary parts of the system work. If any of the parameters are not set as required by Joomla, you can skip to the "Configuring PHP" section for an explanation of the configuration options to make the necessary changes.
The next screen requires you to confirm compliance with the GNU General Public License. Clicking the Next button will take you to the Database configuration screen (see Figure 2-6). This screen will allow you to configure the URL of the MySQL server (often just localhost
on a local installation), enter the database login, set the database where the Joomla data will be stored, and select the collation sequence to be used by Joomla. Note that some remote Web providers will not allow a program to create a new database. If this is the case with your ISP, simply create the database yourself and enter the database name on this screen. The Joomla installer will create the necessary tables within it. In the Advanced Settings tab at the bottom of the screen, there are also parameters that let you select whether to back up or drop any existing data.
Figure 2-5. The Pre-Installation Check screen will confirm all of the necessary server functionality is working.
Figure 2-6. The Database Configuration screen lets you set the database account and database name parameters.
The Main Configuration screen (see Figure 2-7) enables you to define parameters for your site. Here you can set the site name, the administrator password, and choose to install sample data if you wish. Clicking on the Install Sample Data button will write the data into the MySQL database, which provides a good test to ensure that connectivity is working properly with the database server.
The Finish screen tells you that the configuration is complete and provides buttons either to move to the opening page of the Joomla site, or execute the Administrator interface.
If there is an error along the way where the installer just fails, be sure to turn on the error reporting in PHP (see the section "Modifying PHP Error Reporting" later in this chapter). Sometimes errors will be generated that the Joomla system doesn't catch, and only by viewing the PHP errors generated (which are invisible without the proper directive) can you diagnose the problem.
To obtain the best performance on your Joomla server, you need to start at the bottom: the Apache server. Apache server is one of the most tried and tested Web servers in the world. It's used to run some of the biggest Internet Web sites and some of the tiniest. More than 70 percent of the world's sites use Apache for Web serving. Because of the worldwide deployment and testing, Apache stable releases tend to be rock solid. If a problem is encountered, usually the trouble can be traced back to a faulty configuration, rather than a fault in the server itself.
While initial installation of Apache is easy, there can be difficulties in configuring the system to exactly meet your server needs. In the main configuration file (httpd.conf
), there are more than three dozen different directives. Many of the directives overlap and affect not only the operation of the server but also security and performance as well.
When optimizing Apache to run Joomla most effectively, you will have to check all the configuration directives that the Web server uses. The recommended settings are not one-size-fits-all. How you configure the Web server is governed largely by how you see your audience. Do you have thousands of users who will be visiting your Joomla site for a few minutes and leaving? Or, are you trying to make your site a portal where users will spend a majority of their Web time logged in to your site?
Setting the correct values for some parameters such as those relating to timeouts will take some experience, but you can adjust some settings immediately to make your life as a Joomla administrator easier. The most important directives for Joomla include DirectoryIndex, LogLevel
, and ServerRoot
.
This directive defines what index file will be accessed by the Web server. By default, the directive is set to DirectoryIndex index.html
, which means that only index.html
will be returned to a visitor if a directory without a file is requested. Since Joomla uses index.php
to execute, you must add a PHP attribution to ensure that your server functions correctly.
If you look in the httpd.conf
file, you should find the following directive:
# DirectoryIndex: sets the file that Apache will serve if a directory is requested <IfModule dir_module> DirectoryIndex index.html </IfModule>
For Joomla to execute properly, you need to add the PHP file as a default index page. To accomplish this, you only need an index.php
reference before the HTML reference, like this:
DirectoryIndex index.php index.html
The next time a user enters a URL without a file reference (such as http://localhost/
), the directory will first be searched for index.php
and the index.html
file will only be used if the PHP file can't be found.
The LogLevel
sets how verbose the system will make the error log entries. When initially learning Joomla or testing during development, increasing the LogLevel
can make it much easier to diagnose and correct problems with the system. It can also allow you to catch small problems immediately, rather than later in the life of the system when heavy usage can magnify what were minor defects. As the old saying goes—it is best to kill a monster when it is small.
The default LogLevel
setting is warn
. Following are the eight available settings (listed in ascending levels of verbosity):
emerg
— Only records emergency entries when system has faulted and is unusable.
alert
— Records server warnings when action should be taken immediately to prevent catastrophic failure in one part of the system.
crit
— Stores critical conditions that could impair the functioning of the server.
warn
— Records all warnings the system generates. Note that this is the default setting.
error
— Stores errors in system execution.
notice
— Records conditions that are normal and don't threaten system operations.
info
— Provides informational records with optimization suggestions.
debug
— Records all system generated messages, including the acknowledgment of execution of processes.
When the LogLevel
is set, the log will store messages from that level, as well as all messages from the higher critical levels above it. The messages from the notice
level are always logged, regardless of the LogLevel
setting. For a deployment server, it is recommended that a minimum of crit
level logging be set.
When set to warn
, a log entry might appear like this:
[Sat Nov 18 08:16:04 2006] [error] [client 127.0.0.1] File does not exist: C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/AVE, referer: http://www.yahoo.com/
There is also the LogFormat
directive that can be used to customize the logged entry format. Look in the Apache manual for complete instructions regarding this directive's use.
The directive that determines the location and name of the error log is named, appropriately, ErrorLog
. One handy capability of the ErrorLog
directive is the ability to have any log entries routed to a remote server. You might want the log on a remote server if you want to centralize all of the log information of multiple servers in a single place for analysis. Having the log at a remote location also prevents hackers, if they gain access to your main server, from erasing the log of their actions.
To have the log sent to a remote server, you need only specify a remote syslog server in the directive like this:
ErrorLog syslog:logwarehouse
This will send the log entries to a server called logwarehouse
. For information on setting up the server to receive the error log messages, check out the Wikipedia article on the syslog standard:
http://en.wikipedia.org/wiki/Syslog
The ServerRoot
directive holds the configuration for the root directory of the Web server. On a Linux machine, this directive would likely be set like this:
ServerRoot "/usr/local/apache"
On the Windows platform, it would likely be set to something like this:
ServerRoot "C:/Program Files/Apache Software Foundation/Apache2.2"
This value will be appended to all paths that are not fully qualified. If error logs are not being written to the proper place, or configuration files are not available for access, check the value of this directive.
While the previous sections detailed the most important directives to get you started, there are many others that are relevant to Joomla configuration. Note that many suggested configuration sets for features such as languages, SSL, user directories, and so on, can be found in the /defaults
folder within the /conf
folder of the server. You can look at the included .conf
files to see the configuration sets of directives that will best help you set up the system to provide a particular group of features.
Table 2-1 contains a list of important directives and a general description of each. You will find all of these directives in your configuration file. The proper settings for each will be dependent on your deployment needs.
Table 2-1. Important Apache Server Directives
Directive | Description |
---|---|
| Sets the name of the configuration file. |
| Maps files with the extension specified to a character set. |
| Adds a default character set to be used with MIME type text/plain or text/HTML. |
| Sets a map between a file extension and a language. |
| Sets the ports that may accept connections through the proxy. |
| Determines the directive types that are allowed in an |
| Holds the default duration that a document will be kept in the cache if no expiration is set for the file. |
| Determines the default character set. |
| Holds the expiration time in seconds for a tracking cookie. |
| Sets a custom log file and the format to be used by the log. |
| Defines the MIME tag default language for a visitor. |
| Controls the hosts that are denied access to the Web server. This directive can be tremendously useful when fending off a hacker's attack, or limiting connections from unauthorized or unfriendly visitors. |
| Holds the path of the root directory that will be served to requestors. Most often, this directive specifies the path to the |
| Specifies the error document that will be returned to the visitor in case of error. Note that the Joomla system overrides this operator and returns Joomla error pages. These Joomla error pages may, in turn, be overridden by a specified template to transmit custom error pages to the users. |
| Specifies the path of the error file where error entries are logged. |
| Used to set an HTTP response header. |
| Holds the name of the file to be inserted at the top of a directory listing if the |
| Enables or disables the logging of visitor information provided by the request in the form of RFC 1413 identity. |
| Enables or disables persistent connections/sessions. |
| Determines the length of time before persistent connections/sessions will time out. |
| Holds the precedence of language variants if language is not specified by the requestor. |
| Custom-specifies the IP addresses and ports where the server listens. Also see the |
| Holds the number of requests allowed by a persistent connection. The default setting is |
| Configures a Common Gateway Interface (CGI) script for execution on the receipt of a particular message. If PHP will be run through CGI, this should be configured properly. |
| Only useful if you're running PHP as a CGI execution. In that case, this directive sets the location of the CGI script error log file. |
| When messages are sent from the server to a client, this email address is included. It can be useful for a Joomla administrator to configure this setting so that requests and reports from users may be received by the administrator. |
| Name of host and port to be used by the server. The default setting is |
| Amount of time server will attempt operation before a failure timeout. The default setting is |
| Sets the trace behavior. The default condition is |
| Holds the location of the transfer log. |
| Specifies user-specific directories. If your server will be hosting multiple users with various Joomla installations, user directories can be added here. |
| The root of the virtual document. This directive can be important if you are setting up a multi-host system to run Joomla. |
| The IP number of the virtual document. |
The Apache log files can be your best friend when it comes to monitoring your Web server. Although there are some Joomla extensions that can record site statistics, their use is not recommended because of the decrease in server performance. Therefore, if you want to monitor your closely traffic, you must do it through the actual Web server log files. There are three primary types of log files: access, error, and install.
Monitoring these log files can help you do the following:
Balance traffic — If your Web site becomes popular, it is very important that you understand the stress load that will be placed on the server. You should know the peak hours, as well as the hours when there is little activity. In special circumstances (following an event reported by the media), you may receive the mixed blessing of a flood of traffic. In these extreme circumstances, you may choose to shut down processor-intensive services (such as the search function) until the storm has passed. With the slow times, you'll definitely want the opportunity to back up your site.
Examine your user base — The log files can generate a huge amount of information that can be extremely useful to a system administrator. Wouldn't you like to know the percentage split of the type of browsers that visitors are using? It's often surprising. What if half of your traffic comes from the Netherlands? Wouldn't that be important to the future focus of your content? And wouldn't it also be useful to know which Web site is sending all the Netherlands traffic in your direction? These are just a few of the questions you'll be able to answer by taking a serious look at the log files.
See what errors have occurred — You need to know if one of the server modules isn't loading properly, or if the server is generating errors when it attempts a particular function. The error logs can provide vital debugging information to get the server running properly, and ensure that it stays that way.
Watch for hacks and system attacks — The Web is like the old Wild West, and there are very few rules in place. In the 1970s, the United States had minor problems with teenage hackers breaking into computer systems to play around. Nowadays, the venue for hacking is global, and the hackers often have less benign motives. The log files can often reveal a pattern of access, particularly when a hacker is using a piece of software such as a bot that indicates your system is under attack. Once you know an attack is being attempted, there are a great number of remedies you can apply—right down to blocking the IP address that the hacker is using. But you can't stop anything if you don't know it's happening, and examining the logs can often provide an early warning that your system is in play.
After you install Apache and run it for a short time, check out the /logs
directory at the Apache directory root. You will see the three main log files here. Take a look at each file with a standard text editor so that you will be familiar with them. As you progress through this book, you will return to these logs to understand the adjustment and maintenance of your Joomla site.
The /modules
and /extensions
folders contain all of the Apache plug-ins that allow the Web server to interact with other software, including PHP. For a Joomla installation, you're unlikely to modify these folders. However, if you experience a problem or begin having some strange results, it is often a good idea to check the version numbers of the individual modules to determine if there is an upgraded version available.
On the Linux platform, you can generally find the version of a module or extension using the file
command like this:
file mod_authn_dbm.so
On the Windows platform, you can check the version numbers of each extension or module simply enough by looking at the version tab on the properties of the file, as shown in Figure 2-8. You can do a search on the Web or the Apache Web site (www.apache.org
) to see if other users are having difficulty with the version of plug-in installed on your system. If you post a question regarding your problem, be sure to include the version numbers of the plug-ins that you're using so that responders can accurately assess your situation.
Not all modules located in these folders are active. You can use directives in the httpd.conf
file to individually activate or disable a plug-in. Note that additional modules not included with the core install are available for download here:
http://modules.apache.org/
By default, all of your Web content is stored in this directory. You have to be particularly careful on the security settings that you allow for the /htdocs
folder. Since hhtdocs
files have execution privileges for PHP code, if a hacker can find a way to place custom code or a virus into this directory, the potential for mischief is significant. Chapter 14 discusses the best methods of configuring this folder for security.
PHP is much easier to configure than Apache, but it can also present many more security dangers. Since PHP is actually a code execution engine, you must be sure that it is properly configured so that there are no security holes. If compromised, a hacker can potentially not only gain access to confidential information and delete existing content but also set up the platform to execute a program that performs additional mischief.
For Joomla to operate properly, your Web server should be running a version of PHP that is 4.3.0 or greater. Before you begin installation (particularly on a remote server), check the PHP version to avoid any compatibility problems.
Common hacker tricks including setting up a false user interface to collect personal information from your Web site visitors (and sending the data to themselves), creating an infection vector for the distribution of viruses, initiating denial-of-service attacks originating from your server, and even attempting email spam origination.
One of the simplest ways of determining current PHP settings is to use the phpinfo()
code line that you used to check whether PHP was operating in the first place. A file with the single line that reads <?php phpinfo(); ?>
will display the configuration screen shown in Figure 2-9.
Scrolling down to the Configuration section, you can see all the current directives and their settings. Further down are individual sections for each plug-in—many showing their version numbers for easy reference. Additionally, the PHP Variables section near the bottom will show you the values of existing PHP variables, which can be useful both in understanding the system and tracking down possible bugs.
If you are doing a manual compile of PHP to use with Joomla, there are three necessary support libraries that you must include: MySQL, Zlib, and XML. Without these libraries in the compile, Joomla will be unable to execute properly.
Figure 2-9. The phpinfo() command will display the complete PHP settings in the Configuration section.
The following PHP settings are checked by the Joomla system as it is loaded and the recommended settings are:
Safe Mode
— Set safe_mode
to Off
.
Display Errors
— Set display_errors
to On
(only on a staging server).
File Uploads
— Set file_uploads
to On
.
Magic Quotes GPC
— Set magic_quotes_gpc
to On
.
Magic Quotes Runtime
— Set magic_quotes_runtime
to Off
.
Output Buffering
— Set output_buffering
to Off
.
Session auto start
— Set session.auto_start
to Off
.
Register Globals
— Set register_globals
to Off
in the Joomla globals.php
file.
Register Globals Emulation
— Set RG_EMULATION
to Off
() in the Joomla globals.php
file.
Zlib compression
— Set zlib.output_compression
to On
.
You should also have the Joomla file configuration.php
in a directory with Writeable permissions so that you can make changes to the Joomla system setting from within the Administrator interface. The Session save path should also be writable; otherwise, a number of Joomla errors will occur. By modifying the PHP directives, you can change the location of objects such as the Session path.
There are many PHP settings, but not all are directly relevant to a Joomla installation. Many settings you will never need, so this chapter only details the most important ones to a Joomla user. Of the directives listed that are critical to a Joomla user, the one that changes the error reporting display is the most important.
To allow PHP to display errors (very helpful, especially when debugging a template or new extension), you can modify the display_errors
setting in the php.ini
file. To turn on display_errors
, use a line like this:
display_errors = On
By default, this directive is set to Off
to prevent hackers from obtaining extra information about the back-end of the Web site. In fact, the errors will still be written into the Apache error log file as long as the following directive is set:
log_errors = On
By default, log_errors
is set to On. However, especially when you are debugging a file and clicking the Refresh button in the browser, it is inconvenient to constantly reopen the error log to see if the problem is resolved. It is much easier to see the error information displayed inline in the browser window with the presentation generated by the code before the error occurred.
You should turn off the
display_errors
functionality on all deployment servers. The error information can reveal database settings, path names, server names, server addresses, and a variety of other sensitive information that can be used against your server.
As with Apache, you can set the verbosity of the error reporting. You can use the following settings:
E_ALL
— Include all errors and warnings except E_STRICT
errors.
E_ERROR
— Include fatal run-time errors.
E_RECOVERABLE_ERROR
— Include nearly fatal run-time errors.
E_WARNING
— Include run-time warnings.
E_PARSE
— Include compile-time parse errors.
E_NOTICE
— Include run-time notices.
E_STRICT
— Include run-time notices that suggest code changes to ensure forward compatibility with future PHP versions.
E_CORE_ERROR
— Include fatal errors that occur during initial startup.
E_CORE_WARNING
— Include startup warnings.
E_COMPILE_ERROR
— Include fatal compile-time errors.
E_COMPILE_WARNING
— Include compile-time warnings.
E_USER_ERROR
— Include user-generated error messages.
E_USER_WARNING
— Include user-generated warning messages.
E_USER_NOTICE
— Include user-generated notice messages.
By default, error reporting is set to E_ALL
, but you can modify it to also include E_STRICT
warnings by using the OR (|) operator like this:
error_reporting = E_ALL|E_NOTICE
To include all errors, yet exclude a particular category of error, by using the AND (&) and NOT (~) operators directive like this:
error_reporting = E_ALL & ~E_USER_NOTICE
You may not understand how important error reporting can be to Joomla users until you run into a situation that you can't understand. For example, you may get a blank screen when trying to access Joomla with no indication that there is even a problem. When the errors are displayed, you can immediately begin to track down the problem.
On first install, the blank screen is most likely a session path problem. With errors turned on (or you can look in the error log), you'll see an error like this:
Warning: session_start() [function.session-start]: open(C:DOCUME~1dannyLOCALS~1Tempphpuploadsess_6lp0kg4fu0fho3lvagt3je8d74, O_RDWR) failed: No such file or directory (2) in C:Program FilesApache Software FoundationApache2.2htdocslibrariesjoomlaenvironmentsession.php on line 234
The error states that the server can't start a session because there was "no such file or directory." This most likely means that your PHP server is not set up correctly to access a directory where it has read and write permissions.
Open the php.ini
file, and search for the session.save_path
directive. You may find that the path to this file is inaccessible to the Web server. Modifying this directive to a path within the Web server directory will most likely cure the problem on a staging server. On a deployment server, you should use the tools provided by your ISP to modify the permissions to reach the desired folder.
On the Windows platform, the original directive path reads as follows:
session.save_path="C:DOCUME~1dannyLOCALS~1Tempphpupload"
To solve the problem, simply create a folder named php_sessions
that is located inside the Web root directory and point the PHP server to that directory. After creating the new directory, change the session path directive to read as follows (all on one line):
session.save_path="C:/Program Files/Apache Software Foundation/Apache2.2/htdocs/php_sessions"
For a remote Linux install, you may have to change the Linux PHP parameter from the following:
session.save_path = /var/php_sessions
Set it to a php_sessions
folder where you have the top-level access:
session.save_path = /billcat/ws/b1833/pow.dan/php_sessions
Reboot the Apache server and Joomla should work now! From this simple example, you can see how displaying errors can help your problem solving so that you're not left in the dark. This directive is just the tip of the iceberg for configuring PHP.
Table 2-2 shows an abbreviated list of PHP directives that are important to Joomla execution. While the first column displays the directive itself, the second column shows either the possible settings or the type of setting that can be used. The third column contains a brief description of the function of the directive.
Before you begin changing any of the PHP settings, you should make a quick backup of the php.ini
file so that you can always return to the original settings. Since the .ini
file is a simple text file, it won't take up much room on your local drive, and you may choose to make a new backup for every major alteration.
Once you begin making changes to the PHP directives, remember that you must reboot the Apache or IIS servers for the changes to take affect. These directives are initialized when the PHP service is booted, so restarting the Web server will read the new directives.
As an alternative to making a backup of the .ini
, you can simply make the current directive setting line a comment with a semicolon (;) character at the beginning of the line. Then you can put in the new directive on the next line.
Table 2-2. Important PHP Settings
Directive | Settings | Description |
---|---|---|
|
| Determines the directory where all PHP scripts will be executed. Best for Joomla execution if left empty. |
|
| Disables the response header broadcast that PHP is available for execution on the server. In most deployment situations, this setting defaults to |
|
| Sets the directory where PHP extensions and modules are loaded from. If you're having problems with a module such as MySQL, check this directive to determine where it is pointing. |
|
| Determines whether PHP will support file uploads. For many functions in the Joomla system, including uploads for templates, extensions, and images, should be set to |
|
| Specifies a list of directories where the require/include functions look for files. |
|
| Determines whether single and double quotation marks, backslashes, and null characters are automatically encoded or escaped. Joomla recommends this setting to |
|
| Determines whether single and double quotation marks, backslashes, and null characters located in an external resource are automatically encoded or escaped. Joomla recommends this setting be |
|
| Sets the maximum time limit in seconds that a PHP script can execute. A setting of 0 disables the maximum limit. By default, this is set to |
|
| Sets the maximum time limit in seconds that a process can parse input parameters. This time also governs how long the system will wait for an upload to complete. By default, it is set to 60 seconds, so if you are expecting uploads to take longer, you will have to change this parameter. |
|
| Sets the memory limit. |
|
| Limits functionality in a shared-server environment (particularly with remote hosting ISPs). Some of the functions disabled by safe mode include file execution (beyond PHP files), |
|
| Sets the maximum size, in megabytes, that is allowed as an uploaded file. The default is set to |
|
| Sets the path of the temporary directory where uploaded files are first held. |
|
| The base name of the directory used on user's home directory for PHP files (for example, |
|
| Sets the ability to enable |
|
| Defines an alternate compression library if the standard library is not available. By default, this is set to null to use the standard library. |
If you're changing the directive for a reason, I would suggest adding an additional line comment describing the reason for the change. When you configure your next server, you can simply reference the existing .
ini
file and have a lot better idea of what settings you should choose.
MySQL is blessedly simple to get running initially. The real opportunity lies in tuning the performance to provide the fastest response to Joomla system requests. There are many parameters in MySQL that allow you to specify exactly how sessions and memory are used. You can even load-balance MySQL across several servers if your site were to become extremely popular.
Configuring MySQL properly has more to do with monitoring actual usage than predicting bottlenecks. The most common barriers to optimum MySQL performance occur in local drive seeks, reads, and writes. It is only by watching the actual usage patterns that you will be able to determine how best to modify your system.
The setup of MySQL is at the same time the simplest and the most complicated of the servers used by Joomla. I have never had a MySQL installation fail on a fresh system, while I have had problems at one time or another with the stable release of all the others. That said, there can be problems getting MySQL to communicate effectively with the other servers—PHP most notoriously.
On the Windows platform, if you execute Joomla and it shows that MySQL isn't active, be sure that you've rebooted your system since installing PHP. To correctly access PHP extensions, the Path
variable must be set to make the PHP directory available. PHP automatically adds the path to the Path
setting. However, the Path
variable is only read and activated at boot time, so any changes to the variable are not active until the system has been rebooted after installation.
You can check to make sure that the Path
variable is set properly by going to Control Panel
This
Path
string is generally fairly long, so when I need to examine or edit it, I select the variable, and click the Edit button, which will display the field in a text box. The entire path string will be selected, so use Ctrl+C to copy it to the Clipboard. Then paste the string into an editor like Notepad where you examine it and make changes more easily.
Verify that the path to your PHP directory is found in the string. If it is missing, you can change the Path
string by simply adding a semicolon (;) after the last entry and then typing the PHP path. Reboot the machine and try again. That corrects the problem in a majority of cases.
Once you've moved past the precheck stage of Joomla, you may get to the Database Configuration screen and begin to have problems. You may enter the correct MySQL server address, username, and password, and still the system notifies you that it "can't connect." In these circumstances, you probably have MySQL 5 installed and are using the default version 5 of the password security.
There are two methods of remedying this problem. You can turn off the new-style passwords for the entire MySQL system, or you can set an individual user password to use the old-style authentication. If you're using MySQL for applications other than Joomla, I would recommend you configure an individual password to use the old-style authentication.
To set a password to the MySQL version 4.1 authentication type, execute the MySQL command line utility. At the mysql>
prompt, enter the following line, substituting joomlaAdmin
for your existing username and mypassword
for the password you want to use:
SET PASSWORD FOR joomlaAdmin' = OLD_PASSWORD(password'),
The system will respond with a statement that 0 rows are affected, but the command should set up the authentication properly. Execute the Database Connectivity login again, and Joomla should now be able to connect to the system.
To change the entire MySQL authentication procedure, open the MySQL Administrator application and click the Startup Variables button. Select the Security tab and scroll down until you see the "Use old passwords" option. Check the box to the left of the option. To activate the old passwords authentication, click on the Service Control button and restart the MySQL server.
With the database connectivity working, your MySQL problems may be over—or maybe not. In Joomla, when attempting to install the sample data, if you have display errors turned on or you check the Apache log file, you may see an error such as this:
SQL=BLOB/TEXT column 'comments' can't have a default value: ...
This type of error indicates that you are probably running MySQL in strict mode. That means that either STRICT_TRANS_TABLES
or STRICT_ALL_TABLES
is enabled. The strict options make it so that a single error writing a record will result in the entire operation being canceled.
From the MySQL Administrator application, you open the Startup Variables pane, select the Advanced tab, and check the SQL Mode option, as shown in Figure 2-10. If either of the strict modes is stored in the text box, you can simply clear the checkbox to deactivate the option and click the Apply Changes button at the bottom of the screen.
Since this is a startup option, it will not be activated until you either restart the MySQL services (under the Service Control pane), or reboot your machine.
The MySQL setup is handled primarily by the Joomla system itself. However, to really understand how the system is working, you must examine the database objects that Joomla constructs. The best way to do that is to download the MySQL Administrator application. It isn't installed natively with the MySQL server. It is free, however, and you can download it as part of the MySQL GUI Tools from the Web site at http://dev.mysql.com
.
When you execute the application, you'll be presented with a general status screen, as shown in Figure 2-11, which will display the general parameters of the current installation. Along the left side of the screen, you can see the various function icons such as Service Control (functions to start, stop, and restart the MySQL server), Startup Variables (configuration parameters for MySQL execution), and so on.
As an administrator, you will spend most of your time working in the Catalogs area available from the last button of the left selection pane. If you click on the Catalogs button, the pane below will fill with a listing of the schemata of the databases currently available on the MySQL setup. If you click on the Joomla database listed in the pane (in this case, joomla15
), all of the tables of the database will be displayed in the pane to the right, as shown in Figure 2-12.
You've already seen two configuration switches in the Startup Variables that can eliminate problems when executing Joomla. However, by using the Joomla data in MySQL in the manner you would approach a database, there are more powerful possibilities.
You may want the ability to query a Joomla table for any reporting data you might need. For example, there is no native way in Joomla to obtain a summary all of the content items in your Joomla database that don't have a meta-description and are, therefore, indexed poorly by search engines. To find these items, you only need to do a query of the metadesc
field of the jos_content
table and display all of the articles that have an empty field.
Select the Joomla database in the MySQL Administrator application, and right-click on the jos_content
table. When the context menu is displayed, select the Edit Table Data option, as shown in Figure 2-13. A window will be displayed showing all of the data currently in the table.
Notice that the top of the window displays a query like this:
SELECT * FROM 'joomla'.'jos_content'
That general query displays all of the records in the jos_content
table. You can use a simple SQL WHERE
clause to filter the content to display only the records you want. Add a WHERE
clause to return only records with a blank metadesc
field like this:
SELECT * FROM 'joomla'.'jos_content' WHERE metadesc = ""
When you click on the Execute button to run the query, the window will display only those records that have no meta-description. Under the File menu, you can export the result set to a number of file formats (including XML, HTML, CSV, and Excel), so you can use the report as a checklist to add the necessary descriptions to the flagged items.
No user besides the administrator should ever have access to the user table. The user table holds the privileges and user data, so anyone who has access to this table essentially has control over the entire system. However, if you are the Joomla administrator and you installed MySQL long ago, you may not need to access it for quite some time. That may lead to the embarrassing situation of your forgetting the MySQL password.
If you have forgotten a password for a MySQL login, while there is no method for recovering the password, you can reset it. This technique will work even for the root or administrator password, so be careful to use it only on systems where you have permission. Create a text file, enter the following line, and save the file as resetpwd.txt
at the root directory:
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('password'),
On the Linux platform, you can execute the file with a command like this:
mysql_safe -init-file = ~/resetpwd.txt &
On a Windows system, execute the following line at the command prompt:
C:mysqlinmysqld-nt — init-file=C: esetpwd.txt
After the password reset, be sure to delete the resetpwd.txt
file because you don't want something so potentially dangerous to remain on your local drive where some hacker might find a way to execute it.
You probably already have a good deal of experience configuring Joomla to meet your needs. However, you may have overlooked some of the less obvious features that can dramatically change how well the site can be operated.
If you have problems with your Joomla install, you can simply copy over the files. Be sure also to delete configuration.php
because this file is created by the Joomla installer and tells the system that it has already been installed and configured. If this file isn't found in the Joomla directory, the installer will execute automatically.
Although the Joomla development team recommends that you make all administrative changes from within the Administrator interface, there are some times when direct modification is more advantageous. If you are administering multiple Joomla sites, it is possible to write a macro to make batch changes to the multiple configuration files that would be tedious to accomplish through the GUI interface.
The central configuration data for Joomla is contained in the configuration.php
file. All of the Joomla settings are contained within a PHP class called JConfig
. If you open the configuration settings file in your text editor, you'll see the file begins with the class definition like this:
class JConfig {
The file is then divided into various portions. Site Settings
is the first section of parameter values. It will look something like this in your editor:
/* Site Settings */ var $offline = 0'; var $offline_message = This site is down for maintenance.<br /> Please check back again soon.'; var $sitename = 'Joomla!'; // Name of Joomla site var $editor = 'tinymce'; var $list_limit = '20'; var $legacy = '0';
Note that the configuration file included here is in a pre-install state. Your configuration file should match the parameters that you've already set.
The Database
configuration section will look like this:
var $dbtype = 'mysql'; var $host = 'localhost'; var $user = ''; // MySQL username var $password = ''; var $db = ''; var $dbprefix = 'jos_';
The Server Settings
configuration section will look like this:
//Change this to something more secure var $secret = 'FBVtigIl5lApEU4H'; var $gzip = '0'; var $lifetime = '900'; // Session timeout value var $error_reporting = '−1'; var $helpurl = 'http://help.joomla.org'; var $xmlrpc_server = '0'; var $ftp_host = ''; var $ftp_port = '';
var $ftp_user = ''; var $ftp_pass = ''; var $ftp_root = ''; var $ftp_enable = ''; var $tmp_path = '/tmp'; var $log_path = '/var/logs';
The Locale Settings
configuration section will look like this:
var $lang_site = 'en-GB'; var $lang_administrator = 'en-GB'; var $language = 'en-GB'; var $lang = 'english'; var $offset = '0'; var $offset_user = '0';
The Mail Settings
configuration section will look like this:
var $mailer = 'mail'; var $mailfrom = ''; var $fromname = ''; var $sendmail = '/usr/sbin/sendmail'; var $smtpauth = '0'; var $smtpuser = ''; var $smtppass = ''; var $smtphost = 'localhost';
The Cache Settings
configuration section will look like this:
var $caching = '0'; var $caching_tmpl = '0'; var $caching_page = '0'; var $cachetime = '900';
The Debug Settings
configuration section will look like this:
var $debug = '0'; var $debug_db = '0'; var $debug_lang = '0';
The Meta Settings
configuration for the site will look like this:
var $MetaDesc = 'Joomla! - the dynamic portal engine'; var $MetaKeys = 'joomla, Joomla'; var $MetaTitle = '1'; var $MetaAuthor = '1';
The Statistics Settings
configuration section will look like this:
var $enable_stats = '0'; var $enable_log_items = '0'; var $enable_log_searches = '0';
The Search-Engine-Optimization (SEO) Settings
configuration section will look like this:
var $sef = '0';
The Feed Settings
configuration section will look like this:
var $feed_limit = 10; var $feed_summary = 0; } ?>
Be sure to make a backup of your settings file before making any changes. If a change of setting renders Joomla inoperative, you can restore the system by pulling the backup copy and putting it in place. Also ensure that you don't store the backup file in the directory path of your Web server. For example, if you name the backup of configuration.php
as configuration.backup
, if a hacker accesses the URL with that filename, it will not be recognized as a file type and the Web server will simply output it as plain text—exposing private information.
Joomla passwords are often forgotten by users, and the Joomla Administrator interface allows the system admin to reset a user password. However, if you have ever had occasion when you've forgotten an administrator password, you know the frustration of being locked out of your own system. While I was writing this book, I myself had a hard drive crash and had yet to change the Joomla-generated random password of numbers and letters. Needless to say, I couldn't remember the password that I had recorded in a file that was lost in the crash.
Each password in Joomla is stored as a MD5 hash value, so you won't be able to recover the lost password. However, you can reset the password by accessing the table that holds all of the user information.
Message-Digest algorithm 5 (MD5) is a security algorithm that will take a string input and generate a fixed size output number. It is an Internet standard described in RFC 1321.
The length of the number for MD5 is a 128-bit (generally a 32-character hexadecimal number) hash code. Security algorithms of this type are worked so that a small change in the string input (such as the addition of an extra letter) produces a very large change in the output hash. Hash codes are generally secure because of the massive amounts of processing that would be required to decipher the initial string given only the code. However, there are more secure algorithms (such as SHA-1) that Joomla may use in the future.
To begin, you will need to execute the MySQL Administrator application. If you're using an online application such as php My Admin, you will be able to perform essentially the same steps.
Begin by loading the MySQL Administrator utility. You will need to select the jos_users
table in the Joomla database. Note that if the Joomla database is properly secured, you will need administrator or root privileges to access the jos_users
table. If you don't have these permissions, check with the system administrator to either reset the password for you or give you the necessary access.
If you right-click the mouse, the context menu will give you the option of Edit Table Data, as shown in Figure 2-14.
The table editor should open and display all of the current Joomla users. In my case, I needed to reset the admin password, so I went to the row for the admin user. Scroll to the right until you see the column labeled "password." That column will display the MD5 hash of the current password.
Select the field for editing. On the Windows platform, that means pressing the F2 key. You will now need to enter the MD5 hash of a known password. Enter this hash, which represents the actual word password:
5f4dcc3b5aa765d61d8327deb882cf99
When you've finished entering this long string, click on the Apply Changes tab at the bottom of the screen, as shown in Figure 2-15.
Now you can log into the account by typing the appropriate user name and the word password as the password. Be sure to go immediately to the User Manager and change the password to a new one that is more secure.
If you don't have easy access to MySQL Administrator, or if you would prefer to use the MySQL command line, the reset can be performed from there. To perform the password reset, enter the following command:
UPDATE jos_users SET password='5f4dcc3b5aa765d61d8327deb882cf99' WHERE name='admin';
Be sure to substitute the user account you wish to use in place of the admin text in the presented code. This code will replace the current password value with the hash for the word "password."
Now that you can see how easy it would be for a hacker to gain access to your Joomla system, it is critical that you secure your MySQL installation against outside attack. Be sure to follow the security guideline suggestions in Chapter 14.
While this chapter has primarily described general configuration, all Joomla servers should not be configured the same way. When you are doing your initial site construction and later development, you should have a development or staging server where you can freely install extensions, make rough changes to the system, and have full debugging information reported for the fastest resolution to problems. The staging server generally has little in the way of security to allow the broadest access and testing.
When the site is ready for real-world use, it is then transferred to the deployment server. The deployment server may be a remote Web host (such as SiteGround.com
), or it may be a machine different from the staging server that has all the proper security configurations in place. Deployment servers are also called production servers.
For a staging setup, you want to receive the most information available, including error explanations, performance metrics, and login reports. In contrast, in a deployment environment, this type of monitoring exacts a tremendous performance penalty. Logging and debugging routines use a significant amount of processing resources, which have no place in a deployment system. Further, the debugging information provided should be hidden, since it can be used by hackers to locate penetration points in your system.
On the Windows OS, there is a Joomla option that can be very useful for testing purposes—particularly if you want to evaluate a prerelease or beta version of Joomla. This option, a Joomla Standalone Server (JSAS), is a self-contained version of Apache server, PHP, MySQL, and Joomla that doesn't require actual server configuration. In fact, JSAS allows you to install multiple separate sites on a single server and manage them through a single interface. You can download the JSAS from
jsas.joomlasolutions.com
.
Joomla doesn't have a formal debugging structure, so most debugging occurs through a variety of error displays, strategically located print statements, and examination of error logs. In most cases, before deployment of Joomla, you will want to configure your server for the maximum amount of error reporting. When the system "goes live," you will need to turn off these options because they potentially give hackers information that can be used against your site, and the debugging systems create extra overhead that can negatively impact the performance of the server.
Because Joomla (and most PHP applications) is developed with a make change, refresh browser, alter change, try again methodology, the more information supplied by the server when an error is encountered, the easier it will be to locate and correct the problems.
Error codes (provided they accurately reflect the problem encountered) can be the most useful tool in debugging a Joomla application. The PHP messages are particularly helpful in that they describe the problem and cite the line number and file where the error occurred. A typical component error would appear like this:
Notice: Use of undefined constant kasjda - assumed 'kasjda' in C:Program FilesApache Software FoundationApache2.2htdocscomponents com_contentcontent.php on line 32
Web servers (whether Apache or Microsoft Internet Information Server) keep extensive error logs that record problems encountered by the server. These logs can be invaluable for study to locate both problems that could fault the server, and also smaller bugs that, while not halting the application, prevent it from functioning as desired. For example, if Joomla intends to write a poll result into the MySQL database, but cannot find the proper table, an error may be generated unseen by the administrator. The log, however, will show the failed SQL insert. By examining the log, you can correct these small errors.
Once you have thoroughly configured and tested your Joomla system, you will want to make it available to the world of the Internet. The needs of a deployment server are very different to those of the staging server. With a deployment server, you are concerned primarily with security and performance. Many settings that are perfect for debugging can provide potentially compromising information about your Joomla system to hackers.
Additionally, most of these configurations that help you to find problems in your system will also slow down its ability to quickly serve Web pages. By streamlining the configuration, you can obtain substantial performance increases.
You should systematically check and change all of the default accounts and passwords on the system. When a hacker tries to breach a system, those accounts and passwords are known points of entry and as such, will often be the first place to try.
Default accounts and passwords include the following:
MySQL — The root
user is generally the superadministrator of the server. Many default installations leave the password to the account blank. Be sure to change the default password. You might also consider creating a different superadministrator account and limiting the capabilities of the root.
Joomla — The default superadministrator account for Joomla is named admin. Consider changing the user name to jadmin or something of the sort so that a hacker's first guess will not render half of the username/password pair.
MySQL includes fairly robust security, but even the access path for MySQL access by Joomla is stored in plain-text files on the Joomla server. Therefore, you should change as many possible variables from the defaults to minimize the possibility of educated guesses that may lead to the penetration of your system.
Realize that any example password settings used in this book should be changed as well. This is a published work and, as such, publicly available. The accounts and passwords in this book may at some point be added to the standard hacker password dictionaries for automated testing. At a minimum, be sure that any passwords you use from this book are changed before your site is deployed.
Error messages can provide clues to the internal structure of your Web site, including folders, databases, tables, and so on. While messages are critical for debugging on a staging server, on a deployment server, they give a potential window into your system. Therefore, make certain that any display of errors is minimized for your final deployment installation.
Joomla installation and configuration can often seem straightforward until you run into a problem. This chapter has provided an overview of the ways to install and configure Joomla by doing the following:
Understanding the configuration settings of the Apache server through the httpd.conf
file and the various directives that can help you streamline your Joomla installation.
Improving the performance of the server by modifying the debugging and logging settings. By increasing the amount of logged information, you can more accurately determine the source of problems and potential problems.
Refining the PHP installation by changing settings in the PHP.ini
file. Changing the PHP settings can prevent timeouts and help maximize security.
Examining a comprehensive MySQL installation that can help you use the data stored in your database for everything from reporting to a custom password reset.
Adopting a staging server so that comprehensive testing and debugging of a Joomla site is possible without exposing the system to the slings and arrows of the outside world.
Upgrading the staging server installation to a full deployment configuration.
Fine-tuning the configuration of a Joomla site includes much more than streamlining the server performance. The visual aspects of a site presentation can be a key factor in representing a Joomla site as a professional and substantial information portal. Chapter 3 will help you create an attractive custom template that you can use as a foundation for creating your own templates in the future.
18.217.8.82