The company approached Upbeat with a project they had in mind to build a repair plan registration system which would allow their retail partners to create and manage both customer accounts and the repair plans that they’d bought. This system would replace an existing one provided by a partner organisation.
The first phase of the project was to build a base web application that could be developed in future phases.
The base requirements included the ability to create and manage retail agent accounts, which in turn had the ability to create customer accounts and repair plans which could be assigned to the relevant customers. As a part of this, the retail agents needed to be able to generate PDF plan certificates to print off and/or email to customer, or to themselves.
The first challenge was to determine what to build the application in. Upbeat is primarily a Drupal agency and this gave us the option of using either Drupal 7 or Drupal 8, but because this was to be a data management system with no need for content management facilities, we also considered building the web application using PHP frameworks, such as Symfony and Laravel.
Although it would have been quite easy to just build the system using Drupal 7, leveraging the wide range of existing available contributed modules and just have done with it, we didn’t.
While in hindsight this may have allowed us to avoid some, but not all, of the challenges that came our way (more on these later), it was felt that, with no need for content management facilities, Drupal 7 didn't necessarily feel like a good fit.
In fact, the early preference was to use a framework like Laravel, as that would allow us to build up something reasonably quickly and with a minimum of fuss. However, in the end we went with Drupal 8.
Why?
Well, while Drupal 8 essentially brings with it all the same features that weren’t really required for the project, there were a couple of compelling reasons to choose Drupal 8 over the others.
The first is simply that Drupal 8 is the latest version available and represents a complete re-architecting of Drupal. At the time of this project we were already using Drupal 8 in a couple of other ongoing projects. The main one being the new version of Upbeat’s own website, but we hadn’t yet got our Drupal 8 wings, nor pushed to see what we could do with it.
Secondly, there were time and budgetary constraints on the first phase of the project that meant we needed to identify areas where we could make savings on the effort required, while still providing a strong end result.
None of this is to talk down either Symfony and Laravel, both excellent and viable technologies to use. It really was a close call.
In the end, Drupal 8 was chosen because it provided a strong and familiar base, it’s user management features in particular, which allowed us to concentrate on meeting the client’s requirements without having to go build something from scratch. It also allowed us to see where and how we could push Drupal 8 in the web application arena, rather than taking what might be considered a more traditional website approach.
The system is basically built around the in-built user management features of Drupal 8, along with Entity API for providing custom entities (the plans sold to customers, plus the appliances and repair plan terms), the Entity Print module for PDF generation and some custom magic around PDF generation and sending emails.
Most of the challenges we faced came from generating and emailing the PDFs.
By default the Entity Print module generates PDFs on the fly, as required. However, this didn't really fit the need for the system to be able to email a plan PDF to a customer, particularly when taking into account that the scaling was off when we tried to do this for multiple customers at the same time.
To get around this a custom plugin was built based upon the DomPDF plugin provided by the module. We still used DomPDF to generate the PDF, but instead of providing the file stream to the browser for download, we saved the PDF to a file stored in the private file system provided by Drupal that was linked to the plan entity for the customer. This allowed for easy retrieval when sending an email to single and multiple customers.
Emailing the generated PDF plan proved a little more tricky. Once we had solved the problem around PDF generation, while also retrieving a saved copy to reduce overhead, we faced a couple of challenges.
Sending to a single customer was relatively straight-forward, and was achieved through a custom module to put the email together combined with the Mime Mail module, which allowed us to add the PDF as an attachment.
Sending to multiple customers, i.e. a separate email for each customer with that customers plan attached, was pushed back to a later phase to meet the time and budget constraints on the project.
Once you consider that a customer may potentially have more than one plan, it’s not just a case of picking a number of customers and hitting a send button. Unless you purposely limit yourself to only sending the most recent plan, you have to take into account how, and if, you choose which plan is emailed to each customer.
Throw into the mix that at the time we were working on the project the Views Bulk Operations and Rules modules were not yet stable enough for production use and it became clear that the need to create more custom code was going to be much more likely.
In the end, it wasn't felt that this was achievable within the remaining time and budget so, this functionality was added to a backlog to be considered for future development phases.
In the end Drupal 8 suited this project, despite some of the challenges that were faced. Even though those challenges were around specific requirements for the project, we were able to find workarounds for them using the functionality provided by Drupal.
Drupal 8 is relatively new, so it’s to be expected that not all its modules are stable, particularly with the move to object oriented code, and the use of Symfony components making Drupal 8 a very different beast from Drupal 7.
That said, we have ended up with good base web application that can only go from strength to strength over future development phases.
