Wikisource books for binding

I have been experimenting with turning Wikisource works into LaTeX-formatted bindable PDFs. My initial idea was to produce quatro or octavo layout sheets (i.e. 8 or 16 book pages to a sheet of paper that’s printed on both sides and has the pages layed out in such a way as when the sheet is folded the pages are in the correct order) but now I’m thinking of just using a print-on-demand service (hopefully Pediapress, because they seem pretty brilliant).

Basically, my tool downloads all of a work’s pages and subpages (in the main namespace only; it doesn’t care about the method of construction of the work) and saves the HTML for these, in order, to a html/ directory. Then (here’s the crux of the thing) it uses Pandoc to create a set of matching TeX files in an adjacent latex/ directory.

So far, so obvious. But the trouble with this approach of wanting to create a separate source format for a work is that there are changes that one wants to make to the work (either formatting or structural) that can’t be made upstream on Wikisource — but we also want to be able to bring down updates at any time from Wikisource. That is to say, this is creating a fork of the work in a different format, but it’s a fork that needs to be able to be kept up to date.

My current solution to this is to save the HTML and LaTeX files in a Git repository (one per work) and have two branches: one containing the raw un-edited HTML and LaTeX, on which the download operation can be re-run at any time; and the other being based off this, being a place to make any edits required, and which can have the first merged into it whenever that’s updated. This will sometimes result in merge conflicts, but for the most part (because the upstream changes are generally small typo fixes and the like) will happen without error.

Now I just want to automate all this a little bit more, so a new project can be created (with GitHub repo and all) with a single (albeit slow!) command.

The output ends up something like The Nether World by George Gissing.pdf.

Including views in Drupal modules

Views are included in modules by implementing hook_views_api() and hook_views_default_views() and returning an array of view objects from the latter.

The easiest way to construct the view object is to create the desired view via the UI and then export it, saving each exported view into its own function in sites/all/modules/custom/modulename/modulename.views_default.inc and then returning them all in modulename_views_default_views() in the same file (named e.g. _modulename_views_view_name()). For example:

/**
 * Implements hook_views_default_views().
 */
function worksmanagement_views_default_views() {
  return array(
    'work_orders' => _worksmanagement_views_work_orders(),
    'job_reports' => _worksmanagement_views_job_reports(),
  );
}

All of which is good, and works well. (Why not use Features for this, which more or less does exactly the same thing? Not sure; probably stubbornness. That doesn’t matter for now though.) The confusion comes with updating the exported views.

When a view is created, its definition lives in the views_view and views_display database tables. Once the view has been exported and saved into the module, its definition is stored in two places! This can be seen in the Views admin screen, where (once the caches have been cleared) the view is shown as “Database overriding code” rather than “In database”. There will also no longer be an option of deleting it; rather, it can be reverted. Reverting a view will delete its metadata from the two DB tables, and it will be defined exclusively from the module’s code. This is good.

The next step is to edit the view, make some changes, and re-export it. Do not save it! There is no need to save the changes you make (as this would then stick it back into the database and you’d just have to revert it again), but rather just use the export function available from the view editing UI under the edit view name/description menu (see screenshot below). This will export the view as it stands (i.e. in its unsaved, editing state).

Screenshot of View export menu item

After exporting and overwriting the code in _modulename_views_view_name(), clearing the cache is all that’s required to make the view active and update to date with what’s in the module’s code.

Note that the view will be locked for editing; hit ‘cancel’ to unlock it, or break the lock when prompted when next editing the view.

(This is why I don’t want to use Features for this: it feels better to have everything living in the module, rather than having to copy (or ‘revert’ as Features calls it) view definitions from the module into the database.)

Wikisource now exports

Wikisource has begun, at long last, to be able to produce export formats for its books. PDF and Epub have been made available in the last week or so, the first via the WMF-wide book creator tool (which has just started supporting the <pages /> markup that is used on Wikisource to assemble transcribed books) and the second thanks to a script from Italy.