Aram Zucker-Scharff

So, David Yanofsky over at The Atlantic’s Quartz has just released the awesome tool they use to quickly generate charts within their editorial side (in other words, no code required). 

The tool is amazing, simple and easy to use. Basically everything you’d want for a finance- or numbers-focused newsroom. But I have to wonder, if you’re working in WordPress (like Quartz does), then why not integrate it into the actual WordPress workflow? 

Seems to me like it would make things a lot easier.

So, I put in a few hours and took the first step, getting the Chartbuilder tool working within WordPress.

I’m not going to call this a huge deal, because it isn’t. They did a great job of making the tool very portable and simple, it was just a matter of dropping the code into a WordPress menu page.

The biggest problem was just altering the Javascript to work within WordPress’s no-conflict rules for Javascript (aside: no matter where you’re building, using the `$` shortcut for jQuery is sort of bad form). I probably didn’t even do that as effectively as it could be done. 

All that said, it’s the first step towards building it into the editorial workflow of a WordPress website. The next step is to make the whole process accessible from the Add New/Edit Post area. Then to automatically save the items in the WordPress media area. Then to have them insert into the post as soon as you’ve finished creating them. 

After that we could build out a method to save the form states in options or post meta-data and give users the ability to insert a form and then go back and edit it. 

All that could happen. Let’s work together on it.

I’m building out a module for PressForward to create an outgoing RSS feed.

Eventually the hope is to allow users to make such feeds problematically, generating them based on packages of feeds, selected feeds, perhaps even selected items. But for now, in order to prepare for integration with the machine learning program other members of the project are working on, I’m just setting it up to output the ‘All Feed’, or the set of all items aggregated by the plugin. 

I want to get the RSS feed to use the fullest set of tags possible. The death of Google Reader means that the number of sites that decide to support a tag that it ignored (or to better support a tag it underused) will drive further support and use of that tag. That means that not only the fullest possible set should be incorporated, but also I want to use them as accurately as possible. 

One of the interesting things about the RSS spec is that it supplies a number of methods for automated taxonomic organization of channels and associative packaging. The blogChannel tags all in the RSS2.0 example in the spec could be used to auto-create subscription packages, or to suggest packaging intelligently. 

It could be the same with the category tag for the channel, if only it was a little bit clearer. Apparently, current spec use prescribes using the category tag with the domain attribute identifying a system/site that lists feeds and the value being the number under which the feed is listed. 

The sample feed lists Syndic8 as the domain and gives the feed’s unique ID on that site. But this is clearly not helpful for auto-generation (as a feed must be registered first, created second). It also misses an opportunity for greater taxonomy info in the feeds. Also, limiting the the attributes to domain quashes the possibilities to leverage an API to help machines understand the relationships between feeds and between their topics and other potential topics. 

Let’s take Freebase as an example. Here’s a common and well-updated set of related topics and taxonomies. It’s the perfect thing for determining a feed’s taxonomic terms and even forms those terms in the term/subterm forward-slash format prescribed in the RSS spec. 

In the channel tags here, I use category descriptions in a way pretty similar to the spec. There’s a few modifications.

1. I describe the category namespace using the Freebase notable type for my category. This is pretty much how W3 talks about using namespaces in XML. This puts the category item relative to the its parent type in the Freebase taxonomy. 
2. I describe all domains using the taxonomy system I’m basing them on, this is pretty much the method described in the RSS2.0 spec, as far as I can tell, but I haven’t seen anyone using external sites for taxonomy categories as opposed to listings. 
3. I use a title attribute to describe how these items could be used to form a Freebase MQL query.

The idea for the basis of this format is that a machine could read the channel tags, recognize the domain as a query-ready item and then take the items within, using the title attribute, to form a query via the Freebase API. 

Seems like a good idea to me, though I’m far more familiar with reading XML than writing it. What do you think?

EDIT: Made some changes, here they are.

Etherpad Lite AMI – alpha setup for folks interested in Participad:

Working on setting up an AMI for people to run Etherpad Lite. This one is built using the BitNami node.js install. 

Right now, this is the most basic possible install. All that’s been done is everything has been installed and the correct ports open. You still have to start it from the command line and no configuration or security options have been enabled. However, I figure it is a good start. 

If you pop this up and have a good configuration set up, pass it along by sharing your AMI as well. 

Once running, the Etherpad Lite install is available from yourAMIurl:9001/.

This set up will one day be a lot easier to use and is currently still quite technical, but is, at least, less technical to set up than before and is a great alternative for those who want to run Participad, but don’t have the command line access needed to set up Etherpad Lite on a shared server. 

Stand by for more updates on this AMI, with better configuration.

So, earlier today I discovered that there is not an easy way to allow users to control user access to various parts of the back end. As far as I can tell, the functions just don’t exist in the core and the two parts WordPress cares about.

The problem is that WordPress controls access to its various components (and to any developer-added components) using capabilities. The capability system is pretty cool, but in order to make it as customizable as possible, they are not tied to specific user roles. 

This sounds like a good idea, until you want to create a way for a site’s administrators to give specific user roles the ability to access (or not access) parts of a site or plugin. 

Your average user has no interest in checking the user/capability chart every time they want to switch a user’s access. It would be ridiculous to ask them to do so. But just setting up an option for administrators to select user levels is useless to me as a developer, because all the actual functionality resides in setting capabilities matched to things like menus. 

So, I need to be able to do a few things in order to make the two ends meet here. 

1. I need to be able to find out what the user level is based on the capability. 
2. I need to be able to identify a capability that ‘defines’ a user role, that  being one that a user role can do, but that no lower user roles can do. 

So, to do all that, I set up three functions.

The first allows you to get just a list of capabilities, with each capability having an array of the user roles that can use it. As an added bonus, it will also allow you to get just a specific capability and its array. 

The second allows you to get a role by capability. There are two approaches here, you can get the lowest role or the highest role for any capability. I set the function to be able to do both (plugins and themes can create capabilities that do not propagate up, I think), but by default, it will get the lowest possible user role for the capability parameter. 

The third allows you to find that ‘defining’ capability for a user role. By sending the role slug, it will walk through the list until it finds the first capability where the lowest level role is the parameter role. You can then use that capability to set the user level throughout your plugin/theme and then use it to build a set of setting checkboxes or a select where the roles are displayed, but the values are the defining capabilities. 

As far as I could tell, WordPress doesn’t have anything set up to do this yet. So here’s the code.