Every so often I switch computers or reinstall my OS and end up searching around the web for the exact steps to get everything working again. Today, as I set up my OS again, I figured I might as well document the process. Since Linux Mint is based on Ubuntu, I think that these steps (at least most of them) should work for Ubuntu users as well.
1. Install the OS
There are plenty of tutorials around the web explaining exactly how to install Linux. Today I’m going to skip straight to the steps I take immediately after the OS installation in order to turn Linux into a tool for web development.
2. Install LAMP
LAMP stands for Linux, Apache, MySQL, and PHP. The first letter of the acronym (Linux) is already installed, so we don’t need to worry about that. Some people prefer servers other than Apache, databases other than MySQL, or languages other than PHP. However, I think these are the easiest to set up and since I spend the majority of my time working with WordPress, this setup suites me well. There is a handly little tool called “tasksel” that will make the installation of the LAMP stack quite painless. We can use the following command to install this tool from the command line:
sudo apt-get install tasksel
Once tasksel is installed, it can be run using the following command:
This will bring up a selection dialog within the terminal that will let us easily add additional functionality to our OS. In this case, we want to use the arrow keys to navigate to the LAMP server option and press the space bar to select it.
After this we can hit enter and tasksel will go about installing most of the pieces we need. Part way through the installation process, we will be prompted to create a password for the MySQL root user, but other than the, the process is all automated.
Once this process is finished, visiting http://localhost/ in our browser should display a page titled “It works!”
Just to make things easier, at this point I like to go and change the permissions of the /var/www/ folder (localhost). I set my normal/default user as the owner so that I don’t have to switch users when adding/editing files on the server.
3. Install phpmyadmin
I prefer to use a GUI to mess around with my databases. The following command will install phpmyadmin to hande that:
sudo apt-get install phpmyadmin
This will lead to a few more dialogs. The first will ask which sever we’re using, and we can select apache2. Next we will be asked if we want to configure the dabase for phpmyadmin with dbconfig-common. I have always selected the default value “yes” because I don’t have any reason not to. Next, we will be asked to enter some passwords. I don’t remember the exact wording of the prompts but entering the same password we entered in step 2 will work.
Once this process is complete, phpmyadmin should be accessible by going to http://localhost/phpmyadmin/ in our browser.
4. Install WordPress
I’m not going to explain this step because it is already well documented in the WordPress Codex. However, I’ve added it to the list here because:
- Installing WordPress is almost always one of the first things I do.
- Having WordPress installed makes it easy to test whether mod_rewrite is working properly, which is covered in the next step.
5. Setup mod_rewrite
The mod_rewrite module is what allows things like “pretty permalinks” in WordPress to work properly. For some reason, getting it working with Ubuntu/Mint is trickier than it should be. In fact, I’ve run into this issue so many times that I’ve already covered it in a different post.
6. Install git
Many of my projects are hosted on GitHub or Bitbucket, so the easiest way to add them to my new machine is with git. This command will install git from the repositories:
sudo apt-get install git
7. Install node.js, npm, and Grunt
I’ve just started using Grunt and I’m impressed at how well it automates tasks and how easily it allows me to make use of more advanced tools such as SASS, JSHint, etc. Node and npm can be installed easily with the following command:
sudo apt-get install npm
Note that only npm is listed, not node. Ubuntu/Mint will automatically calculate the dependencies that are required and install them as well. This includes the nodejs package. This is helpful because there is another package in the repositories simply called “node” which is not the right package and can cause some confusion. Once npm is installed, the Grunt Command Line Interface can be installed with the following command:
sudo npm install -g grunt-cli
This does not install Grunt itself. The grunt-cli package simply adds the grunt command to the system path so that it can be run from any directory. Grunt itself must be installed locally within each project where it is used. For more details on installing Grunt, I would recommend reading this post on installing Grunt by Stephen Harris.
As mentioned earlier, the Node.js package is named nodejs in Ubuntu/Mint. However, some scripts will be looking for “node” rather than “nodejs” so it’s best to create a symlink between the two using the following command:
sudo ln -s /usr/bin/nodejs /usr/bin/node
8. Changing the Apache User
Since by default Apace runs as the user www-data and the /var/www directory now belongs to our default user account, the automatic updates/plugin installs built into WordPress won’t work. To fix this, we just need to adjust Apache to run under our default user account. We can do that by replacing www-data with our default username in the following two lines of the /etc/apache2/envvars file:
export APACHE_RUN_USER=www-data export APACHE_RUN_GROUP=www-data
9. Get Back to Work!
So that’s how I set up my local development environment. I left out IDEs/code editors because almost everyone has their own preference and if you have a preference, you probably already know how to install it. I personally use Sublime Text, but like I said, that’s personal preference. I also use VirtualBox to install virtual copies of Windows for testing various browsers, but that’s outside of the scope of this article.
Is there anything else you do to get your local development environment up and running? If so, I’d love to hear about it!
- PublishedMarch 4, 2014
- Posted InLinux
This is the fifth in a series of posts documenting the creation of Theme Friendly, a website dedicated to reviewing commercial WordPress themes.
On day four, I built the search page. This was easily the most difficult part of the entire process. Let’s start with the screenshot.
Day 4 Screenshot
If you read my post covering day 3 you might be thinking, “Hey! this looks almost like the review archive from the last post.” …and you would be right. I reused the template part I created for the review archive to display the search results. Adding the search form was a little more difficult though, and filtering the search results based on the input from the search form was even more difficult. Here’s how it worked… (more…)
- PublishedJanuary 7, 2014
- Posted InProjects
This is the fourth in a series of posts documenting the creation of Theme Friendly.
On day three, I built the review archives page. I don’t think this page will be used directly, but on day four I incorporated it into the search results page, so it was still worth building.
Day 3 Screenshot
After all the hard work that went into building the single review page on day 2, this page was pretty short and sweet. It only had to display each theme’s title, quality score, thumbnail, and author. Most of the backend code was easily modified from the single review page code. I just had to add a new image size and some CSS to handle the new layout.
In the next post in this series, I’ll be detailing how I built the search functionality that makes it simple to find only themes that match your exact requirements. Sign up for the Theme Friendly newsletter to find out when it is published. Until then, Happy New Year!
- PublishedDecember 31, 2013
- Posted InProjects
This is the third in a series of posts documenting the creation of Theme Friendly.
On day two, I set about building the individual theme review page. The goal was to provide a quick overview of the quality of a theme as well as it’s features. This was to be done by displaying the contents of all the custom meta boxes and custom taxonomies created on day one.
Day 2 Screenshot
- PublishedDecember 17, 2013
- Posted InProjects
This is the second in a series of posts documenting the creation of Theme Friendly.
Day 1 Screenshot
Most of day one was spent planning and implementing the data structure for the new site. As you can see, I didn’t do too much work on the design:
- PublishedDecember 4, 2013
- Posted InProjects
This is the first in a series of posts documenting the creation of Theme Friendly.
A short history
I’ve been thinking about building a commercial WordPress theme directory for a number of years now. I even tried (and failed) to get one off the ground a few years ago. During that time, a number of other sites sprung up with similar goals and I gradually abandoned my project. However, the idea never left. I kept thinking about what could be done to ease the process of finding the perfect WordPress theme for any particular project. I decided to see if I could build a working solution in just one week.
- PublishedNovember 27, 2013
- Posted InProjects
As of this writing, I have only two plugins in the WordPress.org repository. I periodically update these plugins, but not often enough to memorize all the steps required to get things right on the first try. So for my own future reference (and maybe yours as well) here are all the steps laid out in order.
Last week, Pippin Williamson published a post titled “Why Loading Your Own jQuery is Irresponsible.” This very issues was brought up tonight at the Seattle WordPress meetup, which led to a lively discussion and referenced Pippin’s post. Please, for the love of the WordPress community, just use the version of jQuery bundled in WordPress core…
However, if you’re going to load jQuery irresponsibly, don’t do it such a half hearted way by loading whichever version of jQuery is the latest at the time! Throw caution to the wind and use the new “Random jQuery” plugin! It loads a random version of jQuery from Google’s CDN with no fallback! It supports versions 1.2.3 all the way through 1.9.1! Also it will save people hours of work because rather than being forced to debug a theme that hard coded it’s own version of jQuery, troubleshooters can simply deactivate the plugin! It’s a win/win for everyone! Yes, I did just use an exclamation point at the end of every sentence in this entire paragraph!
- PublishedMarch 15, 2013
- Posted InHacks
Let’s say you want to use add_action() to attach a function to an existing action, but you want to pass your function a few arguments. This seems to be a common problem with no good solution. Yes, you could use global variables, but that’s rather messy, especially if you want to attach the same function to a number of different actions but with different arguments each time. After running into this issue again a few weeks ago, I set out to see if there wasn’t a better way to do this. Here’s what I came up with…
- PublishedMarch 7, 2013
- Posted InWordpress
Data portability within WordPress is a big deal. However, best practices regarding how to properly make data portable are hazy at best. Where should custom post types be defined? What should happen to the data when a user switches themes?
In this post I will attempt to summarize the various arguments, point out one overlooked fact, and offer a limited solution that can be implemented regardless of your particular views on data portability.
Attempted Summary: Themes vs Plugins
For the sake of simplicity, I will be discussing data portability as it applies to custom post types. It seems that the true question that everyone is trying to answer is this:
What is the most user friendly way to implement theme-related custom post types, and what should happen to the data when a user switches themes?
For example, let’s say you’re creating a portfolio theme using a custom post type to hold the portfolio items. At first glance, it appears that defining the custom post type within your theme would make the most sense, because the data is specific to your theme.
However, more and more developers are pointing out that if a user switches themes, their portfolio items will disappear, both from the front end and the back end. Obviously, this is not an ideal end-user experience, and so the suggestion is made to define the custom post type in a plugin. Now if the user switches themes, the data is visible on the back end, although it still disappears from the front end.
Is this a step in the right direction? Yes, probably. However, let’s not pretend that this is good usability. Which is more confusing, trying to figure out why your data is missing completely, or why it’s only missing on the front end? I really don’t have an answer for that. Neither of them are good options. (more…)