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. Here’s a quick overview: make changes in code test in local development server commit changes to git repository git add . git commit -m “Explanation of changes.” git push move updated files to external dev server git ftp push test on external dev/staging server to verify changes move to production site (on same server as dev/staging) git ftp push -s www 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. This was in the olden, pre-Github days. Now that I’m a little bit more confident in my coding abilities, and in my ability to take criticism through code rhuieviews, it’s time to start releasing more of my work into the wild. That started quietly for me a few months ago when I decided to publish the code to a WordPress plugin I had written for a project that never went beyond initial development stages. As I was working on a different project, I decided that I would publish anything I wrote that could be used elsewhere. These two plugins are on my Github profile. Today I published my first jQuery plugin called h5-lightbox. Only this time, I went beyond the borders of my little Github repository and into the official jQuery plugins website. It’s a simple little thing, but I think the power of it is what I’ve learned about the process of creating and publishing a plugin that will might be used by others, or at least be used to build something better. This time, though, it’s not in danger of disappearing by accident 🙂
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. Here’s how it ended up looking: [sourcecode language=”php”] $old_root_url = get_options( ‘siteurl’ ); $root_url = site_url(); $path_flash = "$root_url/wp-content/plugins/$pluginName/js/swfobject.js"; [/sourcecode] Hope that helps someone! Related articles The periodic table of WordPress plugins (poststat.us) WordPress Most Popular Plugins (powerinfographics.wordpress.com) WordPress 3.5 is available for upgrade (kisaso.com)
I’ve been updating my online portfolio hosted on GitHub, and find myself getting lazy. Instead of developing on my local server, then publishing changes, I’ve been making little changes and pushing them to the portfolio repository. Sometimes it’s as simple as adding a link, other times it’s adding/removing a feature, or a whole group of images at once. I get the feeling there’s a better way of committing and pushing changes in general, but before I get too entangled in one method, I thought I’d ask you who are working with Git (or any versioning system, for that matter) how you do things. Any advice is welcome, especially if you have a particular reason for how you work. Take Our Poll