Add the point module type

[pupi1985]

This should be a simple implementation to a new module type (point) that would allow plugins to change user points.

The module is a class that knows how to calculate points that should be changed by the plugin. It needs to be able to update points for a single user (usually the logged in user) and for a set of users (in order to be able to recalculate points).

Plugin developers will need to manually call the qa_db_points_update_ifuser() function in order for point recalculation to be run (after the plugin performs some action that would require points to change for a user).

Location of the abstract classes and interfaces is unclear to me so I added them in the Q2A/Plugin pseudo-namespace.

Note I tried to focus on simplicity for the plugin developer so I decided to abstract them from writing core-related SQL so they just receive known user ids an operate on their own to fetch the points. This ads a little extra work for the core but I think it is simpler this way and also more secure than allowing plugin developers to directly inject SQL inside a dynamic query.

This kind of module should be quite useful for already existing plugins and should open a door for many new kind of plugins. It also should be the answer to a lot of questions in the Q2A forum that request a way to "pay in points" for a given action.

[svivian]

Looks good. Since this uses a different structure to other plugin types we'll have to consider the best approach. I'd like to move all the plugins to a more standard format like you've done here, but it may have to wait until the next version when we can use namespaces. I don't want to have a mess of completely different plugin formats, nor have people start creating plugins in one format only to change it in the next version. But I do like the general idea of having an interface for the plugin type, that can certainly save a lot of method_exists calls that we have currently.

I've also been wondering if many of the plugin types can be replaced by a more generic Event plugin system. For example instead of filter modules, an event is fired after a question is submitted (but before it's saved in the database), and an event plugin could intercept that event. Or for a CAPTCHA module, an event fires when we're about to create the captcha, allowing a plugin to intercept.

[pupi1985]

people start creating plugins in one format only to change it in the next version

I might be missing something here but I think there shouldn't be any issue with that. I mean, the only difference between any other module and this one, from a plugin developer perspective, is extending/implementing the abstract class/interface. Extending the abstract class is optional. Implementing the interface can still be avoided as the core will just call a method in an object, no matter what class it is, as long as it has the method the call should succeed.

This means that in order to implement this module, developers just need a class with 2 methods defined, which is exactly the same as modules such as the editor one in which documentation states The PHP class for an editor module must contain the following functions (all are required).

Even if the idea is to change how plugins work in a near future, I don't think this should be an issue at all and the plugin will generate the same impact as if it worked in the old-way. Furthermore, not documenting the abstract class or the interface will allow them to be renamed without any impact at all.

I don't want to have a mess of completely different plugin formats

I understand this comment is more related to the core rather than plugin developers and it is a good point but I don't think this is a showstopper either. If you consider it is, then, I think it is just a matter of removing the interface and the abstract class. Then, the documentation will state that both methods are required (the same as the editor module) and could suggest a default implementation for one of them (the one in the abstract class). I can update the code to have a similar structure to the other plugins, just let me know.

that can certainly save a lot of method_exists calls that we have currently

It is true the interface will save those method_exists calls. But keeping the same idea as before, specifying that all methods are required in the docs should also serve the same purpose.

many of the plugin types can be replaced by a more generic Event plugin

This might be a bit unrelated to the PR but here are my thoughts.

I think so. They are just hooks. I haven't gone through each method of each module but most likely there are two type of method calls: unidirectional and bidirectional. The former are just methods that get notified and don't interfere in any way with the processing (just like event modules). The latter are the ones that could. How each method affect the processing will have to be analysed one by one.

For example, in a page module, the first page that matches a given match_request call could be called which will not allow all match_request methods on the rest of the modules to be called (in this case modules affect each other and could even prevent their execution). The opposite example is the process module which is just a slightly objectified approach to the event module. I think the event and the process modules could totally be merged into one.

However, I'd reconsider rewriting how that would work: having a single entrance for all events doesn't seem to be a good idea and forces each event module to check for the event called, which is inefficient. I believe there should be a kind of event manager at a core level that could have a list of the possible events (I prefer the word hooks) and for each event a list of callbacks. Plugins will register the callbacks they want for each (predefined or ad-hoc) event, which will be just a unique string that the core will use to identify the event and the key for the list of callbacks, and the core will just ask this generic event manager to fire all the callbacks associated to a given event id in a given time.

Again, if a similar behaviour can be applied to other module types, I think it would require them to be analyzed one by one.

[pupi1985]

Hey @svivian.

When you have a chance, can you take a look at this again? Many users in the Q2A forum are looking for point exchanging and having this implemented will considerably ease that or even make it possible.

I'm open to adapt the code to whatever style you consider appropriate. If the idea is to eventually add this to Q2A 1.9, I can adapt the code to support PHP 5.3 features.

BTW, although I believe this kind of feature should be added to the dev branch, having this feature in the bugfix branch, as a patch, won't hurt at all. Maybe it is a good excuse to see it in action before a minor release. What I mean is that having the interface written in stone will complicate backwards compatibility in the future.

Would it make sense to release this as a test feature to receive feedback from developers and improve? Then, in that case, no commitments will be made regarding the interface.

The rationale for this request is that this feature is not for the end user but rather for developers. So in order to see the result of the feature time will have to pass for developers to update their plugins. The more time it passes, the more time will be needed to adapt the code to support the interface updates that might come in the future. So the more final the interface, the better. Just my 2 cents!