Development

I built this tool using WordPress. I did look into using other frameworks, such as Django and Rails, but was won over by WordPress. A large selling point for me was the enormous ecosystem of theme and plugin developers, although in this case, I didn’t use a huge amount of third-party plugins.

However, access to this vast library of added functionality did streamline specific steps of the process. Add to this the massive amount of hooks throughout both the front and backend of WordPress and what you have is an easily extensible base for your web app, with a relatively high level of security out of the box.

The first step was to create a custom post type (CPT), to represent an instruction. This is a relatively simple task with WordPress. With just a handful of lines of PHP needed to register a custom post type, there are also plugins that achieve this. However, I wanted to keep third-party plugins to a minimum to reduce bloat.

From here I had to establish a fieldset for each instruction. For this, I used ACF, while it isn’t especially complicated to do this manually using PHP, and WordPress’ built-in wp_postmeta table. ACF streamlines this process a lot and makes it easier to revise in future if need be. At this point, the Instruction post type is basically a massive form that is accessible by any logged in user.

For this, I made a custom plugin. This plugin makes use of WordPress metaboxes on the instruction edit screen. What this does is display the initial information in plain text, not inputs, allowing for secure read-only access to this information for certain users. I then styled this information to match the layout of the fundamental form, to make things easier for the admins who may at some point have to use both.

As the active postcodes of the firms are fine-tuned to avoid conflicts, hopefully, this will become the vast majority of cases. In case of either conflict or no active firm nearby, the instruction will assign to the firm which oversees the whole application. When you assign ownership to a valuation firm, they will receive a notification via email. This will also happen when a case is complete, ownership will then return to the original author, who they notify, and you can activate the gathered information.

The first thought of mine was to make a child of WordPress’ built-in Admin Table class. This class is used to display all of the list views in the backend, including posts, pages, users, etc. My thought was that it could be modified to use DIVs instead of HTML table elements, as this would be more flexible. Potentially with relevant fields grouped in ordinary parent DIVs, and this would allow me to break each listed item into two or three rows. This action would essentially double the width, increasing the amount of readable information available at a glance.

In the end, I concluded that by changing the display property of my table cells, I could achieve most of this. There is a slight drawback in that I don’t have full control over the markup I output, so I can’t group related fields in the markup (however I have done visually).

I also added a progress bar, which consists of 5 Boolean values for each instruction. Each one of these represents a significant step along the process, the first being “Firm Nominated” and the last being “Invoice Submitted”. This should be handy, as an empty progress bar will signify to the Admin that this instruction needs attention to progress (they will also receive an email notification).

Eventually, I would like to make the instructions sortable by progress, as this will be a useful view both to the pension provider agents, and the administrators of the service.

I also modified the login screen as this is essentially the homepage now, seeing as there isn’t technically a frontend. There are a few hooks on the login page I used (header and footer), this allows me to style this page without modifying any core files, instead – using a plugin. I moved the original login form into a modal, triggered by a login button. Then for a touch of visual interest, I created a carousel of sorts, which displays the valuation firm logos.

At the time of writing, there are still some features I need to implement. The most interesting of which is the ability to export KPI tracking information. The information is mainly how early or late reports are delivered based on the expected date. The results will give an integer value, i.e., 1 for a day early. You can then average the data to provide an overall score.

This will be on a site-wide and a per-firm basis, allowing the administrators to assess which firms are performing best. Also, how to identify any persistently late firms. I put quite a lot of thought into how to implement this. I toyed with the idea of a third CPT to hold only the critical information for this tracking. However, I eventually concluded the best way would be to make a special status for completed instructions; after which point they would archive and only be visible to individual users. This would then serve as the data source for the KPI tracking.

Thanks for reading, and I hope this is of interest! I am planning to do a write-up like this once a month, workload allowing.