Module Development
From Social Web CMS
This section is designed to take you step by step through the process of making modules for Social Web CMS.
Why make modules?
Social Web CMS developers are committed to extending its functionality through the use of modules. This ensures that the SWCMS core remains lightweight, fast and secure. By making modules, users can easily upgrade their SWCMS installation without worrying about losing custom modifications. In addition, modules provide a fast and effective way for individuals to customize and add unlimited features to their site, and even share their work with the Social Web CMS community.
What's in a SWCMS module?
A typical SWCMS module contains the following files:
- name_readme.html
- lang.conf
- name_install.php
- name_settings.php
- name_init.php
- name_main.php
Most modules will also contain a templates folder. This will be covered later.
Overview of the main files
- name_readme.html:
This contains the version number, author information, a description of the module, instructions for using it, revision history and anything else you feel is necessary. It is shown when a user clicks the module's name in the Module Management section of Admin.
- lang.conf:
This file is a module version of the SWCMS language file. Instead of hard coding language into your templates, it is more manageable if the words and phrases are stored in one place, especially for non-English users who may wish to localize the language to suit their visitors.
- name_install.php:
This file contains information used in the Module Management section of Admin, such as the module's name, a description of what it does, and a version number. This is enough for basic modules, but more complex modules will use the install file for actions to be performed during installation, such as adding a new database table or field.
- name_settings.php:
The settings file is used to define variables that are used throughout the module. Typical examples include the path to the templates folder, images folder and language file. These variables are usually defined twice; once for PHP functions and again as "Smarty" variables used in template files. Examples of these will be covered later.
- name_init.php:
This is the gateway between SWCMS files and your module. In this file you can specify where you want your module to be active, which module hooks trigger the module, and where to send the program when the hooks are triggered. For example, the "Related Links on Submit" module is only active during the submission process, and when the "do_submit2" hook is triggered after the second step of story submission, this file directs the program to the "assign_related_links" function in the name_main.php file.
- name_main.php:
The "main" file contains the PHP functions needed for your module to perform actions.
Modules for action and presentation
Modules for action
Some modules do their work "behind the scenes". The actions they perform are triggered by hooks in core files. These modules use functions in the name_main.php file.
Examples: Akismet, Registration Email
Remember: core hook -> main function.
Modules for presentation
Some modules rely almost entirely on templates. When a template is loaded in the user's browser, a module hook is triggered which inserts a template from the module in the current page. In theory, this is only useful for displaying content, however, with the vast number of cut and paste widgets and JavaScript libraries available, all kinds of extra functionality is possible through template files.
Examples: Easy Submit, Creative Commons License, Nicedit WYSIWYG Editor
Remember: template hook -> show template.
Combining modules for action and presentation
The majority of SWCMS modules are a combination of both action and presentation types. The name_main.php file does the work and passes its results to the template files for display.
Examples: LC Category Manager, Simple Messaging, Random Message
How to identify module hooks
Finding a place in SWCMS to hook your module into is one of the first steps in module-making. If your module is intended to work off a main core file, you'll need to decide which one. Every page in SWCMS is generated by a script in the root folder. For example, index.php, upcoming.php, story.php and user.php generate and send their results to the template files index_center.tpl, upcoming_center.tpl, story_center.tpl and user_center.tpl.
Core files contain module hooks that look like this:
check_actions('filename_position', $vars);
If your module is intended to simply add extra content to the template, then you will need to find appropriate hooks in the template files.
Template files contain module hooks that look like this:
{checkActionsTpl location="tpl_filename_position"}
The following case studies show how modules are put together and the relationship between modules and module hooks.
Note: For more information on module hooks, please see #Custom Module Hooks.
Case Study 1: Easy Submit
Name: Easy Submit
Description: "Adds a quick submit field and button at the top of most pages simplifying the process of adding a new story to a SWCMS site."
Download page: http://forums.socialwebcms.com/index.php?topic=246.0
Easy Submit is one of the simplest SWCMS modules, and an excellent example of a module based solely on templates. It doesn't hook into any core files and uses just a single, existing template hook.
- easy_submit_readme.html: Self-explanatory.
- lang.conf: The words on the right, e.g. "Submit" are stored in the constants on the left.
SWCMS_Easy_Submit_Continue = "Submit" SWCMS_Easy_Submit_PreText = "Submit A New Story: " SWCMS_Easy_Submit_Input_Default = "http://"
- easy_submit_install.php: Information used in Module Management is stored as follows:
$module_info['name'] = 'Easy Submit'; $module_info['desc'] = 'Add a submit new story box to the top of the homepage available only if users are logged in.'; $module_info['version'] = 0.2;
- easy_submit_settings.php: Most of this file is standard in all modules, so just copy, paste and change the module name to suit your own. You'll see examples of how this file can be extended in later case studies.
First, we define the module path. With this, you can write "easy_submit_path" in your functions instead of explicitly writing the full path to your module every time you need it.
define('easy_submit_path', my_pligg_base . '/modules/easy_submit/');
This next part determines whether or not you are currently in the root folder or not. There's no need to edit this at all.
if(!defined('lang_loc')){
// determine if we're in root or another folder like admin
$pos = strrpos($_SERVER["SCRIPT_NAME"], "/");
$path = substr($_SERVER["SCRIPT_NAME"], 0, $pos);
if ($path == "/"){$path = "";}
if($path != my_pligg_base){
define('lang_loc', '..');
} else {
define('lang_loc', '.');
}
}
The following lines, like "easy_submit_path" above, provide shortcuts to the different files and folders within the module. You won't need to edit them except for the module name:
define('easy_submit_lang_conf', lang_loc . '/modules/easy_submit/lang.conf');
define('easy_submit_swcms_lang_conf', lang_loc . "/languages/lang_" . pligg_language . ".conf");
define('easy_submit_tpl_path', '../modules/easy_submit/templates/');
The above definitions can be used in PHP functions, but for your templates, you need to assign them to Smarty variables as follows:
if(is_object($main_smarty)){
$main_smarty->assign('easy_submit_path', easy_submit_path);
$main_smarty->assign('easy_submit_lang_conf', easy_submit_lang_conf);
$main_smarty->assign('easy_submit_tpl_path', easy_submit_tpl_path);
$main_smarty->assign('easy_submit_rand', rand(10000,10000000));
}
Each of those Smarty variables can be used in your template files like this: {$easy_submit_path}
- easy_submit_init.php: This is where we tell SWCMS when and where to use the module:
First, include the settings file above:
include_once('easy_submit_settings.php');
Then, tell SWCMS where you want to use this module:
$include_in_pages = array('all');
$do_not_include_in_pages = array();
The words that can go in the arrays are core files without ".php". Easy Submit is activated by a template hook in pligg.tpl. pligg.tpl is your site's main template file and is used for every page, so simply putting 'all' in the array makes this module available throughout your site. For most modules, you can leave the "do_not_include" array empty.
The next section specifies the hook we want to trigger the module, and what to do when it is triggered:
if( do_we_load_module() ) {
if(is_object($main_smarty)){
module_add_action_tpl('tpl_pligg_above_center', easy_submit_tpl_path . 'easy_submit_index.tpl');
}
}
The key here is the module_add_action_tpl line. The first argument is the name of the template hook, and the second argument is the file we want to insert into the template (which uses the shortcut we defined in the settings file).
Let's leave this module for a moment and look instead at the pligg.tpl file where the template hook is. The hook we're using looks like this: {checkActionsTpl location="tpl_pligg_above_center"}. It's at the top of the "contentbox" div, which means the Easy Submit form will be shown right above the main content. Here's the the hook in the pligg.tpl file:
<body {if isset($body_args)}{$body_args}{/if}>
<div id="wrap">
<div id="header">
{include file=$tpl_header.".tpl"}
</div><!-- header end -->
<div id="content-wrap2">
<div id="contentbox" {if $pagename eq "editor"}style="width:100%"{/if}>
{checkActionsTpl location="tpl_pligg_above_center"}
{include file=$tpl_center.".tpl"}
{checkActionsTpl location="tpl_pligg_below_center"}
</div><!-- contentbox end -->
<div id="sidebar">
{if $pagename neq "editor"}{include file=$tpl_right_sidebar.".tpl"}{/if}
</div><!-- sidebar end -->
</div><!-- content-wrap end -->
</div><!-- wrap end -->
{include file=$tpl_footer.".tpl"}
<script src="{$my_pligg_base}/js/xmlhttp.php" type="text/javascript"></script>
</body>
This module doesn't have an easy_submit_main.php file because there are no actions to perform. Instead, we saw that when the tpl_pligg_above_center hook is triggered, the easy_submit_index.tpl file is shown. That file is in a templates folder within the Easy Submit module.
- templates/easy_submit_index.tpl:
{config_load file=easy_submit_lang_conf}
{if $pagename eq "published"}
{if $user_authenticated eq true}
<form action="{$URL_submit}" method="post" id="thisform">
{#SWCMS_Easy_Submit_PreText#}
<input type="text" name="url" id="url" value="{#SWCMS_Easy_Submit_Input_Default#}" size="55" />
<input type="hidden" name="phase" value="1" />
<input type="hidden" name="randkey" value="{$easy_submit_rand}">
<input type="submit" value="{#SWCMS_Easy_Submit_Continue#}" class="submit-s" />
</form>
{/if}
{/if}
{config_load file=easy_submit_swcms_lang_conf}
The first and last lines manage the language. First, the lang.conf file is loaded using the "easy_submit_lang_conf" constant defined in the settings file, and at the end, the main SWCMS language file is re-loaded before we return to the main site's template.
SWCMS uses Template Lite for separating presentation from back-end coding. Smarty variables have dollar signs and are accessed within curly brackets, e.g. {$URL_submit}. The language defined in lang.conf is accessed using hashes within curly brackets, e.g. {#SWCMS_Easy_Submit_PreText#}. It is worth bookmarking Template Lite as a reference when writing template pages for SWCMS.
Just for fun:
Those of you with a keen eye will have noticed that {if $pagename eq "published"} means the form will only show on the page with "published" stories, i.e. the index page. However, back in easy_submit_init.php we had this line:
$include_in_pages = array('all');
Since we're only showing it when the core file index.php creates the "published" page, you can change this to:
$include_in_pages = array('index');
Alternatively, you could remove the {if $pagename eq "published"} condition in easy_submit_index.tpl, and change the array to this:
$include_in_pages = array('index','upcoming','story');
That will show the Easy Submit form on all three of those pages. Try it for yourself.
Note: Before starting your own module, please read the sections on #Module Security and #Custom Module Hooks.
Case Study 2: Smilies
Name: Smilies
Description: "Converts text to smilies in user comments."
Download page: http://forums.socialwebcms.com/index.php?topic=130.0
In Case Study 1, you saw an example of a module for presentation. Easy Submit used template files to insert a submission form into your pages. Smilies, on the other hand, doesn't use any templates at all. Instead, when a user submits a comment, the Smilies module checks the comment for certain characters, converts them into images and sends the comment back to SWCMS for further processing. The actual display of the comment is handled by SWCMS, not the module.
- smilies_readme.html: Self-explanatory.
- lang.conf: Not included because this module doesn't handle presentation.
- smilies_install.php: Module information as discussed in Case Study 1.
- smilies_settings.php: Without the need for a lang.conf file or templates folder, this file is much simpler than the one seen in Case Study 1.
define('smilies_path', my_pligg_base . '/modules/smilies/');
define('smilies_img_path', my_pligg_base . '/modules/smilies/images/');
if(isset($main_smarty) && is_object($main_smarty)){
$main_smarty->assign('smilies_path', smilies_path);
$main_smarty->assign('smilies_img_path', smilies_img_path);
}
In fact, since Smilies doesn't display anything, the $main_smarty section could be omitted from the file, but it's good practice to include the Smarty variables in case you decide to use them later.
- smilies_init.php: This is where things start to differ from our first case study. Because the Smilies module hooks into system files instead of template files, we use the modules_add_action function to specify what hook will trigger the module and what function to call when that happens.
if( do_we_load_module() ) {
module_add_action('show_comment_content', 'make_smilies', '');
module_add_action('comment_form_label', 'make_smilies_comment_form_label', '');
include_once(mnmmodules . 'smilies/smilies_main.php');
}
Notice that the modules_add_action requires a third argument, but in almost every case, it is left empty.
The Smilies module uses two hooks, both in /libs/comment.php. The first calls the make_smilies function which does the text to image conversion, and the second calls a function that assigns a label to the comment form. These functions are in the smilies_main.php file, which is included using include_once.
- smilies_main.php: Before we look at the actual functions, we need to see the module hooks themselves to understand fully what is happening. In the fill_smarty function in /libs/comment.php, you'll see this rather elaborate module hook:
$vars = array('comment_form_label' => '');
check_actions('comment_form_label', $vars);
$smarty->assign('comment_form_label', $vars['comment_form_label']);
You can read more about module hooks later in this guide, but notice here that the comment_form_label element of the $vars array is empty. The check_actions line is the hook that sends $vars to the make_smilies_comment_form_label function in the module. Here is that function:
function make_smilies_comment_form_label(&$vars) {
$vars['comment_form_label'] = 'Smilies can be used in the comments!';
}
You can see that $vars has been passed by reference to the function which means it can be modified. The comment_form_label element is assigned some text and we fall out of the function back to /libs/comment.php where $vars['comment_form_label'] is assigned to Smarty for display in a template.
The second hook in /libs/comment.php is:
$vars = array('comment_text' => $text);
check_actions('show_comment_content', $vars);
$smarty->assign('comment_content', $vars['comment_text']);
In this case, $text contains the current comment which we want to check for smilies. The make_smilies function in smilies_main.php starts like this:
function make_smilies(&$vars) {
$text = $vars['comment_text'];
...and ends by assigning the modified comment to $vars['comment_text'] before falling out of the function and back to the SWCMS /libs/comment.php file where it is assigned to Smarty for display in a template.
Note: Before starting your own module, please read the sections on #Module Security and #Custom Module Hooks.
Case Study 3: Bookmarklet
Name: Bookmarklet
Description: "This module offers the same functionality as the bookmarklet in user profiles, but it is more portable."
Download page: http://forums.socialwebcms.com/index.php?topic=491.0
The Bookmarklet module serves as an interesting case study because it offers two features, a) it can insert the bookmarklet wherever the end-user puts the custom template hook, and b) it can be used as a standalone page. This second point is particularly useful because Admin pages are created in a similar way.
- bookmarklet_init.php: To display the bookmarklet as its own page, the user will need to access
http://yoursite.com/module.php?module=bookmarklet
in their browser. Notice that this url contains "bookmarklet" stored in the variable "module". Let's see how bookmarklet_init.php handles that:
if(isset($_REQUEST['module'])){$moduleName = $_REQUEST['module'];}else{$moduleName = '';}
if($moduleName == 'bookmarklet'){
module_add_action('module_page', 'bookmarklet_showpage', '');
}
If the variable module contains a value, the value is assigned to $moduleName. If the module is "bookmarklet", then the function bookmarklet_showpage is called when the module_page hook is triggered. Since the module_page hook is in module.php which is the file in the url, we know that this module is triggered immediately when visiting that url.
In addition, the bookmarklet_init.php file also contains the following line:
module_add_action_tpl('tpl_show_bookmarklet', bookmarklet_tpl_path . 'bookmarklet.tpl');
This works exactly the same way as described in Case Study 1. The Bookmarklet template file will be inserted in the location of the tpl_show_bookmarklet template hook.
- bookmarklet_main.php: If the bookmarklet is being displayed as a standalone page, this function is called:
function bookmarklet_showpage() {
global $main_smarty, $the_template, $db;
$navwhere['text1'] = 'Bookmarklet';
$navwhere['link1'] = URL_bookmarklet;
define('pagename', 'bookmarklet');
$main_smarty->assign('pagename', pagename);
$main_smarty = do_sidebar($main_smarty, $navwhere);
$main_smarty->assign('tpl_center', bookmarklet_tpl_path . 'bookmarklet');
$main_smarty->display($the_template . '/pligg.tpl');
}
Let's look at this more closely to see how it generates its own page.
global $main_smarty, $the_template, $db;
First, $main_smarty is needed for storing the language and data to be displayed on the page. We also need the $the_template variable, which tells SWCMS what template you are using. The $db global variable is used for database work and ias actually unnecessary here.
The lines below are used for naming the links in the breadcrumbs navigation menu at the top of the page.
$navwhere['text1'] = 'Bookmarklet'; $navwhere['link1'] = URL_bookmarklet; $main_smarty = do_sidebar($main_smarty, $navwhere);
Every page is SWCMS has a name, so you should give your module page a name, too:
define('pagename', 'bookmarklet');
$main_smarty->assign('pagename', pagename);
These next lines assign the bookmarklet page to the Smarty tpl_center, which is displayed within the main template file, pligg.tpl.
$main_smarty->assign('tpl_center', bookmarklet_tpl_path . 'bookmarklet');
$main_smarty->display($the_template . '/pligg.tpl');
- templates/bookmarklet.tpl: This is the file that is either inserted within an existing template or displayed as a standalone page depending on how the module is used. This template file is very similar to the Easy Submit template file in Case Study 1, except instead of showing a form, it shows the bookmarklet instead.
Note: Before starting your own module, please read the sections on #Module Security and #Custom Module Hooks.
How to make an Admin page
Some modules are designed only for use in the Admin section (e.g. LC Category Manager) and other modules use the Admin section to offer configuration options.
Using the RSS Basic module as an example, the first thing you need is a link in the main Admin page. This is done by inserting a template file into the location of a module hook.
In rss_basic_init.php, this line does just that:
module_add_action_tpl('tpl_header_admin_main_links', rss_basic_tpl_path . 'rss_basic_admin_main_link.tpl');
The tpl_header_admin_main_links template hook is in /admin_templates/admin_main_center.tpl.
The actual template being inserted from the module looks like this:
{config_load file=rss_basic_lang_conf}
<img src="{$rss_basic_img_path}rss_16x16.png" align="absmiddle"/> <a href="{$URL_rss_basic}">{#SWCMS_RSS_Basic_BreadCrumb#}</a><br/>
{config_load file=rss_basic_swcms_lang_conf}
That adds the link to the RSS Basic admin page, but where does it go when you click it? You can see above that the url is contained in the Smarty {$URL_rss_basic}. This is set in the rss_basic_settings.php file:
define('URL_rss_basic', my_pligg_base . '/module.php?module=rss_basic');
$main_smarty->assign('URL_rss_basic', URL_rss_basic);
Notice that the url is the same as the one used by the Bookmarklet module in Case Study 3, except for the module's name.
It works in the same way, too. Here's the code from the rss_basic_init.php file:
if($moduleName == 'rss_basic'){
module_add_action('module_page', 'rss_basic_showpage', '');
module_add_js(rss_basic_path . 'js/rss_basic.js');
}
In this case, when that link is clicked, the rss_basic_showpage function is called and a JavaScript file is included using the module_add_js. This function inserts the following into your site's header when the module is accessed:
<script src="/your_site/modules/rss_basic/js/rss_basic.js" type="text/javascript"></script>
Note: The inclusion of a JavaScript file is not necessary for making an Admin page.
The most important part of creating an Admin page, is restricting access to anyone other than the "god" user. This is the function called when the RSS Basic module is accessed:
function rss_basic_showpage(){
global $main_smarty, $the_template;
force_authentication();
$canIhaveAccess = 0;
$canIhaveAccess = $canIhaveAccess + checklevel('god');
if($canIhaveAccess == 1)
{
$navwhere['text1'] = 'RSS Basic';
$navwhere['link1'] = URL_rss_basic;
define('pagename', 'rss_basic');
$main_smarty->assign('pagename', pagename);
$main_smarty = do_sidebar($main_smarty, $navwhere);
$main_smarty->assign('tpl_center', rss_basic_tpl_path . 'rss_basic_configure');
$main_smarty->display($the_template . '/pligg.tpl');
}
else
{
echo "Access denied";
}
}
It is almost identical to the bookmarklet_showpage function in Case Study 3 except for the addition of force_authentication() and checks to determine whether the user is allowed access to the page or not. If permission is granted, then the rss_basic_configure template file is displayed, surrounded by the header, sidebar and footer present in pligg.tpl.
Note: Before starting your own module, please read the sections on #Module Security and #Custom Module Hooks.
Working with the database
- Accessing the database during module installation
The install file in each module is the place to create new database tables, add new fields or perform other operations that are only required when the module is installed.
In the module's name_install.php file, SQL commands are assigned to three possible elements of the $module_info array which is passed to /modules/modules_libs.php for processing. They are db_add_field for adding new fields, db_add_table for adding a new table, and db_sql for any other SQL command. Here are some real examples of each one in use:
RSS Basic module using db_add_field:
$module_info['db_add_field'][]=array('users', 'user_import_rss', 'VARCHAR', 128, '', 0, '');
Akismet module using db_add_table:
$module_info['db_add_table'][]=array( 'name' => table_prefix . "spam_comments", 'sql' => "CREATE TABLE `" . table_prefix . "spam_comments` ( `auto_id` int(20) NOT NULL auto_increment, `userid` int(20) NOT NULL default '0', `linkid` int(20) NOT NULL default '0', `cmt_rand` int(20) NOT NULL default '0', `cmt_content` text character set latin1 collate latin1_general_ci NOT NULL, `cmt_date` timestamp NOT NULL default CURRENT_TIMESTAMP, `cmt_parent` int(20) NOT NULL default '0', `cmt_name` text NOT NULL, `cmt_email` text NOT NULL, `cmt_website` text NOT NULL, PRIMARY KEY (`auto_id`) ) TYPE=MyISAM;");
Submission Approval module using db_sql:
$module_info['db_sql'][]="insert into ".table_prefix."misc_data (name, data)
values ('Submission Approval', '" . Send_From_Email . "')";
Notice that the tables are accessed using table_prefix before the table name. In some cases, it may be possible to abbreviate this to table_name as in this example from the Submission Approval module:
$module_info['db_sql'][] = "alter TABLE `" . table_links . "` change link_status
link_status enum('discard','queued','published','abuse','duplicated','pending') NOT NULL default 'discard';";
- Using the database within module functions:
SocialWebCMS uses ezSQL to make it fast and easy to use the database in the module's name_main.php file.
Important: In the function you wish to access the database from, be sure to include:
global $db;
Here are some real examples of how modules access the database, but please see the ezSQL documentation for details.
Live module:
$number_of_items = $db->get_var("SELECT var_value FROM " .table_config ." WHERE var_name = 'items_to_show'");
Block Discarded Stories module:
$story = $db->get_row("SELECT link_status FROM " . table_links . " WHERE link_id = '" . $link_id . "'");
RSS Import module:
$feed_links = $db->get_results("select * from " . table_prefix . "feed_link where feed_id = " . $feed_id);
Simple Messaging module:
$db->query('DELETE FROM `' . table_messages . '` WHERE `idMsg` = "'.$key.'"');
Module Security
It's important that input and output from your module is sanitized to prevent exploitation by hackers. By using SWCMS' built-in sanitize function, it is easy to add a layer of security to your module.
Examples:
$username = isset($_GET['username']) ? sanitize($_GET['username'], 3) : '';
if(isset($_REQUEST['view'])){$view = sanitize($_REQUEST['view'], 3);}
$user->extra[$thefield['name']]=sanitize($_POST[$thefield['name']], 3);
The sanitize function is in /libs/html1.php. The function consists of four different types of sanitation. The examples above all use sanitation method 3. Methods 1 and 2 are rarely used in the latest version of SWCMS, but method 4 is very common.
Sanitation types 3 and 4 both filter out html tags and add slashes to try to help prevent mysql injection attacks. Type 3 also uses htmlentities to help prevent XSS.
Basically, if you're going to assign a value to Smarty for output to the browser (or do an echo) you should use method 3. If you're going to save to the database or do some testing (if / while / for / etc) then you use method 4.
Custom Module Hooks
Wherever possible, we encourage the use of existing module hooks in core and template files. However, you might find it necessary to create new hooks in order to achieve the aim of your module. When this is the case, you will need to write clear instructions so that users can add your new hooks into their files.
As Social Web CMS grows, we hope to incorporate new module hooks into the standard SWCMS files to simplify module installation and open new possibilities for module developers.
When creating new module hooks, please follow these naming conventions:
- Template hooks:
{checkActionsTpl location="tpl_filename_position"}
Examples:
{checkActionsTpl location="tpl_profile_center_bottom"}
{checkActionsTpl location="tpl_submit_step_2_pre_extrafields"}
{checkActionsTpl location="tpl_admin_user_show_center_post_killspam_link"}
- Core file hooks:
// module system hook
$vars = '';
check_actions('filename_position', $vars);
Example:
// module system hook
$vars = '';
check_actions('submit_post_authentication', $vars);
In some cases, it may be necessary to pass values to your module. These should be stored as an array in $vars.
Example:
$vars = array("url" => $url);
check_actions('submit_validating_url', $vars);
Sometimes, you might need to work with the value returned from your module.
Examples:
$vars = array("url" => $url,'linkres'=>$linkres);
check_actions('submit_validating_url', $vars);
$linkres = $vars['linkres'];
$vars = array('is_spam' => false, 'url' => $url, 'top_level' => $top_level, 'domain' => $domain, 'subdomain' => $subdomain);
check_actions('link_domain_spam_check', $vars);
if($vars['is_spam'] == true){
$this->valid = false;
return;
}
Useful Resources
- Template Lite - Learn the syntax for editing SWCMS template files.
- ezSQL - Learn how SWCMS accesses and manipulates databases.
- Module Forum - Discuss modules in the SWCMS Module forum.
