As a developer or theme builder, you are welcome to submit your code as a concrete5 package and sell it on our Marketplace for any price you want. It gives you a chance to make some cash and to gain credibility as a person who knows concrete5, which is great for building client relationships.
concrete v5.5 introduces some UI changes. Be sure you've been through this guide before you submit your work.
The Absolute Basics:
These are the rules you need to know.
- The theme or add-on is packaged correctly and installs cleanly. The best way to test this is to create a fresh install of concrete5 and install it there. If you have never built a package, read the documentation about packages and download a free add-on or theme to see it in practice.
- The package has an icon. The correct file is a 97x97 transparent .png with a 4px rounded corner named "icon.png". This psd file can be used as a template.
- You have full rights to all code and associated assets. This is a serious thing and you are responsible for it. The marketplace officially supports the MIT, GPL and our own concrete5 Marketplace License. Any compatible license will also work.
- Realize that this is a product that you will have to support. We require you to provide support to customers for at least 30 days after they buy the add-on.
Barriers To Entry:
Watch out for these problems.
- Errors. Avoid submitting something with known bugs. Work out the problems on the forums or in github / your code host of choice. You will expose yourself to a wider audience than trying to solve bugs on the PRB.
- Licensing issues. Do you actually have rights to the code you pulled off of github? Do you have written consent to make a theme based on a professional sports team? This goes for any assets your add-on uses, if it is trying to capture the "look and feel" of a site or OS.
- Use a distinct name. Our library of add-ons is growing so it's a good idea to have a personal acronym or other "tag" you can use on your packages. Your package can't be named the same as another package already available in the marketplace. For examplae: aaa_rad_gallery instead of rad_gallery. Use non-generic names for your blocks, classes and so on.
- Confusing experience. Make sure your add-on is described accurately on its marketplace page and at least try to keep your grammar and spelling in check. This also goes for the add-on itself. For the time being this also means that your add-on will have to be in English to get reviewed.
- No documentation. Your add-on should also have some docs for it somewhere. TA potential customer will visit to get the full details on what your add-on or theme really does. Also, you will receive fewer support incidents if you have well-written docs. If you have your own site not on concrete5.org that describes your add-on more thoroughly, it's fine for the documentation page just to be a link to your own site.
- External dependencies. If your add-on needs some sort of third-party software, API keys, or it "mashes up" something, try to include those somethings and be ready to explain them.
- Code outside of best practices. Please take a look a the style guidelines and use the concrete5 API whenever possible.
- Make sure whenever you are presenting information to the user, wrap your text in the t() function. It makes your add-on available for translation. So, t("Click here") instead of "Click here".
- Use Loader::db() and its associated functions. Do not build out db calls by string concatenation.
- Use the HTML helper's addHeaderItem for calling your js and css.
- Use Loader::model and so on, do not use require_once
- Make sure your PHP files have the <?php defined('C5_EXECUTE') or die(_("Access Denied.")); ?> at the top of them.
- Use long tags: '<?php' not short tags: '<?'. Not every server setup supports the short ones.
- Get with the times! Concrete5 version 5.5 added some interesting UI changes, among other things. Run through this guide to make sure you're taking advantage of the new features.
- Concrete5 uses the jquery library. Using something else is not forbidden but not encouraged.
- Extraneous files. If you are using extra libraries or assets, that's cool, but your add-on does not need every example for rad_gallery.js included. Mac users, this includes "dot underscore" files.
- One last thing. There are specific requirements for themes and add-ons. So check what you're building against those as well.
A few tips to help you succeed.
- Start your version at 0.9.0. As you update the PRB submission, increment the third digit. When you get it approved, put the version at 1.0.
- Chime in when you upload a new version to the PRB. Don't be afraid to be specific about what you updated.
- If the demo site for your add-on or theme is super-awesome, keep in mind that some customers will expect your product to turn their site into the demo site.
- Be realistic about the required version of concrete5 for your add-on. If you developed it on the current version of the core, do you really want someone installing it over code from a year ago?
- Please don't sell your add-on outside of concrete5.org after you have submitted it here. We don't do any Apple-style legal enforcement of this, but the Marketplace is the fuel in the concrete5 engine and hosting your work here funds development of the core.
- Join the team! Going over other people's add-ons and themes is a great way to learn about cocnrete5 and web development. Plus you're on the inside track for what's new and exciting.
It's always everywhere.
- We do keep 25% of the add-on's price to keep concrete5 afloat.
- If you neglect to support your add-on, or your add-on does not do what it says, we will refund the customer. Refunds incur a 10% penalty. This means that if you create an add-on that will cook breakfast for $15 and your customer tells us they aren't eating a Denver omelette and you won't even dice some bell peppers, you owe us $1.50.
Why All The Rules?
Shouldn't concrete5 have as many add-ons and themes as possible, as quickly as possible?
We absolutely want to have an abundant marketplace representing the interests of our users and developers. That said, we do not intend for the marketplace to be a code repository; much less a jungle of broken, unsupported garbage.
The Peer Review Board is staffed by volunteers from the concrete5 community who have full-time lives outside of concrete5. Many of the best add-ons and themes are the product of their work for real-world clients.
The hope for the marketplace is that a majority of that work is either a client-ready application or a tool that meets some need of the web professional. So what you submit to the PRB should be something that you feel is prime-time ready. It's kind of a unique feature of the concrete5 community that you get to have your product assessed by a competent group of people doing the same work you are and hear their perspectives before going to market with it.