Module Building Guide
The goal of this section is to document a clear, repeatable way for developers to create modules to supplement and enhance the operation of the web2project system. There are numerous code samples included because showing is often more important than explaining. As certain non-core functionality becomes standardized, some of it will be added to the core system itself. This will not only simplify Add On development but also make sure that all modules adhere to the same standards and logic flows.
Failure to follow the recommendations in this section can lead to non-functioning modules, brittle code prone to breaking, security vulnerabilities, and even bad hair days. None of these are pleasant.
- A module MUST follow our standards regarding Naming Conventions for variables, methods, etc.
- All input MUST be filtered before it is used in ‘'’any’’’ capacity to help prevent security vulnerabilities such as SQL injection and Cross Site Scripting attacks.
- A module MUST NOT have raw SQL statements.
- A module MUST NOT have references to the w2p_Database_Query class/object outside of the module’s core class and (optional) subclasses.
- A module SHOULD use core web2project function/method/API calls instead of copy/pasting logic into your own module.
- All code within a module SHOULD adhere to the formatting specified by the PSR-4 Coding Standard. To evaluate your own code, please use Code Sniffer.
Table of Contents
Hooks are how we provide access to specific features and functionality in a standardized way. While no hooks are required in your custom module, they’re generally useful.
Available Since v3.0 (September 2013)
- Workflow Hooks (pre-create, post-create, pre-delete, post-delete, pre-load, post-load, pre-store, post-store, pre-update, post-update)
Available Since v1.1 (September 2009)
- Calendar Hook
- Cron Hook
- Search Hook