Getting your head around the Build Script and adapting it for WordPress can take a bit of time, but there's more! Trying to figure out the best way to publish everything can be a bit of a head-scratcher.
I was pretty upset that publishing the Build Script broke my previous workflow using Espresso's built-in FTP, and eventually had to resort to FileZilla, a self-contained FTP program, to get things working smoothly. But once you tweak it a bit, publishing your Build-Scripted WordPress theme becomes a snip!
Filezilla is a free FTP program available on Mac and Windows, you can download it here.
Here are the filter configurations I talk about in the video:
Hey on a previous note about the modernizer and your theme. I believe you use body class on your wordpress site which doesn’t allow for the modernizer to work if I’m right.
wait my bad there is no html class=“no-js”
Yeah I use Modernizr quite a bit, excellent stuff.
Hey it’s NotsoWiseWoo again. lol is there something you need to do to get modernizr to work? I’m finding out that the no-js is not getting replaced?
ahh ha lol looking at page-source not actual fire-bug which shows the jquery replacements
Thanks for the post Jay. I have a few issues with it though that I hope you can address.
1. With this method – how do you test the published files? If you cannot see what you are publishing, why the hell you would you want to push it live?
2. FTP is archaic. Do you have thoughts or method on using an rsync or deploying with GIT? Perhaps it is somehow possible to simlink the WP index to the publish folder?
Thanks in advance,
Thomas
Hi Thomas,
To be honest I am new to GIT and haven’t worked with it. As I understand GIT is used for working on collaborative (mostly open sourced) projects such as HTML5 Boilerplate, whereas FTP is used for simply publishing a project to a server. If you think there’s an easier way to publish via GIT, please share, I would be genuinely interested to know.
As far as testing is concerned, personally I have each of my client’s sites on one of my subdomains for frequent testing, as sometimes the compression process can mess things up. I generally have 3 copies of a website, running one locally uncompressed, one compressed via the Build Script on a sub domain, and then a final ‘Live’ copy. Even if I wasn’t working with the Build Script, I would still work this way so that I could test a published site on Internet Explorer without disrupting the ‘Live’ site. Again, if you can figure out a better way please let me know so we can share it with any other visitors.
Thanks for posting
Hi Jay, thanx for the post. Maybe I am wrong but:
Wouldn’t you always want to ftp your header.php and footer.php in order to update the references of the new css and js files after you run the build script?
Thanx,
Thanos
Hey Thanos,
I haven’t used the Build Script for months now (I just use W3 Total Cache instead), but I think you are right yes, you should always ftp the header and footer because of the references.
While rsync, git or svn is ideal for pushing versioned changes to a server (and git and svn are also keen for collaborative code editing as well), sometimes the server technology is a giant question mark when designing a website on Wordpress or any other app framework.
Some times I will have a client with an existing hosting solution who needs a Wordpress theme implemented and designed, while others don’t have any hosting solution or a propietary one like Business Catalyst.
In either case, unless it’s an SVN or a good shared web host, I will usually not have command line/shell access on the final production server. Since we don’t have shell access I can’t fully rely on GIT or SVN or even rsync. FTP is archaic but it is universally supported. I can’t justify a client spending on a VPS if they will have limited resource usage just so I can use SVN or GIT to control my changes.
You could give Git-Ftp a try: https://github.com/resmo/git-ftp/
It can be configured so that it deploys the publish folder.