7 min read

Step 2: Plan out our changes

Just like with our module, we are going to be systematic about our customization. This keeps us organized and reduces the chances for mistakes.

Really, these changes are so simple we could probably just dive in and do them, but we want to build good habits for when we want to customize more complex extensions.

Step 2.1: Decide on our changes

Our plugin is going to be essentially the same, hiding or showing parts of our content depending on a particular condition. Only we want to change it so the condition we use is user’s subscription and not their user group. We will need to put in some code to search the database for the visitor’s subscription information.

We also want to clean out any code we don’t need, such as the description HTML page and images.

We will go a little bit further and rename our extension and functions. One day we may want to distribute this plugin to get some traffic to our site, and help other developers like ourselves.

Also, seeing as we are going to rebuild most of this plugin, let’s put a short description in to remind us what it is for, or in case we hire another developer to help with our site later, they can see what it does.

Step 2.2: Mark out our changes

Remember that before we actually make our changes, we want to go through the code and mark them with comments first. This way we are forced to think the whole process through from start to finish before we write any code, and we can see any potential problems before they happen. This beats finding them after we have spent a few hours writing code, and wasting that time going back to repair them.

en-GB.plg_content_njaccess.ini

First, we are going to edit our language file, en-GB.plg_content_njaccess.ini.

If we were making a complex component, we would usually keep the language file open the entire time, and add new entries to it every time we wanted to put some text onto the screen. But our plugin is pretty much a ‘behind the scenes’ plugin so we don’t need much text.

So what text do we need?

Well, as we discussed above, when we hide some content from a user, we probably want to display a message that tells them that it has been hidden, and that they should get a subscription to read it. We also want to remove the current rich description and replace it with simpler, normal text.

So let’s add a note to our current code,

NINJACONTENT=

that tells us to delete it completely. Then we will add a note to write our description and message in its place.

# TODO-Remove this
NINJACONTENT=
# TODO-Add plain text description
# TODO-Add message for hidden text

Wait a minute! What are these hashes? We haven’t seen them before. Up until now we were told that comments were either double slashes (//), enclosing slash asterisks (/* … */), or for HTML some long tags ().

Well, .ini files are different from our . php files, and are processed differently. As a result, they use a different symbol to indicate for comments. So now, we can add # to our list of comment symbols, but for .ini (language) files only.

njaccess.php

Next, open up njaccess. php. As we are basically re-writing this plugin, we might as well change the name of this file and all the functions to something more relevant.

// TODO-Rename this file
// Ensure this file is being included by a parent file. defined('_JEXEC') or
die( "Direct Access Is Not Allowed" );
jimport('joomla.eventplugin');
// TODO- Rename the class to match our new filename
class plgContentNJaccess extends JPlugin {
// TODO- Rename this constructor
function plgContentNJaccess( &$subject )
{...

We don’t have any parameters, so we can remove the parameter loading from the constructor.

...
parent::__construct( $subject );
// TODO-
Remove these as we have no need for parameters
$this->_plugin = JPluginHelper::getPlugin( 'Content',
'ninjaacess' );
$this->_params = new JParameter( $this->_plugin->params );
}

We are renaming everything, so we should rename our regex tags and the function call via preg_replace_callback as well.

function onPrepareContent(&$article, &$params, $limitstart) {
// TODO- Adjust our regex to look for a shorter tag
// and one collector function between the tags
$regex = "#{njaccess(.*?)}(.*?){/njaccess}#s";
// TODO- Rename the function call
$article->text = preg_replace_callback($regex,array($this,"njaccess"), $article->text);
return true;
}
// TODO- Rename the function
function njaccess(&$matches) {

We also want to remove any references to the ACL. We do want to continue to load the user information though, as we need their user id (if logged in) to compare it to the subscriptions in the AEC tables.

$user = &JFactory::getUser();
// TODO- Remove the next 3 lines as we don't need ACL
$acl = &JFactory::getACL();
$myRealGid = intval( $acl->get_group_id( $user->usertype ) );
$accessLevels = '';

We are only going to have one collector pattern now, so only one set of information, the text to be shown/hidden, needs to be collected. To do this, we need to change all the references to $matches[2] into $matches[1] and remove the old $matches[1] checks.

// TODO-change this to matches[1] as we only have
// one collector now
$output= $matches[2];
// TODO-Remove this
if (@$matches[1]) {
$accessLevels = explode(",", trim($matches[1]));
}

Lastly, we need to replace the main processing with a query to check our visitor’s user id against the AEC subscription tables for an active paying subscription.

// TODO-Replace this with a query searching for the
// user's id in the subscriptions table, searching
// for a paying subscription
if (in_array($myRealGid,$accessLevels))
return $output;
// TODO- Get the visitor's id if available.
// If a guest (id = 0) then skip this and display
// the please subscribe message
// TODO- Look for the id in the AEC subscriptions
// table, and check if they have a valid, paid
// subscription. If so, return the text
// if not, skip it and return the message
// TODO- Instead of blank, return our message from our
// language file
return "";
}
}

njaccess.xml

Finally, we come to our njaccess.xml file. Comments can be made into XML files in the same way as HTML .

For our XML manifest, we have a few things to do. At first, we want to rename everything from njaccess, including the manifest itself.




Ninja Access
Daniel Chapman
February 2008
(C) 2008 Ninja Forge
http://www.gnu.org/copyleft/gpl.html GNU/GPL
daniel@ninjaforge.com
www.ninjaforge.com

Also, let’s change the version number of our new plugin to 1.0. Then change the description as well, to suit what we put into our language file.


1.1

NINJACONTENT

Then, we want to remove all the unnecessary files from the description



njaccess.php
njaccess/njaccess_desc.html
njaccess/js/ninja.js
njaccess/images/logo.jpg
njaccess/images/ninjoomla.png
njaccess/images/firefox2.gif
njaccess/images/jcda.png
njaccess/images/validation_xhtml.png
njaccess/images/validation_css.png
njaccess/images/info.png
njaccess/images/change.png
njaccess/images/inst.png
njaccess/images/tabbg.gif
njaccess/images/tab2.png
njaccess/images/gnugpl.png

Finally, rename the reference to our language file to suit the new filename:





en-GB.plg_content_njaccess.ini


Subscribe to the weekly Packt Hub newsletter

* indicates required

LEAVE A REPLY

Please enter your comment!
Please enter your name here