L is for Linux, M is for MySQL, and P is for PHP
I used nextpage to break this writing up into manageable chunks. I know that not everyone likes nextpage, and the implementation in 1.02 is a bit problematic, but we’ll see later how we can modify WordPress to provide full page displays for people who prefer this, and how to refine the nextpage behavior for the rest. And yes, we’ll also add in comment preview.
Once the software for Textpattern and WordPress is on the server and unzipped (discussed in last LAMP essay), you’ll need to create a MySQL database for both tools, unless one is provided for you by your ISP. Since they each use different table naming conventions, I used one database for both installation.
Creating the database is dependent on your ISP. Most companies providing MySQL also prohibit creating databases directly in the MySQL console–a command line interface directly with the database engine. Instead, you’ll use a tool like that which is attached to cPanel to create a database and a user and tie the two together. However, if you did have to create a database directly in MySQL, it’s not that complicated–as long as you have access to the command line version of MySQL.
To access MySQL from Linux, you’ll type the following command which opens a console to MySQL. Notice that you’re passing in a flag designating a specific user, and in this case asking the tool to prompt you for a password (you could also type the password directly in the line, but I prefer not to because Linux remembers your command in history, and I don’t like passwords to show in history):
mysql -u shelley -p
In this case, my user name is my first name, shelley. Once I get the password prompt and type it in , I’ll be in the database engine console.
Since I didn’t specify a database on the command line when I entered the console, I haven’t entered directly into any of my existing databases. To see what they are, I can ask MySQL to show me them:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 1214348 to server version: 4.0.18-standard
Type ‘help;’ or ‘h’ for help. Type ‘c’ to clear the buffer.
mysql> show databases;
| Database |
| shelley_bbweblog |
| shelley_frgn1 |
| shelley_test |
| shelley_wp |
6 rows in set (0.00 sec)
Even if there are several people with databases on the system MySQL engine, only the databases you’re allowed to see should show. This provides a little extra privacy.
I’ve already created the WordPress 1.2/Textpattern database, the one named shelley_test. Well, I used cPanel to create the database ‘test’, and to keep it unique to me, the system called it ’shelley_test’. However, if I wanted to create a database in the console, I would use the create database command:
mysql> create database shelley_test;
Query OK, 1 row affected (0.06 sec)
Impressively easy, eh? Well, I can about guarantee that it’s the easiest thing you can do in MySQL. Now that I’ve generated even more interest in learning how to work with MySQL, you need to create a user and tie this user to the database. The reason is that both Textpattern and WordPress (and Movable Type and most other database driven tools), require three things for installation: a database, a user, and a password.
(They also require a server name, but unless you’re getting into some kinky remote data access, you’ll use the local server name, handily designated as ‘localhost’, when queried for server name.)
When creating a user, what you’re really doing is creating a named set of permissions, which just happens to be usable by a what can be termed a ‘user’. To do this, you’re going to use the MySQL GRANT command, and grant all permissions to the specified person, for the specified database, accessed via the localhost server, and identified by a password.
Or in one command:
mysql> grant all privileges on shelley_test.* to someuser@localhost
identified by ’somepass’ with grant option;
Query OK, 0 rows affected (0.00 sec)
Of course, you’ll replace the name and password for your system, as well as the database name, but what I’ve done with this command is to grant all priviledges on anything contained within the database shelley_test to the ’someuser’. However, they’ll only be able to access the database from the local machine and only after giving the specified password.
I could have given this person access to all databases using ‘*.*’ in place of ’shelley_test.*’, but first rule of thumb with good database habits: never give more than is needed. By this I mean never grant more permissions that a person needs to get the job finished.
If I had not given the localhost host designation, your PHP applications would not have been able to access the database, and the user would not be able to log int MySQL from the command line. If they tried, they’d get an error similar to:
ERROR 1045: Access denied for user: ‘anotheruser@localhost’ (Using password: YES
Of course, MySQL could automatically assume all users can access the database system from the local host, except this violates that rule I just mentioned, which is Never give more than is needed.
There are fancy variations of all these commands, but we’ll hold them for another time. Right now, you’ve created what you’ve needed to finish the WordPress and Textpattern installations.
When the WordPress files are unzipped, chances are they’re unzipped into a named subdirectory. The first thing you’ll want to do is move them into your wordpress directory. You can do this your FTP program, or you can use the Unix move command, ‘mv’. Change to the subdirectory that contains all the files and subdirectories and do the following:
mv *.* ../.
When finished, you can then delete the directory just emptied, again using your FTP program, or the Unix remove command, ‘rm’. First, move up a directory, and then remove the WordPress unzipped file directory:
rm -r wordpress-somename
There is a readme.html file located in the top level directory of the files just installed. You can see the one with my installation here. This provides what WordPress calls the “5-minute install”, and you’ll want to use these instructions.
You can either manually edit the configuration file for the weblog, by opening wp-config-sample.php either using a text editor on Linux, or by downloading the file to your PC and editing it there. Later I’ll demonstrate how to use the granddaddy text editor of them all, vi to do simple text edits in Linux, but for now, we’ll let the program make the configuration file.
To create the config file, open the install-config.php page in the wp-admin subdirectory in your browser and provide the information needed. This will be the database name, username, host (localhost), and user password. If you’re running multiple versions of WP, you can change the table prefix, but for now, since this is the first install, we’ll leave it at wp_.
Once you run, you should get a message something to the effect of, All right sparky! with congratulations for not screwi… congratulations for being successful. You don’t have to remove install-config.php, as it can’t be used to overwrite an existing configuration file; but you should anyway. The second rule of good database habits is: evil shit lives, don’t leave behind any open doors.
Next, load the install.php application, also located in wp-admin. A link for this file is provided in install-config.php if you’ve run this. The installation application should be able to run unassisted, and as long as it can access the database, you shouldn’t have any problems.
The first page provides feedback as to what’s been created, and a link for step 2. This page also shows some status of table and other object creation, and also asks you what the URL for the blog is. In my installation this is “http://wordpress.burningbird.net”.
Step 3 should give you note that you’ve successfully installed WordPress, that a user has been created called admin, and a generated password is given. Don’t lose this! If you don’t record that password down, you’ll have to do the install all over again.
At that point, you can log into WordPress, and the first thing you should do is access the Profile option, and change the password. You’ll also have to provide an email address for the admin user.
That’s it. You be WordPress bad at this point. My installation is at http://wordpress.burningbird.net.
In the next essay, we’ll take a closer look at the WordPress tables, and work on importing Movable Type entries. Next, though, installing Textpattern.
Since the database has already been created, all you need to do with Textpattern is make sure the tool files are located directly in the weblog directory, moving them out of the unzipped subdirectory if needed. Once set, all you need to do is run the Textpattern setup application, setup.php, located in the textpattern subdirectory.
As with the WordPress installation, you’ll need to provide your MySQL username and password, database name, and host. Again, provide a prefix if you’re going to install multiple weblogs in the same database; otherwise leave it blank. In addition, ensure that the paths to the web root and textpattern installation are correct.
You’ll note a secret word, used for authentication security. Make sure you change this, okay?
When you click the bright red button, the next page that opens has a textarea with your configuration information contained in it. You’ll want to copy this and add this to the config.php file in the textpattern subdirectory. You can use your local text editor or one located on the server.
Important Note: It’s critical that there is no text or white space or carriage returns after the final closing PHP tag, ?> in this file. Doing so will cause problems later. Once you add the text, stop, save, and close the file.
After you’ve created the config.php file, then click the button that says, “I did it”. The next page allows you to create a user, use whatever answers are appropriate to your circumstances. Note that the version used in this example does not verify the password: watch the typos.
Click the button and that’s it. You’re ready to go. After you remove the setup.php file, that is. My Textpattern installation is at http://textpattern.burningbird.net.
Again, next essay we’ll look at importing Movable Type entries, and explore the Textpattern tables.
Why WordPress over Textpattern
I’ve been asked in comments, and elsewhere: why WordPress over Textpattern? Both are PHP, and both are open source.
Well, when I originally looked at Textpattern, I didn’t know it was open source. I had missed the license information that read:
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name Textpattern nor the names of its contributors may be used to
endorse or promote products derived from this software without specific
prior written permission.
Though Textpattern is being developed by one person, Dean Allen, he has left the source open for innovation, copy, reuse, and even distribution–with the only caveat that the original copyright be included. This is open source.
Still, there is a major difference between the two development efforts: WordPress is not only open source, it’s also a multi-developer project, registered and maintained at Source Forge. Though Matt of Photo Matt fame is the primary developer of this product, if for some reason he decides he would rather spend his time photographing naked people holding fruit, he can; the project might slow for a bit, it won’t stop. Why? Because Matt is not the only force behind WordPress.
More than that security, I, as a developer, am attracted by the thought that changes to code I make could be incorporated back into the product, if it’s vetted by the development team. The same is true for Textpattern, but the infrastructure isn’t in place.. As far as I know, Textpattern is Dean Allen, and if Dean gets hit by a beer truck–fates forbid–that’s it for Textpattern.
(Let me know if I have this wrong.)
More than that, though: I’m a tweaker. WordPress is naturally easier to tweak, in my opinion, than Textpattern. However, this is more my personal opinion than any ultimate truth; others may find Textpattern easier to tweak.
Finally, WordPress is the more mature product, and those aspects of Textpattern that folks like, such as the friendlier administrative interface and superior XHTML support and controls, not to mention abstraction from the physical layer, just aren’t as important to me. Or if they are, I feel they can be emulated in WordPress…with a little tweaking.
Regardless, both are good products by good people and a viable alternative to proprietary software options, which is why I’m covering both.
Enough for tonight. But as you can see, installing both Textpattern and WordPress is not a complicated process: grab the software, unzip it, place it in the weblog directory, create database and user, and then open a page in your browser and follow the instructions.