Automatic Plugin & Theme Updating From GitHub ā€“ Part 2

github2In Part 1, I tried to describe some of the why and a little of the how I’ve gotten to this point with GitHub Updater. In this point I’ll try to go into a bit about how the plugin works.

The basic premise and design of GitHub Updater is to be very lightweight to both the developer and the end user. For the developer, inclusion of only one or two lines of code in the plugin or theme header will allow it to get automatic updates via GitHub Updater. All the end user needs to do is install and activate (or network activate) the GitHub Updater plugin.

GitHub Updater is even smart enough to allow for plugins to be hosted on WP.org and get updates from WP.org as long as the branch header is master. If the developer wants to update from GitHub all they need to do is change the branch header to something other than master. I use this for development by designating GitHub Branch: develop on my development site. Please refer to the README for a better explanation.

When the branch is master and there are tagged releases, these tagged released are preferentially used for updates. When the branch is something other than master, tagged versions are ignored and the specified branch is used during the update.

In the plugin’s evolution I think I’m using some better OOP practices. As such, as I search though all the plugins and themes in the user’s installation I parse out those that don’t have the requisite header. When I find a plugin or theme that has the appropriate header, either GitHub Plugin URI, GitHub Theme URI, Bitbucket Plugin URI, or Bitbucket Theme URI what happens is that the URI is parsed and data from the local plugin is placed into a class object. As you’ve no doubt just noticed the GitHub Updater does also works with Bitbucket hosted code too. Unfortunately it doesn’t work completely with private Bitbucket repos, but that’s another post.

After gathering the local data, the plugin reaches out to GitHub via the GitHub API to get the remote info. At this point there is lots of transient setting and getting so the GitHub API doesn’t get hit too frequently. This is necessary because GitHub’s API only allows 60 unauthenticated requests per hour. More than 60 requests per hour yields a 403 error. Bitbucket’s API doesn’t seem to have this limitation, but the results are cached nonetheless.

Each API class, so far just GitHub and Bitbucket, is written as an extender class. Doing it this way should allow for adding additional API classes for additional git repos in a more logical fashion. Think Gitlab.

A CHANGES.md file is also parsed, if present, to add into the View Details screen. At this time parsing a standard readme.txt isn’t done, but it’s certainly something on the horizon. I’ve also created a pseudo-rating based upon the number of stars, forks and issues the repo has.

The updating is hooked into WordPress’ core methods, as is renaming of the downloaded plugin/theme update. So far so good and GitHub Updater just works in WordPress 4.0beta.

I’m sure there’s probably another post, Automatic Plugin & Theme Updating from GitHub – Part 3, coming.

WCLAX

Iā€™m attending WordCamp LAX

Can’t wait to meet loads of new WordPress peeps!

As an added bonus I’ll be bringing/escorting/dragging my daughter with me. I hope she likes it as much as her brother did.

The Events Calendar Outlook Import Fix

In The Events Calendar the ability to add an event to your calendar via an iCalendar file is now in the core plugin. This used to be a feature only in the Events Calendar PRO plugin.

Out of the box this works great for either Google Calendar or Apple’s Calendar. However, in Outlook, adding the event would create a whole new calendar instead of adding the event to the user’s default calendar. It seems that the issue is simply the addition of the X-WR-CALNAME header in the generated iCalendar file. This header is valid according to iCalendar.

Unfortunately Outlook doesn’t seem to like this and its inclusion causes the creation of an entirely new calendar and not just a new calendar event. The solution is to remove this line. When this is done an event will be added to the default Outlook calendar.

A while ago I wrote a quick function to remove this line. This solution was made much simpler by Modern Tribe’s inclusion of a nice filter hook. Lately I’ve found more people having this issue and having difficulty implementing the fix. In order to simplify the solution I’ve converted the solution to a plugin.

So go grab The Events Calendar Outlook Import Fix plugin from the WP.org repo. All you have to do is install and activate. Please bear in mind, when this plugin is active users of other calendaring apps may have problems. This is a solution for sites whose users only use Outlook.

Automatic Plugin & Theme Updating From GitHub ā€“ Part 1

githubAbout 10 months ago I decided to scratch an itch. I was running 3 or 4 different WordPress websites, including this one. I was also playing around customizing these sites by creating some one-off plugins and child themes. At the time I was doing a lot of cowboy coding on my own domains. Mostly because I didn’t know better. Developing in localhost has been an amazing boost in productivity.

I have to mention this because this is not my day job. In fact, my day job keeps me incredibly busy and usually I end up coding at night and in off hours. For those that don’t know, I’m a trauma/acute care surgeon. Currently I’m also the Chief of Staff of one of our local hospitals. It’s not like I already didn’t have enough free time.

So I was creating a number of simple plugins that I really didn’t think were either good enough or appropriate for the WP.org repository. As such, when I wanted to use them on different sites I would FTP them up after writing them and then I’d have to do it all again after updating them. I decided it was time to figure out how to hook into WordPress’ automatic updating. At the time, the most popularly used method was Joey Kudish’s WordPress GitHub Plugin Updater.

As I was looking into the code the first thing I felt myself wanting to do was to make the code into a plugin so I didn’t have to put so much extra code into the plugins to be updated. Later I found another couple of projects that did either plugin or theme updating.

Initially I was able to modify one, Codepress’ GitHub Plugin Updater, enough so that I not only had a working plugin updater, but I had managed to parse the GitHub URI of the plugin’s repo to the point that no other settings were needed inside of the plugin that’s being updated other than a single header line.

Around that time Kudish’s project wasn’t getting a lot of updates and in one issue that Gary Jones had created, I referred him to my project. Now you have to know, I had no idea at the time who Gary was. Boy do I now. Gary forked my project and the next thing I noticed were several pull requests that made the code look so much better and work so much more efficiently. Gary was incredible. He gave invaluable feedback without telling me how silly it was do things the way I was and made me think about WordPress Coding Guidelines, at least a little bit.

At this point plugin updating was fairly solid and next up for me was updating for themes. There were 2 projects that did theme updating, one from UCF’s Theme Updater, and one from Seth Carstens, part of his Whitelabel Framework, which improved upon UCF’s work. Currently theme updating is working as well as it is in a very large part due to Seth’s help.

Originally I had created 2 plugins one for updating plugins and the other for updating themes. After both were functioning, I decided to combine them into a single plugin that I call GitHub Updater.

Along the way Paul Clark provided immense help and support by showing me both why and how I should do things one way instead of another. Paul even created his own version, Git Plugin Updates.

What I’ve hoped I’ve created in GitHub Updater is a plugin that not only scratches my itch, but also makes plugin and theme development and updating simpler for many other developers within the WordPress community.

Next up, Automatic Plugin & Theme Updating from GitHub – Part 2.

Sporting a New Look

So @tommcfarlin has finally made his Mayer theme available for WordPress.org sites. I’ve been following Tom’s progress with Mayer and I had to make it my first purchased WordPress theme.

I really appreciate Tom’s (and WordPress’) core philosophy, “decisions, not options”. It allows for much more efficient code. I’m really looking forward to how Mayer evolves.

Transferring IMAP Messages

Well I’m on to my final phase in transferring from my own server to @DreamHost. Actually, transferring mail and not loosing messages jacked up my anxiety level significantly. I’ve done a lot of testing and found that imapsync works great.

After tweaking the command, I came up with the following.

perl imapsync --host1 localhost --user1 myserveruser --password1 MASKED --host2 x.x.x.x --user2 user@dreamhostdomain.com --password2 MASKED --authmech2 PLAIN --authmech1 CRAM-MD5 --usecache --delete2 --expunge2 --delete2folders --pidfilelocking

This command will use caching and delete messages/folders on the destination that don’t correspond to the origination. Doing it this way I could test as much as I wanted. It also helps to have an extra domain to test with.

So I added the domain to use DreamHost’s DNS and hosting, set the nameservers to DreamHost and waited for propagation to complete. I had a small glitch in moving the mail accounts over from one domain to another in DreamHost but @DreamHostCare help is awesome. Once that got straightened out I just ran the above command for all users and sent out the new information for their email clients.

So far it’s worked entirely as expected. This was my first test as I have another domain to transfer that has more users.

Hopefully now all I have to do is get used to DreamHost’s spam filtering.

x.x.x.x is the IP of my mail server on DreamHost.

Add Custom Header Images

After using this plugin for quite a while I decided to refactor it and submit it to the WordPress Plugin repo. I figured maybe someone else might find it useful.

What the plugin does is add all images that have been uploaded to a page titled The Headers to the header image array and allows for the selection of any of them or a randomized selection via the Customize > Header Image menu on the front end of the site.

First the plugin removes any of the default header images, if present, and then adds all the images that have been uploaded to The Headers page as the new header images. If you don’t have a page named The Headers then the plugin will not activate. The Headers may be a private page.

The idea for the plugin came from the article written by Julio Biason who was inspired by wpti.ps.

Dreamhost, WordPress and WebDAV

So next on my list was figuring out how to create a nested group of password protected directories with different users accessing various sub-directories. It’s much simpler than it sounds. The only caveat was that the main domain is running WordPress.

As such I had to tweak the .htaccess file. Fortunately the instructions were simple.

Then I created a series of nested WebDAV directories in the Dreamhost Panel and assigned user accounts as needed. Every user needing WebDAV access got it for the primary WebDAV directory and then each sub-directory had only the user accounts as needed.

Surprisingly this worked great. I may need to get an SSL certificate for the domain if I want to have the WebDAV encrypted but that should be very doable.

Transferring WordPress

So the benefit of having many domains to play with is that I get to test things out before I put them on a live site.

I was able to successfully transfer a multisite WordPress installation to @Dreamhost. Here’s what I did.

  1. Use 1-click installer to create base site @Dreamhost.
  2. Make site a multisite installation.
  3. Use SFTP to copy existing plugins/themes.
  4. Use WP Migrate DB Pro to push existing database to new database.
  5. Create mirrored subdomain in @Dreamhost panel for subdomains.
  6. Remember to check Remove WWW from the main domain.

Shout out to @Dreamhost support for pushing me in the right direction.

Next up, tackling IMAP email transfer.

Not Running a Server

I’ve been running my own server for over 5 years now. It has been a great and sometimes frustrating experience. I think I’ve finally decided to let the pros do the server administration and just focus on the other stuff. The other stuff being coding, writing, and playing with technology.

I’m looking into @Dreamhost. They seem to offer a wealth of features at a reasonable price. Honestly what gives me the most anxiety is transferring all the old IMAP email over to the new host. There’s a wiki entry about transferring email and using imapsync. I really need to investigate this.

Wish me luck. Updates to follow.

7ads6x98y