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!
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.
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:
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.
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.
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.
I needed a way in my multisite setup to have multiple environments that shared the same database, but used different domains.
… 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.