We’re HIRING TWO WEB DESIGNER/DEVELOPER positions

The Sr. Web Designer role will be a front-end and PHP developer heavy, WordPress experience necessary kind of job where you’ll work directly with WordPress VIP (http://vip.wordpress.com/) to build sites for our brands (Chrysler Capital, Maserati Capital, RoadLoans, Santander Consumer USA, and more) in addition to building our core websites where customers can pay their bills and dealers can view loan applications. http://www.santandercareers.com/job/sr-web-designer/

The Web Designer II position is more design and user experience related: designing whole websites, making mockups and prototypes, seeking to improve conversion rates, understanding analytics, content maintenance, etc. http://www.santandercareers.com/job/web-designer-ii/

Both positions are open to officing out of our Denton, TX Square location or our Downtown Dallas, TX location — both of which have plenty to offer in the way of restaurants, transportation, coffee shops, etc.

So if you know someone into design or web development, share this with them!

http://www.santandercareers.com/job/sr-web-designer/

http://www.santandercareers.com/job/web-designer-ii/

Local, Dev, Staging, Production WordPress Workflow

I just wanted to share real quickly (because I’m pretty stoked) that after months (really, years) of development I finally have what I consider a professional workflow for WordPress development.

Below is a graphical representation of what takes place. But it breaks down to this (with Git, but can easily be accomplished with SVN as well):

  1. Pull down the Github repository
  2. Develop locally at local.example.com
  3. Commit changes and push to Github
  4. Push to Beanstalk if you want changes immediately pushed to dev.example.com
  5. Merge master to production and push to Github and Beanstalk
  6. The production branch is automatically deployed to staging
  7. Manually deploy to production from within Beanstalk

Notes:

  • Local and Dev share a database (but don’t have to)
  • Staging and Production share a database (but staging only has read access)

WordPress Workflow

 

You can fork the Denton Bible Church Website even if you just want to use this is a framework for your project.This is built off of Hybrid Enterprise which is a cleaner repository that accomplishes the same thing.

Finally, and sadly, I am still looking for the best multi-environment database solution. Ideally, a fourth environment would be used to make content changes against the latest production branch code and then changes would be selectively deployed to the production database. WordPress 3.6 almost had a great solution.

Settling the WordPress Absolute vs Relative URL Debate

WordPress is somewhat notorious for using absolute URLs in its linking to images and other posts within content. Many have argued for both sides.

It’s quite simple for me: relative URLs are easier for development, absolute URLs are smarter for live websites.

There’s a compromise to be had.

WordPress should add these shortcodes to core:

  • [home_url]
  • [uploads_directory_url]

This enables the user and the WordPress editor to insert links to other pages and media on the site while maintaining its given site domain and path. Developers would no longer have to find and replace all instances of the home URL when importing a local database to another environment.

When linking to another page on the site, WordPress could insert [home_url]?p=203, maintaining a lifetime of environment changes and domain moves without broken URLs.

Or, when linking to an image: [uploads_directory_url]/2013/01/example.jpg. Actually, I think linking to media needs to be completely rethought (i.e. [media id="100"] would render whatever image path was associated with that media ID. This would allow you to update an image in the media library and have the image update everywhere it exists on your site).

Update: I wrote a proof of concept plugin for media being inserted into posts with shortcodes to ensure portability.

Theme revisions and WordPress cache busting

When you enqueue CSS or JS files WordPress will append the current WordPress version as a parameter … an attempt at cache busting.

The process by which sites or servers serve content or HTML in such a manner as to minimize or prevent browsers or proxies from serving content from their cache. This forces the user or proxy to fetch a fresh copy for each request. Among other reasons, cache busting is used to provide a more accurate count of the number of requests from users.
IAB

This type of parameter on your static resources is semi-useful. When you upgrade your version of WordPress returning visitors will be served with a fresh copy of your files. But what about all those changes you made to your style.css in between WordPress upgrades?

I use Beanstalk as my SVN repository host. Their coolest feature is automated and manual deployments. Simply commit your changes locally and watch them deploy to your staging/production server within seconds. No FTPing (and no accidents). Beanstalk puts a single file in the root directory of wherever you’re deploying to called .revision. It contains a single integer which is the latest revision that was deployed. You could manually update a file like this if you don’t use deployments.

So this function below grabs that revision number. You can then place this function in your enqueue call to replace the default WordPress version parameter with the latest SVN revision number … busting caches when they need to be.

WordPress network in multiple environments with a single database

Problem

I needed a way in my multisite setup to have multiple environments that shared the same database, but used different domains.

  • server1.example.com
  • server2.example.com
  • example.com

… each of those would point to the same database. This is easy to achieve in a standard WordPress install using define( 'WP_HOME', 'http://server1.example.com' ); and define( 'WP_SITEURL', 'http://server1.example.com' );.

When you add multisite to the mix it breaks.

The problem is that the wp_blogs table defines the domains too, so I needed a way to define them in the config file.

Solution

UPDATE: A more complete solution: https://github.com/developdaly/WordPress-Skeleton

Taking @chrisguitarguy‘s advice, I used sunrise.php to intercept the host and spoof it so that WordPress uses domain I customize to load the site content.

A really sweet WordPress development environment

I’m always trying to figure out a more efficient way to do development. I’ve tried more than a dozen different applications to develop in: Notepad, Notepad++, Dreamweaver, FrontPage, Aptana, and so on.

Whichever application you end up using it still only solves some of the problems. So this post will divulge my development environment for some projects. This isn’t the ‘end all, be all’ and it will evolve, but its evolved to this point over years and years and I finally have something I really enjoy.

Most of the content in this tutorial is applicable to any operating system, but it is written for Windows users and some parts will need to be amended for Mac users.

Table of Contents

Local Environment

I used to hate local development. It makes sharing your work so much more difficult, configuring a local server isn’t always easy, and there’s so many things to change once you move to production. Not anymore.

Install Apache, MySQL, and PHP

First of all, for any local development you’ll need WAMP, XAMPP, or MAMP. These set up an environment that allows you to run a website on your machine. I use WAMP on a Windows machine. All of these programs will install Apache, MySQL, and PHP along with some helper applications like phpMyAdmin.

Choose which one you like the most and install.

Configure MySQL

After you’ve installed your server environment you need to create a database for your WordPress site.

Open phpMyAdmin or another bundled database application. From the homepage of phpMyAdmin you’ll be able to easily type the name of a new database and save it.

Configure Apache

There are two steps to allowing your computer to act as the server for a website using a real domain. Our intention is to setup example.com to run off of the local computer (rather than from the internet).

Use your real domain

One of the most annoying things about local development is that most tutorials have you setup http://localyourdomin/
. That means when its time for production you have to find and replace all occurrences of that in your database and files. Lots of room for error there. So let’s just use your real domain: http://example.com (obviously, replace all instances of example.com with your domain).

1. Edit your HOSTS file

In Windows, use Notepad to open C:WindowsSystem32driversetc (be sure to “Run as administrator”) .

Add to the bottom of the file:

# 127.0.0.1 example.com #local
# 123.4.5.6 example.com #production
  • The # (pound sign) denotes a comment. So everything following the pound sign is ignored. So this example won’t change anything once you add it to the file.
  • 127.0.0.1 is the IP address of your machine. Replace 123.4.5.6 with the IP address of your remote server (the one your website is hosted on).
  • #localand #production are just comments to signify which server goes where.

Now, if you un-comment the local server when you try going to example.com your browser will look to your local machine.

NOTE: You can get browser extensions to quickly switch between hosts. Since I do most of my development in Firefox I use HostAdmin.

2. Edit Apache’s httpd.conf

Your computer now knows that example.com is hosted on your machine, but your server needs to know where your local website is located.

Open up httpd.conf (varies depending on which software you installed, but in WAMP its in C:wampbinapacheApache2.2.17conf).

Add to the bottom of the file:

<VirtualHost 127.0.0.1>
 ServerName example.com
 DocumentRoot "C:/wamp/www/example_com"
 ServerAdmin [email protected]

<Directory C:/wamp/www/example_com>
 Order Allow,Deny
 Allow from all
 </Directory>
 </VirtualHost>

Save.

Install WordPress

Download the latest version of WordPress, unzip it, and put its contents intoC:wampwwwexample_com.

Go to example.com and you should see the WordPress installation screen. Follow the wizard. The database name is the one you created earlier. The username (by default) is “root” and the password is blank (null).

Code Editor

You may use Notepad to do all of your development. Pat yourself on the back; you’re hardcore. You’re also missing out.

Finding the right software is hard. Some are ugly, featureless, slow, or dead. A couple years ago I found Aptana. Its an IDE, which basically means that it does way more than edit files.

What does an IDE (and specifically Aptana) offer?

  • Remote FTP/SFTP file editing. Upload/download of files.
  • Code completion: PHP, CSS, HTML and more.
  • Real-time error/warning checking against W3C standards.
  • Local projects

After you install Aptana you can create a project.

  1. Go to “New” → “Project…”
  2. Name your project (maybe example.com)
  3. Uncheck “Use default location”.
  4. Browse to and choose C:wampwwwexample_com
  5. Click Finish

Your project now contains all WordPress core files, themes, and plugins. Use the project explorer to view all of your files

You can also use Aptana to connect to FTP and remotely edit files. A better method may be to edit locally and use Aptana’s synchronization features to push the files live after you’ve tested locally.

Source Control

At this point you don’t need to go any further unless you’re interested in using source control. Everything we’ve done so far is good enough for a local environment and/or remote editing. But you can make things even beefier with source control…

Source control can be confusing and I’m not going to explain everything here. Instead I’m just going to layout how to use various tools to interact with SVN.

For those a little unfamiliar though, here’s some benefits of source control:

  • History of changes
  • Backup of code
  • Teams can work on the same code simultaneously

I use a few different repository systems, but my favorite is Beanstalk. A single feature makes Beanstalk amazing: deployment. More on this in a bit.

SVN setup

Repository structure is important to get right. There’s lots of ways to do it and you probably will need to tailor it to your project’s needs. But imagine you’re developing several themes and plugins. This is the organization I’m using for just that:


/
    /themes/
        /my-theme/
            /branches/
            /tags/
            /trunk/
                index.php
                style.css
    /plugins/
        /my-plugin/
            /branches/
            /tags/
            /trunk/
                my-plugin.php

This organization allows you to add multiple themes and plugins and keep them each separate from each other and allows you to tag a new version of the theme/plugin.

Create that structure in Beanstalk or whichever solution you’re using. Add a theme or plugin directory and put some files in its trunk directory.

Checkout locally

Now we want to checkout our theme/plugin locally and have it sit right inside the local WordPress installation we already setup.

  1. Install TortoiseSVN
    1. This allows you to do SVN actions within the Windows file system
  2. You’ll need to restart after you install. So tweet this post so you know how to get back to it ;)
  3. Navigate to C:wampwwwexample_comwp-contentthemes
  4. Add a new directory with the name of your theme, my-theme
  5. Right click my-themeand choose “SVN Checkout…”
  6. Enter the URL of your repository
  7. Make sure your Checkout directory is the one you right clicked on
  8. Click OK

You’ll probably have to enter your SVN credentials as well.

Now you can login to your local WordPress and your theme/plugin will be visible (assuming you have the necessary files).

You can edit files and view the changes locally, then once you’re satisfied with your work you can commit it to the repository.

Deployment

Here’s the fun part (and we’re almost finished). Like I said at the start, it annoys me to have to manually upload and overwrite files via FTP. Its just an extra step and more room for error.

Deployment works like file syncing. Beanstalk keeps a revision record and puts it on each of your servers. This file tells it which other files you’ve made changes to, added, or deleted. Then it scours your server and syncs the files by making it identical to latest revision in your repository.

Using Beanstalk you can automatically deploy all commits to your remote server. I don’t suggest doing this exactly.

Staging server

Use Beanstalk to setup an automatic deployment every time you commit to your staging server. Pushing all of your commits to a staging server makes your latest revisions remotely accessible. This is handy for showing clients or for non-developers to see a working example (i.e. quality assurance, marketing, etc.). Its also a good idea to keep the staging server environment identical (or very similar) to what you’ll be pushing it to on production.

Production server

Finally this is your 100% publicly accessible live website. I use Beanstalk to manually deploy to this environment. Automatic deployment to production may work for you (especially on smaller, less critical sites) but you’ll need to be ready to roll back in the event of any problems.

After staging looks and works perfectly then I use a few clicks of the mouse inside of Beanstalk to manually deploy the latest version. Within seconds I’m confident that all production files are up to date.

Roll back

In the case that something goes horribly wrong, just manually deploy the previous revision. Its so easy!

Show Me Yours

I’d love to know how you have your environments setup. I’m willing and ready to improve mine. Streamlining the process just means I can spend more time paying attention to better code.

What is Your WordPress Experience Level?

[polldaddy poll=2641979]The most successful marketers have one thing in common — they know their audience. Unfortunately, I’ve taken my site in so many directions over the years that my audience has consistently changed, rather than consistently grown. So that’s mistake #1 that I made.

Mistake #2 is that since I’ve decided on the general goal of this site — that is, to make Develop Daly accessible to customers and to provide rich information on WordPress and web design — I haven’t really addressed who I’m writing to.

Now, whomever my audience is won’t dictate the exact content of the site, but it will help me determine whether or not posts like “Is @font-face Safe to Use Yet?” needs more or less explanation of the general topic of web fonts. With that said, leave your vote on the poll.

WordPress Tips 2010

WordPress Tips 2010

For the past two years I’ve give ten tips on how to better use WordPress so I wanted to continue the tradition. This time, however, I’m taking a bigger picture look at the WordPress horizon. These “tips” are less tangible than adding a snippet of code to a template or installing a new plugin. Still, you’ll surely find them helpful for understanding WordPress more as well as keeping up with the always evolving software.

Also, there’s many posts out there featuring tips for WordPress. Honestly, I don’t have much more to add at this point. That said, after the 3.0 launch in April 2010 there will be much more to discuss.

Theme Frameworks

My prediction is that before long the majority of new themes will be child themes. That is, once the WordPress theme repository supports child themes I think they will catch on quickly with developers and gradually gain users. The reason is simple. Child themes are easier to make, maintain, and switch between than traditional themes.

The parent/child theme relationship is already possible with any theme, but frameworks built for the sole purpose of being said framework are so robust and well thought out that they’ll pioneer the themeing frontier for the next couple of years.

WordPress = BuddyPress + WordPress MU + bbPress

So this equation has long been one of frustration.

  • If you wanted to use BuddyPress with WordPress you needed WordPress MU.
  • If you wanted to use bbPress with WordPress it needed it’s own install.
  • If you wanted to use bbPress integrated with WordPress you got a headache.
  • If you wanted to use WordPress MU with all of the features of its standalone counterpart then you had to wait.

This year will be dominated with consolidation. All of these separate projects are already in the works to become seamless. WordPress MU will simply become WordPress. BuddyPress will work in WordPress. bbPress will become a plugin that will fit right into WordPress.

This has to be one of the most exciting things for developers. Suddenly managing these different properties will reside under one roof. Nuff said.

Community

The driving force behind WordPress’ success is community. 2010 seeks to make the community more accessible. Ideas are floating around about how to revamp WordPress.org to be more community-centric, giving everyone a voice and making ideas actionable.

On top of this, the WP user base is so large now that feuds pop up about the differences in how WordPress should be run. While its not ever a good thing to quarrel, it is nice to know that people care enough about this project to put their feelings into it.

And then on the flip side, the user base is so diluted with every type of person out there that wrangling the community is harder than ever. So it may not be long before large groups begin to move away from WP to find their new, upcoming project. There’s nothing wrong with that — its how WordPress grew to be so successful. Don’t fret though, WordPress is here to stay for a long, long time.

Pro, Premium, Core Plugins

I’m not differentiating between these three categories of plugins. They all share the same idea of being well-developed and supported plugins. In other words, its taking more and more to be considered a worthwhile plugin these days. Its the nature of capitalism at work and its been great for producing some high quality projects so far. The downside, of course, is that competing with the “big boys” is becoming harder.

But, an experiment is upon us and officially supported plugins (those that WordPress will put a stamp of approval on) are nearing. The debate is back and forth over whether having “official” plugins is good or not, but it should at least prove to be a move in the right direction for those wanting a bit more stability and longevity out of their sites.

Re-Dedication to Perfection

Matt and the WordPress committers have always been keen on keeping the code clean and bug-free. Nothing can be perfect, of course, but there seems to be a renewed spirit of making sure the best quality code gets into the core. Beyond that, there’s a promise for more stringent testing phases to ensure that bugs are caught and fixed before major releases. This comes from keeping the development cycle more organized and also from a simple spirit of making 3.0 the best WordPress ever.

I’m Thankful For WordPress

There’s a lot of things I’m thankful for: my family, my dog, a freelancer’s freedom, Christ. But as it pertains to my livelihood I’m particularly thankful for WordPress.

Not only was WordPress my kick-start into standards-based web design, but it has since served as my primary CMS of choice. I don’t need to go into features that make WordPress great. They are and if you don’t believe me I can prove it to you elsewhere.

The WordPress feature-set is nice, but I’m most thankful for everything surrounding WordPress. Community: IRC, forums, thousands of WP-centered blogs with great info, WordCamps, passion.

I’d like to touch on that last note: passion. I’ve seen some passionate people around the WordPress-o-sphere for a while, but I’ve recently just really noticed it. I’ve always felt passionate about WordPress, but of course the fire grows.

Any sort of product, service, company, etc. with a following there will have turmoil at some point. WordPress licensing debates have gone on forever, but within the past year they’ve really blown up. The same sort of fiery issues come up every once in a while (i.e. commercial plugins, duplicating premium themes, wp.org progress, MU, etc.). Those on both sides of an issue dig their trenches and seemingly burrow deeper and deeper as the argument continues.

Of course fighting for your stance tooth and nail isn’t anything new. But what amazes me is that WordPress can cause it. For starters, WordPress is six years old. In part, its infancy is probably a cause of some of the issues. Nevertheless, it hasn’t be around long and already there are enough users divided amongst themselves. It’s not a good thing, but it is cool to see so many people making their cases because they care.

No one would waste their time arguing about WordPress if they didn’t care — almost no one, that is. Sure, there’s some people that argue because they just like to disagree with people. Others do so selfishly and care not what is best for WordPress but for themselves. For the most part, though, people want to see WordPress succeed (beyond what it’s incredibly achieved so far).

So we argue debate because we care.

Sometimes we just need a reminder of what we’re thankful for. Keep that in mind if you’re amongst those of us who spend time (too much?) trying to figure out where WordPress is, where it should go and how to get there.

Happy Thanksgiving.

WordPress for Project Management

This is a call to all those interested in using WordPress as a project management tool. I’m certainly not alone in desiring similar functionality that existing project management tools offer, namely Basecamp.

There’s been some attempts that are full on plugins, but they don’t quite fit the bill, and more importantly they’re out of date and mostly unsupported.

Before I tell you my plans, let’s make the case for WordPress Project Management.

Why Would You Want to Use WordPress for Project Management?

1. Because you can
This is usually a terrible reason for doing something, but WordPress is an extensible platform that’s obviously proven it’s worth so why not add to it some really great new functionality? WordPress developers have no doubt that it can be done, but it hasn’t been thoroughly tackled yet.

2. Cost
Basecamp and other PM solutions out there are reasonably priced, but we’ve been spoiled with open-source software, so we need our “free” fix. The cost does start to get steep when you’re managing lots of projects though.

3. De-fragmentation
If I could centralize all of the web-related things I do then I’d be much happier. I’d prefer that my project management and in-development sites be more closely tied together so that my clients can more easily stay in tune.

4. Control
We “WP self-hosters” love control. I’d prefer to control my brand, my data, features…you name it.

What Does Project Management Really Include?

  • User accounts
  • Multiple projects
  • To-do lists
  • Collaboration

At its core PM generally offers those. Let’s take a look at how WordPress can handle those. We’ll also introduce WordPress MU, since it has quite a bit to offer in our case.

  • User accounts –> Done.
  • Multiple projects –> Done. You can use each child blog as a project.
  • To-do lists –> I think 2.9’s introduction of custom post types could find a use here. There still needs to be some customization.
  • Collaboration –> Done. Posts and comments.

What Else Do We Need?

So if you wanted to use WP for PM today you could do it, but it’s not ideal.

I think WP should handle PM in the front-end for the most part. This way we can control the user-interface more easily, and only provide the user’s with what is necessary. This means we need a theme.

A Theme

Really you could use any theme you wanted and using posts and comments you’d have a fairly organized setup. Of course, they wouldn’t be ideal. A step in the right direction is the P2 theme. Most importantly it allows you to post directly from the front-end. Secondly, it presents posts and comments in a more digestible fashion than the traditional blog post UI.

Most people love the Basecamp interface, so we should really look to it for inspiration. In fact, it’s so nice that I decided to clone it.

I’ve created a new theme called Basechamp. Before you freak out, I know it’s a complete rip-off. I’ve intentionally just copied it while I experiment with the PM idea. It won’t be released to the public until its got its own skin. Also know that it’s a very incomplete piece of work.

So there’s a ray of hope that achieving a project manager can mostly be achieved with a simple theme.

What’s Lacking

What this theme doesn’t yet account for is the administrator. If you’re using WPMU to set this up you can assign a theme to all of the child blogs (each its own separate project). If you’re the admin though you may want to see an overview of all projects, so we’d need to add a template that called data from all projects.

What if someone other than the administrator is assigned to multiple projects, they need an overview page as well. I need to figure out how to best implement this.

All project updates need some sort of email subscription management (subscribe to new posts and comments, daily/weekly summaries, choose to notify certain users of the new post or comment).

To-list lists and milestones need an extensive calendar system.

So, My Plans?

As you can tell, I’ve got something in the works that I plan to release at some point. I’ve already got some support behind this, but I’m interested to know who else may be interested in using this and who might want to help finish it up. Also, the theme will be a child theme for Hybrid and Justin Tadlock has already shown some interest in the project.

In the meantime, we’ll call this Project Basechamp. Give your ideas for a new name when it’s launched.

What am I looking for?

  • A new design for the theme that takes inspiration from Basecamp
  • To-do list implementation
  • Calendar support for to-do lists and milestones
  • Robust email functionality
  • General help and ideas

How to get involved

Leave your comments. Also, join the forum. Serious developers will get access to the code.

Share your Basechamp feature ideas.