Sam's notebook


Pear_Exception makes it to a stable v1.0.0 after 11 years!

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

Not sure why, but earlier this morning I thought it’d be fun to revisit some ancient code of mine, in the form of the Bookkeeping plugin for WordPress. So I’ve brought it (more or less) up to date and released a new beta version.

[One comment] [Keywords: , , ] [Permanent link]

Just tried the new cafe that’s opened at the shops near the corner of Winterfold Road and Carrington Street. It’s far nicer than I was expecting! Not that a suburban shopping centre should be expected to produce boring cafes, it’s just that they rather often do. :-)

It was a nice place to sit outside, the tables are nothing unusual (the chairs weigh a ton), and they weren’t playing the radio but rather had chosen what music to inflict on people — with good results. And the coffee was terrific.

Updated: I got the name wrong earlier; it’s not got a space in it.

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

Three feeds are gone from Planet Freo. Only two of the sites are kaput though; the SFFC still has a site, but they’ve ditched the feed (not on purpose, I’d say, because they’ve still got an icon for it on their homepage).

  1. South Fremantle Football Club
  2. FreOasis
  3. Fremantle Carnevale

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

Sorry to everyone who noticed; Planet Freo‘s been offline for 48 hours. I thought I needed access to my home machine to fix it; turns out I didn’t, but anyway I waited till I was home (and powered by a dram of Ardmore) to fix it. It is now fixed.

I’ve updated the FreoWiki page that lists the feeds (if anyone’s keeping track of who’s been censured).

Anyone know of other blogs that should be on the list? Let me know!

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

Fremantle Reform has been added to Planet Freo.

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

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/ 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.)

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

I wanted to be able to browse validated works on Wikisource by category, rather than just alphabetically, so I cobbled together this:

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

I was perhaps too hasty to dismiss Drupal’s taxonomy system. It is perhaps good to make this distiction between ‘content’ nodes and ‘metdata’ nodes; why create ‘content types’ for data that isn’t content?

So I need a new rule… perhaps it’s to do with frequency of updates and inserts? So that any entity whose records are not regularly updated or created should be thought of as non-content, and use the Taxonomy constructs.

A Book content type, for instance, might have a field for Binding Type which ten years ago we set to Hardcover, Paperback, and Magazine (or whatever… those are not great examples, but for a home library perhaps representative). Now we add Ebook also, but really that’s the limit of the modifications. Under the bare-bones Drupal paradigm with no taxonomy, one would create a Binding Type content type, and create only three nodes in it. Such foolishness! Better to create a new vocabulary.

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

Drupal’s entity model is pretty confusing if one is used to the strict world of ‘proper’ RDBMSs, but it does start to make sense after a while. It’s best to just forget about all the cruft that comes with the standard installation, and work with the base functionality (and some that’s currently provided by modules but seems will be in D8 core).

Taxonomy, for instance, provides a subset of the functionality that can be built with entity references (a.k.a. foreign keys in the relational model, except there’s no integrity!).

The commenting system (which is also in core) can be constructed with basic Drupal things like content types, views, blocks, and rules.

Same goes for Book pages. Everything, really.

(At least, this is my current thesis; an attempt to reduce the number of modules I have to get my head around to under a thousand…)

Basically one needs to just know of the following:

Database term Drupal equivalent (sort of)
Table Content (or Node) Type
Row Node
Column Field
Foreign key Entity reference field
View View
Enum field type list_text field type
Boolean field type list_boolean field type

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