From the beginning of our PRO plugins, we have received many contact form submissions requesting a demo of our plugins. Over the years we have pointed users to various examples or explanations of how a plugin functions for their use case. Now, after a few rounds of scope and extensive development we have launched demonstrations of our plugins.
Challenges
We realized early on the biggest challenge for demonstrating our plugins was going to be that the plugins are largely WordPress admin driven. Figuring out how to provide admin like interactions on the front end of our site while maintaining a direct correlation with our plugin experience was no easy task.
We also wanted to keep our demonstrations inline with the plugin source code so we could regularly and easily introduce updates to demonstrations as our plugins evolve.
Another big lift was we needed to provide a way to persist changes to settings and updates without interacting with the actual database nor affecting other user’s demonstrations. Each plugin is different so no single solution could work for all demonstrations.
Advanced Sidebar Menu – Basic Version
The basic version of Advanced Sidebar Menu is completely free and installable from the WordPress plugins system so the most accurate demonstration is actually to install the plugin on your site and play around with it.
Instead of creating a plugin demo per say, we created a demonstration which would explain the menu hierarchy and general functionality of the plugin in an interactive way. Because we are not demonstrating the actual plugin, we could build the demo entirely custom.
We created a custom Gutenberg Block and built the demo using our custom Svelte system. Because we used a block, the actual demo may be shown in this post.
Advanced Sidebar Menu – PRO Version
The PRO version of Advanced Sidebar Menu originally was made up entirely of classic WordPress widgets. Due to the complex way WordPress handles widgets, it was decided any attempt to demonstrate the widgets would become a maintenance nightmare and ultimately not a viable option. Once Gutenberg hit the scene and we introduced Advanced Sidebar blocks, a demonstration, while complex, could be possible.
Content
In order to properly display a menu created by the plugin we would need a large set of pages which provide enough hierarchy to be useful. Luckily the OnPoint Plugins site already has a large hierarchy used for plugin documentation. By including the PRO – Demo page within the documentation, we get the necessary content for free.
Block Settings
Registering a block with Gutenberg gives you a helper edit callback which receives an attributes and getAttributes property for interacting with attributes in your block. For the purpose of this demonstration, these attributes are called “Block Settings.”
The Gutenberg system has a few ways to handle block settings, but the important takeaway is all of them require database interactions to save and retrieve values. Since our demonstration must not interact with the database, we needed to come up with another way to pass the attribute related properties and their functionality.
We created a useAttributes custom hook which stores and retrieves block settings using basic React state with Immer to simplify value updates. This allows us to pass the expected attributes down to the block settings components while maintaining the original component signatures. Put simply, we can reuse the same React components from the plugin’s blocks within our demo.
Preview
The WordPress Component package includes a ServerSideRender component which is used to display a preview of the menu when editing an Advanced Sidebar block in the WordPress admin. WordPress core provides a block-renderer REST API to generate the content for the ServerSideRender component.
While we can’t use the ServerSideRender component on the front end due to internal validation and dependencies, we can use the block-renderer endpoint to retrieve the finished HTML of our preview and display it using a sanitized dangerouslySetInnerHTML in a custom React component.
Persisting Settings
You’ll notice at the bottom of the demo there is a “Save” button. Clicking this button will not only keep the values of the block settings when you come back to this page, but also retain the settings throughout the website for all Advanced Sidebar menus.
The settings are saved to a browser cookie which is accessible on any page of the website. We used a cookie instead of browser storage to allow the values of the settings to be read by both PHP and JavaScript.
The basic version of the plugin includes a debugging system which allows replacing block settings with test values to allow validating and/or trying out different block settings on the front end of a site. Using the block settings values stored in the cookie, we are able to replace the block settings throughout the OnPoint Plugins website.
Result
The end result is a demonstration which allows you to interact with the actual block settings and see the result of your changes using the OnPoint Plugins website page hierarchy.
Go Live Update Urls PRO
The Go Live Update Urls PRO plugin functions entirely within the Tool section of the WordPress admin. Bringing a UI which is not intended to work outside the admin to the front end required us to think deeply about how the basic and PRO plugins work together.
With the plugins functionality being entirely centered around working with the database we also needed a way to simulate database interactions without exposing our database to actual changes.
Mocking the Basic Plugin
The basic Go Live Update Urls plugin handles all of the database interactions with the PRO version adding the enhanced UI and additional features. In order to provide a demo of the enhanced UI and functionality, we decided to completely exclude the basic version of the plugin from the demo in favor of a special mocked version.
The mocked basic version provides all PHP classes required by the PRO version but instead of interacting with the database, the calls are routed to internal handlers. As far as the PRO version is concerned, the basic version of the plugin is available and functional.
The PRO version is installed in this website like a normal plugin and may be updated like any other plugin. The demo will always be up to date with the latest features as the plugin is updated.
Persistent History
In order to provide demonstration feedback for standard functionality like updates, counting, and history, all interactions are saved within a PHP session. You may interact with the demo as if you are making changes to a real site and results will be persisted and communicated.
Using a PHP session allows each user to interact with the demo in their browser without affecting other users’ experience. Simply switching to a new browser or going incognito resets the session for the user.
A simulated database is calculated behind the scenes to provide accurate results. Essentially, we used an array of starting values and some creative calculations.
WordPress Admin Styles
While building the demo we discovered the UI was receiving a lot of the styles from WordPress core stylesheets. This can be an issue for two reasons:
- The WordPress admin styles are not available on the front end of our website.
- WordPress core has been cleaning up old scripts and styles so at any time they may go away.
We used this opportunity to go through the styles in both the basic and PRO version to declare styles explicitly instead of receiving them from WordPress core. Now we are using the plugin styles directly in the demonstration without issue.
Result
The result is a fully interactive demo with all PRO features available.
Conclusion
We put a lot of time and love into these demonstrations. We hope they will meet our goal of giving potential users the full picture of how a plugin works and what it can do before they install it.