- System Apps
- Core Apps
- Premium Apps
- Template Apps
- Language Apps
- Tailored Apps
- Studio Overview
- Adding Apps
- Paid Levels
- Remote Storage
- DB cluster
- Code Convention
- Code Quality
- Common Mistakes
- Profiles structure
- Creating a Module App
- Creating a Template App
- Creating a Language App
- Creating a Payment Provider Integration App
- Creating an App Auto-update Script
- Studio Apps
- Handling Date and Time
- Browseable categories
- Search Forms
- Images Transcoder
- Video Transcoder
- List of personal data and sensitive content in the DB
- Auto generated documentation
During wring the code always keep in mind the following things:
- this is Open Source product and the code is visible to anyone, we have to always show quality, readable, consistent code. In the future your code can be used for copy&paste, and be the base for other modules.
- check if your code have no unused parts, so it will not confuse other developers.
- make sure that the code is executed the most effective way, since UNA can be used for heavy loaded sites.
- don't write duplicate code, because in this case it will be difficult to change and support such code in the future.
- code must work in different server environments, such as different OS(Windows, Linux, etc) and Web-servers (Apache, Nginx), some PHP modules maybe disabled or even can't be added.
Every commit must be atomic and include short description of the committed code and number of issue in the repository in the form of #123.
The name of the module in every file should be named without spaces, if readable module name contain spaces it can be added after the name without spaces, for example:
@defgroup QuoteOfTheDay Quote of the Day
Make sure that the comment in the beginning of every file is correct. In many cases files are copied from other modules and this comment is left unchanged.
In the working repository module version must have DEV postfix, and for UNA modules module version number matches major UNA version, for example 9.0.0.DEV. Also compatibility in working repository must be 9.0.x. Compatibility and version is changed when module is released.
Make sure that the code is written using UNA code convention - https://github.com/unaio/una/wiki/Code-Convention.
Don't leave unnecessary commented code.
To get content of the URL, use
check*function based on the checked action.
It's better to define module name in install.sql (
SET @sName) in the beginning of the file.
Be careful with grid objects, it can be accessed directly, so it's important to set correct
Make sure that the sum of widths of fields in
sys_grid_fieldstable is 100%.
Write descriptive comment for every
service*method, example of comments for
service*methods can be seen in
BxEventsModule.phpfile in Events module.
If you use some of Base classes for your module, make sure that all classes are derived from the classes of the same base module, if there is no reason to do it otherwise.
Don't add new classes to
default.lessfile, if adding is necessary discuss with other team members.
Don't create indexes longer than 191 for
utf8mb4fields, they will not work on InnoDB, as an example the following code will not work properly:
CREATE TABLE `tablename` ( `name` varchar(255) character set utf8mb4 collate utf8mb4_unicode_ci NOT NULL, ... INDEX `name` (`name`) )
You need to limit field length or index length:
... INDEX `name` (`name`(191)) ...
Be especially careful with indexes for multiple fields, sum of all fields must not be greater than 191.
Don't use references for method's arguments in modules Template class.
For example instead of such method:
function getLotsPreview($iProfileId, &$aLots, $bShowTime = true)
Try to compose the code, that will work without the reference:
function getLotsPreview($iProfileId, $aLots, $bShowTime = true)