When it comes down to installation, not all Content Management Systems are created equal.

I will start out by saying that while I have installed WordPress on a server before (that was hosting my website), I used CPanel and I remembered it being incredibly easy, but that was because it had “softiculous” which is a one-click WordPress install service that some web hosts offer.

This process of doing it via ftp was not quite as simple, and I had to tweak some permissions (possibly opening myself up to a host of security issues in the process), but really WordPress was still pretty painless when compared with Drupal’s installation process. And Concrete 5 turned out to be the most painful.

The Process

The process for each CMS was the same, starting out. Create a database (this can be set up through Cpanel with MySQL databases or through PHP MyAdmin, depending on how your Cpanel is set up, security-wise). Create a user-admin for that database. Make a note of the user and password you used to create the database, and store that somewhere–you will be using it later! Download the CMS from whatever web page hosting it (i.e. drupal.org, wordpress.org.) and uncompress the zip file.

The database starts out empty, and is populated by the installation of the CMSs. Each CMS puts its own prefix on the tables it inserts into the database, so they do not conflict. This is not true of all CMSs, however–Concrete 5 requires a dedicated database, but even after creating a separate database just for it, I still had issues with it.

With FileZilla or some other file transfer protocol client, ftp the folder downloaded (and uncompressed) from the CMS website to the server and upload the files for each CMS, right into the public_html.

WordPress

From there, it was cookin’ with gas, with WordPress. When I open up in a browser the url we were given, tacking on the folder name at the end, I got a friendly, “There doesn’t seem to be a wp_config file. Would you like us to create one?” Yes, Please! So hitting “submit” basically installed WordPress, and it took me through some prompts to set up a database connection, what to name the table prefixes, etc.

I did have to tweak the file permissions on WordPress by right-clicking on the wordpress folder itself and viewing the file permissions, and changing them to allow everything (“777” as I’ve come to know it).

Eventually, though I am nervous about this, I had to revisit this folder later as I could not upload any graphics, and chose the “Recurse into subdirectories.” That took a long time (5-10 minutes). That made me wonder if I’d done something horribly wrong. But, it fixed it! And I could add content and edit.

Now, this was actually done on a remote server somewhere other than this site (which is hosted through WordPress.com, and I do not have access to their public_html directory–I only offer this as one explanation of how to get permissions to work on a remote server, but this does NOT seem like good practice to me to open the permissions wide open, because that may expose it to attack. But that website will not be up long, as it was just for a class exercise in installation).

Drupal. Oh, the Agony.

We all knew that drupal would be more difficult, and the Mercury going into retrograde the day of the demo was not the real problem. Drupal is hard to install, period.

When I first tried it (Thursday in class), however, I was doomed to failure merely because there was no database set up yet. So I just got an error message  sans any formatting which made little sense (I wish I’d written it down). Yet, I believe the same error was there today when I tried again, database in place. So, I took a couple of steps:

I delete the htaccess file per Steve’s suggestion. (Steve is someone else in my class, but he later found a blog that had an excellent tutorial for installing drupal that went step-by-step, and I may follow it to redo this process later. The tutorial even has a free eBook for download as a pdf.)

I also copied the default.settings.php file in the sites folder, and changed it to “settings.php.” Initially I tried just changing the name, but then Drupal gave me an error that the default was missing, so I added it back in so that there were two files.

After that, I fared a bit better, in that this time I saw the drupal blue droplet, with a message asking if I would like to install (woo hoo!).

Installation then hit a few snags:

“File system
The directory sites/default/files does not exist. An automated attempt to create this directory failed, possibly due to a permissions problem. To proceed with the installation, either create the directory and modify its permissions manually or …….”

and

“Default settings file The default settings file does not exist.
The Drupal installer requires that the ./sites/default/default.settings.php file not be modified in any way from the original download. “

and

“Settings file The settings file does not exist.
The Drupal installer requires that you create a settings file as part of the installation process. Copy the ./sites/default/default.settings.php file to….. “

Ugh. Again, Steve helped me tremendously (pioneering this process, so to speak), suggesting it was a permissions issue and to change the permissions of install.php and index.php to “777.”

That did take care two of the above warnings, and so I tried setting permissions on the sites folder to 777, but the warning was still there. I tried setting the default folder inside of sites to 777, but it kept changing it back! So I threw caution to the wind and went back to the sites file permissions and chose “recurse into subdirectories.” That fixed it. Off we go.

I was then brought to the database set up, which I filled out…

And, Voila! Finally…

Now that it was installed, it will be an interesting process learning to add content, which I played around with for an hour or so before I had to rush off to my evening class. I could not edit the existing “home” page at all (something I had not remembered from my earlier experience with Drupal), and could not see how to add photos, but linking to urls worked. Changing the default theme OR making any change at all to the color scheme through the Drupal interface completely broke the css and it went to plain text and links on a white page. Steve wonders if this is because I deleted the htaccess file early on. Ooops.

It should be an interesting semester.

Concrete 5

At first, Concrete 5 looked like it might be one of the easier installs. Boy was that wrong. In the end, it has turned out to be the hardest, and so far, I have not been successful at installing it on a remote server–even installing it on my own machine at home with root privileges took two attempts. And by that time, I was so fed up with it, I didn’t feel like playing with the interface. The feeling I had was similar to sewing projects that took me so long that by the time I finished the dress, I didn’t want to wear it, because all I could think about was the loooong process of making it, and hoped that I would feel like wearing it eventually, before it would no longer fit. I feel that way now about Concrete 5.

At the onset, as I said, it looked like it would be easy. It came up with an install screen, which told me that I needed to free up some permissions to be writable. Mousing over the one box with a red flag provided more info as to which files needed to have permissions modified. So I went and changed those permissions by right-clicking to get to Properties in the ftp client on the remote server side, and tried again.

Of course, those 85 tables were put there by WordPress and Drupal, which could use one database and play nicely together. Soooo, I asked my teacher to create another database, one that I could dedicate to Concrete 5. He obliged me, and I tried again, only to get this error:

Doing a search on Concrete 5, it turned out that only users with ROOT privileges to the hosting server could get Concrete 5 to connect to the database. I found this one one forum, before perusing the site at Concrete 5, on installation, where it also outlined this. The teacher gave me GRANT permissions to the extra database that he’d created to be dedicated to Concrete 5, but GRANT is not quite as administrative as root, and perhaps that’s why it didn’t work. I finally gave up (as we were having other issues with that server as well), and decided to try it on one place where I knew absolutely that I had root privileges–on my own desktop computer at home, using MAMP, a free server software program.

With MAMP (or XAMP if you’re using a pc), I merely had to put the Concrete5 folder into htdocs, navigate to my localhost (after first signing into phpMyadmin through MAMP and creating a blank database), click on that folder, which brought me up to the familiar install screen. This time, however, I didn’t encounter any permissions issues, and when it came time to fill out the “connect to database,” the biggest issue I had was remembering WHAT password went with which admin_user I had set up for myself in phpMyAdmin, because Concrete 5 would not allow “root” for the password, as it said that passwords HAD to be at least 5 characters long…and looking in the config file for phpMyAdmin, I could see that the “root” user had a default password of “root.” Hmmmm.

I did finally get through that hurtle, however, by accessing a prior project I’d done in MAMP because I still had the database.php file that had the PDO object which connected to the database with the user and password specified (*whew!*), so using those credentials, I was able to connect to the empty database I’d created. Yay!

It was on this screen, unfortunately, that I hit my second snag. I thought, “this is going to take a while, why don’t I do something else on the computer while that grinds on installation.” Mistake. As I’d recently upgraded my system to Mountain Lion, I am still not familiar with the “swipe” function that is now on the mouse, and merely putting the mouse down and moving to navigate to another window in the browser automatically hit the “Back” button on the install screen. OOOPS. Trying to navigate “forward” did not work–now the connect to database told me that I had a database which was populated with tables, which it couldn’t work with! Going to phpMyAdmin, I discovered that I could not merely “DROP” the database and create a new one, nor could I rename it, nor could I delete it in any way. This was maddening, as it is on my OWN COMPUTER. What I finally had to do, and which was time-consuming and tedious, was that I had to go to that database “concrete5” that I’d created, and go through and delete the tables ONE BY ONE. There must have been at least 200 tables. What a nightmare. No wonder Concrete5 needs its own database!! I finally deleted all of the tables, however, and came back to the database connect  window, which again started installing attributes, whereupon I carefully put the mouse down, holding it by the edges, and went to make some tea and read a book and above all, NOT TOUCH THE COMPUTER while it installed.

That was more successful.

Hitting “Continue to your site” took me to my site, with a popup of helpful informational dialogs that led to various tutorials on how to lay out pages in Concrete 5. I closed those, however, and, owing to my frustration of having had to spend 10-15 minutes manually deleting tables, had named my site “Concrete Shoes,” a euphemism borrowed from the mafia (I suppose they actually called it “cement shoes”) to relieve my feelings.

Wow. So there it is. It sure looks like a plain WordPress site. Perhaps it will be easier to create custom themes for, however. We shall see.