Extending the WP MobileAdmin Plugin : Section 2
As mentioned in the overview page, plugins to MobileAdmin will be loaded and used automatically, assuming they are in a directory within the mobile_plugins directory, and contain at least a .php file that conforms to the following specifications.
The minimal code required for a plugin
Here is the complete code for everything that would be required to create a new plugin for Mobile Admin, called “SamplePlugin”, for the sake of this example:
<?php class SamplePlugin_MobileAdmin extends MobileAdmin {var $Name = "SamplePlugin"; var $MatchingUserAgents = array('SampleUserAgent'); } $MAController->RegisterMobileAdminPlugin('SamplePlugin_MobileAdmin'); ?>
This file, if located at /wp-content/plugins/mobileadmin/mobile_plugins/SamplePlugin/SamplePlugin.php, will be picked up automatically when MobileAdmin is scanning for its plugins.
Now, of course, this plugin won’t actually do anything (and therefore fall back on the implementation it inherits from the default plugin), but it can be used to highlight the basic elements required in a plugin, as well as illustrate a general principle involving inheriting behavior from the default plugin.
As you can see in the first line, plugins are implemented as PHP classes that extend the default MobileAdmin class. This means that the default plugin is the “parent” of this class, and by default everything in your new plugin will work just like the default plugin, unless you tell it differently by overriding only the specific parts you want to change.
Let’s go through the example above line by line and cover what you need to know.
For adhering to the naming convention (which is important), you should name your class SamplePlugin_MobileAdmin, where the first part is your unique plugin name and the last part is “_MobileAdmin”. You should provide a “Name” variable within the class (as shown) which also matches the name you’ve given to the class.
Matching User Agents
You also need to specify which browsers this plugin should be used for by defining the “MatchingUserAgents” variable. This is a simple array of strings, in which any browser which has a user agent string containing the text ‘SampleUserAgent’ (in this example) will be considered a match and this plugin will be used.
For another example, I’ll often add normal browsers to this list while I’m developing and testing a plugin. Setting the variable in this manner: var $MatchingUserAgents = array('Mozilla','AppleWebKit'); will result in browsers like Firefox and Safari being considered as matching user agents for this plugin.
You’ll see yet another example of browser matching in the bundled WindowsMobile plugin, although this one matches slightly differently. In that file you will see:
var $MatchingUserAgentPatterns = array('/Windows CE/mis');
var $MatchingUserAgents = null;
This is using the pattern matching feature for user agents, which will allow you to specify one or more regular expression patterns to be checked against a browser user agent, instead of just checking whether the user agent contains a string.
This is kind of a poor example, since it’s not doing any fancy pattern checking and could easily just be using the regular string matching method, but it’s just there as an example.
If both MatchingUserAgentPatterns and MatchingUserAgents variables are defined, the patterns will be checked first, and then the strings, so you can use either or both methods in the same plugin.
Plugin registration
The last line in the example above:
$MAController->RegisterMobileAdminPlugin('SamplePlugin_MobileAdmin');
will register this plugin as available with the MobileAdmin plugin. This is an important part of the auto-load routine, so don’t forget it. As you can see, it’s a simple call to a function, passing in the name of the class you just defined as a string: ‘SamplePlugin_MobileAdmin’.
Now to make your plugin actually do something different, check out the sections on CSS + javascript, and the advanced section if you really want to seriously tweak things.