Skip to content
mr.bob templates targeting plone
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


Plone templates for mr.bob

This distribution contains some templates to use with mr.bob.


The primary focus is creating a small set of high quality templates for plone development. The first ones on the list are:

  • basic distribution template (a two namespaces distribution).
  • buildout template (with all the bells and whistles for development and testing.
  • diazo theme template.


  • Creates the distribution folder structure
  • profiles folder and files within it
  • Set ups and other top level files (LICENSE, HISTORY.rst, README.rst)
  • general configure.zcml
  • locales folder
  • browser folder
  • permissions.zcml with a dummy permission
  • upgrades.zcml and
  • and tests folder
  • minimal buildout with develop, testing and coverage report
  • travis-ci integration

What's missing:

  • resources folder (static folder registered with grok)
  • jbot overrides folder XXX override something like the portal logo or so
  • top level docs folder (?)
  • add tests that check the resource folder
  • add tests that check the browser view
  • add tests that check the jbot override


Not even started, contributions welcome.


Same here as plone_buildout, contributions welcome.

Code and contributions

Code is hosted on a github repository, so fork away and make pull requests to improve it.

Contributions, with patches and/or suggestions, are always welcome.

Code conventions

Being picky as I am, everything code on the distribution and generated by the templates should pass pep8, pyflakes, contain no superfluous spaces and any tab at all anywhere. Life is better when it's free from distractions.


All major features (new templates, refactorings) should happen in branches, which are expected to be constantly rebased to master branch.

Small patches and changes go directly to master branch which at some point a stable branch catchs up (rebases to) to make a new release.

Just after the release master branch splits again from stable and continues to evolve to merge new feature branches that are kept in separate branches.

Given that, the only branch that is guaranteed to be always available and without forced (rewrited) updates will only be stable branch.

Keep that in mind when forking and making feature branches.

You can’t perform that action at this time.