I would like to start out by addressing much of the feedback and suggestions we've been receiving since Paul's blog post on MOD Author feedback. Thanks to ..::Frans::.. for starting such a lengthy discussion.
As many of you know, the MOD Team is highly interested in the feedback from our MOD Community, both it's users as well as the MOD Authors. Especially the MOD Authors, as you are our driving force behind the phpBB MOD Industry. So we take all of your suggestions seriously.
Many discussions from the blog post have resulted in some changes in the way the validation process works, from Validation, to the MOD Database, and the future MOD Database. Subscribing to MODs to stay informed of updates is one of those features that was requested that Paul graciously implemented. We are working on some documentation what will help MOD Authors understand the Validation process better
We will be publishing a page soon that will list everything a MOD Validator looks for when validating the MODs as best as could be written down... the entire validation process is very extensive, so it's difficult to contain it all in a single page and still make it worthwhile to read.
From here forward, major MOD Team Announcements will be posted in the Announcement forums instead of hiding in the MOD Writers Discussion forums. i.e. such as new releases to MODX or Packaging Guidelines. Many of you probably noticed an increase in the number of MOD Related announcements recently. One goal we have is to increase the communication quality and quantity between the MOD Authors and the MOD Team and make the Validation process a bit more transparent as well.
- Tell us about the MODs in Development Forum
- That forum will NOT be policed in such a way that we validate MODs within it. Of course, rules must be applied, but we (the MOD Team) do not, and will not test MODs in that forum, we do not do any pre-validation process. That is up to the MOD Author and the users that download the MODs from that forum. To get a MOD validated, one must submit to the db to be validated.
Compatibility
Best practices, what do we mean when we say that? It's not about how you code. Lets say you are creating a MOD, your goal should be to make that MOD have the LEAST amount of core code (phpBB3 default files) edits. Acyd Burn's Attachment Mod for phpBB2 is a very good example of this because it had very few edits to the core files.
One method you could do is include and file and then call functions where ever you need to add the funcationality of your MOD. This is not always possible.
You should be including files with functions and not having the user edit in huge blocks of code or functions, or classes into phpBB3 core files. Keep everything as simple as possible, and you will achieve two objectives:
1) you will make it easy for yourself to update the MOD, now if you release an update for your MOD, your user should simply replace the files, whereas if you edit in a bunch of code, you have to make them edit it again with your updates. That is never preferred... replacing files is always a much better method of updating.
2) you will make it easier for the user to update their board to the next version of phpBB. This is call compatibility.
Scalability
Scalability is coding in such a way that it is easily expandable and so that it can handle higher traffic loads. That way your code will last for years instead of months. Scalability is tied in quite a bit with optimisation and performance. So how can you code in such a way to ensure scalability? ... well, and this again, is tied in with optimisations. For example: adding SQL Queries to loops is BIG NO NO. Why? well, the bigger the loop gets, the more queries you will be running. It becomes a problem when you have 300 queries for every page load. With a couple users it is fine but imagine 50 or even 5,000 users on your site at the same time
Security
The first thing to do as a MOD Author is to make yourself aware of the security within phpBB, that is XSS (Cross-site scripting), CSRF (Cross-site request forgery), and SQL Injection. All of these are surprisingly simple to prevent, but you as a MOD Author must first educate yourself on what they are and how they work. Only then can you become better at ensuring you code in such a way to prevent these types of attacks. You can never be to sure or too safe. You can never believe that you code perfectly securly.
First, SQL Injection, one of the easiest things to prevent against. What is it? according to Wikpedia: SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. To prevent SQL injection you need to know how to use request_var and dbal::sql_escape correctly.
Coding Guidelines
The coding guidelines should be followed to ensure easy readability of code and everything is consistent.
- Are there any specific things I need to do for UTF-8 compatiblity in my MODs?
- 1) use the third parameter of request_var for strings ...
request_var('foo', '', true)
2) use utf8_normalize_nfc() on strings
Normally the two are done together like this
$foo = utf8_normalize_nfc(request_var('foo', '', true));
