Feeds:
Posts
Comments

How to use .htaccess

introduction to .htaccess

There’s a good reason why you won’t see .htaccess files on the web; almost every web server in the world is configured to ignore them, by default. Same goes for most operating systems. Mainly it’s the dot “.” at the start, you see?

If you don’t see, you’ll need to disable your operating system’s invisible file functions, or use a text editor that allows you to open hidden files, something like bbedit on the Mac platform. On windows, showing invisibles in explorer should allow any text editor to open them, and most decent editors to save them too**. Linux dudes know how to find them without any help from me.
Mac Finder view with invisible files
that same folder, as seen from Mac OS X

In both images, the operating system has been instructed to display invisible files. ugly, but necessary sometimes. You will also need to instruct your ftp client to do the same.

By the way; the windows screencap is more recent than the mac one, moved files are likely being handled by my clever 404 script.

** even notepad can save files beginning with a dot, if you put double-quotes around the name when you save it; i.e.. “.htaccess”. You can also use your ftp client to rename files beginning with a dot, even on your local filesystem; works great in FileZilla.

What are .htaccess files anyway?
Simply put, they are invisible plain text files where one can store server directives. Server directives are anything you might put in an Apache config file (httpd.conf) or even a php.ini**, but unlike those “master” directive files, these .htaccess directives apply only to the folder in which the .htaccess file resides, and all the folders inside.

This ability to plant .htaccess files in any directory of our site allows us to set up a finely-grained tree of server directives, each subfolder inheriting properties from its parent, whilst at the same time adding to, or over-riding certain directives with its own .htaccess file. For instance, you could use .htacces to enable indexes all over your site, and then deny indexing in only certain subdirectories, or deny index listings site-wide, and allow indexing in certain subdirectories. One line in the .htaccess file in your root and your whole site is altered. From here on, I’ll probably refer to the main .htaccess in the root of your website as “the master .htaccess file”, or “main” .htaccess file.

There’s a small performance penalty for all this .htaccess file checking, but not noticeable, and you’ll find most of the time it’s just on and there’s nothing you can do about it anyway, so let’s make the most of it..

** Your main php.ini, that is, unless you are running under phpsuexec, in which case the directives would go inside individual php.ini files

What can I do with .htaccess files?
Almost any directive that you can put inside an httpd.conf file will also function perfectly inside an .htaccess file. Unsurprisingly, the most common use of .htaccess is to..

control access
.htaccess is most often used to restrict or deny access to individual files and folders. A typical example would be an “includes” folder. Your site’s pages can call these included scripts all they like, but you don’t want users accessing these files directly. In that case you would drop an .htaccess file in the includes folder with content something like this..

NO ENTRY!
# no one gets in here!
deny from all

which would deny ALL direct access to ANY files in that folder. You can be more specific with your conditions, for instance limiting access to a particular IP range, here’s a handy top-level rule for a local test server..

NO ENTRY outside of the LAN!
# no nasty crackers in here!
order deny,allow
deny from all
allow from 192.168.0.0/24
# this would do the same thing..
#allow from 192.168.0

Generally these sorts of requests would bounce off your firewall anyway, but on a live server (like my dev mirror sometimes is) they become useful for filtering out undesirable IP blocks, known risks, lots of things. By the way, in case you hadn’t spotted; lines beginning with “#” are ignored by Apache; handy for comments.

Sometimes, you will only want to ban one IP, perhaps some persistent robot that doesn’t play by the rules..

post user agent every fifth request only. hmmm. ban IP..
# someone else giving the ruskies a bad name..
order allow,deny
deny from 83.222.23.219
allow from all

The usual rules for IP addresses apply, so you can use partial matches, ranges, and so on. Whatever, the user gets a 403 “access denied” error page in their client software (browser, usually), which certainly gets the message across. This is probably fine for most situations, but in part two I’ll demonstrate some cooler ways to deny access.

custom error documents
I guess I should briefly mention that .htaccess is where most folk configure their error documents. Usually with sommething like this..

the usual method. the “err” folder (with the custom pages) is in the root
# custom error documents
ErrorDocument 401 /err/401.php
ErrorDocument 403 /err/403.php
ErrorDocument 404 /err/404.php
ErrorDocument 500 /err/500.php

You can also specify external URLs, though this can be problematic, and is best avoided. One quick and simple method is to specify the text in the directive itself, you can even use HTML (though there is probably a limit to how much HTML you can squeeze onto one line). Remember to begin with a “, but DO NOT end with one.

measure twice, quote once..
# quick custom error “document”..
NO! ErrorDocument 404 “

There is nothing here.. go away quickly!

Using a custom error document is a Very Good Idea, and will give you a second chance at your almost-lost visitors. I recommend you download mine. But then, I would.

password protected directories
The next most obvious use for our .htaccess files is to allow access to only specific users, or user groups, in other words; password protected folders. a simple authorisation mechanism might look something like this..

a simple sample .htaccess file for password protection:
AuthType Basic
AuthName “restricted area”
AuthUserFile /usr/local/var/www/html/.htpasses
require valid-user

You can use this same mechanism to limit only certain kinds of requests, too..

only valid users can POST in here, anyone can GET, PUT, etc:
AuthType Basic
AuthName “restricted area”
AuthUserFile /usr/local/var/www/html/.htpasses

require valid-user

You can find loads of online examples of how to setup authorization using .htaccess, and so long as you have a real user (or create one, in this case, ‘jimmy’) with a real password (you will be prompted for this, twice) in a real password file (the -c switch will create it)..

htpasswd -c /usr/local/var/www/html/.htpasses jimmy

..the above will work just fine. htpasswd is a tool that comes free with Apache, specifically for making and updating password files, check it out. The windows version is the same; only the file path needs to be changed; to wherever you want to put the password file.

Note: if the Apache bin/ folder isn’t in your PATH, you will need to cd into that directory before performing the command. Also note: You can use forward and back-slashes interchangeably with Apache/php on Windows, so this would work just fine..

htpasswd -c c:/unix/usr/local/Apache2/conf/.htpasses jimmy

Relative paths are fine too; assuming you were inside the bin/ directory of our fictional Apache install, the following would do exactly the same as the above..

htpasswd -c ../conf/.htpasses jimmy

Naming the password file .htpasses is a habit from when I had to keep that file inside the web site itself, and as web servers are configured to ignore files beginning with .ht, they too, remain hidden. If you keep your password file outside the web root (a better idea), then you can call it whatever you like, but the .ht_something habit is a good one to keep, even inside the web tree, it is secure enough for our basic purpose..

Once they are logged in, you can access the remote_user environmental variable, and do stuff with it..

the remote_user variable is now available..
RewriteEngine on
RewriteCond %{remote_user} !^$ [nc]
RewriteRule ^(.*)$ /users/%{remote_user}/$1

Which is a handy directive, utilizing mod_rewrite; a subject I delve into far more deeply, in part two.

get better protection..
The authentication examples above assume that your web server supports “Basic” http authorisation, as far as I know they all do (it’s in the Apache core). Trouble is, some browsers aren’t sending password this way any more, personally I’m looking to php to cover my authorization needs. Basic auth works okay though, even if it isn’t actually very secure – your password travels in plain text over the wire, not clever.

If you have php, and are looking for a more secure login facility, check out pajamas. It’s free. If you are looking for a password-protected download facility (and much more, besides), check out my distro machine, also free.

500 error
If you add something that the server doesn’t understand or support, you will get a 500 error page, aka.. “the server did a boo-boo”. Even directives that work perfectly on your test server at home may fail dramatically at your real site. In fact this is a great way to find out if .htaccess files are enabled on your site; create one, put some gibberish in it, and load a page in that folder, wait for the 500 error. if there isn’t one, probably they are not enabled.

If they are, we need a way to safely do live-testing without bringing the whole site to a 500 standstill.

Fortunately, in much the same way as we used the
tag above, we can create conditional directives, things which will only come into effect if certain conditions are true. The most useful of these is the “ifModule” condition, which goes something like this..

only if PHP is loaded, will this directive have any effect

php_value default_charset utf-8

..which placed in your master .htaccess file, that would set the default character encoding of your entire site to utf-8 (a good idea!), at least, anything output by PHP. If the PHP4 module isn’t running on the server, the above .htaccess directive will do exactly nothing; Apache just ignores it. As well as proofing us against knocking the server into 500 mode, this also makes our .htaccess directives that wee bit more portable. Of course, if your syntax is messed-up, no amount of if-module-ing is going to prevent a error of some kind, all the more reason to practice this stuff on a local test server.

groovy things to do with .htaccess
So far we’ve only scratched the surface. aside from authorisation, the humble .htaccess file can be put to all kinds of uses. If you’ve ever had a look in my public archives you will have noticed that that the directories are fully browsable, just like in the old days before adult web hosts realized how to turn that feature off! a line like this..

bring back the directories!
Options +Indexes +MultiViews +FollowSymlinks

will almost certainly turn it back on again. And if you have mod_autoindex.c installed on your server (probably, yes), you can get nice fancy indexing, too..

show me those files!

IndexOptions FancyIndexing

..which, as well as being neater, allows users to click the titles and, for instance, order the listing by date, or file size, or whatever. It’s all for free too, built-in to the server, we’re just switching it on. You can control certain parameters too..

let’s go all the way!

IndexOptions FancyIndexing IconHeight=16 IconWidth=16

Other parameters you could add include..

NameWidth=30
DescriptionWidth=30
IconsAreLinks SuppressHTMLPreamble (handy!)

I’m not mentioning the “XHTML” parameter in Apache2, because it still isn’t! Anyways, I’ve chucked one of my old fancy indexing .htaccess file onsite for you to have some fun with. Just add readme.html and away you go! note: these days I use a single header files for all the indexes, and only drop in local “readme” files. Check out the example, and my public archives for more details.

custom directory index files
While I’m here, it’s worth mentioning that .htaccess is where you can specify which files you want to use as your indexes, that is, if a user requests /foo/, Apache will serve up /foo/index.html, or whatever file you specify.

You can also specify multiple files, and Apache will look for each in order, and present the first one it finds. It’s generally setup something like..

DirectoryIndex index.html index.php index.htm

It really is worth scouting around the Apache documentation, often you will find controls for things you imagined were uncontrollable, thereby creating new possibilities, better options for your website. My experience of the magic “LAMP” (Linux-Apache-MySQL-PHP) has been.. “If you can imagine that it can be done, it can be done”. Swap “Linux” for any decent operating system, the “AMP” part runs on most of them.

Okay, so now we have nice fancy directories, and some of them password protected, if you don’t watch out, you’re site will get popular, and that means bandwidth..

save bandwidth with .htaccess!
If you pay for your bandwidth, this wee line could save you hard cash..

save me hard cash! and help the internet!

php_value zlib.output_compression 16386

All it does is enables PHP’s built-in transparent zlib compression. This will half your bandwidth usage in one stroke, more than that, in fact. Of course it only works with data being output by the PHP module, but if you design your pages with this in mind, you can use php echo statements, or better yet, php “includes” for your plain html output and just compress everything! Remember, if you run phpsuexec, you’ll need to put php directives in a local php.ini file, not .htaccess. See here for more details.

hide and deny files
Do you remember I mentioned that any file beginning with .ht is invisible? ..”almost every web server in the world is configured to ignore them, by default” and that is, of course, because .ht_anything files generally have server directives and passwords and stuff in them, most servers will have something like this in their main configuration..

Standard setting..

Order allow,deny
Deny from all
Satisfy All

which instructs the server to deny access to any file beginning with .ht, effectively protecting our .htaccess and other files. The “.” at the start prevents them being displayed in an index, and the .ht prevents them being accessed. This version..

ignore what you want

Order allow,deny
Deny from all
Satisfy All

tells the server to deny access to *.log files. You can insert multiple file types into each rule, separating them with a pipe “|”, and you can insert multiple blocks into your .htaccess file, too. I find it convenient to put all the files starting with a dot into one, and the files with denied extensions into another, something like this..

the whole lot
# deny all .htaccess, .DS_Store $hî†é and ._* (resource fork) files

Order allow,deny
Deny from all
Satisfy All

# deny access to all .log and .comment files

Order allow,deny
Deny from all
Satisfy All

would cover all ._* resource fork files, .DS_Store files (which the Mac Finder creates all over the place) *.log files, *.comment files and of course, our .ht* files. You can add whatever file types you need to protect from direct access. I think it’s clear now why the file is called “.htaccess”.
These days, using is preferred over , mainly because you can use regular expression in the conditions (very handy), produce clean, more readable code. Here’s an example. which I use for my php-generated style sheets..

parse file.css and file.style with the php machine..
# handler for phpsuexec..

SetHandler application/x-httpd-php

Any files matching the regular expression statement, that is files with a *.css or *.style extension, will now be handled by php, rather than simply served up by Apache. Any statements you come across can be advantageously replaced by statements. Good to know.

Section 1: Master Slave replication
For ex, if you want to replicate from master A to slave B

1. Create a replication account on master A
‘%’ means all the other boxes, so all slave boxes can use
the same user/passwd to replicate data from the master A
mysql> grant replication slave, reload, super on *.*
to ’slave_user’@'%’ identified by ’slave_pass’;

2. Shut down the master server if it is running
sudo /home/y/bin/mysqladmin shutdown -u root –password=’root_passwd’

3. Modify master’s configuration
in /home/y/etc/my.cnf generally
[mysqld]
server-id=master_server_id
log-bin=binlog_name
(do yinst set mysql_config.log_bin=log-bin

4. Restart the master mysql server
then the master will log updates by writing them into the bin-log
to restart the mysql server, run
sudo /home/y/bin/mysqld_safe &

5. Copy the mysql db data from master to slave to make them in sync before replication
by following instructions in Section 2: To get a full copy of the master DB

Note:in terms of how to copy the data from master to slave,
there are multiple ways, if all the database tables you are
replicating are myISAM tables, then you can use the method
mentioned here, otherwise, you might want to check the
Mysql replication link for more details

6. Shut down the slave if it is running
using the same command as step 2 on slave box

7. Configure slave server to know its replication id
modify /home/y/etc/my.cnf on slave server

[mysqld]
server-id=slave_server_id
master-host=master_host
master-user=slave_user
master-password=slave_pass
#specify which database you want to replicate
replicate-do-db = database1_to_be_replicated
replicate-do-db = database2_to_be_replicated
replicate-do-db = database3_to_be_replicated …. (etc)
* slave_server_id is the replication id of the slave
server, it must be different from the master’s ID and
all the other slaves’ ids
* master_host is the name of the master host.
* slave_user/slave_pass must be the user/passwd set up in step 1

8. Restart the slave mysql server (like step 3 and 5)

9. Run “show slave status” under mysql prompt on slave B
check out if the replication is started

10. You can also un “show master status” on master end
to see what is the current bin-log on master box

11. To see if there is any issue, you can check /home/y/logs/mysql/mysqld.err
on both master and slave boxes, to see if there are any issues there.

Section2 :To get a full copy of the master DB

1. Issue read lock to all databases to make sure the current data snapshot on master is consistent
mysql> flush tables with read lock;

2. IMPORTANT:Reset (clean up ) the binary log on master box
since we are going to first copy the current data snapshot from master to slave, the existing binary log has all the update commands logged until now, we need to clean them up before starting the replication, this step is very important, please run this first on the master box before continue to the next steps
mysql> reset master;

3. Stop the mysql processes on the slave box
sudo /home/y/bin/mysqladmin shutdown

4. Scp all the relevant DB files from master box to slave box
scp -c blowfish -r /home/y/var/mysql/data/db_dir1… username@slave_box:/home/y/var/mysql/data
after this is done, change all files owner/group to mysql under /home/y/var/mysql/data on slave box

5. Start the mysql server on slave box sudo /home/y/bin/mysqld_safe &

6. Log into the slave box (optional)

7. Run check tables on command line(optional)
$> mysqlcheck –all-databases
make sure the above give you ok status

8. run “select count() from some_replicated_table” to compare the slave DB with the master DB
* to confirm they have the same data content

9. Now it is good to say we have a good copy of the data from the master box

10. Unlock the tables on the master box
mysql> unlock tables

Mirroring a Subversion Repository

As of version 1.4, Subversion provides an “svnsync” utility that may be used to create a mirror of a repository. It should be used only for read-only mirrors — it will break if any changes are committed in the target repository that were not made in the source repository. This is primarily useful for backup purposes, or for creating a local mirror used by clients that have no intention of checking in changes, as it is not a trivial operation to check out from one repository and commit to another and it requires manipulation of the mirror repository.

To create a new Subversion repository that is a mirror of an existing repository, do the following:

  • Create a new filesystem directory that will be used to hold the mirror, like:
$ mkdir /mirror/subversion
  • Use the svnadmin utility to create a new repository within that directory, like:
$ svnadmin create /mirror/subversion/OpenDS
  • The mirror repository must be configured to allow revision properties, and it should only allow those changes by the “svnsync” user, which can be done by creating a “hooks/pre-revprop-change” file in that repository with the execute permission set and with the following contents:
#!/bin/sh

if [ "$3" = "guest" ]; then exit 0; fi

echo "Only the guest user may edit revision properties through svnsync" >&2
exit 1
  • Initialize the mirror repository using the “svnsync init” command, like:
svnsync init --username guest file:///mirror/subversion/OpenDS https://opends.dev.java.net/svn/opends
  • Use the “svnsync sync” command to populate the mirror repository, like:
svnsync sync file:///mirror/subversion/OpenDS
  • To keep the mirror up to date, periodically re-issue the above “svnsync sync” command (e.g., using a cron job).

See http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt for more information on the svnsync utility.

<!–

–>

 

OpenDS Wiki Home

Project Site Links

Wiki Contributor Resources

Wiki Info

Leave Feedback
Terms of Use

 

Page Info Print Friendly My Prefs Log in

This page (revision-2) last changed on 20:56 05-May-2007 by NeilWilson.

 

What Links Here

Subversion Tips And Tricks

JSPWiki v2.4.102

[RSS]

Page Info Print Friendly My Prefs Log in

This page (revision-2) last changed on 20:56 05-May-2007 by NeilWilson.

By any use of this Wiki, you agree to be bound by this website’s Terms of Use. Copyright 1994-2007 Sun Microsystems, Inc.

 

 

 

SVN Setup

Setting up a SVN 1.4 server using Apache 2.2 on Ubuntu

To setup svn 1.4 , we need to compile both apache 2.2 and svn 1.4 from source.
This how to has been tested under Ubuntu Dapper and Edgy.

sudo apt-get install build-essential libneon25-dev autoconf libtool -y --force-yes

Before starting make sure you have removed previous apache2 and subversion installation from your system.
To do this:
sudo apt-get --purge remove apache2 subversion
sudo mv /etc/init.d/apache2 $HOME/apache2_bak

cd $HOME
mkdir softwares
cd softwares

wget http://www.zlib.net/zlib-1.2.3.tar.gz
tar xvfz zlib-1.2.3.tar.gz
cd zlib-1.2.3/
./configure –prefix=/usr/local
make
sudo make install

cd ..
wget http://apache.forbigweb.com/httpd/httpd-2.2.3.tar.gz
tar xvfz httpd-2.2.3.tar.gz
cd httpd-2.2.3/
./buildconf

./configure --prefix=/usr/local/apache2 --enable-mods-shared=all --enable-deflate --enable-proxy --enable-proxy-balancer --enable-proxy-http --enable-dav --enable-so --enable-maintainer-mode

make
sudo make install

sudo /usr/local/apache2/bin/apachectl start
Now test your apache2! goto browser and type http://localhost, you should see it works!!

sudo /usr/local/apache2/bin/apachectl stop


sudo cp /usr/local/apache2/bin/apachectl /etc/init.d/apachectl
sudo chmod +x /etc/init.d/apachectl

We just need to add a few lines to the file for it to work nicely:

sudo vi /etc/init.d/apachectl

Add the followinig, so the top of the file looks like:

#!/bin/sh
#
# chkconfig: - 85 15
# description: Apache is a web server.

Save the file.

sudo /usr/sbin/update-rc.d apachectl defaults

Securing Apache

It?s also a good idea to create a dedicate Apache system user account. It?ll make your install much more secure.

sudo adduser --system apache

Now we just need to make sure that Apache runs under this user. We do that by editting the configuration file:

sudo vi /usr/local/apache2/conf/httpd.conf

You need to find the lines that say:

User daemon
Group daemon

And change them so they look like:

User apache
Group nogroup

sudo /usr/local/apache2/bin/apachectl start

Installing Subversion 1.4

As we have built Apache from source, we’ll need to do the same for Subversion in order to get the Apache 2 modules mod_dav_svn and mod_authz_svn.

# rm -f /usr/local/lib/libsvn*
# rm -f /usr/local/lib/libapr*
# rm -f /usr/local/lib/libexpat*
# rm -f /usr/local/lib/libneon*

#Get the latest svn tar ball
wget http://subversion.tigris.org/downloads/subversion-1.4.2.tar.gz
tar xvfz subversion-1.4.2.tar.gz
cd subversion-1.4.2/

sh autogen.sh

./configure --prefix=/usr/local --with-apxs=/usr/local/apache2/bin/apxs --with-httpd --with-apr=/usr/local/apr --with-apr-util=/usr/local/apr

make
sudo make install

This will also add the relevant LoadModule directives into your Apache 2 configuration for you.
Creating your repository

Now, create your Subversion repository:

svnadmin create /home/yourusername/subversion/repos

We have to make that repository owned by Apache so that it can be accessed via the web:

sudo chown -R apache /home/yourusername/subversion/repos

Authentication File

Now create a user/password file for authentication:

/usr/local/apache2/bin/htpasswd -cm /home/yourusername/subversion/dav_svn.passwd yourusername

When prompted, enter your password.
Configuring Apache

Edit your /usr/local/apache2/conf/httpd.conf file with the following placed at the end:


<Location /svn>
DAV svn
SVNPath /home/yourusername/subversion/repos
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /home/yourusername/subversion/dav_svn.passwd
Require valid-user
</Location>

If you want access control based on different users, add the following line after the Require valid-user line:

AuthzSVNAccessFile /home/yourusername/subversion/svn_access_control

To setup a local mirror using svnsync

To have a mirror setup first ensure that the local repo you are going to use as the mirror should have the same uuid as that of the master.

To get uuid of a repo, go to its working copy and type
svn info

now make the mirror svn’s uuid same as masters uuid, you can get the uuid by typing
svn info URL/PATH

cat – <<EOF | sudo svnadmin load –force-uuid dest
SVN-fs-dump-format-version: 2

UUID: d48dd586-eb1d-0410-b581-e6e13afcedeb
EOF

cd /home/ajopaul/subversion/repos/hooks/
vi pre-revprop-change
sudo vi pre-revprop-change

Add the following lines
#!/bin/sh
USER=”3″
if [ “USER” = “svnsync” ]; then exit 0; fi
echo “Only svnsync user can change revprops” >&2
exit 1

sudo chmod +x pre-revprop-change

sudo svnsync init --username your_master_svn_username file:///home/ajopaul/subversion/repos http://xxx.xxx.xxx.xxx/svn

sudo svn proplist --revprop -r 0 http://xxx.xxx.xxx.xxx/svn

sudo svn propget file:///home/yourusername/subversion/repos --revprop -r 0 http://xxx.xxx.xxx.xxx/svn

time sudo svnsync sync file:///home/yourusername/subversion/repos

Remember! local mirrors is/should be read only

To ensure no commits happen on the local mirror add the following lines to hooks/pre-commit script

#!/bin/sh
SVNLOOK=/usr/local/bin/svnlook
USER=`SVNLOOK author -t $3 $1`
if [ “$USER” = “svnsync” ]; then
exit 0;
fi
echo “Sorry no commit allowed on mirror! use ’svn switch’ to point to master repo and then point back to local mirror after the commit” >&2
exit 1

If by any chance your svnsync locks ur mirror repo or if you recieve a message such as:
Failed to get lock on destination repos, currently held by ….
Type this
svn propdel svn:sync-lock --revprop -r 0 file:///home/ajopaul/subversion/repos/

php Tips

Turn On Error Reporting Immediately

The single most important thing I tell people who use PHP is to turn error reporting to its maximum level. Why would I want to do this? Generally the error reporting is set at a level that will hide many little things like:

* declaring a variable ahead of time,
* referencing a variable that isn’t available in that segment of code, or
* using a define that isn’t set.

These factors might not seem like that big a deal — until you develop structured or object oriented programs with functions and classes. Too often, writing code with the error reporting turned up high would cost your hours as you scoured long functions that didn’t work because a variable was misspelled or not accessible.

PHP won’t tell you anything in that case – it’ll just create the new variable for you and initialize it to zero. The remedy is to put the following line at the top of every PHP document as you develop:

error_reporting(E_ALL);

It simply forces the error reporting to be at its highest level. Try putting this line in other PHP programs, and more often than not you’ll receive a barrage of warning messages that identify all the potentially wrong elements of the code.
Single Quotes and Double Quotes are Very Different

I never recommend using ” (double quotes) when programming with PHP. Always use ‘ (single quotes) unless you need the features of ” (double quotes). You might think it’s much easier to write code as:

echo “Today is the $day of $month”;

However, using single quotes forces variables to be outside the quotes; instead, you must use the period (.) to combine strings. It makes for faster coding but can be more difficult for other programmers to read. Let’s look at what would happen if we put an associative array value in the previous code:

echo “Today is the $date[‘day’] of $date[‘month’]“;

You would receive a parse error and it would be harder for another team member to read. Two correct ways to write that line of code would be:

echo ‘Today is the ‘ . $date[‘day’] . ‘ of ‘ . $date['month'];

and

echo “Today is the {$date['day']} of {$date['month']}”;

These might not look as pretty as the original code, but syntactically they are both correct. Additionally, I believe the first method, with single quotes, is easier to read.

The use of single and double quotes also applies to associative arrays. Consider this code:

$SESSION[team] = $SESSION["old_team"];

One main problem exists in that line of code. The associative entry team on the left side needs to have single quotes around it; otherwise, PHP will think it’s a define and give you a warning message (only if error reporting is at maximum). I would recommend that the code should look like this:

$SESSION['team'] = $SESSION['old_team'];

I wish I’d known the difference between single and double quotes as they pertain to strings when I first learned PHP.