We’re HIRING TWO WEB DESIGNER/DEVELOPER positions

Standard

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

Standard

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

Standard

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

Standard

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

Standard

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.