New Iptanus File Upload Plugin Architecture

Version 4.0.1 of the Iptanus File Upload plugin, released in 2017, stepped the major version number from 3 to 4 — and that step marked a rebuilt architecture. The work had been under way since April 2016, and its aim was to make the plugin’s user interface answer to what people actually wanted from it.

Why it was needed

The reason was design.

How a site looks, and how easily people can use it, matters to its brand, its popularity and its traffic. That is true of any site, and on a commercial one it shows up directly in conversion and in sales.

It is one of the reasons WordPress outgrew other CMS platforms such as Joomla and Drupal: it gave programmers and designers a framework they could extend, and they built thousands of themes on it. Anyone starting a WordPress site can now get the look they want without great expense or effort.

Then there is the pace of the web itself. Every few years something new arrives — phones, then SEO — and something else goes away, as Flash did, and each shift changes what a page has to do: be responsive, carry a call to action. Interfaces move too: content went from many pages to one page with infinite scroll; graphics went from heavy gloss and gradients to something leaner, with more diagrams and fewer colours. A site now needs renewing roughly every year simply to keep pace.

A plugin that draws things on the page cannot sit that out. Its interface has to sit comfortably beside the rest of the content, so that the whole page feels like one thing rather than several. A plugin that spoils the design is a plugin nobody chooses.

How far the plugin had got

Iptanus File Upload has allowed design changes since it first shipped. Here is how far that stretched at each major version:

Major Version	Plugin Design	Customization options	Means of customization	Design change level
1	Single design strictly defined	Element classes	CSS rules put on theme’s Custom CSS area	Limited styling changes
2	Single design loosely defined (flat)	Element classes, Custom CSS area	CSS rules	Limited but easier styling changes
3	Two flat designs, normal and responsive	Element classes, Custom CSS area, responsive option, filters	CSS rules, shortcode options, filter hooks	Extended styling & limited functional changes
4	Template based unlimited designs	Element classes, Custom CSS area, responsive option, filters, template classes	CSS rules, shortcode options, filter hooks, class declarations	Full styling and functional changes

Up to version 3, only parts of the design could be changed. Anything more meant rewriting a good deal of the plugin’s code. Version 4 changed that.

The new architecture

Version 4 separates what the upload form looks like from what it does. All the HTML, JavaScript and CSS that draw the buttons, text boxes and everything else live in a single mixed PHP file: the template. Which means there can be many templates, and so many different-looking forms, with the administrator choosing which one each upload form uses.

It follows the model-view-controller (MVC) approach, which splits the code into three:

1. the model, which contains database and other kind of definitions (e.g. attribute, settings and advanced options definitions),
2. the view, which generates all the visual representation to the users
3. the controller, which receives and processes user input, modifies model and updates view.

The architecture is not purely MVC, but it does mean that changing a shortcode attribute, a setting, an advanced option, the look of one element, or the look of the whole form is a matter of editing a single file. That is what lets the plugin keep moving, quickly and safely.

Technically, each template is a singleton class holding the functions that manage the form’s elements. When the plugin needs to draw an element, or read its value, change it, focus it, hide it or activate it, it calls the template’s functions — it never touches the element directly.

The default template contains detailed inline instructions and explanations of functions and their use, so that a new and completely different template can be created. On the other hand, if the purpose is not to create an entirely new template but modify an existing one only partially (e.g. modify only one of its elements), it can be done easily by creating a child class and redeclaring only the parts that are necessary, without having to modify the original template or rewriting all the code.

What it made possible

Version 4.0.1 itself shipped with a single template, drawing the form exactly as version 3 had, for backwards compatibility. The point of the work was everything that could come afterwards — and did: the Material UI theme, introduced in 4.21.5, is a second template, and an upload form built entirely in React.

If you have questions, or you have found a bug, please contact us.

The Iptanus team