On this page you will find a set of code rules and general development workflow we try to impose in the coreBOS project. I strongly recommend that all developers who want to contribute to the project read these guidelines and try to apply them as much as possible. I will take them into consideration at the moment of accepting code contributions.
In general I am paraphrasing the PHP FIG - RECTIFIED, PHP-FIG Standards Recommendations, and Produccing Open Source Software, but with some minor adjustments to the reality of our code base. So anything you read there is useful.
I am open to suggestions and comments and I know this is a living document that may change as we go forward, so don't hesitate to contact me.
The best place to contact the developer community is on our gitter chat group.
The blog is mostly developer oriented and there is a lot of information here on the documentation site.
You can ask in the forum also, but don't hesitate to get in touch, we are a really friendly and helpful community.
The project lives on github and we recommend following the typical fork and pull request procedure. Read here for the exact steps.
Use the github issues section (prefered) or the Mantis bug tracker. Read here for some additional ideas.
In general the next sections apply both to PHP and Javascript code. Each has their own particularities, but we should try to be as consistent as possible.
We are currently not following this recommendation. We load the files we need using require or include from wherever they have been added in the project.
We will probably get to this in the future but it is not a high priority right now.
All development MUST be done using error_reporting set to E_ALL and we should not leave any warning nor notice in the code. They must all be eliminated.
If you run into a part of the code that emits a lot of warnings, either dedicate some time to eliminating them or send me the details and I will take care of it.
All development MUST be done using MySQL Strict Mode and we should fix any SQL commands that we create.
If you run into a part of the code that has some SQL Strict error, either dedicate some time to eliminating it or send me the details and I will take care of it.
Security is a very complex and important issue which requires a lot of dedication and time. In other words, dedicate time to studying and understanding security issues.
This is a list of things that you MUST do before executing a commit:
git diff {files} | grep dump git diff {files} | grep fatal git diff {files} | grep log
for f in {diff file list}; do php -l $f; done;
AngularJS Git Commit Message Conventions
<type>(<scope>) <subject>
another way of reading that is:
what(where) how
in this second form, the when and who are controlled by git itself, so sign your commits.
Some additional clarifications:
These are the steps to update the service worker:
fold service-worker.js > sold include/sw-precache/regen_swprecache fold service-worker.js > snew meld sold snew # make sure the update is about the files you know have changed # the typical error here is for the update to include some javascript or css code you have not committed yet rm sold snew
Always commit the service worker update in it's own commit. Do not mix it with any other changes. This way we can safely ignore all those commits when searching, or easily locate changes when needed.
We recommend and use two tools to help validating the formatting issues in PHP and Javascript files.
You can find rulesets for the above guidelines in the build/cbSR directory.
For example, to validate a PHP file you can execute:
./phpcs.phar --standard=build/cbSR file_to_validate
You could also execute this command on javascript files, but eslint is better:
eslint -c build/cbSR/eslintrc.js file_to_validate
You can use phpcbf and the eslint –fix to get changes applied automatically
I actually bundle phpcs and phpmd in one file (checkfile) that I use to validate my php files:
echo ====== echo $1 echo ====== phpcs.phar --standard=/var/www/coreBOSwork/build/cbSR $1 phpmd.phar $1 text unusedcode php -l $1