With your own dedicated server, many of the configuration tasks fall squarely on your shoulders. PHP is no exception. Most of the PHP configuration settings are found in the php.ini file, which is often located in /etc/php.ini on Linux servers. You must edit the file as root, and any configuration changes will only take effect after you restart your web server.

For example, a common setting that system administrators might want to change is the memory limit, which is generally too low for many web applications. Edit php.ini and find:

memory_limit = 16M

You can then change it to something like:

memory_limit = 64M

Save the file and then restart Apache:

service httpd restart

To see if changes have come into effect and to look at any other configuration settings you might want to change, you can create a phpinfo.php file in a regular document root of one your websites. Edit the file and add the following code:

<?php

?>

Save it and then load that file from your web browser. It will print out a list of all PHP configuration settings.

Continue reading: Configuring PHP: php.ini and phpinfo

StartServers

You have already configured Apache to control the number of child processes to keep running. This directive will tell Apache how many to start initially when your server first boots. Depending on the level of traffic you expect to get, this number may be low or high. For general purposes, 5 should be sufficient.

StartServers 5

Timeout

This controls the amount of time Apache waits to do a number of tasks. For example, it controls how long it waits for a GET request (i.e. for someone to download a page or images) and also how long it will allow a POST request (i.e. when someone is sending something on a form). The default is 300, but you can lower it to something like 150 to help reduce some server strain when it is waiting on failed attempts and also help prevent DoS attacks on PHP scripts like message forums. Do not set it lower than 90, however, as this may cause some of your site visitors to get timeout errors on working content.

Timeout 150

Once you have made all of the changes you want to make to your Apache configuration file (httpd.conf), you need to restart Apache:

service httpd restart
or
/etc/init.d/httpd restart

These tips are not the only ones you can use to optimize your Apache installation, but they should help you get a head start.

Continue reading: Apache HTTP Server Optimization: Part 3

In a previous post, I explained how to use chmod to change file permissions and also provided some security tips to ensure your file permissions are not more permissive than they need to be. Looking back on those posts, I think it would be useful to list some common file types and the maximum permissions that those files should have. The maximum means that there is no legitimate reason for those files to be any more permissive.

(r = read, w = write, x = execute) (Owner, Group, Other)

1. Executables - CGI files - Perl scripts, for example, often need to be executable. 755 (rwx r-x r-x)
2. Regular HTML and PHP files - These only need to be read by the outside world. 644 (rw- r– r–)
3. Private files - Sometimes text data files are stored on the server but do not need to be seen. 600 (rw- — —)
4. World writable - use these only if absolutely required by the application. 666 (rw- rw- rw-)
5. Full permissions - almost never necessary and could cause security problems. 777 (rwx rwx rwx)

There are other combinations, but these are the common permissions for files on most Linux servers. Only change file permissions if necessary. Otherwise, keep them as conservative as possible. This will ensure the security of your website(s) and server.

Continue reading: Permissions for Common File Types

Yesterday, I highlighted some of the critical Joomla security issues that you should consider. Here are a few more you should add to your list:

All of these can be set within your local php.ini directory (if your server allows it), rather than manipulating the global one for the server.

1. Use the “disable_functions” to prevent the use of some dangerous PHP functions:
Example: disable_fuctions = show_source, exec, phpinfo

2. Use open_basedir. This will limit which files PHP can opened to the directory tree specified (i.e. in your home folder)
Example: open_basedir = /home/webguy/www/html

3. Disable register_globals. Joomla will actually warn you if you have this enabled:

Example: register_globals = 0

4. Disable allow_url_fopen. This is used when you want to create PHP wrappers to open remote URLs. You can probably imagine the dangers that would create if exploited.
Example: allow_url_fopen = 0

Source: Joomla Security Checklist

Continue reading: More Joomla Security Tips

Joomla is a powerful free and open source content management system. It has become very popular, and many web hosting provider offer instant installer scripts that can automatically install Joomla onto a customer’s website. In certain, situations, however, you may prefer to install Joomla yourself. When you do, there are certain security issues you should know.

1. Delete the “install” directory. Joomla tells you to do this, and if you forget, the results can horrific.

2. Chmod configuration.php to at least 644. No one should be able to access your configuration.php file. The only reason to even leave it as 644 and not 600 is that some web servers on shared hosts require PHP files to be readable by the web server, which is a different user than the site owner.

3. Backup early and often - Create backups of Joomla’s MySQL database. If anything ever does go wrong, you will have a backup.

4. Install mod_security - ModSecurity is an application firewall designed for web applications like Joomla. It will protect you where a network firewall cannot.

5. Secure your database - Setup Joomla to access the database with a user with limited privileges, and make sure the password is not easy to guess.

There are many more security issues you should consider. Over the coming days, I will highlight some of them. Hopefully, they will help you keep your Joomla installation stable and secure.

Continue reading: Joomla Security Tips

Whether your goal is marketing or simply communicating with your website’s online community, there comes a time when you need to send out a mass email. I am not suggesting you spam your customers or users. What I do suggest, however, is that you have some way of contacting people who were interested enough to join your site or sign up for updates.

Many content management systems, such as Joomla, have mass email features built-in that allow you to easily send mail to your users. Usually, they will present you with two options: PHP Mail or SMTP. PHP Mail essentially calls a particular PHP function that will contact your mail server (such as Sendmail or Postfix) to send the email. SMTP functions just like a regular email client and will login to an email account.

From personal observation and the advice of people who have tried it, unless you have some pressing reason to avoid SMTP, you should prefer it over PHP Mail. Although you may not notice the difference for small mailing lists, something larger can bog down your server when using PHP Mail. It works fine for occasional contact forms, but for mass emailing, you should just go directly to the source: your mail server.

Continue reading: PHP Mail Vs. SMTP Mailing Lists

A “safe mode” in general is a term used to refer to software that has all but the most critical components disabled in order to increase stability. Often times when there is a stability or security issue, running in safe mode will allow the user to still access the system and fix any problems.

In PHP, safe mode is primarily a security option that prevents would-be attackers from using PHP scripts to execute operating system commands. Theoretically safe mode is supposed to be a method for increased web application security. It is intended to be run in shared hosting environments and is not needed on a VPS or dedicated server. In PHP 6, safe mode will be removed.

The downside of PHP Safe Mode is that certain scripts and web applications do not function properly with it enabled. Server administrators can disable it and take other security measures to harden their Web applications, and individual users can also work around it, although they should check with their web host first to make sure they do not compromise security.

Most web developers and website owners dislike safe mode because of the limitations it places on scripts. If you feel strongly about it, you should find out if a web host uses it before subscribing to their service.

Photo Source: Flickr

Continue reading: What is PHP Safe Mode?

Server-side scripting means that a script that is executed on a website will be processed by the server and then displayed as regular HTML in the user’s browser. The alternative to it, client-side scripting relies on the user’s own browser, often including plugins, to execute the designated scripts. Both are common, but there are some decisive advantages to taking care of scripting on the server side.

When a website relies on the client’s browser or plugins to execute the script, the assumption is that the necessary plugins or features are actually installed and enabled. If the user does not have the necessary requirements or chooses not to use them, those features on the site will be unavailable. Examples of client-side scripting include Java and Adobe Flash.

With server-side scripting, everything happens internally before the user ever sees the site. By the time the user gets to the page, it is already displayed correctly, and it will be the same content for every user. They do not have to download any extra tools or plugins. Examples of server-side scripting include PHP, Perl, and ASP.

Photo Source: Wikimedia Commons

Continue reading: Advantages of Server-Side Scripting

Selecting a MySQL database table with a PHP document is a quick way to get certain output onto a web page with very little coding or effort. You may want nothing more than a simple printout of the database table or something more complex like a full web application.

Regardless of the scenario, selecting multiple database tables in the same query is a little more tricky. Here is a syntax that worked for me. First connect to your database the way you normally would, then enter your query like this:

$result = mysql_query("SELECT * FROM table1, table2 ");

Replace “table1″ and “table2″ with the actual names of your tables. Next, you can show rows from both tables, but if any of the rows have the same names in both tables, you will have to specify them specifically in the query.

Finally, display the results however you like:

while($row = mysql_fetch_array($result))
{
echo "<div id='corn'> ";
echo $row['corn'];
echo "</div> <div id='wheat'> ";
echo $row['wheat'];
echo "</div> ";

For more information on MySQL Select, see w3schools.com
Photo: Wikimedia Commons

Continue reading: PHP: How to Select Multiple Database Tables

If you hope to compete with Facebook, LinkedIn, or even MySpace, stop reading now. I am not promising anything like that, but in some cases, you might want to make a small social network for a particular student group, organization, niche market, city or town, or people with particular cultural interests.

There are two methods for developing a social networking site. One is to outsource it completely and use a hosted solution, such as Ning. With it, you can you can literally have your own site up in minutes, but you will not have your own domain name for it (only a subdomain) and will not have absolute power and control.

The second method involves either creating your own or using a script. There are paid solutions, such as SocialEngine ($250) or free and open source solutions, such as Elgg. Both use PHP are fully customizable to your specifications and can easily be integrated with your current site. Best of all, you will have your own domain and full control.

Photo Source: Flickr

Continue reading: Create your own social networking site

When dealing with a web server, it is important to understand the relationships of one file to another, those files to the server, and those files to the Web. When creating hyperlinks or configuring various website options, particularly PHP or Perl scripts, you will need to know both absolute paths and relative paths.

Absolute Paths

There are two types of absolute paths you will encounter. The first is directly related to the Web and the website’s domain name. For example, the path to myfile.html might be:

http://www.mywebsite.info/folder/folder3/myfile.html

On the server, the absolute path would be something like:

/home/user/public_html/folder/folder3/myfile.html (useful in configuring scripts)

Relative Paths

With a relative path, the server looks at where the user currently is then moves either forward deeper into a directory or goes up to any number of parent directories. For example:

folder3/myfile.html

Inside the html file, you might need to link to an image in a directory that is two steps higher:

../../images/myimage.jpg (which is the absolute path: http://www.mywebsite.info/images/myimage.jpg)

With this knowledge, you should be able to link within documents and configure scripts.

Continue reading: Understand absolute and relative paths

Aside from writing, I also develop websites for clients on a freelance basis. In the ideal scenario, I get contacted by an interested client who has neither a domain name nor a current web hosting company. I can then steer that client to the host and domain provider I think is best and will work well with Joomla or whatever content management system I use.

Unfortunately, many clients come with their own baggage. More often than not, it includes a domain hosted by a company like GoDaddy and possibly a current website that is less than stellar. The worst situation that I ever encountered was a client who had chosen to use GoDaddy’s hosting service with a Windows server. Anyone who has tried to use PHP content management systems with Windows is probably already cringing at the thought.

Aside from the usual problems with GoDaddy’s control panel, I had to content with Windows and its strange compatibility issues with PHP. Theoretically, it should work fine with Joomla, but that requires proper configuration, something GoDaddy failed to do. Mind you, the Joomla installation was automatic from their own control panel, but it still never worked quite right. In the end, the client settled for a less-than-perfect site. My advice to anyone who wants a website: ask those who know first before you make purchases.

Photo Source: Flickr

Continue reading: What people should know about Windows servers