Reserved for future use.
Credit to Cent for this information:
- loads the modulename_settings.php file which has all of the definitions.
- include_in_pages is an array with all of the pagename(s) the module should work in.
- do_not_include_in_pages is an array of pagename(s) the module should not work in. include_in_pages can be ('all') and do_not_include_in_pages can be ('submit') which makes life pretty easy.
- module_add_action('external_name', 'internal_function_name', 'variables')... whereas external_name is the name placed in .tpl files such as check_actions('external_name'). internal_function_name is the name of the php function that should be triggered in the modulename_main.php file.
- include_once(mnmodules . "moduledirectory/modulename_main.php) just loads all of the PHP functions for the module.
- module_info['name'] is the name of the module for the module manager
- module_info['desc'] is the description
- module_info['version'] is the version number
- [i]module_info['requires'] is an array of any dependent modules required (pass/fail)
There are PHP functions which are called, when needed, from various templates. You will need to declare globals for certain variables that you will need access to outside of the function like $db (for the database), $smarty and $main_smarty (for smarty variables -- to set or retrieve values) and any other variables as well like $linkres (if needed).
The module's readme file. I've been trying to make them easier to understand and with step by step instructions for installation and configuration.
Here is where you define all of your module's variables.
- define('modulename_path', '') - path to your module
- define('modulename_plugins_path', '') - path to plugins your module uses (if necessary)
There is also a section called if(is_object($main_smarty)) which allows you to send variable definitions back to smarty. I used them in the imageupload module, but I dont actually use them. However, I can see how they could be pretty powerful as it allows you to send back variables called set from within the module itself.
That's pretty much all I know. I believe module_add_action_tpl would in some way allow you to include say an HTML form within a template. Like, I believe I could have used it to automatically include the "Select JPG file" file attachment using the module instead of having to use enable_extra_fields. This would allow people to turn off the module, and essentially turn off the ability to upload image file with an entry. As it stands now, if you turn off the module, the form fields are still present even though they don't actually do anything.
Pligg delegates control to the a module in three ways: using code hooks, using template hooks, and by direct references from the template. See this page for more information:
How to Create Modules in Pligg
To make a change in a Pligg site, it is critical for the developer to decide whether it should be a change to their site module, or a change to Pligg itself. If it is a change to the core functionality in the underlying platform (Database APIs, Security Issues, Code Improvements, etc.), that would be useful to any kind of site that uses Pligg, then that change should be made in Pligg, and submitted to Pligg, as a Pligg developer, for inclusion in the next Pligg release.
A recommended method is to work with a copy of Pligg checked out, and a copy of your site checked out, each right next to each other in your development environment. Periodically, you can synchronize the working copy of Pligg with the repository, to check for updates. If there are any updates, also compare Pligg and your site in a comparison tool, and incorporate the Pligg updates into your site. If you need to make any updates to Pligg, make them in your working copy of Pligg and then commit them to the repository.
If a change does not apply to any site that will use Pligg, but it applies to your site only (for example, a change to the your template, a change to your language file, or a change to code that is specific to your site), then that change should be made in your module (or template), not in the Pligg core, if at all possible.
If it seems necessary to change Pligg core code in a way that is specific to your module, please keep the following, important suggestions, in mind:
- Most parts of the Pligg core code, call module hooks. The part of the code you want to change may already call a module hook. If so, simply incorporate your change through that module hook instead of the Pligg core code
- If you need to replace core functionality, then you may be able to do that by instructing PHP to exit after it processes your module hook, instead of continuing to execute the code that would have come after the hook in the core
- If there is no hook in exactly the place you want to make a change, then look around a little. Often the change can actually be made from some other part of the code, where there is a hook.
- If you are certain that there is no usable hook, maybe there should be! Strongly consider adding a hook to the Pligg core code and using it for your module instead of adding your own code to the core. Chances are, if you needed a hook there for your module, other people would probably find it useful for their modules, too.
- There is sort of a universal hook that executes at the beginning of every Pligg user script. If the particular script you want to inject a change into does not have its own hooks, then consider using the universal hook, and checking the current script name, to know when to call your additional functionality.
- Remember that core code changes, for a developer, are a last resort! (they can cause inconsistencies, conflicts, duplication of effort, forks, and other such headaches). If all else fails and you absolutely must, at least temporarily, make a core change on your site, please mark it with a unique code (like your initials or username), so that it will be easy to find and distinguish later.