Tag Archives: anthologize

Recent Anthologize updates

Anthologize, you are neglected, but not forgotten!

In the past week or so, I’ve done two maintenance releases (0.7.2 and 0.7.3) for Anthologize. A few highlights:

  • Fixed some issues with the way TCPDF saves image files in a temporary cache. This should help to avoid the dreaded “TCPDF ERROR: Can’t open image file” fatal error when exporting to PDF on some server configurations.
  • Fixed some issues with the way that Anthologize’s JS and CSS files are loaded, for better compatibility with other plugins and with SSL wp-admin.
  • Fixed a bug that gave non-admins the ability to change settings on some multisite configurations.

Speaking of not forgotten, I haven’t forgotten my friends who supported my Anthologize campaign back in 2012. This post goes out to Eric A Mann, an outstanding WordPress developer and blogger. Thanks for supporting Anthologize, Eric!

Anthologize automated tests now run using WP’s unit test suite

Anthologize, I haven’t forgotten about you! I have some very cool stuff in the works, but for now, a quick update on the progress of the campaign-funded work.

Back in 2011, Patrick Murray-John added some unit tests to Anthologize, covering a number of public methods in the TeiApi class. A number of the major refactoring jobs I’m currently undertaking will require additional test coverage, but they are (unlike TeiApi) dependent on WordPress being initalized. So I’ve migrated Anthologize’s tests to use the WP test suite. I’ve used the scaffold provided by the dope and phatte wp-cli (incidentally, I hope that their scaffold becomes the de facto standard for WP plugin tests).

This change means that, in addition to requiring PHPUnit, you’ll also need to have the WP test suite installed. You can install it manually, but I recommend using wp-cli to get the job done in just a command or two. In brief:


$ wp core init-tests /path/to/wp-tests --dbname=wp_test --dbuser=root --dbpass=asd
$ mysql -u'root' -p'asd' -e 'CREATE DATABASE IF NOT EXISTS wp_test'

To run the tests,


$ cd /path/to/wp/wp-content/plugins/anthologize
$ WP_TESTS_DIR=~/path/to/wp-tests phpunit

You can define WP_TESTS_DIR in your .bashrc file for quicker use in the future.

This post is brought to you by Anthologize campaign supporter Demokratie & Dialog. D&D, a Major Sponsor of Anthologize (woo hoo!), is using WordPress and BuddyPress in amazing ways both to study the way that government policy affects youth and to get youth themselves involved in the development of said policy. I had a chance to get to know the very excellent Andreas Karsten of D&D at BuddyCamp Vancouver last year, and we have big plans to start a BuddyPress jazz band. Many thanks for your support of WP, BP, and Anthologize!

Anthologize 0.7

Anthologize 0.7 is here. Get it while the gettin’s good!

Version 0.7 includes a number of important, under-the-hood improvements. Some highlights:

  • The way Anthologize loads itself has been largely rewritten, which means that it fires up more reliably – and using fewer resources – than ever before.
  • Some validation issues with epub exportsr have been cleared up
  • In previous version of Anthologize, PDF exports sometimes failed because Anthologize could not copy inline images to the necessary temporary directory. This process has been rewritten so that our PDF library uses WordPress’s standard upload locations, avoiding permissions errors
  • A Spanish translation is now available
  • Full compatibility with PHP 5.4 and WordPress 3.5

In addition, a Credits page has been added to the Anthologize menu. This new page includes shout-outs to all those supporters of my fundraising campaign. If you donated (and opted not to remain anonymous), check out the Credits page to see your name in lights! And if I’ve made a spelling error, or linked to the wrong URL, please let me know.

This round of development was brought to you by Cyri Jones. Cyri is an educator and technologist doing amazing things with WordPress and BuddyPress in lovely British Columbia, including his ZEN Portfolios platform for student portfolios, and private social networks for a number of local school districts. I’ve had the good fortune to do some work for Cyri’s projects, and I think that the work he’s doing with these free software platforms points toward a very interesting model for putting social learning technologies in the hands of those who can use them. Cyri was also the brains (and brawn) behind the very first BuddyCamp, held last October in Vancouver. Rock on, Cyri!

Anthologize Dev: Update 1

The Anthologize fun has begun!

A few months ago, I held a successful Kickstarter campaign to support some development on Anthologize. In the past week or so, I’ve started work in earnest. This first round of development has consisted of a number of unglamorous but important cleanup tasks. A rundown of what’s been done so far:

  • Improvements to the way that TCPDF stores its cache files, to avoid permissions errors that can mess up PDF export
  • Improvements to the way tags and categories appear in HTML export mode
  • Improved compliance with WordPress coding standards
  • Rewritten plugin initialization, for better stability across various setups and decreased memory footprint
  • Localization improvements
  • Better compatibility with PHP 5.4+

This round of development was brought to you by Siobhan McKeown, an early and enthusiastic supporter of my Anthologize campaign. Siobhan is the proprietress of Words for WP, a delightful consultancy focused on writing documentation, publicity, UX, and other copy for WordPress-based businesses. She’s the best at what she does, and rumor has it that she also has a very famous musician for a cousin. Thanks, Siobhan!

Antholocheers

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

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.

Help fund a round of Anthologize development

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!

Anthologize 0.6

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!

Dude ranchin’ at THATCamp

This year I attended my third THATCamp (at CHNM, anyway – I’ve been to a few others around the country). The first time I went, in 2009, I’d just started working with Matt Gold on the CUNY Academic Commons. I didn’t know many people in the digital humanities community. I was a graduate student in philosophy, accustomed to conferences that were philosophy-ish and graduate-student-esque. THATCamp stood in stark contrast to this background, and as a result was very new and exciting. An event where academics would get together to talk about things that were actually interesting, independently motivated, and new – the very idea of it! I couldn’t help but feel intoxicated by it all.

Fast forward two years. I’m no longer a graduate student. I’m no longer a full-time employee of a university. I’m no longer a stranger to digital humanities and the DH community. And I’m no longer a n00b. Unsurprisingly, this perspective changes the way I experience THATCamp.

For one thing, the “more hack, less yak” theme which prevails at THATCamp does not have revelatory ring it once had. I build stuff for a living. All I ever do is hack. As a result, I actually look forward to the occasional yak. I recognize that the “less yak” mantra arises out of frustration about the futility of “mere” talk, and represents a railing against the tendency of academic activity to consist of little more than such talk. In this sense, I should probably be grateful that I’m no longer in a career where I feel trapped under a pile of words. And, in fact, I do feel pretty happy about it, especially after all these years. But my recent career changes do mean that I don’t get the same gee-whiz-I’m-so-excited-we’re-actually-doing-something rush out of THATCamp that many others (justifiably) do.

On a related note, I’m less excited about geekery these days than I was before I was a professional geek. (I’m being intentionally narrow in my use of the word ‘geek’ to mean ‘someone who codes’. The word isn’t particularly important; swap it out for ‘coder’ if you want.) THATCamp can be like a dude ranch. The city slickers come to the country for the weekend, ride a horse, throw a lasso, eat some beans-n-bacon, and say “Gee, isn’t the country life great?” What the dudes don’t realize is that being a rancher means doing stuff like shoveling a lot of cow shit. In the same way, coming to THATCamp and learning a bit about Greasemonkey scripts or the Google Maps API or WordPress themes can be a rush – after all, those things are all really cool. But it’s also a kind of cartoonish picture of what it’s like to write code all day long, which is really more about shoveling the cow shit of bug tickets than about whizbang jQuery effects and singing campfire tunes.

Of course, I’m under no illusion that THATCamp sessions are meant to be introductions to the Real Cowboy Life, and I’m certain that the attendees of such sessions aren’t under any such illusions either. And I should be clear that I don’t want to be a spoilsport. For the most part, I think it’s genuinely good for people to learn how to write code (where writing code should be understood as standing in for a whole bunch of related phenomena). For one thing, it’s undoubtably good for people to engage critically with the tools that mediate so much of our lives. Moreover, people like Patrick Murray-John have been making some interesting, if tentative, arguments for the ways in which the modes of thinking exemplified by coding might interesect with, and augment, the modes typified by traditional academic work. Plus, learning to code is just plain fun. So it’s great that people who wouldn’t otherwise have the chance to learn something about code have THATCamp as an outlet. I’m just no longer one of those people, I guess.

I also would probably enjoy THATCamp more if I broke outside of my own comfort zone. During this year’s event, I skipped a couple sessions to write Anthologize code with a few members of the One Week | One Tool gang. It was a blast, and a great way to spend time with some friends who are otherwise scattered throughout the country. Yet, I might have gotten more out of the event if I’d attended more sessions, especially sessions whose subjects were a bit outside of my normal area of specialization. But at an event like THATCamp Prime, which has the usual round-up of DH A-listers talking about tried-and-true topics, it becomes increasingly difficult to find those truly new conversations.

I don’t really mean these observations to be wholesale critiques of the THATCamp setup. Many of the reactions that I saw to this year’s event – blog posts, tweets, personal conversations, and the excited looks on people’s faces – suggested that the newcomers felt the same sense of giddiness that characterized my own first THATCamp experience. But I do think it’s interesting how my giddiness (or lack thereof) is so hugely shaped by changes in my own standing over the years. Maybe next year I’ll make more of a concentrated effort to carve out a spot at THATCamp for folks with my particular set of interests and strengths.

Extending Anthologize: Part 2

In my last post, I gave a brief overview of what happens when you click the Export Project button in Anthologize, with an eye toward demonstrating the role that third party plugins (written by people Just Like You!) can play in extending the software. In this post, I’ll flesh out some of those details.

Step 1: Anthologize, meet my format

Anthologize has what I like to think of as two internal APIs: the WordPress-facing API, and the theming API. The first step is to let Anthologize know that your format exists, which you’ll do by using the key function in the WP-facing API: anthologize_register_format(). (Check out how the WPAPI functions work in the source.) You should call anthologize_register_format() in a function hooked to anthologize_init, which ensures that it won’t fire before Anthologize is ready for it. Here’s a simple example:
[code language=”php”]
function register_my_anthologize_format() {
$name = ‘example_format’;
$label = ‘My Anthologize Format’;
$loader_file = dirname(__FILE__) . ‘/base.php’;

anthologize_register_format( $name, $label, $loader_file );
}
add_action( ‘anthologize_init’, ‘register_my_anthologize_format’ );
[/code]

anthologize_register_format_option() takes three arguments. The first is the name that Anthologize will use internally as a unique key for your format. The second is the name that users will see on the Export screen radio button and elsewhere in the interface. (It’s a good idea to set a textdomain for your strings so that they can be translated – eg $label = __( 'My Anthologize Format', 'my-anthologize-plugin' );.) The third argument is the absolute server path of your main translator file, the file that will be loaded at export time.

You can read a more in-depth example, embedded in a loader class, in this bare-bones plugin that I built for testing purposes. And the definitive examples, of course, can be found in the way that Anthologize registers its native export formats (yum, we love eating our own dog food!).

What does this give you? First, it makes your format available as a format option on the second screen of the export process:



Second, it gives your format a Publishing Options page. Since we haven’t registered any options yet, we get the bare minimum, the shortcode toggle that all formats get:



Third – and this is the big thing – anthologize_register_format() tells Anthologize that, if the user has selected your format on the export screens, the TEI document containing the project data will be handed off to the translator file whose path you specified when you registered the format. That’s where the format translation itself happens.

Step 2: Gimme some options

One of the big thoughts behind the Anthologize plugin architecture is to model WordPress’s design philosophy, which is to provide relatively few options in the core product but to allow for arbitrarily extended functionality by plugins. That’s the purpose behind anthologize_register_format_option(), the second pillar of Anthologize’s WP-facing API. anthologize_register_format_option() gives a framework for plugins to register any kind of option associated with their custom format, provides all the integrated markup for presenting those options to users, and passes along the user’s choices to the Anthologize TEI document used for format translation.

Format options can also be loaded at anthologize_init, though you should be careful to load them after the format itself. I’ll do that by using an add_action priority:
[code language=”php”]
function register_my_anthologize_format_options() {
$website_name = ‘website’;
$website_label = ‘Website’;
$website_type = ‘textbox’;

anthologize_register_format_option( ‘example_format’, $website_name, $website_label, $website_type );
}
add_action( ‘anthologize_init’, ‘register_my_anthologize_format_options’, 15 );
[/code]
(Note that the first argument is the unique $name of the format I intend to associate the option with.) This registers a plain textbox with the label ‘Website’:



You can also register checkboxes, if you need a Boolean:
[code language=”php”]
$option_name = ‘include_dedication’;
$option_label = ‘Include Dedication?’;
$option_type = ‘checkbox’;

anthologize_register_format_option( ‘example_format’, $option_name, $option_label, $option_type );
[/code]


Or you can register dropdowns:
[code language=”php”]
$fontface_format_name = ‘example_format’;
$fontface_option_name = ‘font-face’;
$fontface_label = ‘Font Face’;
$fontface_type = ‘dropdown’;
$fontface_values = array(
‘courier’ => ‘Courier’,
‘georgia’ => ‘Georgia’,
‘garamond’ => ‘Garamond’
);
$fontface_default = ‘georgia’;

anthologize_register_format_option( $fontface_format_name, $fontface_option_name, $fontface_label, $fontface_type, $fontface_values, $fontface_default );
[/code]
This kind of option highlights some of the other possible arguments that anthologize_register_format_option() will take: an array of possible values, and a default selected value:


All the options you provide, and in particular the options selected by the user at export time, are handed to your main translator file at the very end of the Anthologize export process.

So that’s how you get your format and its options registered on the WordPress side of things. Stay tuned for a discussion of how translators might be built.

Are you a potential plugin developer with ideas about how this API might evolve to better suit your purposes? Hop onto the dev list.