What I write in these posts is not the perfect travel of an expert and consumed WordPress developer but the gnarly and error-prone stroll of an average developer (pun intended).
I will make mistakes and will try to correct them along the road and mean to share the path I’ve taken with all its fallback and wrong turns and not to show the best possible one.
After setting up the plugin using
grunt-init I’ve deployed it in my local site and made it available on GitHub. I will commit to the GitHub repository throughout the work and the plugin can now be downloaded and installed in WordPress. The code I show becomes much more comprehensible when observed in context.
One of the requirements of the plugin is that site administrators should be able to set a custom login/subscription page and to output, in this page, the custom plugin output. Going back to the still red light first test, the one I set up in this post, I need to give the site administrators these two possibilities by adding:
- an option to set the custom page for login
- a shortcode to output in the page that outputs, mind the test, an element with an
id = "member_login_form"attribute
The Codex has an extensive section dedicated to the creation of Options Pages but Tom McFarlin’s plugin boilerplate that I used for my grunt-init WordPress plugin boilerplate comes with a settings page added for the plugin that’s empty to begin with.
The best and clearest guide I could find to the not so intuitive WordPress Settings API was the one by Otto on WordPress.
I’ve read other guides on the matter but when it comes to clarity this is the best and it also plays along with WordPress instead of trying to get around it or hack it.
The code I added in the GitHub commit and little I did that is different from what the above guide illustrates.
What’s left on the plugin to-do list, adding to the shortcode mentioned above, is the redirection of the visitors to the right admin or login page.
In the past I used karenv’s plugin options framework and would have liked to use it today as well: no point in re-inventing the wheel. Sadly though I could not make it work the way I wanted and even if I had coded a nice adapter class, you can see its traces in the GitHub repository of the plugin, I had to remove it from the project. But still it’s one of the few OOP alternatives for a plugin options framework. It’s instructive in how it leverages the possibility to pass an array to callback functions like
add_settings_field( 'custom_member_login_page', __( 'Custom login page', 'membersignup' ), array($this, 'the_one_echoer'), 'membersignup', 'main_settings', array('key1' => 'value', 'key2' => 'value2') );
Where keys and values might be type, name, value, label, description, etc. of the field that the callback function
the_one_echoer can check to render the right form element.