How to install WordPress using MAMP

The traditional, long way (Use WP-CLI for the fast short way)

  • Download WordPress
  • Extract and rename wordpress folder after your project
    • Follow my rules of
      • Files and folder lowercase (file.jpg of some-folder)
      • No spaces, use dashes for multiple words (file-name.jpg or folder-name)
      • Only use underscores (_) when naming a database
      • Extracted the zip or compressed file
      • Delete zip file for good computer house cleaning
  • Change MAMP settings. By default the port is 8888. Change the port to 80

screenshot of MAMP settings for port

  • Change the Document root to Sites
    • This is an exception to the folder name rule because this used to be an out of the box feature of IOS but they removed it with recent IOS systems. I name it with a capital letter out of tradition.

screenshot of Sites Document Root

  • Note Stop and start MAMP servers
    • Mac IOS will ask you to enter your password to stop and start servers
    • You will know if it is working if you when you click on ‘Open WebStart page’ you see a path of http://localhost and not http://localhost:8888
  • Use phpMyAdmin to create a new empty database
    • Use lowercase only and if multiple words use underscores
    • Name the database without saying db or database in name (for better security)
  • Place your new, extracted, renamed WordPress folder inside your new Sites folder
  • If you browse to http://localhost you should now see your new WordPress project
    • Click project and you will now walk through browser pages to install wordpress

Page 1

choose language

Page 2

Tells you that you are about to populate your database with the WordPress tables.

Click the Let's go! button


Page 3

This is your database connection info. When you enter this, WordPress will be able to connect to your database and populate the database you just created with the WordPress database tables. It will also create a wp-config.php file and put your database info in that file. This file is important to keep safe because if someone gets a hold of it, they can access and delete your database. The MAMP default username is root and the default password is root. This is fine for local development but when deploying to production you obviously want a more secure user name and password. In production your Database Host is usually localhost but some hosts use a different URL. They will let you know if they do in their cpanel. It is also a good security practice to rename the Table prefix to something other than wp_. Click Submit button when your Database info is correctly entered.

screenshot of WordPress sample database info

If you get an error

error database page

You’ll get this is you typed any of the info incorrectly. It’s a good idea to write down and store all your connection information in a safe place. Click Try again to take another stab at putting in the correct info.

Page 4

run install

If all is well, you’ll get this. Click Run the install.

Page 5

This will start to add info to specific WordPress database tables. Put your Site Title in (great SEO boost right out of the gate). Enter a username (Never use admin as the password as most hackers try that first because most people use it.). For local development you can put an easy password like password as you are the only one that has access to this. But when you put it live, you obviously want a better password. It should be noted that the username and password here are to enable you to login to the WordPress Admin Dashboard with Admin privlidges.

Check confirm use of weak password checkbox if you use a weak password.

Enter your email. This is important if you ever forget your password as WordPress will send you an email when you request to reset your password.

When working locally or on a staging server, you obviously don’t want SEO engines to see your site so check Discourage search engines from indexing this site. Make sure to uncheck it when in production or else your site will be invisible to all search engines which is obviously bad for business.

page 5 screenshot.

Finally, click Install WordPress.

Page 6

If all goes well you will see:

will see this page.

If not, troubleshoot and try and find the error of your ways. Click the Log In button.

Page 7

You will see this page.

Use your login credentials to login to the admin Dashboard.

To login in the future go to http://localhost/your-wordpress-site/wp-admin

GoDaddy apply_filters() error with WP-CLI Solution

Do you get this error when working with WP-CLI in GoDaddy?

Fatal error: Call to undefined function apply_filters()

Easy solution is to update your WP-CLI with

$ wp cli update

Update on this post

When I ran the above code on the godaddy shared server I got this error:

Error: /opt/wp-cli/bin/wp is not writable by current user

To fix this I used this reference goddady fix

which tells you to go to your home directory $ cd

install wp-cli

$ curl -O

give the proper permissions

$ chmod +x wp-cli.phar

test to make sure it is working

$ php wp-cli.phar --info

create an alias in your .bashrc so you can just use wp in your terminal commands

$ echo "alias wp='~/wp-cli.phar'" >> .bashrc

refresh that file

source .bashrc

if you test this out inside a wordpress install, you should see it working

$ wp plugin list

Thoughts on Wordmove and Workflow

WordMove is like Capistrano for WordPress. If you are coding a simple static site, you just need to FTP your HTML, CSS to your server. But WordPress isn’t a static site and it has a database filled with tables.

Moving your WordPress site from place to place has always been a pain. So much of a pain, that it is for people to make all their changes on the live server. This is known as [cowboy coding]( and is a bad practice. Don’t do it.

Why is Cowboy Coding so bad?

If your luck is anything like mine, something will break and you nor your client will be very happy. There has to be a better way and the great news is, there is.

Introducing environments

You’ll hear a lot about different environments when you enter the world of a developer. You have front end developer and back end developers and these days their worlds have collided so much so that it is hard to tell the difference.

So the three environments I’ll mention today are local, staging and production. Developers names these environments differently. If you’re working on your own project, name stuff how you want. If you are on a team, have a meeting and determine your naming conventions and how you’ll use git and github for your version control.


This file is super important for your team. Come up with what you want to watch and what you want to ignore. Huge for teams.

Naming Conventions

Huge. Come up with a team coding style guide. Makes life so much easier. Tabs or spaces?

Local Development Server

This is on your machine. So my workflow is to have VirtualBox installed with Vagrant and VVV. VVV came from the WordPress community and this helps set up our virtual box with an environment for WordPress. Virtual Machine and Vagrant came around to make improvements from WordPress developers working with MAMP. There is tons of material out there for you to sink your teeth in to learn all about VirtualBox, Vagrant and VVV so I’ll leave that as an exercise for you to do.


If you want to quickly create WordPress sites, use VV.

VVV Dashboard

VVV Dashboard gives you a nice view to see stuff like phpMyAdmin and all your local sites.

To Debug or Not to Debug

Turning debugging on in wp-config.php in staging and local environments.

Search Engines

Make sure you are not visible to search engines in staging and local but are visible in production.

Update Permalinks

If your links are acting strange, make sure to update permalinks.

Staging Server

So you spend all week working on the coolest WordPress custom theme ever. You test it and it works on your machine. But you need to show it to your client. That is the purpose of the staging server. Your client can’t see your computer unless you bring it to them. Why not make life easier for both you and your client and set up a staging server. That way anyone connected to the internet can see your WordPress stuff.

I usually set the staging server up on my client’s shared host. They have a cpanel that I can use to do the following:

Enable SSH

FTP is so old. Been there, done that. It is not secure. They have SFTP but imho, SSH is the way to go. Chances are your client is using a shared host so just keep in mind that many shared hosts will require that you email/call them before they enable SSH.

Generating SSH keys

Once you have that set up you need to create your private and public keys. Private is on your computer and you save the public onto your shared host. That’s how the remote server knows you are who you say you are (and not a hacker).

Then if all goes well you will be able to SSH into your remote server Using something like:

$ ssh

Then you’ll see your box.

The next thing I do is set up [WP-CLI]( on my remote host so that I can quickly and easily install WordPress on my remote server.

Create A Database

So on your shared host, log in to the cpanel and create a database. I like to name my databases with no spaces and underscores instead of hypens. Example database name: my_sample_database. I make sure my password doesn’t have any crazy characters as they tend to break WordMove.

I write down all this information a safe place. If you don’t and you forget the info, you’ll hate yourself for forgetting.

  • DB Name
  • DB User
  • DB Password
  • DB Host

When you create a MySQL database you need to name it properly (you’re host will tell you how it should be named), you need to create a user and associate that user with the database and give that user all permissions.

I also write down my WordPress admin login information (username and password) that I created using WP-CLI


Production is your live site. Right down the Database information for production in a safe place. (it will be inside your wp-config.php file). Someone should provide you the WordPress admin login info if you did not create the site. If you are creating it, write it down in a safe place.

WordMove time

So now you navigate to your VVV site. I create this using VV create and pass the information I need to create my local site. It usually will take approximately five minutes to get your new WordPress site created. Good time to go for a walk and grab some coffee.

I then browser to my WordPress project root and create my Movefile file with

$ wordmove init

That will create a Movefile. This file is in YAML format which means spacing is very important. Things will break if the spacing is off. If you think all the info is correct but it isn’t working. Delete the file and recreate it with meticulous detail and attention to the spacing. That has saved my neck a bunch of times.

All that Staging and Production connection info you saved to a safe location is now front and center. Get it and plugin it into your WordMove file into the different environments. Add the SSH and database info for Production and Staging. If all goes well you can begin using WordMove.

I usually start by grabbing the entire production site and pulling it locally

$ wordmove pull -e production --all

Your Machine or your Virtual Box?

This is a very tricky part and I’ll tell you how I navigate this very dangerous waterway.

I don’t install WordMove on my local machine. I install it on my VirtualBox machine. This will prevent lots of problems with path. That way when you accidentilly try to run wordmove from your local machine, you will get command not found.

To get into your Vagrant virtual machine you use vagrant ssh. After about three minutes, you’ll be SSH‘d into your virtual box. Then you need to navigate to your project.

Where are your sites in vvv?

Usually in the www folder

Don’t forget htdocs


I create zsh (and oh-my-zsh) for my virtual box and give different themes for my remote site and local site so I can visually know where I am. I also add aliases so I can easily move around.

Once I pull my whole site locally, I update all the plugins. I remove all plugins not being used. I remove all themes not being used. I usually keep the most updated WordPress theme in case I ever need to switch to it to troubleshoot.

I then push site to staging server and tell the client to check out my changes. When they give me the green light I pull down the latest and greatest database and includes from production (so I don’t overrite any blog entries or images) and then I push to staging and test. If all is good, I push to production and test and make sure I update permalinks and set the production SEO search engines to on. (it updates the robots.txt file).


That’s all for now. Let me know what you think in the comments below.