Content is a large portion of a website initial deployment and continuous updates are critical to great SEO, ensuring a solid workflow that our team can follow – helps us expedite the process and keeps everyone involved more efficient.
TeamworkPM is a fantastic tool for teams, staying organized and tracking the time it takes to do work for clients is critical in pricing services to ensure you are making money and not losing it. The list below identifies a few of the hurdles this workflow has helped us overcome.
We know exactly what stage every piece of content is in based off of the status, and due dates.
We are able to accurately log all time spent on a single piece of content.
It works for all content types such as an eBook or Infographic, that may require multiple skill sets to create.
It maintains a single thread of the status comments and total time spent.
We do not have update more static documents like, attachments, or notebooks which are easy to get out of version or neglected.
This is a straight-up copy of the orginal article found at https://mallinson.ca/osx-web-development/
I have pased it to my blog because it is extremely valuable to my workflow and I never want to lose it :). Be sure Chris Mallinson and thank him for the write-up.
The Perfect Web Development Environment for Your New Mac
This version of the tutorial works with macOS Sierra (10.12), OS X El Capitan (10.11), OS X Yosemite (10.10), or Mavericks (10.9) and uses Homebrew as a package manager. I streamlined this tutorial in August 2014 to make it even easier to set up your development environment. I’ve archived the original version. In January 2016, I added support for xip.io, which is a DNS redirecting service. This allows you to access your local sites from any device on your network.
I’ve been using this particular configuration, or one quite like it, for several years, but when I picked up a new laptop recently, I decided to start from scratch. There were a ton of settings, scripts, and programs installed on my old machine that I no longer used, and I wanted them gone.Feel free to use this guide on any Mac, but you may find that there are differences on your machine if it’s not a fresh install of OS X. These are the exact steps I used to get things running on my machine, and it’s been tested on many machines.
Why Not Just Use MAMP?
MAMP is a package that will install MySQL, PHP, and Apache on your Mac all with one download, and a quick install. It’s a great option and MAMP Pro, the paid version, will provide most of the features you need to run multiple web sites on your machine. I don’t use it because most of what it offers is already a part of OS X, and I prefer to customize my environment beyond what MAMP provides out of the box. If I’m already going to be playing around with the config files, I may as well go the distance. The main benefit of MAMP is that it leaves all your default system settings alone, sandboxing your development environment. I don’t get any benefit out of that. It also allows you to easily turn on and off services. I don’t ever turn them off, so that’s not any help to me either.
Mac OS X is a great operating system for developers, but many of the features important to us are turned off to make the OS more easy to use for everyday tasks, and more secure. Many of the configuration files we need to edit are hidden away in directories that do not show up in the Finder by default. I’m not going to tell you how to edit files here. Some people prefer command-line tools like Vim or Pico. For most of my code editing needs, I use Sublime Text. It’s not free, but I find the features well worth the price. If you’re going to be using a text editor every day, you’re going to want to pay for a good one. Sublime Text can open files like any other GUI text editor, and can also be invoked from the command line. Make sure you’re familiar with editing config files in the text editor of your choice before continuing.
Everything we’ll be installing here is free, and you can certainly go a long way without having to pay a cent for any of your software. However, don’t be afraid to pay actual money for great apps. If you’ve bought a Mac, you already understand that spending money on a well designed product usually saves you time in the long run. Software works the same way. Below are some of the programs I use regularly.
First, you need to have Xcode (Apple’s development bundle) installed for a few of these tools to work. You can get by without it if you try really hard, but if you’re a developer, you’re probably going to need to have it at some point. It’s massive, so start downloading it now. Grab it from the App Store, and then grab a coffee or play with your kid or dog.
For OS X 10.9 (Mavericks) and up, the developer command line tools can be installed by running the following command within terminal.
Once Xcode is installed, start it up. The tools we need will not work unless the app has run once, and you’ve accepted the licence agreement. You don’t need to do anything with the app. Just start it up (It can take a while to run the first time, even on a fast machine) click agree, and shut it down.
Homebrew is a popular and amazing package manager for OS X. Package managers keep all the big and small tools that we need to install on our machines tidy and up-to-date. It could not be easier to install. Switch over to your terminal, and type in this one command:
It can take a while for the install, but that one command is all you need for Homebrew. Really.
This is optional. You may prefer another kind of database, or no database at all. Feel free to skip this if you don’t need it, but really, you probably do. MySQL no longer comes pre-installed as of Mountain Lion (10.8) as it did with previous versions or OS X. Download it here. You can try the latest version of MySQL for the latest version of OS X. The latest version is currently for 10.11. Choose the 64bit “DMG Archive” one.
This is a great little tool to that allows us to use wildcard subdomain names.
With the default apache settings, you can add as many sites as you like in subfolders of the web root. You can have sites like this:
However, that creates a problem. When you have each site in a folder, it’s more difficult to manage the settings for each site. Each one must then have a different absolute root. The solution is to create a subdomain for each site, and use URLs like these:
We can accomplish this by placing all three sites in our /private/etc/hosts file, but then we need to keep adding entries every time we add a new site. dnsmasq allows us to do this by interrupting each request that ends with .dev and forwarding it to a designated IP address (127.0.0.1 in our case).
To install dnsmasq, we use the previously installed Homebrew. The following commands will install dnsmasq, configure it to point all requests to the .dev top-level domain to our local machine, and make sure it starts up and runs all of the time.
We’re now done with dnsmasq, and if all goes well, you’ll never need to think about it again. Now, to get Apache going.
Your Local Web Root
Apache has a default location for storing website files, but I prefer to create my own web root that is independent of Apache. You can place your files anywhere you wish, but I prejust put them in a directory called /www on my main hard drive. Put yours wherever you wish. In that folder, I have a few subfolders. /www/home is a main website that I use to list all my local sites (I’ll show you how to make that site dynamic later on). /www/sites is the folder in which I place each of my other sites. Each of those site folders has a webroot (/www/sites/client1/wwwroot), and an assets folder (/www/sites/client1/assets), where I keep source files or other documents related to the site.
Step one is easy. It’s actually almost done. Mountain Lion (10.8) was the first version of OS X without Apache in the “sharing” section of the preferences pane. No big deal though, since you just need to start it up once using the terminal. Open up the Terminal app, and enter the following command. You’ll be asked for your administrator password.
sudo apachectl start
That’s it. Test it out by visiting http://localhost in your browser. You should see a simple page that says “It Works”. Apache is up and running, and is ready to serve your sites. It will stay on until you turn it off (I never turn it off), and will start up automatically each time you start your computer. Don’t worry about taxing your computer’s resources by running Apache. It won’t be a problem.
Apache will serve up sites as is, but there are a few quick changes we need to make to the configuration files before we are ready to go. Using your favorite text editor, open up /private/etc/apache2/httpd.conf
If you’re going to be using PHP, you need to tell Apache to use the PHP module to handle .php files. On line 169 (line 117 before 10.10 (Yosemite) but could be different on your system), you need to uncomment this line (remove the “#”)
Starting with OS X 10.10 (Yosemite), Apple moved from Apache 2.2 to Apache 2.4, and that means there are a few additional changes we need to make. First, there is a directive that helps secure your machine by denying access to the entire file system by default. I’ll show you how to remove this directive, since I find that easier on a machine meant for development. The section of code runs from line 220 through 223. You can comment out (place ‘#’ in front of each line) or just remove this section.
508 # Virtual hosts
509 Include /private/etc/apache2/extra/httpd-vhosts.conf
This tells apache to load the information in the httpd-vhosts.conf file in the /private/etc/apache2/extra/ directory. We need to edit that file. You can delete or comment out everything in that file, and replace it with the following:
Options Indexes MultiViews FollowSymLinks
Allow from all
Then run the following to force Apache to load your new config files:
sudo apachectl restart
This configuration allows you to use the URL http://client1.dev on your local machine with your site files stored in /www/sites/client1/wwwroot. It also allows you to use the service xip.io to use the URL http://client1.[LOCAL IP].xip.io to access your sites from another machine (or device) on your local network. So, if your machine’s local IP address (not your public IP address), is 192.168.1.10, the URL for a site might be http://client184.108.40.206.10.xip.io. You can find your local IP address in your network preferences.
Xip.io is offered for free by Basecamp and provides one of the simplest services on the internet. They run a simple DNS server that redirects all traffic to *.xip.io back to the IP address indicated by the subdomain.
Now you don’t need to update config files every time you add a new site. Simply add the necessary folders to your “sites” directory, and the site will work locally with its own subdomain.
A Custom Home Page
Now that you have a bunch of local sites running on your machine, you can bookmark them all, or you could do something fancy, and create your own custom home page that lists all the sites currently available on your machine.
If you’ve got the development chops to build this yourself, go right ahead. All you need is some kind of script that can analyze your sites directory, and a way to output it. I have a PHP script that I’ve used for years to do this. Disclaimer: I do not use PHP very much, and my code is rough. If you’re better at PHP than me, which is likely, and have suggestions for improvement, by all means let me know, or submit a pull request.
This year marks a big year for our Church, lots of things are happening but for my department and specifically myself, my largest project to date is on the horizon, a complete overhaul of our main site http://savannahchristain.com
A standard way to search google for pages within a specific site is to enter ‘site:www.yoursite.com’ into a google as search parameter. This will return only results from the site you specified. Omitting any additional search terms will return all pages of the site as your result. In theory this should give you an idea of how many pages google has indexed on your site.
Just a quick intro to the purpose of this sites existence, and why I am even taking the time.
As a developer who does not work within a larger team, I find it difficult to keep my thoughts and reasoning on track during a project. I frequently ask myself why I did things when I know at the time I had made that decision for a purpose.
My intent is for this site to be a diary of clarity when developing so that I may refer to it in the future as well as share resolutions to issues I was forced to figure out on my own. I also feel much of my research could be used by other Web Developers, specifically among Church Web Developers who have different hurdles to deal with beyond technology.
Currently I plan for most of the content to be focused on Expression Engine, HTML/CSS/JS, and responsive techniques, but I am not limiting it if I find something else important to say.
Enjoy the ride, I hope this time next year I will be able to look back at this post knowing I accomplished my original goal.