Category Archives: wordpress

I develop free software because of CUNY and Blackboard

· 52 Replies

For two reasons, Blackboard is the key to why I develop free software.

The first reason is historical. I first got into free software development because of my work with the CUNY Academic Commons project. As spearheaded by Matt Gold, George Otte and others, the Commons is intended to create a space, using free software like WordPress and MediaWiki for members of the huge community of the City University of New York to discover each other and work together. The project is not pitched as a Blackboard alternative, for a number of reasons (primary among which is that the Commons’s Terms of Service prohibit undergraduate courses from being held on the site). Still, the Commons was conceived, at least in part, out of frustration about the near lack of collaborative tools and spaces in CUNY. And more than anything else, Blackboard (by which I mean Blackboard Learn, the proprietary learning management software that has been CUNY’s official courseware for quite a few years) is the embodiment of what can be so frustrating about academic technology at CUNY: central management, inflexibility, clunkiness, anti-openness. In this way, Blackboard begat the CUNY Academic Commons, and the CUNY Academic Commons begat Boone the developer.

There is another reason why Blackboard is integral to my free software development. It is ideological.

Short version: I love CUNY and I love public education. Blackboard is a parasite on both. Writing free software is the best way I know to disrupt the awful relationship between companies like Blackboard and vulnerable populations like CUNY undergraduates.

Here’s the longer version. I’ve been affiliated with CUNY in a number of capacities over the last decade: PhD student, adjunct lecturer, graduate fellow, full-time instructional technologist, external contractor. I’ve seen many parts of CUNY from many different points of view. Like so many others who have philandered their way through CUNY’s incestuous HR departments, my experience has rendered a decidedly love/hate attitude toward the institution. You can get a taste of the what CUNY hate looks like by glancing at something like @CUNYfail. The love runs deeper. Those fortunate enough to have “gotten around” at CUNY can attest to the richness of its varied campus cultures. In every office and every department on every campus, you’ll meet people who are innovating and striving to get their work done, in spite of a bureaucracy that sometimes feels designed to thwart.

And the students. CUNY is the City University of New York, the City University. It belongs to New York, and its history is tied up with the ideals of free education for New York’s residents. While the last few decades have seen the institution (as a whole, as well as a collection of campuses) evolve away from these ideals in various official and unofficial ways, it’s impossible to step into a CUNY classroom without getting a sense that CUNY still serves as a steward for New York’s future. CUNY is too huge and its population too varied to make general statements about the student body, but I’ll say anecdotally that, of all the universities I’ve been associated with, none even approach the level of racial, economic, and academic diversity that you find on a single campus, to say nothing of the system as a whole. CUNY is (to use a lame but apt cliché) a cross-section of New York: her first-generation Americans, her first-generation college students, her rich and her poor, her advantaged and her vulnerable. (See also Jim Groom’s I Bleed CUNY, which makes a similar point with a lot less abandon.)

Public education is a public trust, maybe the most important equalizer a state can provide for its citizens. CUNY, with the population of New York City as its public, could demonstrate the full potential of public education in a more complete and visible way than perhaps any other public university. It’s for this reason that it breaks my heart and boils my blood to see CUNY money – which is to say, student tuition and fees – poured into a piece of software like Blackboard.

In virtue of their age, undergraduates are inherently a vulnerable population, and CUNY undergraduates – reflecting as they do the full demographic spectrum of New York City itself – are doubly vulnerable. Many CUNY undergraduates go to CUNY because if they didn’t, they wouldn’t go to college at all. This imposes certain moral strictures on those responsible for managing and spending the money paid by CUNY students in tuition and fees. Wasting CUNY money is a far worse crime than wasting, say, shareholder money in a private company. Shareholders have freedom; if they don’t like your management, they vote with their feet/wallets/brokers. CUNY students, by and large, do not have the same freedom; it’s safe to say that, for most CUNY students most students, big-ticket NYU and Ivy Columbia are not reasonable alternatives. CUNY students are, in this sense, captive, which means that their hard-earned tuition money is captive as well. Thus it is a very bad thing to spend that money on things that aren’t worth it.

And Blackboard is not worth it. Vats of digital ink have been spilled expounding Blackboard’s turdiness, and this is no place to rehash all the arguments in depth. A short list, off the top of my head:

  • The software is expensive [EDIT 9-21-2011: See this post for more details on cost]
  • It’s extremely unpleasant to use.
  • It forces, and reinforces, an entirely teacher-centric pedagogical model.
  • It attempts to do the work of dozens of applications, and as a result does all of them poorly.
  • Blackboard data is stored in proprietary formats, with no easy export features built in, which creates a sort of Hotel California of educational materials
  • The very concept of a “learning management system” may itself be wrongheaded.
  • As recently reported, the software may be insecure, a fact that the company may have willingly ignored.
  • Blackboard’s business practices are monopolistic, litigious, and borgish

In short, Blackboard sucks. Blackboard supporters might claim that some, or even most, of the criticisms leveled above are false, or that they apply equally to other web software. Maybe. And I certainly don’t mean to downplay the difficulty of creating or assembling a suite of software that does well what Blackboard does poorly. But the argument against spending student money on something like Blackboard goes beyond a simple tally of weaknesses and strengths. As Jim Groom and others have argued for years, shelling out for Blackboard means sending money to a big company with no vested interest in the purposes of the institution, which in the case of CUNY is nothing less than the stewardship of New York City’s future, while the alternative is to divert money away from software licenses and into people who will actually support an environment of learning on our campuses. Frankly, even if Blackboard were a perfect piece of software, and even if its licensing and hosting fees were half of what it costs to hire full-time instructional technologists, programmers, and the like to support local instances of free software; even if these things were true, Blackboard would still be the wrong choice, because it perverts the goals of the university by putting tools and corporations before people. The fact that Blackboard is so expensive and so shitty just makes the case against it that much stronger.

As long as our IT departments are dominated by Microsoft-trained technicians and corporate-owned CIOs, perhaps the best way to advance the cause – the cause of justice in the way that student money is spent – is to create viable alternatives to Blackboard and its ilk, alternatives that are free (as in speech) and cheap (as in beer). This, more than anything else, is why I develop free software, the idea that I might play a role in creating the viable alternatives. In the end, it’s not just about Blackboard, of course. The case of Blackboard and CUNY is a particularly problematic example of a broader phenomenon, where vulnerable populations are controlled through proprietary software. Examples abound: Facebook, Apple, Google. (See also my Project Reclaim.) The case of Blackboard and its contracts with public institutions like CUNY is just one instance of these exploitative relationships, but it’s the instance that hits home the most for me, because CUNY is such a part of me, and because the exploitation is, in this case, so severe and so terrible.

On average, I spend about half of my working week doing unpaid work for the free software community. Every once in a while, I get discouraged: by unreasonable feedback, by systematic inertia, by community dramas, by my own limitations as a developer, and so on. In those moments, I think about CUNY, and I think about Blackboard, and I feel the fire burn again. For that, I say to CUNY (which I love) and Blackboard (which I hate): Thanks for making me into a free software developer.

“Posts per page” dropdown for BuddyPress single forum topic view

· 3 Replies

This morning I whipped up a little BuddyPress ditty for the CUNY Academic Commons that allows your members to select how many posts they’d like to see at a time when viewing a single forum topic. It’s not particularly beautiful (for one thing, it requires Javascript to work correctly, though it degrades gracefully by not showing up when no jQuery is available). For that reason, it’s probably not really appropriate for distribution in BuddyPress itself, at least not without some heavy cleanup. Anyway, here it is:

In your theme’s functions.php, place the following function:

[code language=”php”]
/**
* Echoes the markup for the “number of posts per page” dropdown on forum topics
*/
function cac_forums_show_per_page_dropdown() {
global $topic_template;

// Get the current number, so we can preselect the dropdown
$selected = in_array( $topic_template->pag_num, array( 5, 15, 30 ) ) ? $topic_template->pag_num : $topic_template->total_post_count;

// Inject the javascript
?>

jQuery(document).ready( function() {
jQuery(‘div#posts-per-page-wrapper’).show();
jQuery(‘select#posts-per-page’).change(function(){
var url = ‘?topic_page=1&num=’ + jQuery(this).val();
window.location = url;
});
});

Posts per page:

The GPL is for users

· 9 Replies

The General Public License (aka the GPL) is for users. This observation seems so obvious that it needn’t be stated. But for those who develop software licensed under the GPL (like WordPress and most related projects), it’s a fact that should be revisited every now and again, because it has all sorts of ramifications for the work we do.

Users versus developers

What do I mean when I say that the GPL is “about users”? Who are “users”? We might draw a parallel between software and books. Books have readers (hopefully!), and they have authors. Authors read too; proofing is a kind of reading, of course, and one might argue moreover that reading is an inextricable part of writing. Yet when we talk about a book’s “readers” we generally mean to discount its author. ‘Readers’ in this sense is a gloss for ‘just readers’, that is, those readers whose relationship to the book is limited to reading. The situation with software is more complex, but roughly the same distinction can be made between users and developers. ‘Developers’ refers broadly to those people involved in the conceptualization and implementation (and also often the use) of a piece of software, while ‘users’ refers to those who just use it.

My reading of the GPL is that it’s heavily focused on users. (References to the GPL throughout are to GPL 3.0. You can find older versions of the licence, such as version 2 that is shipped with WordPress, on GNU’s website.) Take the opening line from the second paragraph of the Preamble:

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users.

Here as elsewhere in the text of the GPL, no real distinction is made between “you” as it refers to developers and “you” as it refers to users. Closer analysis makes it pretty clear, though. Take, for example, the freedoms that are purported to be taken away by proprietary licenses: the freedom to “share and change” software. Developers – or, to be more specific, license holders, who are generally either the developers themselves or, in the case of work for hire, the people who paid for the software to be developed – generally do not restrict their own rights to share and change the software that they create. Instead, restrictions are imposed on others, the (“just”) users.

Similar reasoning applies to the core freedoms that are outlined in the Free Software Definition, a sort of unofficial sister document of the GPL, also maintained by the Free Software Foundation. The four freedoms:

  • The freedom to run the program, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

On the face of it, freedoms 1 and possibly 3 are focused on developers, in the sense of “those who are able to write code”. But, with respect to a piece of software that they did not write and whose license they do not control, coders are just regular users (in the same way that Vonnegut may have been a “reader” of Twain). All four freedoms, indeed, are user-centric. The license holder, almost by definition, doesn’t need permission to use the code (0); the developer doesn’t need to study the code to know how it works (1); owners can redistribute at will (2); owners can modify and redistribute at will (3). It’s only in the context of users – those who did not write the software – that these freedoms need protection in the form of free software licenses like the GPL.

The GPL does make a few explicit provisions for the developer/license holder:

For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

The second provision is a sort of legal convenience; the first intends to ease what may otherwise be a prohibitive consequence of the core freedoms guaranteed by the rest of the GPL. Both are important and valuable. But it seems fair to say that they are secondary to the user-focused parts of the document, at the very least because they are motivated by other parts of the document, while user freedom needs independent justification.

There’s no question that the people who bear the brunt of implementing and upholding the GPL are software developers. In that sense, the GPL is very much “for” them. But, in a broader sense, that’s a bit like saying that school is “for” the teachers because the teachers play a key role in education. Schools are for children; they provide the motivation and justification for the whole enterprise. Similarly, the GPL is for users; if everyone wrote their own software, and there were no “just users”, the GPL (or any free software licenses, or any licenses at all) would be unnecessary.

Sacrifice

If I buy a pizza, I trade ownership of money for ownership of pizza. Once I have the pie, I can do pretty much whatever I want with it. I can eat the whole thing myself, I can share with a friend or two, I can throw it on the sidewalk. I can save the pizza in hopes that prices rise so that I can make a quick buck in a resale, I can retail off the individual slices, or I can give the whole thing away. I can’t use the pizza to solve world hunger (not because I’m not allowed, but because it’s not possible); I can’t use the pizza as a deadly weapon (not because it’s impossible, but because I’m not allowed). In short, ownership bestows certain rights. Not all rights – I don’t have the right to murder with the pizza, or to do impossible things with it – but many, even most of them.

The situation is more complex with intangible goods; especially those, like software, which can be reproduced without cost or loss. Copyright law in the United States (so far as I understand it; IANAL etc), in accordance with the Berne Convention, grants rights over intellectual and creative works to the authors automatically, at the time of creation. Thus, if I write a piece of software (from scratch – set aside issues of derivative work for a moment), I am granted extensive rights over the use and reuse of that piece of software, automatically, in virtue of being the author. That includes copyright – literally, the rights related to the copying and distribution of the software. In short, the default situation, for better or for worse, is for the developer – and only the developer – to possess the rights and freedoms enumerated by the Free Software Definition. By default, nothing is protected for the users.

Free software licenses exist in order to counteract this default scenario. But keep in mind what that means: When a developer releases a work under a license like the GPL, certain freedoms and rights are granted to users, which necessarily restricts the freedoms of the developer. The GPL admits as much:

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

“Responsibilities” is a nice way of putting what is essentially the stripping of certain rights (in the same way that, once you become a parent and thus responsible for your child’s well-being, you no longer have the right to go on a week-long bender). Once the software is released under a GPL, the original author has lost the right of exclusive distribution of the original software. Subsequent developers, those who modify and redistribute the software, are similarly restricted.

It’s a trade-off. Users get certain rights (viewing source code, copying, modifying, redistributing) because the developers have given up the default right of exclusivity. Examined in itself (without reference to subsidiary benefits for the moment), the trade-off is clearly made for the benefit of the users, and involves sacrifice on behalf of the developer, sacrifice which is usually quantified in monetary terms (Bill Gates didn’t get rich by writing open source software), but could also be associated with pride in being the sole author, etc. There are, in addition to this, secondary sacrifices involved in free software development (loss of identification with the software because of modifications or forking, less guaranteed income than in a proprietary development shop, increased support requests that come from wider use of a free-as-in-beer product [though the GPL explictly says that you can charge what you want, and that no warranty is implied]). To some extent, these secondary sacrifices can be mitigated by the realities of the market, and are anyway subject to the particulars of the scenario in which you find yourself. But the core sacrifice – giving up exclusivity over distribution – cannot be separated from free software licenses.

Software licenses are political documents

Developers have all sorts of reasons for releasing software under free software licenses like the GPL. A few, off the top of my head:

  • You want to modify and redistribute existing software that is GPLed
  • You want to distribute somewhere that requires GPL-compatibility, like the wordpress.org plugin repository
  • You believe that forkability and other GPLy goodness makes for a better product
  • You want to develop for a platform, or contribute to a project, that requires GPL compatibility

I classify these reasons as prudential, in the sense that they are focused on the material benefits (money, fame, better software) that you believe will come from developing under the GPL. All of these reasons are great and important, and many of them have motivated my own work with GPL-licensed software. Taken together or even individually, it’s easy to imagine that these (and other) benefits would outweigh the sacrifice involved in giving up exclusive distribution rights over your work.

There’s another kind of justification for releasing under the GPL: you endorse, and want to advance, the political and moral ends that motived the creation of the GPL. The GPL assumes that it’s a good thing for users to have maximal freedom over their software:

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

The assumption here is that “greatest possible use to the public”, and by the extension the good of the public, is something to be actively pursued – a moral claim par excellence.

And, among free software licenses, the GPL is perhaps the most explicit about the ways in which user freedoms (and thus the greatest good of the public) should be guaranteed and propagated. The “viral” nature of the GPL constitutes a kind of normative statement about the value of user rights over developer rights, which goes beyond other free software licenses that do not share its viral nature. The difference might be summed up like this. Alice and Bob are coders, and Carol is a potential user of the software. If Alice writes a piece of software and licenses it under a free software license like those in the BSD tradition, Bob can fork the software, make a few changes, and sell it to Carol under any terms he’d like – he can compile a binary executable for distribution, without making the source code available, converting his fork into closed-source, proprietary software. If Alice licenses the software under the GPL, on the other hand, Bob can still modify and sell to Carol, but he may not change the terms of the original license – in particular, the source code must be made available for further modification and distribution.

The normative aspect of the difference is in the value that each license scheme ascribes to the rights and freedoms of various individuals involved. BSD is more permissive with respect to Bob; GPL limits his ability to license the derivitive work as he pleases. GPL is more focused on Carol, and protecting her – and other “just users” like her – at the cost of some of Bob’s freedoms. (The GPL is for users.) One might express the difference in political terms thus: the GPL is more liberal, and less libertarian, than the BSD. Users, who are on the weak end of the power spectrum when it comes to software, are protected under the GPL, in the same way that society’s underprivileged and weak are often the focus of political liberalism. On this picture, licenses, like laws more generally, are designed in part to create the restrictions necessary to protect the positive freedoms of a vulnerable population.

For developers who agree independently with the normative principles underlying the GPL, its moral benefits can outweigh the sacrifices it entails. Such a justification is the starting point for Stallman and the Free Software Foundation (see, for example, the FSF’s about page). You may, of course, foreground other aspects of free/open-source software when justifying your licensing. I’ve listed some justifications above, and entire movements have sprouted to focus on prudential, rather than moral, justifications for open source development.

But – and here’s the rub – licensing your work under the GPL constitutes an endorsement of its moral justifications, even if it’s not (from a cognitive point of view) what motivated you personally to apply the license. If you choose a free software license for prudential reasons, you are not justified in complaining when your project is forked. If you choose the GPL for prudential reasons, you can’t altogether disavow the inherently altruistic underpinnings reflected in the license’s preamble. Put another way: Among other things, software licenses are political documents, and it’s incumbent upon developers to understand them before adopting them.

It’s important for developers to think carefully about this before diving into a license. My own take is that the original motivation for free software – that user control over the software they use is fundamental to their autonomy – becomes truer every day, as more and more of our agency is mediated through software. For that reason, licenses like the GPL are ethically important, at least if your worldview depends (as mine does) on respecting the agency of other human beings.

This post was prompted by a recent post by Ipstenu. Much of my thinking on the matter is clarified and inspired by the first few chapters of Decoding Liberation: The Promise of Free and Open Source Software, a book about free software written by philosophers/computer scientists Samir Chopra and Scott Dexter. You can (and should) buy the book here.

Musings on Git and Github

· 2 Replies

About a year and a half ago, I started moving all my personal and professional software development to Git and Github. Here are a few thoughts on what it’s meant for me as a developer.

Originally, the primary impetus for the change was that, as version control software, Git is so much better than Subversion. But in the last few months, the value of Github (the site, as opposed to Git the software) has become increasingly evident and important. As developers (in the WordPress world, especially) have taken more and more to Git, and as folks in general have become more familiar with Github, the value of Github’s social model to my work has increased by a huge amount. Between private and public repositories, client work and open source projects, I collaborate with dozens more people today than I did at this time last year. Some of this collaboration is planned ahead of time, and so maybe isn’t so notable. But increasingly, it’s unexpected and unsolicited – forked repos, pull requests, bug reports and patches.

Probably many of these changes are incidental, and are unrelated to version control at all. But I like to think that the mechanisms of Git – cheap branching, sophisticated merging – and the design of Github – activity streams, easy forking – have played a role. Using Github has changed, and continues to change, my development practices, by making me think more about audience and reuse (notions that are familiar to teachers of writing), encouraging the “release early and often” mantra (since all my stuff is public anyway more or less as soon as I write it), and orienting me toward collaboration by default, rather than solo coding. All these changes are highly laudable, leading to better product, and making my work more fun.

If you are an open-source developer, working in locked-up or practically invisible repositories (or, heaven forbid, not under version control at all), do yourself a favor and get acquainted with Git and Github. The benefits are potentially transformative to the way you approach your work.

Setting up PHPUnit with MAMP

· 4 Replies

After a few hours of Googling and headdesking, I finally got PHPUnit up and running in my local environment. In the end, I had to make reference to a bunch of different resources. It was a convoluted enough process that I don’t think I can replicate step-by-step instructions, but I can at least list some of the stumbling blocks I hit along the way.

My setup: OSX (10.6.8), running PHP 5.3.2 from the MAMP package. Generally, the commands I give here will have to be run as root; use either sudo each time or enter the root prompt with sudo su.

The basic instructions for installing PHPUnit tell you to use PEAR:
[code language=”bash”]
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear channel-discover pear.symfony-project.com
pear install –alldeps phpunit/PHPUnit
[/code]
But when you’re running MAMP, ‘pear’ may point to the wrong version of PHP – the version that comes bundled with OS X, or another of the versions that comes with MAMP. Make sure that you’re referencing the proper one (source). In my case, that means:
[code language=”bash”]
/Applications/MAMP/bin/php5.3/bin/pear channel-discover pear.phpunit.de
[/code]
and so forth.

As noted here and elsewhere, PHPUnit requires at least PEAR 1.8.1, but MAMP (or at least the version I have installed) ships with an earlier release. (You’ll know that this is the case, because when you try installing PHPUnit with the commands above, you’ll get a bunch of messages about required versions.) When I tried upgrading PEAR with the internal
[code language=”bash”]
/Applications/MAMP/bin/php5/bin/pear channel-update pear.php.net
/Applications/MAMP/bin/php5/bin/pear upgrade pear
[/code]
I got a “Nothing to upgrade” message. I ended up doing a sort of manual upgrade, using step 6 of these instructions:
[code language=”bash”]
cd /Applications/MAMP/bin/php5.3
curl -O http://pear.php.net/go-pear.phar
php go-pear.phar
[/code]
and then following the on-screen instructions for configuring PEAR.

I found that, in my situation, the automatically generated PEAR configuration files pointed to the wrong version of PHP. I used the instructions in this comment to lead me in the right direction. More specifically, when I looked at the PEAR config settings
[code language=”bash”]
pear config-show
[/code]
I saw immediately that some of the paths were pointing to the wrong version of PHP (at /Applications/MAMP/bin/php/ rather than /Applications/MAMP/bin/php5.3/). I reconfigured the necessary paths like so:
[code language=”bash”]
pear config-set doc_dir /Applications/MAMP/bin/php5.3/lib/php/doc
[/code]
and so on.

This got me to the point where I could fire up PHPUnit on my version of PHP, without getting a ‘command not found’ error. However, I didn’t get very far in my testing, because I kept getting fatal errors. In my PHP error logs, I could see that lines in PHPUnit, like the following, were failing to find their targets:
[code language=”php”]
require_once ‘PHPUnit/Autoload.php’;
[/code]
This suggested that the include_path in my php.ini didn’t have the correct directory. So I opened it up (on my installation, it’s at /Applications/MAMP/conf/php5.3/php.ini). It turns out that PEAR had attempted to rewrite the include_path directive but it had pointed to the wrong path for my purposes. I appended the following path (which is where PEAR keeps the PHPUnit package files): /Applications/MAMP/bin/php5.3/lib/php/PEAR

Et voilà – it finally worked:
[code language=”bash”]
phpunit –version
# PHPUnit 3.5.15 by Sebastian Bergmann.
[/code]

They’ve got Wally covered

· 3 Replies

We came back from a mini-vacation in Wisconsin yesterday to find a package on our table addressed to Wally. Inside was this beautiful quilt:

The very cute card was inscribed, in part: “Commissioned by Paul Gibbs. Made by Andrea Rennick”. Paul and the Rennicks are a few of my friends from the WordPress and BuddyPress world, each of whom I’ve met in person exactly once. Lately there has been no shortage of reminders that online friends are the real deal; having some of that kindness directed toward me and my family brings it all home. It’s a nice reminder that our geographical distribution – Paul is in Old Blighty, and the Rennicks are in the frozen north – doesn’t change the fact that we’re real coworkers, and real friends.

As a bonus, you can check out a set of making-of photos.

Thanks, Paul, Andrea, and Ron!

Anthologize 0.6

· 1 Reply

I just tagged version 0.6-alpha of Anthologize in the wordpress.org plugin repo. This new version has a bunch of bug fixes, improvements to stability and consistency of output, and a few new feature goodies. Read more about the release here.

On a related note, Anthologize development has recently moved 100% over to our Github repo. We’d previously used Trac for ticketing and Github for code management, but now we’re doing everything on Github. If you’re a user, please feel free to open new issues. If you’re a developer, send those pull requests!

WordPress for credit: Conceptualizing and justifying a WP course

· 8 Replies

A few months ago, I was contacted by Kathryn Weinstein, a local graphic designer and member of the graphic design faculty at Queens College, about co-teaching a WordPress course, for credit toward the Graphic Design degree, in the fall of 2011. Immediately, I felt drawn to the prospect of revisiting my old haunting grounds. But more than that, I was convinced that such a class had potential to benefit students in a few important ways. So I agreed to the project, and Kathryn and I have been planning, off and on, since then.

While the first goal of this fall’s course – titled “WordPress: Beyond the Basics” – is, of course, to serve its enrolled students, Kathryn and I have agreed that we also want our experience to serve as a sort of experiment for future courses, at QC and beyond. In that vein, I’ll be writing occasionally, both here on my personal blog and on our course site, about the process of planning and executing the course. This post will focus on how we’re conceiving and justifying the class, in very broad terms.

What would a WordPress course look like?

The course objectives, in the current draft of our syllabus, look like this:

  1. to strengthen web-building skills
  2. to explore the relationship between content, design and organization
  3. to gain familiarity with standards and best practices in the industry

This suggests a multi-layered approach to the course. On one level (roughly corresponding to the second objective in our list), it’ll be what I take to be typical of a graphic design curriculum. The first and third objectives, which will involve getting our hands dirty with some real coding, call for more justification. A few thoughts:

  • As anyone knows who’s ever tried to hire someone to do web work, or land such a gig himself, the term “web designer” has a wide variety of accepted uses. Sometimes it’s used in the strict sense, where the designer delivers comps that are, in turn, implemented by more “technical” folks. Sometimes a “web designer” is a front-end specialist, doing the creative work and the implementation, often at the same time. Sometimes “web designer” means “coder of web stuff”. Most often, the “designer” is the jack-of-all-trades, knowing enough about each stage of the idea-through-implementation process to be able to make it happen. By learning something substantial about web technologies, students will make themselves fit a greater variety of these definitions. That, in turn, means more job opportunities after graduation.
  • Even if the designer never touches a CSS declaration after semester’s end, it’s unquestionably beneficial to have at least a rough understanding of how the Web’s underlying technologies work. How many web professionals have been frustrated by site mockups, created by “pure” designers, that are impractical or impossible to translate into markup? More importantly, how many hours and dollars have been wasted in this way? Much of this frustration can be avoided if the relevant parties share a common grasp on some key concepts: the CSS box model; the distinction between client- and server-side processing; progressive enhancement; etc.
  • As some of my friends in the digital humanities have argued, there is a general, humanistic argument for learning about how the web works. For one thing, the Web is the medium through which so much of our communication happens – and, by extension, the medium in which our conceptions of others and ourselves are formed. Working with some of the tools that make the Web work is a way of engaging critically with the medium, thereby arriving at a richer understanding of our relationship with it, and how it affects our relationship with the world. On a related note, writing code – whether on the Web or not – is a mode of inquiry that is (arguably) fundamentally different from more traditional academic modes, and (definitely) different enough to make it epistemologically worthwhile. (This last bit is nicely summed up, appropriately enough, by WordPress co-founder Matt Mullenweg’s pithy “scripting is the new literacy”.) Some of us would like to see these kinds of priorities spread throughout the curriculum; this class can serve as a testing ground.

On balance, I see these considerations as a pretty solid justification for the academic value of a course like the one we’re considering.

Why WordPress?

If it’s not too much of a stretch to justify a graphic design course on designing for the web – and, as you might gather from my previous musings, I don’t think it’s a stretch at all – you may still wonder why it makes sense to focus on WordPress.

There are a few reasons. First is a conviction, shared by Kathryn and me, that diving into a complex platform like WordPress will ultimately make for a more engaging and valuable experience than a more staged, “Hello World”-style introduction to web technologies. It’s true that many of our students will never have seen so much as a line of HTML, and it may be true that our job would be easier if we waded in the shallows instead of diving headfirst into WordPress’s morass of HTML, CSS, PHP, MySQL, JavaScript…. But I – a Seasoned Web Professional – didn’t learn about the web that way. I learned by jumping into a complex system, and figuring my way out.

The architecture of WordPress makes this kind of learning easy. Take WP themes. I’ve often heard friends (who were much smarter than me, by the way) complain about the fact that WP’s theming system involves the on-the-fly interpretation of raw PHP – a recipe for security and aesthetic disasters if there ever was one. But this feature/bug also makes the themes readable, and thus hackable. The fact that WP is written largely in procedural PHP means that you can follow its thread of reasoning, change a line of code, and see the changes with a simple browser refresh. No compilation; no MVC framework; no class dependencies. One might argue that these features of WP make it less robust or sophisticated, but they almost certainly lower the bar for the n00b.

Moreover, WordPress is really, really widely used. Starting with WP will give students a sense of what it’s like to develop a website in the actual world. More than that – facility with WP development is something that a budding designer can put on her resumé, and it will actually mean something to those who read it.

From an ideological point of view, I’m a fan of the fact that we’ll be able to build an entire class on totally free technologies. From the LAMP stack, to WordPress, to Firefox and Firebug, we’ll be developing with tools that are free-as-in-beer and free-as-in-speech. That’s good for students in several ways. It means that they won’t have to plop down for expensive licenses. And it means that lessons about data ownership and free software philosophy can come along for the ride.

More to come

In an upcoming post, I’ll be talking in more detail about what we plan to cover in the course. It’s still very much a work in progress – and will be right up through the beginning of the semester, as we won’t know until then about our students’ backgrounds – but I plan to use this space to workshop some ideas. Feedback welcome!

Building a baby photo site with WordPress

· 17 Replies

My wife and I just had our first baby, which is the occassion for much nachas and, by extension, picture sharing. Facebook is, for better or for worse (emphasis on the latter), the de facto place for such sharing to happen. For a number of reasons – a desire to be somewhat selective about who sees my family pictures, my Project Reclaim sensibilities, the fact that I don’t have a Facebook account and generally think that Facebook is an evil company – I don’t want to use FB for this purpose. As in the case of my Twitpic-like photoblog, I figured I could use WordPress to set something up that was nearly as seamless as Facebook, or Google+, or Flickr, or whatever.

The criteria

There were a few things I wanted out of the baby site.

  1. Easy (or zero) login for users
  2. Control over who has access
  3. Optional email notification for new content
  4. Easy, javascripty gallery browsing

When I started, I was pretty sure that I’d be able to get all of these things pretty easily, using existing WordPress plugins. I was both right and wrong about this: plugins exist for all of these purposes, but none of them were very easy to implement. As a result, I ended up building several pieces from scratch. I’ll go through each of the criteria, talk a bit more about what I was looking for, and then say something about how it was achieved. By doing this, and sharing the code (spoiler alert: https://github.com/boonebgorges/Hard-G/tree/master/wp-content), I’m hoping that I can help others with similar sensibilities to get started on their own sites.

Non-sucky registration and login

I love WordPress, and I understand the important reasoning behind the decisions that led to the design, but WP’s user registration system sucks. I didn’t want just anyone to be able to create and activate an account. I didn’t want users to have to click an activation link. I didn’t want users to have randomly generated passwords that would need changing later on. And I wanted users to have the option of logging in a non-WP way.

Several of these problems could be solved by using Facebook logins. I’m not willing to give my photos over to the horrific FB leviathan, but I’m happy to piggyback on their login APIs if it will save my family and friends a few headaches. I wanted my users to have the option of clicking a single button that would give my site the ability to provision them based on their persistent Facebook login.

I started by looking at some popular Facebook Connect plugins from the wordpress.org plugin repository. I didn’t really like them. Most were linked to the Comments section of blog posts, while I wanted to use the logins for overall site access. Most were dependent on Javascript for logins, while I wanted to handle logins on the server side. Most used an outdated version of FB’s API (or at least of the PHP API classes that FB offers). And, to be blunt, most were too much of a mess, having been retrofitted many times over, and as a result next to impossible to extend. I tried modifying one or two of the more popular FB-WP plugins to do what I wanted, but I ended up writing so much garbage spaghetti code that I decided to cut my losses and start from scratch.

So I boned up a bit on the FB API, and wrote a small plugin that I call Wally Login. Together with the registration page template from my custom theme (a child of TwentyEleven), it does a couple of key things.

Your choice

Your choice

  • Rudimentary access control · If a non-logged-in user tries to visit any page on the site (other than the registration page), he is redirected to the Register page.
  • FB login integration · If a user clicks the “Log me in using Facebook” link, they’re directed to the FB authorization page for my website (which is registered as a Facebook app). There, they’re asked to approve the app – a one-time process – and are then returned to my site. Based on the display name, email address, etc that I get from FB, I create a WP user corresponding to the FB account. On future visits, approved users who are logged into Facebook will be automatically logged into my WP site whenever they visit it (an important point, because FB cookies are persistent over browser sessions, while WP logins, by default, are not). As a result, in the best-case scenario, a user will authorize their FB account with my site one time, and will never again have to think about authorization on Wally’s page.
  • A customized WP registration process · If users opt not to go the FB route, they can create a WP account directly on the site. I wanted to avoid sending users to an unthemed wp-login.php or wp-signup.php page, so I cribbed a few lines of code from BuddyPress and made my own registration and login dialogs. Wally’s site is part of a larger WP network, but I wanted to bypass WPMS’s built-in registration stuff (which requires users to activate their accounts, and is thus generally too hard for newbies to grok). My custom registration therefore creates the user directly (with wp_insert_user()), using a password that he provides, and skips the activation email. (By bypassing account activation, I’m removing an important spam prevention tool. More on that in the next section.)
  • Customized email notifications · Because I’m not using the built-in registration process, I needed to write my own email notifications for account applications and approvals.

If you decide to use my code, keep in mind that it’s not particulary beautiful. I wrote it for my own use, which means that it will take a bit of elbow grease to get it to work on your own site. In particular, if I were writing something for more general distribution, I would not be so reliant on a theme template as I am here. But if you’re looking to create a site like mine, this code is a great place to start – especially the FB integration stuff, which has made the registration and login process about as smooth as it can get.

Access control

The final important thing that the Wally Login plugin does is to provide me (the site admin) with control over who has access to the site. There are a couple ways I could have approached this issue. One is to whitelist users ahead of time. The problem with this is that I’m bound to forget some names, get email addresses wrong, and run into other problems that stem from my unfortunate lack of omniscience. Another strategy is the invitation code. When unique to the individual, this method suffers from the same drawbacks of the whitelist; when non-unique (ie when everyone uses the same invitation code) it takes away much of the security, as the code can be passed around quite easily; either way, invitation codes are clunky, easily misplaced, and all too often mistyped.

Thanks for applying

Thanks for applying

As a result, I ended up going with a third option: an application and approval process. Here’s the idea, conceptually. Anyone who wants can create an account on my site (either through Facebook or natively; see the previous section). However, the account does not actually allow access to the site unless the account is also approved by the administrators. Thus, after the initial application, two emails are sent: one to the applicant saying “thanks for applying, please be patient”, and one to me saying “there’s a new applicant, please approve them”. Then I go to my approval interface and click the Approve button (if I want), which marks the user as approved in my database and sends them an email saying “You’re in!”

Here’s a brief description of how it works technically. All applicants have a WP account created for them. Every new account is marked, at the time of creation, with user_status = ‘2’, and I make sure that no page other than Register can be viewed by an account with user_status = ‘2’. In this way, I am turning the idea of activation around a bit – natively, WP makes the user do the activation, but in my case I do it. The admin tool I use to activate users is my Unconfirmed plugin, designed for a slightly different purpose but quite at home here. (For technical reasons, Unconfirmed needs users to have activation keys; thus Wally Login also generates some dummy keys during the user creation process so that Unconfirmed will work right.) Unconfirmed, in turn, does the work of flipping user_status to 0 upon approval.

Taken together, Wally Login and Unconfirmed (with custom WP registration, FB integration, user approval by admin, etc) has given me a comfortable level of access control, without making the process unduly difficult for my users.

Email notification for new content

One of the biggest drawbacks of creating a standalone picture site instead of using an all-purpose social network (in practice, this means Facebook) is that the standalone site is likely to be forgotten. FB collects all of your network’s activity into a single stream; it’s highly unlikely, on the other hand, that Wally’s site will become part of anyone’s daily routine, so that they stop by to check for new content. For that reason, good email notification of new content is essential to making the site work.

Dead simple email subscription

Dead simple email subscription

I first tried using the popular Subscribe2 to handle these notifications. But I ran into a bunch of problems. For one thing, I didn’t like that S2’s subscription management happened in the Dashboard – I want to keep my users on the front end. S2’s category-based subscription is too complicated for my site, where people are either going to want to subscribe to all posts or to none at all. And the widget that comes with S2, for display on the front-end of the site, is pretty much atrocious. (Sorry. The rest of the plugin is nice. But that widget sucks.) At first I tried solving these problems just by building my own widget for S2, one that would tell the user whether he was currently subscribed, and show an Unsubscribe/Subscribe button, as appropriate. But, given the structure of S2’s data (which is somewhat arcane, and in any case far too complicated for my purposes), it ended up being a lot harder than it should have been.

So – wait for it – I wrote something from scratch. It is dead simple. Two parts: (1) a widget, which does exactly what I describe in the foregoing paragraph; and (2) hooks into publish_post to send an email to all subscribed users (along with some gentle checks to make sure dupes are not sent). This plugin has no admin UI and no options, because I don’t need any of those things.

Pretty galleries

Since the main point of the site would be to look at lots of pictures, it was quite important to have an easy, pretty way to do so. By “easy” I mean, primarily, navigable by keyboard; by “pretty”, I mean, primarily, bigger than the content area of a typical blog post. Less important, but still desirable, was the admin interface: I wanted it to be easy to upload lots of pictures at once, to add captions and other metadata if necessary, and to turn it all into a gallery that would look good on the front end.

Pretty, easy

Pretty, easy

You know the drill: I tried a couple of the more popular free plugins, but all of them were annoying in one way or another, and each one was way overengineered for my meager needs. I was especially disappointed by the back-end admin for the popular gallery plugins, which I found lugubrious, unintuitive, and impossible to extend. After some consideration, I decided that I actually preferred WP’s native Add Media interface for uploading photos and adding metadata, and that I was perfectly happy with the way that WP’s gallery shortcode displayed content on the front end, at least when viewing thumbnails.

So the only thing I really needed was to implement the javascript that would allow for keyboard navigation and lightboxing of gallery photos. Thanks in part to his extremely uncreative and literal plugin naming schema, I found Viper007Bond’s jQuery Lightbox For Native Galleries plugin. It does almost exactly what I want, right out of the box.

I did make a few minor mods, though. First, the plugin is a bit greedy in the way that it filters the output of get_attachment_link(), which was either breaking things (as in the case of comment_post_redirect on attachment posts) or making it hard to display links to the attachment page instead of the raw attachment file. The former problem I solved with a filter; for the latter problem, I was a bit lazy, so I modded the plugin itself in addition to adding an explicit ‘lightbox’ class to attachment links. This combination of hacks makes it work perfectly for my purposes.

Odds and ends

A little bonus

A little bonus

With my absolute requirements met, I was able to add a few other goodies to the site. My theme is a child of Twenty Eleven, which I’m pretty much using as-is. But I’ve added a few fun bits. First, on each attachment page, I added Download links, so that users could download images of various resolutions for printing or editing. I messed with the WP Admin Bar so that users coming from Facebook wouldn’t see Log Out and some other inappropriate links. And under each thumbnail in Gallery view, I’ve added Download/Comments links, so that users could bypass the jQuery lightbox and go straight to the attachment permalink if they wanted.

It took some work, but I think I’ve ended up with a site that is nice to use and easy to maintain, without resorting to the extreme discomfort associated with Facebook. Hooray!

Unconfirmed 1.2: non-Network support; delete options

· 2 Replies

I’ve just tagged version 1.2 of Unconfirmed, my WordPress plugin that allows for easy management of unactivated registrations on your WP site.

Unconfirmed 1.2 has two new, handy features:

  • WordPress non-Network support Previous version of Unconfirmed supported only WP Multisite (Network mode). That made sense, because WP “single” does not have native support for user activation in the same way that MS does. However, BuddyPress, when run on WP “single”, apes Multisite’s activation functions, and in those cases, it makes sense to use Unconfirmed. Version 1.2 introduces support for this kind of setup.
  • A “delete” option A lot of people have asked for a “delete” button, which would allow admins to delete unactivated registrations altogether (usually used in case of spam registrations). In Unconfirmed 1.2, those wishes have been granted. The new version allows you to delete spam registrations, one at a time or in bulk.

Download Unconfirmed from the wordpress.org repo, and follow development at https://github.com/boonebgorges/unconfirmed.