Plugin Code Requirements

1st Official Post

    In the process of converting my existing very large SMF forum (80 million+ posts) I've had to write some new plugins in addition to a bunch of conversion scripts and an extended version of the SMF importer for Burning Board (some search terms in there to help others find help for their related problems. :) )


    My question here relates specifically to the plugins I created. What kind of requirements are placed on how a package should be created? Ex) Does it need to conform to a coding style, be a specific functionality type, pass a certain performance benchmark, pass a security check, or does it just need to follow the object oriented nature of WBB (I.E. classes are open to extension but closed to modification)?


    The first plugin I'd be submitting is a "Fancypost" BBCode:
    - It adds a BBCode class file
    - The BBCode allows users to send in any number of css attributes to apply to the content inside the BBCode tag
    - Only specific css attributes are allowed
    - The values of those attributes are sanitized and escaped before use
    - It adds a bbcode and bbcode attribute to the appropriate tables using an xml file


    Any guidance or links to a related threads that didn't turn up in my searches would be much appreciated!

    • Official Post

    Hi


    these are the most important points we check for when auditing the plugins:

    • There should be no security issues (esp. the use of Prepared Statements / Parameterized SQL Statements is a must). If we spot a security issue the plugin will be rejected, if not we expect timely updates once the author becomes aware of the issue.
    • I should scale (e.g. 1+n Queries must be avoided at all costs)
    • It should fit into the overall UX of Burning Board / Community Framework: Use existing UI elements, use existing language items, orient yourself at the language used by us
    • It should provide value: Any functionality that's trivially available from within the ACP will be rejected. If there already is a plugin providing the exact same functionality it probably will be rejected.
    • It should respect software licenses of third party code included (fairly obvious)


    Plugins don't need to follow a specific coding style, as long it is readable and understandable for the person checking the plugin. They don't have to be perfectly object oriented or MVC confirm either, as long as the separation is not completely broken.


    Basically the process is an individual process tailored to the specific plugin and author. There are some issues that only apply to certain kinds of plugins and a developer that's new usually receives a more detailed review.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login