A plugin development framework with a lot of reusable code and a nice settings page builder.

<a href="http://hikari.ws/tools/" rel="nofollow ugc">Hikari Tools Framework</a> isn’t a plugin with features for the end user. It’s a development framework with tools to be used by other plugins, so that they don’t need to duplicate the same code over and over again.
It deeply decreases plugins development time, specially in building options pages. For that, instead of building the whole HTML for each plugin, we can just prepare an array and it’s used to build the whole page.
Another great feature this framework offers is options detection and reset. With the use of another simple array, in the bottom of options page it prints a table showing to plugin’s users all kinds of options the plugins creates, being it wp_options, comment meta, post meta, and even network-wide options and user specific options (usermeta).
Every kind of data your plugin stores in database is shown in a clear way, with its key so that users can easly search for them in database. But they don’t need to, because together with each option it informs if there’s any data of that type stored, and provides user-friendly command to reset them all, totally cleaning the user’s database from any data created by the plugin. Very easy and practical to use, and instantly available to any plugin that consumes Hikari Tools Framework!
<h4>Features</h4>
There are really a bunch of features available, here are the most used ones.
<ul>
<li>DRY: Using the Don’t Repeat Yourself principle, features are developed only once in the framework and are used anywhere you want! And once the framework is updated, the update is automatically replicated to all plugins that use it!</li>
<li>Object Oriented: it provides 2 classes, which you can expand to implement your code, and then call parent methods anywhere to use Framework’s features. Also, if you wanna add special features to a specific method, just overwrite it in your class!</li>
<li>Automatic ‘plugins_loaded’ and ‘init’ actions: follows WordPress standards and runs the least code possible during plugins load time. Each object is instantiated and runs its <code>construct()</code> method during ‘plugins_loaded’ action, and its <code>startup()</code> method during ‘init’ action</li>
<li>Data dump: great for debugging, you can use the <code>HkTools::dump()</code> method to pass any kind of data and have it dumped, with a title above it, anywhere you want! And there’s also the <code>HkTools::formatCode()</code> that receives a string and prints it using formatting plugins if available, or pre HTML element if needed.</li>
<li>Strings search: use <code>hasNeedle($haystack,$needle)</code> and <code>hasNeedleInsensitive($haystack,$needle)</code> methods to search inside strings. They use PHP’s <code>stripos()</code> to do the search, but instead of returning numbers that are rarely used it returns ready-to-use boolean values to say if <code>$needle</code> was or wasn’t found, and <code>$needle</code> can even be an array if you wanna search many strings at once!</li>
<li>Version checks: the Framework tests PHP and WordPress versions and doesn’t load itself if requirements aren’t fit, and plugins that consume it follow a standard of testing the Framework version too.</li>
<li>Paths to plugin files: it provides 2 variables for local path and URL for plugins root folder, for each plugin that consumes the Framework!</li>
</ul>
Full featured options page builder: This one deserves its own features list, so many they are! The HkToolsOptions class handles all your options data and options page building, including reseting data to default:
<ul>
<li>Instead of having in each of your plugins a complete HTML page to allow your users to setup configs, just create an array with your options data and everything will be handled by the Framework, including handling default values and registering the options page and its menu item!</li>
<li>Many types of data are supported: text, textarea, select, radiobox, checkbox, and if neither of those are enough you can also specify custom areas where your special options (ex: complex data that requires custom HTML, JavaScript, etc) can be placed!</li>
<li>Store multiple settings in a single option using arrays: forget those dumb plugins that add dozens of wp_options rows, now you can use a single array to store all those settings, and place them all in a single options variable. And you don’t have to deal with the complexity of setting them to use array, because the Framework handles it to you!</li>
<li>Use multiple sections: Does your plugin use so many settings that it becomes messy? Don’t worry, create visually separated sections to organize your settings, each of them having a title and help text to explain what the section refers to. And multiple sections are still stored in a unique array’ed wp_options row!</li>
<li>Store your options in multiple places: aside from the most known wp_options (which is specific for each site), you can also store Multisite / network-wide options (that are shared by all sites in a MultiSite network) and user specific options (which are stored together to current user and are valid only to him).</li>
<li>Too many storage places make it hard for plugins users to delete them all when they are uninstalling the plugin? No! Hikari Tools Framework easily resets them!: it provides an uninstall form which is added in the bottom of default options page, listing all kinds of options (wp_options, sitemeta, usermeta, postmeta, commentmeta, …) your plugin uses, informs for each of them if there’s any data stored ATM, and provides a command to delete them all from database, followed by a command to directly uninstall the plugin! This feature can also be used to reset options to default.</li>
<li>Default options aren’t stored: many plugins use to add default options to database when they find none, therefore storing data that didn’t need to be there and blocking users from deleting those data before deactivating the plugin. With Hikari Tools Framework plugins that doesn’t happen, because it doesn’t save data automatically and uses default settings when options data isn’t found in database. And that’s totally transparent for you while handling options in your code!</li>
<li>Special debug feature: There’s a property named <code>HkTools::debug</code> that’s set to false by default. In your plugin you can develop debugging code that will only be run if <code>$this->debug</code> is set to true. Then, it’s just a matter of setting it in your extended class and all of a sudden all debug will be available to you! BTW, options pages have “hidden” debug code, and when <code>HkToolsOptions::debug</code> is set to true they are automatically shown without you having to worry with anything!</li>
<li>Automatic options loading: Always load your options object first, because its <code>HkTools::loadAllOptions()</code> method automatically loads your options and stores them in <code>HkTools::optionsDBValue</code>, regardless if it was indeed loaded from database or was built from options defaults. The class by default handles a single wp_options variable, but you can create more objects and overwrite <code>loadAllOptions()</code> to load and provide them all.</li>
<li>Options page customization: if some part of default page doesn’t fit your needs, you can change it by overwriting a <code>HkToolsOptions</code> method, instead of having to throw the whole class away and go back building full pages again.</li>
<li><code>HkToolsOptions extends HkTools</code>: of course, all features available in HkTools are also available in HkToolsOptions to be used for handling your options.</li>
<li>Reset and uninstall commands use JavaScript to alert user about data lost and ask confirmation before deleting</li>
</ul>
I dedicate Hikari Tools Framework to Ju, my beloved frient ^-^

Alternatives to Hikari Tools Framework

Top alternatives