Why we've created "yet another cms"
We've developed the play-cms out of our needs for a large client project (online shop for a major swiss publisher). Play framework was the perfect fit, but there is no cms around. The requirements were too specific for a generic system, yet the client's web team required a good deal of cms functionality. Our main priority was to create a flexible play-based cms that supports you instead of standing in your way when developing a custom client solution. And since it was not our first cms, we gave it a spin.
When to use the insign play-cms
- If you need cms capabilities in your play project
- If your app needs authentication/authorisation
- If you want a deep and ready-to-use integration between cms and your custom play application
When NOT to use insign play-cms
- If you need a full-blown cms solution with enterprise features such as Magnolia or Alfresco
- If you need workflow capabilities (although you could enhance the play-cms in that direction)
- .. and you're ok to not use the Play framework
- Powerful yet light-weight cms - made for custom projects that require cms capabilities
- Content block based architecture - basic blocks provided - add your own blocks
- Comfortable authoring: WYSIWYG, frontend controls, drag and drop content blocks on the page - or pages in the navigation tree etc.
- Time-based publishing and unpublishing
- Role-based permission system:
- Manage users and roles from the backend
- Assign inheritable permissions to content blocks and pages
- Use these permissions everywhere within your application (annotation-based controller actions, or in code)
- Integrate with your own user provider
- Various ways to integrate your application
- In-page: Create custom content blocks that can be placed everywhere throughout the site
- Whole-page: Create whole pages (where you control the url routing) and integrate cms features such as the navigation
- In-content: Create custom filters that replace variables used in the wysiwyg editor with your own dynamic data
- Powerful and customizable caching patterns: Page-level caching, block-level caching, individual cache expiry settings etc.
The insign play modules are based on JPA2 for easy and powerful ORM-based persistence, and can use any JPA2-compatible storage backend (we use MySQL).
This is a typical project structure:
Other noteworthy components:
- Fulltext search: Elastic search/index provider integrated, custom provider(s) can be added
- WYSIWYG editor: TinyMCE
- Media library: Optional MoxieManager provider, or add a custom provider
- Security: play-auth is based on Apache Shiro and allows fine-grained, role-based permissions to content blocks
- Java 8
The insign play-cms consists of the following modules:
Content management system
Authentication & Authorisation framework, based on Apache Shiro
Common tools & utilities used by all modules
Default backend admin theme
Note: The theme used is Metronic
CMS Demo Project (play-cms-demo)
To help you getting started with play-cms, you can clone/fork our Demo-Project found here: https://git.insign.rocks/open-source/play-cms/demo (see its README for the various installation methods).
Read more about the Demo-Project in the CMS-Demo Documenation
How to contribute
Missing a feature? Found a bug? Code contributions are very welcome! To contribute, please fork the repository and create a PR with your code.
Alternatively, create a bug report or feature wish issue using the GitLab issue tracker.
Feel free to contact us in the play-cms community for further discussions, questions etc.
play-cms is licensed under the Apache 2 license.