Submit to Marketplace
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. Check out this video for an overview of how the review process works:
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. For users of Inkscape and other vector graphics programs, check out this svg file.
- 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. If your work needs custom licensing, we will have to review that on a case by case basis.
- Realize that this is a product that you will have to support. For commercial add-ons we require you to provide support to customers for at least 30 days after they buy the add-on. For free add-ons its up to you, but if we see reports of it consistently not working we will yoink it from the marketplace.
- It's our store - you're a vendor. We may choose to not include your add-on or theme. Generally we try to take an inclusive approach, but we reserve the right to politely pass on any offering for any or no reason.
- The Peer Review Board (PRB) is a group of volunteers who graciously review add-ons and themes to keep the approval process going. They are in control of you getting your listing live, so be nice. Here's the current PRB members and admin list.
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. This goes for any assets your add-on uses, not just code. Before you submit something, be sure of the following: Do you actually have rights to any third party code? Do you have rights to any assets you're using: fonts, icons, images etc. This means you need to include whatever license says you have the rights to use whatever you did not create yourself. If you are offering a third party service, make sure you have explicit permission to use this service in the form of an email from the service.
- Selling Outside of Marketplace. If your add-on/theme is wrapping a service that costs something, we may choose to not include it in our marketplace. We also strongly discourage you from selling your add-on/theme outside of our marketplace. It makes support annoying and isn't fair to the hard work we and the community put into building the core product, providing feedback through the PRB, and marketing the solution as a whole.
- Extending add-ons. An old adage suggests that it is "better to ask forgiveness than permission". This is one case where the opposite is true. If you are going to extend or enhance an existing add-on, check with the original developer beforehand.
- 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 example: aaa_rad_gallery instead of rad_gallery. Use non-generic names for your blocks, classes and so on.
- Borrowed Brands Unless you work for a brand under a formal relationship you can document, your listing should not use that brand as a primary marketing tool.
- 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.
- My Grab-Bag o' Goodness. If you're a developer with some reusable tools others might depend on, you should share those on GitHub. That way other developers can grab a copy, include it in their add-on, and know that their included code will work consistently within their add-on, regardless of what your latest version does. There are no complex external dependencies in our package system by design, not through oversight.
- Elaborate add-ons. Much like using third-party API's, if your add-on requires additional accounts, connects concrete5 to another system and so on, please create a staging site that reviewers can play with rather than putting the burden on them to spend hours configuring an environment to test your add-on.
- 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 versions 5.5 and 5.6 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.
- Abandoned submissions will be removed. Unapproved items with no activity from the developer for 30 days (uploading new versions, posting messages) will be marked for deletion and removed in 7 days without warning. You are welcome to re-submit your work.
- One last thing. There are specific requirements for themes and add-ons. So be sure to build with those in mind.
A few tips to help you succeed.
- concrete5.org community leader Johnthefish has written an excellent how-to about getting submissions approved.
- 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.
- SCREENSHOTS Screenshots get used in the marketplace view from within concrete5's dashboard. This is where a good piece of sales come from. The ideal dimensions are 400 x 400. It's a good idea not to use shots of the interface. Put that stuff in the documentation. If your add-on is not visually exciting, put a cool picture in or something. To get a sense of why you want to do this, just click the "themes" or "add-ons" link from the dashboard dropdown next "Extend concrete5"
- Be original! We do like competing solutions to the same problem in the marketplace, but please create unique solutions to those problems. If a particular add-on or theme hinges on a particular library or service, do something to differentiate your contribution. Check that the name of your add-on is different enough from existing add-ons, so add-ons refrenced in forum discussions can easily be looked up in the marketplace!
- 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 30% of the add-on's price. This goes to running concrete5.org and building new versions of the core. Thank you for helping concrete5 continue to grow.
- If you neglect to support your add-on, or your add-on does not do what it says, we will refund the customer.
- When the time comes, you can request a payout. That creates a note in a log. We check the log regularly, but not daily. Legally we commit to pay you within 30 days of your request. Practically it typically happens once a week. We pay you via paypal, to the email address associated with your account. If you need something different, work it out by PM'ing to Frz.
Why All The Rules?
Shouldn't concrete5 have as many add-ons and themes as possible, as quickly as possible?
UPDATE: We have a new listing of open-source contributions. If you have something that you think is just fun and exciting but not really a product per-se, feel free to fill in the form linked on that page and your project should get a link. Of course, there has always been our how to section, which is another place for sharing ideas.
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.