I hear the battle cry of website owners every time WordPress releases an update: “The update broke my site/theme/plugins/heart!” Usually I ignore the wimperings with the knowledge that “good” developers test their stuff with the pre-release versions so there aren’t any surprises.
Well the surprise is on me, now 🙁 The WordPress 3.6 update broke my sites.
I admit, I’m guilty of one or more of these (especially the Prima Donna), but there are things that I can — and do — work on. Reading this article made me rethink some of my attitudes as a developer and a manager, but it was this one line made the whole article come together:
What’s worse, they don’t have a single ounce of Asperger’s in them, so they insist on staring at your eyes throughout the meeting.
I’ve started working with Git as part of my Web development workflow, and am just getting the hang of some of the tools. I’m still running into problems, but it’s mainly where I haven’t taken the time to read Pro Git and learn what it is I’m trying to do.
verify changes on production. smile at work accomplished
I’ve also tried working with git flow for feature and release management, but haven’t quite got the hang of it yet to make sure I’m doing it right. Once I know more about what it’s doing, I’ll write about how I’m integrating it with my own workflow.
I’ve written a few plugins for jQuery and WordPress over the past few years, but mostly for specific projects or my own personal use.
The first time I released a plugin (Hashgrid for WordPress) for others to use, I ran into the challenge of maintenance hosting: I didn’t have time to maintain it, and my host ended free hosting and I lost the files.
I recently started a new job as a full-time WordPress developer managing several websites and the myriad of custom themes, child themes, and plugins. This is a lesson learned from an issue I had with one plugin in particular.
Using Chrome on OS X, I get security warnings that a script wouldn’t load on a particular page. When I looked into it, I found it was because in wp-admin, my site url is set to http, but that page (and several others) is served from https. Since there’s a mix of protocols, good browsers will block scripts from running across SSL/non-SSL.
The plugin was using get_options('siteurl') to create the path string used to load scripts through wp_register_scripts. Switching to site_url(), which returns a string with the protocol that the page is being rendered on, lets me now safely load the scripts on any page in the site.