Currently, docker composer is called via an explicit process execution. Docker composer should be replaced by calls to Docker API. Indeed, the user of composer is simple enough to be replaced by a manual setup via the API.

Thanks to #16, it is now possible to configure several prototype/project templates at the same time. However, Gunilla is still missing an option to select another template than default.

Currently, 'download' action causes dependencies to be downloaded every time. Dependencies might be cached locally to prevent useless downloads. Same mechanism as Maven could be used: having a repository in user home folder, for instance '.gunilla/repo'.

Deploy = download + build_themes + install

Config is an abstraction of gunilla.json file which describes the workspace. So a Config object should not really be a singleton but rather a property of the workspace.

Dump would consist in:

• Dumping the content of the DB into a local file
• Copying data files from WP instance locally

The purpose is that it would be possible to restore the state of a WP setup after deleting and re-creating related docker instances.

Plug-in dependencies should be defined via the Gunilla file.

Currently, plugins/themes under development are mixed up with dependencies in the same folder. Source code of new themes/plugins should be clearly separated from dependencies to allow better and easier version control configuration (prevent versioning of dependencies code, etc).

A possible solution is to create a temp folder under which dependencies and developed themes/plugins are copied together before being pushed to the WP instance. The temp folder could then simply be ignored by the version control system.

Currently, executing several times enable_multsite duplicates the same line in config file. This should not be the case.

When creating a new theme prototype, a template might be provided to have starting point. A new 'add_prototype' action might be added which would take 2 arguments (options): the name of the prototype to add and the source folder. Workspace file should be updated.

Replace current bash variables file by a JSON file. Include also theme builder configuration in there.

• Add explanation after multisite enable: go to Admin > Tools > Network Setup (.../wp-admin/network.php)
• Add explanation before multisite complete: edit files following instructions provided in network creation page

Currently, instances created using composer are started upon start up. They should only be started on demand (i.e. with gnl start).

Add main() entry point for actions handling and replace current shell script. Add executable via setup.py (see theme builder for an example).

Indeed, deregister_host has to be executed with "sudo" (or anything similar), it cannot therefore be automatically included in the clear action.

IP addresses can change after machine reboot. This is annoying if the host was registered in hosts file (it must then be re-registered). Composer should create instances with fixed IP addresses.

• Replace occurrences of wplab by gunilla
• Consider gnl as executable name (seems to be unused, according to apt at least)

When creating a new project, a template might be provided to have starting point. The 'init' action should accept an argument (options): the source folder of the template.

A user-specific configuration file should be parsed at Gunilla startup to enable for instance the use of named prototype/project templates.

Example

[gunilla]
default_project_template=default
default_prototype_template=default

[project_templates]
default=/path/to/default/project/template

[prototype_templates]
default=/path/to/default/prototype/template