The Entity Version module attaches a version number to content entities that helps content editors to understand the evolution of the content item.
Versions are composed of major, minor and patch numbers and can be changed manually or by third party modules.
- Entity version workflows: this module allows configuration and control of version numbers through workflow state transitions.
- Entity version history: module provides a "History" tab for content entities that have a version field in order to visualise the versions in a table format.
This module provides a configuration page found at "admin/config/entity-version/settings" where an appropriate version
field can be selected for entities and their bundles that have at least one version field.
Those fields will be then used as target for functionalities provided by sub-modules.
This module provides a permission called administer entity version
which allows configuring the module settings.
You can build the development site by running the following steps:
- Install the Composer dependencies:
composer install
A post command hook (drupal:site-setup
) is triggered automatically after composer install
.
This will symlink the module in the proper directory within the test site and perform token substitution in test configuration files such as behat.yml.dist
.
Please note: project files and directories are symlinked within the test site by using the OpenEuropa Task Runner's Drupal project symlink command.
If you add a new file or directory in the root of the project, you need to re-run drupal:site-setup
in order to make
sure they are be correctly symlinked.
If you don't want to re-run a full site setup for that, you can simply run:
$ ./vendor/bin/run drupal:symlink-project
- Install test site by running:
$ ./vendor/bin/run drupal:site-install
The development site web root should be available in the build
directory.
Alternatively, you can build a development site using Docker and Docker Compose with the provided configuration.
Docker provides the necessary services and tools such as a web server and a database server to get the site running, regardless of your local host configuration.
By default, Docker Compose reads two files, a docker-compose.yml
and an optional docker-compose.override.yml
file.
By convention, the docker-compose.yml
contains your base configuration and it's provided by default.
The override file, as its name implies, can contain configuration overrides for existing services or entirely new services.
If a service is defined in both files, Docker Compose merges the configurations.
Find more information on Docker Compose extension mechanism on the official Docker Compose documentation.
To start, run:
docker-compose up
It's advised to not daemonize docker-compose
so you can turn it off (CTRL+C
) quickly when you're done working.
However, if you'd like to daemonize it, you have to add the flag -d
:
docker-compose up -d
Then:
docker-compose exec web composer install
docker-compose exec web ./vendor/bin/run drupal:site-install
Using default configuration, the development site files should be available in the build
directory and the development site
should be available at: http://127.0.0.1:8080/build.
To run the grumphp checks:
docker-compose exec web ./vendor/bin/grumphp run
To run the phpunit tests:
docker-compose exec web ./vendor/bin/phpunit
To enable step debugging from the command line, pass the XDEBUG_SESSION
environment variable with any value to
the container:
docker-compose exec -e XDEBUG_SESSION=1 web <your command>
Please note that, starting from XDebug 3, a connection error message will be outputted in the console if the variable is set but your client is not listening for debugging connections. The error message will cause false negatives for PHPUnit tests.
To initiate step debugging from the browser, set the correct cookie using a browser extension or a bookmarklet like the ones generated at https://www.jetbrains.com/phpstorm/marklets/.
Please read the full documentation for details on our code of conduct, and the process for submitting pull requests to us.
We use SemVer for versioning. For the available versions, see the tags on this repository.