Sam's notebook

Monday MediaWiki December 4th, 2017, 6AM

Miscellaneous

Monday morning, hot and humid, and the rain’s been falling all night (nearly 5 mm!). It’s one of those lovely days when you can look out to the ocean and stand on the limestone and feel this place.

I’m reading through the position statements that have been accepted for the Wikimedia Developer Summit in January. It’s great to read other people’s ideas in this form. I think there’s not really enough of that, in MediaWiki development: it’s hard to get an idea of other people’s ‘big picture’ thoughts of what the future should hold.

[No comments] [Permanent link]

PhpFlickr 4.1.0 November 27th, 2017, 7PM

Programming

I’ve just tagged version 4.1.0 of my new fork of the PhpFlickr package. It introduces oauth support, and hopefully improves the documentation of the user authentication process. This release deprecates some old behaviour, but I hope it doesn’t break any. Bug reports are welcome!

There are some parts that are still not converted to the new request flow, but I’ll get to them next.

[No comments] [Keywords: , , , ] [Permanent link]

CFB Folder 1 done November 26th, 2017, 9AM

Open content

The first folder of the C.F. Barker Archives’ material is done: finished scanning and initial entry into ArchivesWiki. This is my attempt to use MediaWiki as a digital archive platform for physical records (and digitally-created ones, although they don’t feature as much in the physical folders). It’s reasonably satisfactory so far, although there’s lots that’s a bit frustrating. I’m attempting to document what I’m doing (in a Wikibook), and there’s more to figure out.

There are a few key parts to it; two stand out as a bit weird. Firstly, the structure of access control is that completely separate wikis are created for each group of access required. This can make it tricky linking things together, but makes for much clearer separation of privacy, and almost removes the possibility of things being inadvertently made public when they shouldn’t be. The second is that the File namespace is not used at all for file descriptions. Files are considered more like ‘attachments’ and their metadata is contained on main-namespace pages, where the files are displayed. This means that files are not considered to be archival items (except of course when they are; i.e. digitally-created ones!), but just representations of them, and for example multiple file types or differently cropped photos can all appear on a single item’s record. The basic idea is to have a single page that encapsulates the entire item (it doesn’t matter if the item is just a single photograph, and the system also works when the ‘item’ is an aggregate item of, for example, a whole box of photos being accessioned into ArchivesWiki).

[No comments] [Keywords: , , , , ] [Permanent link]

Tabulate updated to not require REST API plugin November 25th, 2017, 9AM

Programming

I’ve removed Tabulate’s dependency on the REST API plugin, because that’s now been moved in to core WordPress. (Actually, that happened rather a while ago, but I’m slack and haven’t been paying enough attention to Tabulate this year; other things going on!)

I hope to get back to adding file-field support to Tabulate sometime soon. That’d be a useful addition for me. Also, the whole situation with Reports needs sorting out: better documentation, easier to use, support for embedding in posts and as sidebar wigets, that sort of thing.

[No comments] [Keywords: , , , , , ] [Permanent link]