Seeking junior PHP developer

Graduate software engineer at

Work for an innovative internet startup company, breaking new ground in the areas of social networking and self-understanding.

Salary range: $50,000 to $70,000 NZD
Location: Devonport, Auckland
Start: early May

About you

You are finishing your studies in software engineering or computer science and are seeking experience. Internet technology excites you. You are thorough. And passionate about finding simple solutions for complicated problems.

You are a great programmer.

You are looking forward to gaining experience and working with excellent mentors.

What we can offer

Your ability to understand and evaluate, then abstract and re-use code will be essential to your success in this position. We will test your code and problem solving skills in the interview process.

Other useful experience and skills, in order of importance, are:

  • PHP or other another object oriented language
  • Behavior-driven or test-driven development
  • Behat, Mink, Selenium2, Gherkin, Cucumber
  • Document object model (DOM)
  • Javascript, jQuery or other event-driven programming
  • Git and GitHub
  • Contributing to open source
  • Drupal
  • Linux systems and Puppet
  • Testing frameworks, continuous integration, Jenkins

About Archetypes is a social site that allows a user to identify their archetypes by taking a short quiz. Archetypes are a universal pattern of behavior that motivates everything we do. They represent the blueprint of one's soul. Once discovered, archetypes enable users to better understand themselves and others. The online platform allows users to search original and curated content, products and people, and easily find what is relevant, meaningful and entertaining to them. Visit, take the quiz and begin a journey of self-understanding and become a more authentic you.

We are ready to grow our Auckland team and want a junior developer to grow with us. Are you ready to join us?

You will get to work closely with a dedicated mentor, learn about software development processes for large distributed teams, learn new technologies, new skills and gain valuable industry experience.

How to apply

By Tuesday 29 April, tell us why you would be a good fit for this role, ask any questions and let us know your salary expections.

If you want to send us your CV too, include a link to it. (If sending a link to your CV is a problem, then this might not be the right job for you.)

DrupalSouth returns!

Four years after the last DrupalSouth, and three fantastic Australasian Drupal conferences later, DrupalSouth returns!

DrupalSouth Wellington 14-16 February 2014 is setting up to be a great event! With an awesome venue, large capacity and amazing sponsors, things are well on track.

I co-organised the previous two DrupalSouth's in Christchurch 2008 and Wellington 2010. Josh Waihi is leading the charge for this great event. I am chair for the front end track. And I am recruiting you!

The call for submissions is open until the end of the month. That means you have just two weeks to get your session proposals in!

The theme of this event is "Unlikely Superhero". We want to showcase how Drupal changes the way that we build websites.

You do not need to have previous presentation experience (although it helps) to present at DrupalSouth. You just need to have something that you can share that others will find interesting. Perhaps;

  • A Drupal contrib project or subsystem that you know well, e.g. Twig, Views, Zen, Symfony, Features, new features in Drupal 8
  • A tool or technology that complements Drupal, e.g. Puppet, Backbone.js, jQuery, Sass, Backdrop, Redis, Memcache, Apache Solr.
  • An interesting website you worked on. Case studies are very popular, and there are some great Drupal websites in NZ and Australia to share!

Submit your session proposal now!

If you have an idea but are not sure, want to discuss, or practice, you can contact your local Drupal meetup organiser, a fellow member or me! :)

See you in less than four months!

I am seeking opportunites

I am seeking career opportunities.

My ideal client/employer would;

  • have a mission related to creating fantastic software or a service.
  • have me work primarily with;
    1. Javascript
    2. a framework, language or technology that is new to me.
  • value it's team over everything else.
  • contribute to open source.
  • be a not for profit.
  • be making a difference.
  • be in Auckland so I can sit next to my colleagues. (I usually work remotely. I will not relocate.)

That is a big wish-list, but I am happy to compromise! :)

I have worked on Drupal projects for the last 7 years. Most of that time for amazing Drupal shops; CivicActions,, PreviousNext and others (see my CV). My skill, seniority and knowledge is highly valuable to Drupal companies & projects. Indeed I can get well compensated working with Drupal. And Drupal is a fantastic piece of software—a great choice for most websites. And most of all, Drupal has an incredible community of contributers and collaborators.

But it is time for me to move on;

I am becoming more and more curious what other web frameworks, languages and tools are like. I want to learn new things and tackle problems of a different type. I love Javascript. I am drawn to building web applications instead of web sites. I want to refine my user interaction design skills.

So I am seeking career opportunities! :)

I am currently freelancing until I find the right opportunity. So please contact me about short term projects too.

Scheduled Publishing with Workbench Moderation

Originally posted at

Scheduler module allows content editors to specify times for content to be published and/or unpublished. However it is not compatible with Workbench Moderation module, which allows content to have states like “draft” and “needs review” rather than just “published” or not.

Scheduler Workbench is a new module that integrates Workbench Moderation and Scheduler modules, so that content can be configured to become published or unpublished and be assigned a new moderation state at a date and time specified by the content editor.

PreviousNext recently built the same functionality for a client project using Rules & Rules Scheduler modules. This proved rather difficult to implement; Workbench Moderation also allows content with a published revision to have a more recent current revision in a “draft” or “review” state while content editors are working on it, and Rules does not provide sufficient transparency to easily understand & debug a number of tricky edge cases:

  • If a content item is scheduled to be published but it already has a published revision, the current revision should become the published revision on the scheduled publishing date.
  • The content’s Workbench Moderation history should be clean and easy to audit; There should only be one log entry per scheduled event.
  • Should the (un)publishing-dates act on revisions or nodes? Should the date-time values be stored per revision or per node? If revisions, do the published revision's dates preside over the current revision's dates? Can content that is about to be (un)published still be easily exposed to content managers via the Views module and ordered by the date-time of the scheduled event?
  • Should scheduled dates be removed from the content at or after processing? At exactly which point in the process? How can an audit trail of executed scheduled (un)publishing be provided?
  • If both publish and unpublish scheduled events get executed on the same cron run—perhaps because an editor scheduled them very close together and/or cron has not been running for a while or is not frequent enough—does the content end up being unpublished? Workbench Moderation calls node_save() content with a published revision in an "asynchronous" drupal_register_shutdown_function()-callback, which makes this a rather difficult edge case to handle. Additionally;
  • Workbench Moderation's node-history table should always be consistent with with the node table; Only nodes that have node.status = 1 should have a row in workbench_moderation_node_history where published = 1 and vice versa. And workbench_moderation_node_history should only have one row where current = 1. And that should refer to the most recent revision.
  • Should an editor be able to scheduled already-published content to become unpublished for a specified period? Or only the opposite?
  • If content is manually (un)published before a scheduled (un)publishing, are the respective scheduled events ignored on cron?

The list goes on.

For a more recent project we found Scheduler Workbench module much easier to work with than a Rules-based implementation, since all of the functionality is clearly defined in unambiguous code, rather than abstracted through configuration.

PreviousNext contributed several patches to the module to fix some bugs, handle some of the edge cases and generally get the module more stable. All of these patches have been committed upstream already—thanks William Hurley (whurleyf1)!

Another patch for Scheduler is still in the queue and is required for Scheduler Workbench to function correctly. See #1660252 “Publishing transitions twice through draft” on for more detail.

Another bonus about Scheduler and Scheduler Workbench modules is that it does not require a cron-management module like Elyisia Cron, as you can call Scheduler module's own cron callback without invoking Drupal's full cron. This is important because calling Drupal’s full cron too frequently causes performance issues, while calling it too infrequently means scheduled (un)publishing events are often “late”.

Scheduler Workbench can also be configured in such a way that it handles content "freshness" requirements. PreviousNext has found that many Australian government organisations regularly audit their content. In some cases content should even become unpublished if staff have not been marked the content as reviewed within about one year of it being published.

PreviousNext also implemented a Rules-based solution of content freshness for our client project. The default review period is set per content type, but the exact expiry date can be overridden on an individual content item’s “review by” date field. If a content item is not manually updated or “marked as reviewed”, it can be configured to become unpublished and marked as “needs review”, or just marked as “needs review” but left published. And the default value for this option is configurable per content type.

Scheduler and Scheduler Workbench modules can be configured to implement a significant portion of such “freshness” requirements.

Drupal Downunder 2012 is 2 months away, Session proposals close Monday

Drupal Downunder 2012 is just 2 months away and session proposals close this Monday!

The second Drupal Downunder will be Australasia's biggest Drupal event ever, with Dries Buytaert returning for his second DrupalDownunder, and other keynotes from Dimitri Gaskin and Gian Wild.

And tonnes of other great content, tutorials and sessions by other Drupalistas from Australia, New Zealand and beyond.

If you have been thinking about submitting a session proposal about that really interesting project, client or code you worked on recently, or have some special skill set you want to share with the Drupal community, get your ideas into words this weekend and submit a session proposal by this Monday 14 November to have it considered for the programme.

Finally don't forget that LCA ( is the week immediately following Drupal Downunder.

A New Way to Migrate WordPress Content Into Drupal

The Donald W. Reynolds Journalism Institute (RJI) is an organization that seeks out and tests innovations in journalism to find the best solutions for use in the real world.

Their new Palantir-developed Drupal website replaces a custom PHP website and two blogs. Part of our assignment involved migrating content from RJI's WordPress blogs into Drupal.

Initially, we intended to do this using the WordPress Import module. However WordPress Import is a stand-alone module that does not integrate with CCK fields, meaning that you cannot import WordPress post categories or authors as CCK text or node-reference fields. It also has limited options for importing files attached to WordPress posts.

To solve this problem, we created WordPress XML for Feeds, a module that allows Drupal's Feeds module to parse the WordPress export file (WXR). It uses a map to create Drupal nodes (or other entities) in the same way that Feeds uses a map to create Drupal nodes from an RSS feed. This allows site developers to create an arbitrary map that tells Feeds module where and how to store the WordPress post's data in Drupal (e.g., as a CCK field, as a property on the Drupal node, or as some other entity).

Syndicate content