// May 30, 2012
Here is my workflow and tools I use when working on a WordPress site locally.
[XWML]AMPP?
For WordPress development, you'll need Apache, MySQL and of course PHP.
If you're on a Mac, you can get XAMPP or MAMP, which will let you install these
software without much knowledge of configurations and compiling. I tend to use XAMPP because I
can use it on port 80 instead of 8888. Use whichever you like the most.
On Windows, you can use WAMP.
Source Control Management
I realize that the use of SCM is quite rare among WordPress users. But with my programming background, it's really hard to not use a SCM. Where I can choose, I always use Git to version my code.
You can either version your wp-content folder, your theme folder or your complete WP install folder.
I like to put the whole wordpress install under version control. That way, I'm always sure that I have the WP version I need for my site to work properly.
If you version your whole WP install, you should at least add 'wp-config.php' (without the quotes) to your .gitignore file (if using Git).
Depending on who will add the content to your site, you might want to make Git ignore the 'wp-content/uploads/' folder as well. Just add a .gitkeep inside it so Git will not remove it from your tracked files.
WP_DEBUG
Another obvious thing: in your local wp-config.php, set WP_DEBUG to true. That way you'll better understand why some plugin make your site crash.
The Debug Bar plugin
Install the "Debug Bar" plugin:
http://wordpress.org/extend/plugins/debug-bar/
Environments (Development, Staging, Production)
Since you develop locally, it means you have a "Development" environment for working on your site and a "Production" environment where your site is hosted. But if it's a big website and you don't want to mess things up, I strongly advise having also a "Staging" environment on the same server than "Production", but on a different subdomain. This makes it easy for you to see if you have any bug related to the hosting environment (PHP version or whatever), and it makes it easy to show your changes to your client before push them live in "Production".
A no brainer for some people, but sadly I still see a lot of WordPress devs not having
this.
Deployment tools
Use an automated way to deploy to "Production" and "Staging". Usually, it's something you might call with the command line. Like a Capistrano task. Or you can make your own Shell script. These tools (capistrano or shell scripts) will usually involve deploying via Subversion or Git. But you can use rsync as well.
Your script can be as simple as push your local changes, pulling them in your Staging/Production environment, then changing your wp-config.php file. Or it can be more elaborate, like exporting your local MySQL database and pushing it, then importing it to the server, replacing every occurrence of "http://localhost/mywpdevsite" for "http://staging.mysite.com" in it. Whatever automated tool you'll end up using will beat the heck out of FTP'ing your files manually on your server. FTP is slow, insecure and too manual for my taste.
If Capistrano seems too much for you, but scripting in Makefiles is not your thing, you can always try Fabric or William, which are both DSL's for interacting with your staging/production server via SSH. (Note that William is my pet project and is nowhere near Fabric in terms of completeness or stability. But it's in Ruby!)
Dealing with URLs in your MySQL dumps
Like I mentioned on the previous point, you'll need to modify your exported MySQL dump because WordPress and some of its plugins will store your domain in the database. Personally, I tend to use the "WP Migrate DB" plugin to change every occurrence of the dev URLs to the staging/production URLs. It's done via the admin so it's not automated, but it's still a time saver. Some scripts exist too, like this one, but I didn't try it yet.
Conclusion
Although working locally might seem like an overhead, it doesn't have to be: Automate your deployment and version your code.
You'll feel much safer knowing that you can always revert to a previous version of you site if something goes wrong. And it's stress-free development, which means you can go wild with your changes without fear of breaking your site.
// March 30, 2012
So you're on a Mac, and you need to test your cool website on Android, except
you don't have any Android-powered device? Read on.
(The following have been tested on Mac OSX Snow Leopard and Lion)
- Download the Android SDK on this page: http://developer.android.com/sdk/index.html
- If you don't have it, create a bin directory in your home folder (~/bin)
- Extract your Android SDK zip archive into it, so you should have ~/bin/android-sdk-macosx
- Add ~/bin/android-sdk-macosx/tools directory to your $PATH environment
variable:
- for this, open ~/.bash_profile (create this file if it doesn't exist) in your text editor, then add the
following line (modify yourusername):
export PATH="$PATH:/Users/yourusername/bin/android-sdk-macosx/tools directory"
- To update your current shell's environment variables, execute this in the
terminal:
source ~/.bash_profile
- You should now be able execute the
android command. If it shows "No Java
runtime present, requesting install", and a message dialog asking you to
install Java, proceed with this installation as Android SDK needs Java to
work.
- Once you've executed
android, a window should appear, listing some Android
SDK files. We will need to install some "Platforms". For my part, I installed the packages that are selected by default
(Android 4.0.3 (API 15), at the time of writing this). But feel free to
download as many Platforms as you wish.
- When you're done loading packages, you can click on Tools > Manage AVDs...
from the Android SDK Manager app. Doing so will show you a Window named
"Android Virtual Device Manager".
- Click on "New..." to add a new Virtual Device.
- Name your device something like "my_avd" (dont put any space or special
characters in it)
- Choose your target. In my case, I chose "Android 4.0.3 - API Level 15".
- I suggest you keep every other settings at their default values and click
"Create AVD". Doing so should display a dialog that says that your AVD was
created. Click OK.
- Now, you should be able to run this AVD with the
emulator command
provided by the SDK, which is inside the "tools" directory, like
the android command. So in your terminal, run the following command
emulator @my_avd , where my_avd is of course the name of your AVD.
- You should see the DDMS app opening, and a dialog thanking you for using
Android SDK. Note: I like to help the people that give me free tools to
test my apps, so I recommend you check "Send usage statistics to Google",
and click "Proceed".
- Wait for your virtual device to boot. Depending on your hardware it may
take a couple of minutes. After which everything should work fine.
- Oh yeah, and since this tutorial is about testing Web applications, you can
open the Web browser by clicking on the lower right (earth) icon.
If you're testing a Web app that you're developing locally, you will need the IP
address of your machine, in place of 'localhost'. Doing an ifconfig in the terminal will give you this
address.
And that's it!
// March 10, 2012
If you develop WordPress sites, chances are that you know a lot of functions,
and how to use them. But there are quite a lot of them, and if you don't know
them all, you might end up re-inventing the wheel for some of the sites you
create.
Because fortunately, WordPress already implemented most of the Wheel, and a lot of this Wheel is available as functions, that you can read about in the Codex.
So it would make sense for you to learn them.
But going to the Codex and reading about every single function to see what they do is an effort that takes
time. And in my opinion, it's better to just set this as one of your goals, and let
something remind you later about this goal.
That's why, two weeks ago, I launched The Daily WordPress Reference newsletter to help
people learn all the important WordPress functions. Every day. One at a time.
Right now, we're over 230 WordPress enthusiasts to receive one function reference every day.
Try it! It's free.
And if you like it, you should also follow the Daily WordPress Reference on Twitter. :)
Let me know what you think about it!
// November 19, 2011
The problem
I always need to send people screenshots. For this, i used to use LittleSnapper to publish the screenshots on my server (at http://s.juliendesrosiers.ca/*) for other people to see them.
It worked great, but for the sake of learning bash, and because i love to make my own things, i made a small Automator script to accomplish this simple task.
The script
filename=$(basename $1)
public_url="http://s.juliendesrosiers.ca/$filename"
scp $1 tannant:/home/deploy/apps/s_juliendesrosiers_ca/$filename
/usr/local/bin/growlnotify -m "Uploaded: $public_url"
echo $public_url | pbcopy
Explanations (and things to modify)
The first line takes the base name of the file’s name (for example, instead of /home/user/julien/myfile.jpg, it would be myfile.jpg only)
filename=$(basename $1)
Create a variable that will hold the full publicly accessible path, with the file name. Change s.juliendesrosiers.ca for your own web address.
public_url="http://s.juliendesrosiers.ca/$filename"
scp will copy the file from its local location (in your computer) into your remote server (in my case, “tannant” is simply an ssh shortcut for this host, but in your case, you’re likely to replace this for something like “youruser@yourhost.com”). You’ll also want to modify the remote path (/home/deploy/etc…) to reflect the directory structure of your own server.
scp $1 tannant:/home/deploy/apps/s_juliendesrosiers_ca/$filename
The following line will notify you that your upload worked successfully.
For this line, you’ll need to install Growl, along with it’s command line utility “growlnotify”.
With homebrew, it’s only one brew install growlnotify away.
/usr/local/bin/growlnotify -m "Uploaded: $public_url"
Last but not least, we put the newly-uploaded image’s public address into the clipboard.
echo $public_url | pbcopy
Now the Automator part
- Open Automator
- File > New > Application
- In the actions library, choose “Execute a shell script”, and drag it into the right panel.
- In the “input data” select at the right, choose “as arguments”, or something like this (i have the french version).
- In the big text field, paste your big (modified to your needs) command.
- Save. On your desktop, or in /Applications, or whatever.
Usage
Just drag your images or screenshots over to the Upload Automator script’s icon to upload them to your server and wait for it to return your public URL.
Note
Please note that if you want people to see your uploaded files on your server, you must serve them with a Web server (Apache, nginx, etc). This is outside of the scope of this post.
// September 18, 2011
The renowned cellist Yegor Dyachkov came to us asking for a CMS for his new website. So we created a simple, Sinatra-based (programmed in Ruby), CMS that makes it possible for him to manage all of his site’s content.
The excellent graphic designer Susan Scott created the mockups for Julie to integrate into the website, using HTML5 and CSS3 code.
The result is an elegant website that features the music of a master cellist. We really hope you will enjoy this piece.
Open source
From this project i abstracted and open sourced a small Sinatra module (https://github.com/juliend2/ck_image_upload) to handle the image upload in CKeditor for the Sinatra back-end. I also created a jQuery plugin (https://github.com/juliend2/julienMP3Player) for the MP3 player.
More infos about julienMP3Player here.
// July 20, 2011
Ever wanted your own Github-style wiki on your own mac server? Read on…
Gollum is the Git-powered wiki that is used in the Github’s wiki system. This tutorial will show you how to run it on Pow’s zero-configuration server on your mac.
Step 1:
Install gollum on Ruby 1.9.2 (tried 1.8.6 with no luck)
gem install gollum
Step 2:
Create a blank repository where you want to store your wiki pages. I put it in ~/Sites/wiki so i wrote:
cd ~/Sites/wiki
git init
Step 3:
in ~/Sites/wiki/ , create a config.ru file with this content in it :
require "gollum/frontend/app"
Precious::App.set(:gollum_path, File.dirname(__FILE__))
Precious::App.set(:wiki_options, {})
run Precious::App
(thanks to this thread)
Step 4:
Install the “Pow” webserver:
curl get.pow.cx | sh
Step 5:
cd ~/.pow
ln -s ~/Sites/wiki
Step 6:
Gollum lets you edit wiki pages with textile, markdown, Rdoc, and many others. If you want to edit your entries with Textile, you’ll need to install the RedCloth gem, like this:
gem install RedCloth
Step 7:
Now, the fact that your rack app is in the wiki folder makes your app available through wiki.dev on the machine that is hosting it. BUT, if you’re like me and you need to access it from another computer in your network, then you need to get the IP address of your mac that is hosting the wiki, and add an entry like this in the /etc/hosts file on every machine that wants to access the wiki (in my case, the macmini that is hosting the wiki has 192.168.2.12):
192.168.2.12 wiki.dev
That’s it! You can now visit http://wiki.dev in your browser.
// April 2, 2011
These days i’m creating a website for a musician. And he needed an MP3 player for his website. So my first thought was to use an open source MP3 in flash . But since i need to extend it, i looked at the AS2 code and i thought about the possibility to use JavaScript instead (i prefer JS to AS). It turns out there is already a library that lets you play and control sounds via JavaScript, by using a swf file (for maximum compatibility). It’s called SoundManager2, and it rocks. But since i needed something that could play multiple songs one after the other and that can be easily dropped via jQuery in a non-obstrusive way, i created a jQuery plugin that leverages SoundManager2, and i called it julienMP3Player.
Here’s a Demo: lab.juliendesrosiers.com/demo/julienMP3Player/.
Download/Fork it on GitHub: github.com/juliend2/julienMP3Player.