Due to the NDA with the client, the case study explains the problems solved by DevriX and our process breaking the business requirements into technical components and software architecture without sharing brand names and URLs.
Our client had a theme shop providing niche-specific WordPress themes. Their last three themes were successful and gained popularity, but customers complained that they couldn’t switch between themes. This locked people with a specific design prohibiting them from reusing essential functionality from other themes owned by the company.
Our Business Process
Our team leader was in charge of outlining the business requirements together with the business owner and breaking them into specific components as a part of a framework.
We have built several theme framework before for different vendors and had a process in mind that was tested, and proven with time – as new themes are being created, and updated over time.
A spreadsheet was used to establish the common components used by all themes, and a mindmap defined the requirements for the main components of the framework and their specific features. After the project proposal was accepted, we translated all of the feature requests from the mindmap and our proposal to Asana and delegated the requirements to the engineers.
Our first proposal was building a plugin that is to be shipped together with the theme. After reviewing a large number of support requests and discussing a possible change with some customers, it turned out that the technical understanding of most customers is limited and they often struggle with basic changes, which resulted in a standard framework environment as a library within the theme.
The framework was entirely OOP-based and was packed within a single folder within the theme body. A JSON configuration file was included that allowed enabling and disabling features per theme if needed over time – in case we enhance the framework with features that aren’t supported in old themes or a new lightweight theme that doesn’t support an existing feature.
None of the additional components was loaded unless it was specifically enabled from the main configuration file.
Abstracted were form and component builders which were reused in widget forms, theme options and provided a model layer for easily fetching data within custom templates. Adding new custom components was also fairly easy which allowed for further development opportunities.
All themes provided the look and feel for the components enabled by the framework, and inherited the implemented functionality.
The admin look and feel was comprised of several main sections:
- Theme Options
The homepage was fully widgetized, so we built several main custom widgets providing business-specific functionality for the target audience of our customer. Customers had creative requirements for their landing page so we built highly configurable widgets pulling specific post type entries in a certain order, and dragging and removing widgets across the homepage made it pretty easy for everyone to change the look and feel of the site without technical background.
We designed a custom Theme Options panel controlled by the JSON configuration file provided with the theme. A tabbed look and feel listing the options in a predefined order allowed for a pleasant end user experience. A small percentage of our customers were technical, so we had a hidden “Custom CSS” option provided with the framework that could be activated and support staff can provide CSS snippets for custom changes.
The business-specific post types had complex relations, often resulting in one-to-many-to-many listings across the site. Selecting a page template unlocked custom meta boxes with additional features, filters and autocomplete fields, as well as drag and drop for intuitive data management across the site.
Reusable UI and backend components
The platform was defined with reusability in mind, and we were fully aware that more themes will be designed on top of the framework.
Therefore in our initial planning we discussed in details each of the core components, and the plans for extending it furthermore. We had three different component categories:
- Unique components shipped with every theme
- Core components styled by the theme
- Core components provided as-is
In order to accommodate all use cases, we introduced a separate theme folder that allowed drop-in components that were automatically interpret by the framework and registered to the platform. This allowed for overriding core components and adding new ones, as well as granular control over the backend.
Some components came as features only, with enough selectors that allowed external themes to style them and move their panels as needed.
The Theme Options panel included a dummy XML file importing the test data and mapping the related post type. It was built on top of the standard WordPress Importer, but applied several extra steps for properly mapping the post types, creating custom pages, assigning page templates and aligning the demo data accordingly.
In order to provide the support staff with a way to modify the data for specific users, another drop-in folder with a specific name was observed and dummy data was pulled from that folder if one was present.
Later on we integrated the Software Licensing add-on by Easy Digital Downloads and shipped a separate version of a plugin that included it. Our client created a new type of license, so we branched our main repository and shipped a very identical version with an additional folder including the licensing API.
The framework conversion was a success and we were able to convert an existing theme to the framework without using data or affecting the look and feel. After the launch we had several small iterations adjusting minor changes and adding more hooks for easy customization. During the process we received a new static theme and integrated it with the custom framework, and this theme is now live with several thousand sales already.