Room for improvement
According to the official WordPress Codex, implementing a single custom option in the back-end requires nearly a full page of code! As more options are needed or requested for one or multiple WordPress sites, developers may quickly find themselves in over their head working on things that are secondary to the goal.
The old way
Let’s start with a typical scenario. Say you want to implement a new option where the site owner can modify the footer’s content. Normally you’d have to register the option in the theme’s functions.php file and then write another function with some HTML output that will hook into the WordPress back-end to create a dashboard page where the site owner can change/save this new custom option. And when the option doesn’t work, opening phpMyAdmin is usually unavoidable. Developers may find themselves repeating these steps for each option they implement.
What if all that redundant work was eliminated? Rapid Platform’s Options Framework was designed with this idea in mind. The Options Framework allows developers to define a set of human-readable (option name/default option value) pairs that will be used to initialize a WordPress site with those custom options, complete with dashboard pages to go with it. As soon as the Rapid Platform is activated in WordPress, and once the user chooses to initialize the custom options, the database table, default option values and dashboard pages are all created automatically, and they are immediately ready to use.
Example
A rapid-config.php file is dropped into the current theme’s root folder. This file should contain one or more calls to register_dashboard_fragment(). Once this is done, Rapid Platform will recognize the config upon activation of the plugin, then prompt the user to initialize these newly configured options. Once accepted, the initialization happens automatically; options are created in the database and dashboard pages are created in the back-end.
This:
Instantly Becomes This:
