Category Archives: wordpress

Introducing Participad: Realtime collaboration for WordPress

· 15 Replies

Today I’m releasing the first public beta of a new WordPress plugin: Participad. Participad integrates an Etherpad Lite install into your WordPress installation, enabling realtime collaboration on the WordPress Dashboard or the front end of your WP site. If you’d like to download Participad, learn more about its features, or play with a demo site, check out participad.org. In the rest of this post, I’ll give some of the technical background about Participad, and some explanation of why it was built.

Participad was developed as part of some work I’m doing for thatcamp.org. If you’ve even been to a THATCamp unconference, you know that the first thing that generally happens in a session is that someone starts a Google Doc for collaborative notes, and tweets the link to the #thatcamp Twitter stream. In one sense, this is great – it’s very much in the spirit of THATCamp to have shared, crowdsourced, online notes for each session. But Google Docs, for all its coolness, is not the ideal tool for the job. For one thing, Google Docs are tied to a user’s account, making it very difficult to assemble a persistent, searchable archive of all THATCamp notes. There’s also the concern of storing user-generated THATCamp content on Google, which is alternatively benificent and malevolent, depending on the swings of the market.

Etherpad provides an ideal solution to the Google Docs conundrum. It’s a free software project that can be locally hosted, giving organizations and admins full control over the software and the data within. Etherpad has recently been rewritten as Etherpad Lite, an implementation in Node.js that is far more lightweight and easy to install than the original Etherpad, and, notably, has a rich REST API for integration with external software. This is what makes Participad possible: Participad uses iframes to display the Etherpad interface inside of WordPress, and then uses the EPL API to sync content between Etherpad Lite pads and the associated WordPress posts.

Participad is shipping today with three “modules”, each of which is a separate implementation of Etherpad Lite in your WP installation:

  • Notepads are the solution to the THATCamp/Google Docs problem described above. Notepads are a WordPress custom post type that can be created and edited from the front end of the blog by any logged-in user. Participad comes with a widget and a shortcode for displaying the Create A Notepad interface. And Participad redirects the Edit link seen on the front end of WP blog posts, so that it leads to a front-end editing interface. Content is synced back to the WP database every two minutes, or whenever a user clicks away from the Edit interface. In the spirit of THATCamp, Notepads can be “linked” to WordPress posts and pages, and a Participad widget can be placed in a sidebar that will display a list of a post’s Notepads. And because Notepads are just a species of WordPress posts, you can access lists of Notepads via an archive page.
  • Frontend is the Participad module that allows you to enable front-end, Etherpad editing for *any* WordPress content type. Turn it on, and the Edit link for any post will lead to an Etherpad interface, embedded in your theme where your static content would normally appear. Participad has a permissions schema that works with your WordPress installation, ensuring that only the users with the proper rights to edit a given piece of content through WP are able to edit that content through Participad as well.
  • Dashboard enables Etherpad editing throughout the Dashboard of your WP installation. All Edit screens – posts, pages, and other posts types – will have their WP editors (the Visual and HTML tabs) swapped out with a Participad tab. Autosave works just like it does in WP, and content is synced back to the WordPress database when you click Publish or Update.

I have a feeling that these three modules will cover most of the potential uses of Etherpad in WP, but if you have an unusual need, Participad is designed to be extensible. Build your own module by extending the Participad_Module class, in your own WordPress plugin.

Full instructions on setting up Participad can be found at http://participad.org/faqs/. Please note that Participad requires a separate Etherpad Lite installation, and for the moment, that installation must be accesible on the same domain as your WP install.

If you’d like to follow development, contribute fixes or improvements, or suggest future features, please visit Participad’s development home at github.com/boonebgorges/participad.

Antholocheers

· 7 Replies
Totals

Antholocheers

I’m happy (and, frankly, a little surprised) to announce that my campaign to fund a round of Anthologize development, which ended last night, successfully met its funding goal of $2,500. Donations came from friends and strangers; individuals and organizations; and from the WordPress, ed tech, digital humanities, and other miscellaneous communities of awesomeness. Close to $1,000 (or more, depending on how you count – more on this in a moment) came in within the last 24 hours.

First off: Whoo! And thanks!

Second, here’s an exact breakdown of the funds:

  • The final tally from the Indiegogo campaign was $2,665.
  • I got an email late yesterday from the team in charge of the OpenLab project at CUNY City Tech. They pledged an extremely generous $1,000 for the Anthologize campaign. For bureaucratic reasons, their donation couldn’t come through Indiegogo, so we’ll be working out a different way to deliver the funds.
  • The Roy Rosenzweig Center for History and New Media agreed (amazingly) to match, dollar for dollar, all donations to the campaign. Their contribution comes to $3,665.

This gives us a grand total of $7,330, which translates to about 98 hours of development time. It’s worth saying again: Whoo! And thanks!

Next steps: In the upcoming week or so, I’ll be reaching out to donors to collect any information necessary for their awards: mailing addresses, links to their websites, etc. Over the course of the next few weeks, I’ll be talking to other members of the Anthologize dev team about a roadmap for using these dev resources. And I’ll be starting to work down those 98 hours around the middle of November, when my work schedule eases up a bit. That’s also when I’ll start blogging in earnest about progress on the plugin, as well as some more general thoughts about crowdfunding for this sort of project, about the viability of free software projects not owned by any specific institution, about the role of Anthologize in publishing, and other such philosophical delights. These posts will “sponsored by” the contributors who pitched in $75 or more, which means that I need to write at least 15 of them 🙂

I’m looking forward to the next stage of Anthologize. I hope you are too – you made it happen.

Anthologize campaign update, and a sneak peek

· Leave a reply

My Anthologize development fundraiser is going great so far – as of this writing, $870 has been pledged. Put that together with the generous match from CHNM, and you’ve got $1,740. This translates to over 23 hours of dev time. A huge thanks to those who have already made pledges – you’ll be hearing from me individually once the campaign is over on October 10.

Aside from some miscellaneous cleanup and compatibility issues, my first goal during the development period will be to get the plugin running better in more server environments. Our most reported bug is that Anthologize Exports time out due to memory limits. This is an especially vexing problem on inexpensive, shared hosting, which is what much of the Anthologize target audience uses for hosting their WordPress sites. I’ve started to sketch out a plan in this Github ticket for making Anthologize exports less memory-hungry.

It’s always hard to estimate these things, but I’m guessing that 23 hours will be enough to do the initial plugin cleanup, and to get most of the way toward the rewrite of the export process described above. That’s progress!

Remember, more pledges mean more development. If you want to see more fixes and enhancements to Anthologize, you’ve got until October 10 to donate.

Three talks in Vancouver

· 8 Replies

For those Bo(o)neheads who follow me to every event in VW vans, I’ll be giving three talks in Vancouver next month:

  1. BuddyPress: Beyond Facebook Clones, Oct 13, WordCamp Vancouver. I’ll highlight some uses of BP that are not straightforward social networks. (BTW, if you know of any really cool ones, please let me know in the comments!)
  2. Free Software and the University: The Story of the CUNY Academic Commons, Oct 14, BuddyCamp Vancouver. I’ll be using the story of the Commons as an excuse to rant about an allegory about the importance of free software in public schools.
  3. Getting Started with BuddyPress Plugins, Oct 14, BuddyCamp Vancouver. I’ll be giving an overview of what WordPress plugin developers need to know about getting their feet wet with BP plugins.

Help fund a round of Anthologize development

· 2 Replies

In 2010, I was on the team that built Anthologize, a WordPress plugin for turning your WP content into ebooks. (For more on the project, check out my previous posts on Anthologize.) People continue to be interested in using Anthologize. Just the other day, for example, the nice folks at Profhacker published a post on using Anthologize to build a printable syllabus. When I saw that blog post come through my Twitter stream, my first thought was “Oh boy, here comes another round of bug reports that the team doesn’t have time to address”. Somewhat in jest, I tweeted the following:

I got quite a bit more interest than I expected. In addition to a couple direct inquiries from individuals and organizations, CHNM – where Anthologize was originally prototyped – offered to match, dollar for dollar, any donations to the cause (up to a maximum of $5,000).

So now I’ve got to put my money (or your money!) where my mouth is. I’ve started an Indiegogo campaign where you can pledge any amount to support a round (or more) of development time for Anthologize. Check it out for full details: http://www.indiegogo.com/anthologize. The campaign runs through October 10, and development will start in November.

Please spread the word!

Using Git locally for a Subversion-based project (like BuddyPress)

· 9 Replies

In the past, I’ve written extensively about using Git with WordPress projects. I’ve focused primarily on Git as the primary development channel, with SVN (in this case, plugins.svn.wordpress.org) used for distribution only.

In contrast, I use Git for all my local development on the BuddyPress project. In this case, BP’s “official” history is in its SVN repo. My local Git repo is just a mirror. This setup means that you need a different kind of workflow, one that gives precedence to the Subversion repository. I’ll be using BuddyPress as an example below, but a similar workflow will work for any Subversion-based project where you want to do local development in Git.

(Side note: Mark Jaquith published a similar guide on how he uses Git to do WordPress core development. His process and mine are independently derived, but they are, of necessity, conceptually similar.)

Setup

  • Get Git.
  • Create a local directory for your BuddyPress installation. Use git-svn-clone to pull the SVN revision history into this directory. 
    $ mkdir /path/to/wordpress/wp-content/plugins/buddypress 
$ git svn clone -T trunk -t tags -b branches http://buddypress.svn.wordpress.org /path/to/wordpress/wp-content/plugins/buddypress

    Git will crawl through the entire revision history of the BuddyPress project, which will take a while.

  • I generally have two active, ongoing branches in my local BP-Git repo, one corresponding to trunk and one corresponding to the current bugfix branch. I use master (the default Git branch) for trunk, since that’ll be the default setup after the clone. You’ll need to create the bugfix branch manually. I use the ‘1.6.x’ naming convention for the 1.6 SVN branch, etc. 
    $ cd /path/to/wordpress/wp-content/plugins/buddypress
$ git checkout -b 1.6.x 1.6 # In other words, create a new branch, called 1.6.x, which tracks svn's 1.6 branch
  • If you’ll need to do development using BP’s bbPress 1.x implementation (“Group Forums”), you’ll need to manually download bbPress 1.1 into buddypress/bp-forums/bbpress/

Development

Day-to-day development goes something like this:

  • Make sure you’re on the right branch. Most day-to-day dev happens on trunk/master, but in some cases it’s necessary to work on the current bugfix branch. Once you’re on the right branch, make sure that you have no unstaged changes, and use git-svn-rebase to get the most recent changes from upstream: 
    $ git checkout 1.6.x $ git svn rebase
  • Create a new topic branch for this bugfixing session. I generally name it after the ticket number. 
    $ git checkout -b bp4453
  • Fix your bug or develop your feature. Commit small changesets as desired.
  • When you’re done with your development, you’ll be in one of the following situations.
    1. You’ve fixed the issue, and want to merge your commit history directly back into the public branch. This generally means that you fixed everything with a single changeset, or perhaps a small number of changesets that have good commit messages, etc. In that case, you can do a straight merge back to the public branch. Switch back, git-svn-rebase to make sure none of your collaborators have updated the SVN branch since you started working, and then merge. 
      $ git checkout 1.6.x $ git svn rebase 
$ git merge bp4453
    2. You’ve fixed the issue, but you want to reduce a large number of changesets to a single commit. You have a few options here. You can use git rebase -i like Mark suggests. I generally do not do this, because rebasing on publicly shared SVN branches makes me nervous. Instead, in these cases I’ll use a squashed merge, which lays all of your changes on top of the destination branch, and leaves them uncommitted.
      3. $ git checkout 1.6.x 
$ git merge --squash bp4453 
$ git commit -m "This is the actual commit message I want to show up on BP's SVN"
    3. You want to share your changes with others, in the form of a patch, before committing to SVN. You’ll need to use the git diff utility, while doing a formatting trick to make sure that it’s compatible with the standard UNIX patch utility used in the SVN world. 
      $ git diff --no-prefix 1.6.x...HEAD > ~/path/to/patches/4453.01.patch
  • Assuming you are ready to send some commits up to SVN: 
    $ git svn dcommit
  • In some cases, you may have sent a commit to the bugfix branch that needs to be applied separately to the main dev branch (trunk). There’s a couple different ways you might handle this. I usually use git-cherry-pick: 
    $ git checkout master 
$ git svn rebase 
$ git cherry-pick e1f2e3f # The hash of the Git commit on the bugfix branch 
$ git svn dcommit

Releasing

Releases follow a regular tag workflow:

$ git checkout 1.6.x 
$ git svn tag 1.6.2

We do some weird stuff with BuddyPress (related to mirroring on wordpress.org/extend), which is outside the scope of Git – sadly I have to use svn for some of it :'(

Some of this is specific to BP, but most can be applied to any project where you want to use Git on a project that lives in SVN. Now git out there and git er done! and other ‘git’ puns.

WordPress hack: turn email style quotes into blockquotes

· Leave a reply

I like to use email-style quotes when I write:

In your email, you said



 > Boone, you suck



You were totally wrong about that.

I wanted to be able to do the same thing on my blog (or in my blog comments) and have the quote rendered as an html <blockquote> element. So I wrote a little filter.

Martha Burtis on hacking a WordPress hacking workshop

· Leave a reply

Martha Burtis, instructional technologist extraordinnaire at University of Mary Washington, wrote earlier today about some WordPress development workshops she’ll be leading at Universidad del Sagrado CorazĂłn in the upcoming days. She’s responding to my prodding, and in the process, demonstrates with aplomb a few of my central points:

On the overlap between web development and education:

I got into Web design/development years ago because I loved how it allowed me to architect experiences. I got into higher education at the same time because I really do believe that education is one of our society’s highest callings. Blending my passion for education with my passion to craft experiences is basically what drives me […] I believe strongly that the fundamental nature of the code we work with speaks to the values we’re trying to embrace in the practices that our code enables. I love WordPress because it affords me possibilities. It affords me possibilities because it is open.

On how she plans to frame the technical parts of the workshop:

People are always amazed when they find out I studied English as an undergrad. I never quite understand why. Don’t they know that code is poetry? Seriously, I’m going to talk a bit about the relationship between code and poetry — a relationship that I’ve always found fascinating. I’m also going to talk about code as a tool for building experience. Finally, I’m going to talk about the way our values and politics (small “p”) inhabit the code we work with.

Martha illustrates the value that WPedu can bring to the broader free software project. People working with WordPress inside of the university approach their development (design, etc) with a focus on the user, and the benefits that the open nature of the software bring to the user experience. And people from academic backgrounds are trained to reflect critically on the way that software mediates our relationships with the world and with each other. This is a breath of fresh air in what can sometimes be an overcommercialized and results-focused community. Rock on, Martha!