Monthly Archives: November 2013
How To Install New WordPress Site Locally Using MAMP: First Lap
Finally! Something that might actually be useful for someone.
My issues before installing:
Had some weird old WordPress install that needed to be uninstalled:
Step One: Delete all “wordpress” folders from the Mac
Step Two: Delete (“drop”) all related databases (not tables) from PHPMyAdmin
Step Three: Clear browser cache (maybe not necessary, but why not)
Had been traumatized by previous half-baked WordPress install:
Step One: Consult an actual WordPress book (I chose “Smashing WordPress” 3rd Ed by Hedengren).
Step Two: Read at least three different places in the WordPress codex about installing WordPress locally via MAMP.
Now that my “baggage” had been resolved, I moved onto the actual re-install.
Step One: Identify where you want the new site to reside. This can be anywhere. Using MAMP Preferences, under “Apache”, browse to your designated folder. Wait for the servers to connect.
Step Two: Download WordPress.
Step Three: Copy and paste the downloaded “wordpress” folder into your designated folder that MAMP is using.
OK. Seems easy enough. At this point, I pointed my browser to localhost and of course it didn’t work automatically. Instead, it complained about my lack of wp-config file.
Now, me and the config file go waaay back. So I felt prepared to make the following changes:
Step One: Open the provided wp-config-sample.php files and change all the DB_NAME settings to whatever is easiest for you to remember.
// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘database name’);
/** MySQL database username */
define(‘DB_USER’, ‘yourname’);
/** MySQL database password */
define(‘DB_PASSWORD’, ‘password’);
/** MySQL hostname */
define(‘DB_HOST’, ‘localhost’);
/** Database Charset to use in creating database tables. */
define(‘DB_CHARSET’, ‘utf8’);
/** The Database Collate type. Don’t change this if in doubt. */
define(‘DB_COLLATE’, ”);
Step Two: Go to PHPMyAdmin. Create a new database with the same name you just put into the config file. Create a user with all privileges whose username and password matches the config file. Make sure the user’s host is “localhost” specifically.
Step Three: Copy and paste new values from the api.wordpress.org secret key salt page into config (not necessary for security on a local site, but since this will eventually go live, again, why not?).
Step Four: Change the name of the file to wp-config.php and save.
At this point I pointed my browser to http://localhost:8888/wordpress/wp-admin/install.php and lo and behold, it now prompted me to create my user account and name the site! Woot woot!
Four on the Floor
If you want a real thrill, try making changes to a live WordPress site after a recent deployment and numerous unknown changes by a third party half an hour before marketing needs the updated site for a client meeting…
Yes, this is what has happened to me, not once, but twice in the past two weeks! We find ourselves bereft of a relevant testing environment, in the midst of trying to create local testing environments and a subdomain environment in addition to github. However, before all of those dev environments got set up correctly, we had to debug a few items from the recent re-deployment/migration.
Step One: Change the featured image for a page so Facebook gets it right, and break the site! Okay, the whole site didn’t break, but we suddenly lost the very page we were trying to fix. Lost as in it didn’t display AND we couldn’t find the file on the FTP. Upon trying to move the local version of the file, we found we suddenly didn’t have permissions to change that directory. Enter “Sam”, in charge of recent re-deployment, who enlightened us to the fact that after the deployment, “Owner” of most files and directories had changed to “Apache” from “Our Organization”. After changing the ownership back, we were able to get the file back on the website, the page worked again, AND I figured out how to get Facebook to display the correct thumbnail for the specific page using their “developer” documentation. Actually, some of the better documentation I’ve seen (including you, WordPress).
Step Two: Unable to upload images through the wp-admin screen. Attempted to deactivate and reactivate a few plugins, as recommended in the aforementioned WordPress documentation, and lo and behold half of the styling for the site was lost! Oh my! At this point I literally had to sit down because I had no clue what the problem was or how to fix it. Before restoring a backup of the whole site (I know, I know, stop panicking, Jessica), I fished around the office for some help from other developers not working on this specific site.
After some handy “inspection of element”, we discovered the essential css had been lost. Part of the problem was that we were used to using the Appearance –> Edit CSS part of the Jetpack plugin to easily add and override CSS. Probably not the cleanest or most efficient, but since the site has dozens of style.css files, this seemed like the intuitive choice. Some mysterious element called “Custom CSS” had disappeared from the site quite a while ago, as we saw from a recent download of the site to my computer. So we went back to the now defunct test site, went into Edit CSS, copied the whole file, pasted into the theme’s style.css with a few “!important”s thrown in for good measure, and lo and behold the style came back and two hours later I was exactly where I’d started. I was beginning to feel like the only thing I could accomplish was not making the site worse, and if it was the same at the end of the day as at the beginning of the day, then I was doing well. Sheesh.
Needless to say, these are not the best nor permanent fixes. I would love to be able to test the site back into normal health, but ironically that is proving more difficult than it seems since every attempt as creating a new testing site under a subdomain manages to somehow, you guessed it, break part of the live site.
Things I have learned:
- WordPress is not simple. It is complicated and often unpredictable. Especially plugins.
- Don’t feel brave. Instead, make a backup, then try the very smallest change possible.
- Sites break every day. Today just happens to be your day. Tomorrow will be someone else’s.
- An efficient, intuitive testing system must be setup when the site is created. Unless you want a site that never changes ever again.
- The database(s) in WordPress are essential. Even though they may appear “black box” like, take them into consideration when creating backups, development sites, and local versions. Learn to work with and love them, not ignore and delegate them.
Recent Comments