There can be a big difference between an addon or theme that works beautifully in the context of the site it was developed for and the same package installed on another site.

In the wider world of the Concrete CMS Marketplace it may not be sufficiently robust or user-proof outside of its home environment. What makes sense to you as a developer may be cryptic to others. Here we run through some of the common technical issues.

Even if you are not developing for the marketplace, this may help you write more robust code.

Make the reviewer's job easy

Follow the guidelines below, setup test accounts, minimise the amount of additional work a reviewer needs to do to review and test your addon or theme. 

PHP Version

If you develop on the latest php version, check you have not used any php syntax or functions that could break when run on older php versions. If you develop on an older php version, check yor code will not break when run on the latest php version.

Concrete Version

Make sure your package installs, works and uninstalls on the latest Concrete CMS version and also on the minimum version you specify in the package controller. Be realistic about the minimum version. Do you really want the overhead of maintaining compatibility that far back?

Errors and Warnings

Perhaps your production server is set up to be as forgiving as possible, to continue running despite minor errors and warnings. However, you can't be sure your users will be running such a benign environment and reviewers probably won't be either. So similar to php version, you will also want all the errors and warnings enabled throughout your development server.

User inputs

You may be careful about inputting correct values, but site owners or even site visitors may not be so careful. Some site visitors may even be malicious. Typical weaknesses include:

• Non numeric values breaking a numeric input field.
• Long text inputs being too big for fixed length database fields.
• Incorrectly quoted or unescaped text breaking an html tag on the page it is rendered on.
• Empty inputs causing subsequent null object or zero errors.
• A over-long or too big input value causing something to overflow or to keep looping effectively forever.
• Script or SQL injection - where an site visitor can input text that, when rendered later, inserts script or SQL that does something they should not be allowed to do.

Look critically at inputs in dashboard pages and edit dialogues. When an input is open to a site visitor, look at it extremely critically.

A related issue is uneconomical database fields. Don't be tempted to declare every database field as Text as to avoid any risk of overflow. As a general rule, database fields should be of a type and size relevant to their purpose and no more.

User Interface

There are conventions in the Concrete user interface. In most cases, marketplace packages should follow to those conventions. If the convention is for a blue button, don’t try and design an edit dialog with a rainbow striped button.

Text Translation

Your development may be just in English or your own language, but for the marketplace all packages must support translation into other languages. This means that all interface text strings must be written in English with t() functions wrapped about each string. You don't need to provide any translations, just wrap the t() functions about all text strings so that the Concrete core can associate them with translations.

Actual translation files should be outside of your package and managed through https://translate.concretecms.org/. If you would like to be involved in translating packages or the core, you can join the translation team and upload your translations there. 

Use Concrete classes and helpers

The general rule is that if there is a core class for doing something, you should use it, even if it appears more long-winded than a direct call to a PHP function. Common issues are PHP include statements, direct file input/output and direct use of PHP superglobals.

Using core utilities often helps make code more flexible and robust, allowing a package to be installed in a wider range of environments and protecting against known issues and edge cases.

Again, such conformance may not be important to a single development, but it becomes important when other sites use marketplace packages.

Theme compatibility

You may have developed an addon while working on a site with a particular theme. However, when that addon is released to the marketplace it could be used with any theme. As a minimum, make sure it is compatible with the core Atomik theme and it will then be compatible with many other bootstrap based themes.

For marketplace themes, follow the page area and template naming conventions established by the core themes. If the core calls an area "Sidebar", don't call it "Right" or "Left" in your own theme. Following the convention makes it easier to swap between themes and will expand the base of potential customers for your theme.

Core user interface

All theme and block template CSS styles need to be scoped to .ccm-page so they can't inadvertently interfere with dashboard styles.

Function and class namespace

Anything that provides a name visible outside of your package could conflict with something else. Names you have used need to coexist with names that thousands of other developers may be using. When two of those names collide, it can result in some hard to track bugs and consequent support requests. This can apply to PHP, JavaScript, database tables, files, and as noted above, to CSS.

In general:

• Stick to Concrete naming conventions for files and classes.
• Where possible, keep any name locally scoped. If it isn't visible outside your submission, then it can't be confused with anything else.
• If it needs to be visible outside your submission, use a prefix or wrapper of some sort. Many developers use their initials or business names, so protecting their namespace also promotes their branding!
• Don't steal other's namespaces. For example, a JavaScript file that steals the jQuery "$" magic function is doomed to cause script errors.

3rd party code

Make sure any 3rd party or vendor code is correctly licensed and you have followed all license conditions. Include all license files. Only bundle usable code, we don't need all the test cases, examples and everything else from a 3rd party GitHub repository.

Clean up after yourself

Uninstall is rarely important on a single site project. In the wild, uninstalling cleanly is very much more important. Test your package can be installed, uninstalled and reinstalled of a fresh Concrete site with default content.

Documentation

What is often obvious to you or to your directly trained customer is often not so obvious or even cryptic to others. A marketplace package needs clear instructions on how to use it. Good documentation can also help with sales.

Make the reviewer's job easy

We said this at the start and say it again to finish. Minimise the work needed to review your submission and it will get through quicker.