Fetching contributors…
Cannot retrieve contributors at this time
53 lines (35 sloc) 2.11 KB


This file is for any notes aimed at developers of Tabulate or related projects.

Revision control

We develop in Git, using Github at

Stable tags are committed to the Subversion repository, which is only used as a deployment system: trunk is stable, the branches directory is not used, and the tags directory is a mirror of the Git tags.

Version numbers

Tabulate follows the Semantic Versioning guidelines:

The version number is hard-coded at two places in tabulate.php and two in docs/ It would also be in but as trunk is stable there's no need to specify a stable tag.

The versions of WordPress that we test against are hard-coded in and the Travis build file .travis.yml.

When updating scripts, the version numbers in WordPress\Tabulate\Menus::admin_enqueue() also need to be updated (or should these just be changed to also use TABULATE_VERSION?).

Documentation generation

The main user manual at is built by the Sphinx documentation generator from ReStructureText files in the tabulate/docs directory. A primer for the syntax is available on the Sphinx website

To build the documentation locally, first make sure you've got Sphinx installed then change to the docs/ directory to run make html (or make.bat html if you're on Windows). It will put the generated documentation in the docs/_build/html/ directory.

There are various links to the MySQL documentation that should be updated when new MySQL versions are released (we always link to the most recent version).

Ideas for future development

Some possibilities:

  • Widget for FoH display of data (akin to the Shortcode).
  • File storage, for blob types.
  • Bulk changes, for modifying filtered data.
  • LaTeX output.
  • Tree/hierarchy display, for self-referencing foreign keys.
  • A cross-platform mobile app, that can connect to a Tabulate site and create records.

There may be more listed in the issue queue on Github: