Aram Zucker-Scharff

I’m releasing a new WordPress plugin today that allows you to use shortcodes to embed comments and comment threads into the body of stories. It’s called Response Stack. The goal is to build stories out of comments and help both the original story and the discussion around it live on. You can see the first […]

PressForward – 2.4.0 release. :

PressForward is a WordPress plugin built to process feeds as a feed reader, allow groups to share and discuss the items that come in and then post about them as an integrated editorial process. Currently in Beta.

This patch upgrades the PressForward system with an eye towards prepping it to run on more server configurations and to resolve some of the major bugs for a wider release.

A few long standing enhancement requests have been incorporated into this release for user needs outside of the current testing circle.

It also brings PF into compatibility with WP3.8.

Finally, this patch switches a few functions (most notably post-deletion, and the creation and transition of post meta through the PF process) to easier to extend functions with an eye towards maintaining as high a degree of backwards compatibility as possible for anticipated major changes in how the tasks involved in those features are accomplished. By calling these methods from discrete functions, we’ll be able to change the code internal to those functions while leaving the larger processes (hopefully) intact.

Our next anticipated full release will be 3.0, so named as we plan to bring PF to a wider testing group.

This morning I’m releasing the latest major upgrade for the PressForward plugin for WordPress.

For those of you not already familiar with this fantastic project, it endeavors to be an editorially-focused replacement for Google Reader that resides and follows through the whole of the aggregation process within WordPress. 

This release is almost entirely dealing with back-end issues (though there were some serious cosmetic problems with the new 3.8 dashboard that had to be fixed). 

Mainly, there were two goals in this release:

1. Get everything essential to functionality working.

2. Insure that future releases from this point onward wouldn’t fall to significant backwards compatibility issues. 

This is really the first time on a project that ‘2’ meant more than paying attention to WordPress’s functions and templates and hopefully I did a decent job thinking it out.

The biggest part of ‘1’ that ended up being addressed was dealing with other server configurations. As I’ve been learning more about server set-ups, packages, puppets and Vagrant, it has allowed me to build a variety of servers with functional but differing set ups. As I used these to test the plugin, I discovered all sorts of problems that we hadn’t encountered simply because of homogeneity in server configurations by myself and our primary testers. 

Some of these problems were relatively minor (folder structures for example). Some of them were major (providing cURL as a fallback for servers that disallow fget). I think I’ve covered a reasonable majority of configurations and testing now, but I won’t know for sure until the next release, which will target a wider group of users for testing.

On an entirely different note: 

This release I’ve had to start dealing with how little I really understood at the initiation of the project. For the first time in our release history, I think the majority of fixes are a reflection of elements of the code I wrote in Month One being unable to scale to what we want to do with the project. I suspect that the near future for PF will include about a month fixing stuff like this.

My growth as a developer has been pretty significant over the life of this project because of it and everything else I’ve been working on. I’d like to be honest about this, especially because the prospect of a wider release means exposing some of my badly written code to a developer audience outside of the group at GMU’s Center for History and New Media. It’s pretty clear that the code I wrote when I started is nowhere near the quality of the code I write now.

All this is especially worth noting because about a year ago, I pushed PressForward 1.7 to GitHub, the first truly functional version of the project and the first to bring an immensely useful Object Oriented Methodology, with the significant work of Boone Gorges. 

Code to escape WordPress strings for Google Analytics. :

A Quick Template Tag to create Google Analytics Event Tracking on links. Built on behalf of CFO Publishing. 

I don’t really see anyone doing this in a way that guarantees completely safe strings for event tracking or custom variables. I think this way does, especially for strings with quote marks in them, which could be nasty. Thoughts?

One of WordPress’s worst weaknesses is it’s lack of non-taxonomic relationships between posts. The plugin Posts 2 Posts tries to resolve it, but it doesn’t have a lot of flexibility nor is it easy to use. (Not to mention, creating a whole table to deal with the problem is a bit heavy handed.)

This is especially annoying when dealing in testing or staging environments. If you don’t want to make relative links or if your local environment (like mine) has trouble with anything other than query strings you’re going to have a bad time.

Internal links inside of posts are too easy to break and too difficult to fix and there isn’t a decent native way to address it, as far as I can see. 

So, I’m working on a solution.