> For the complete documentation index, see [llms.txt](https://hoaxly.gitbook.io/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hoaxly.gitbook.io/documentation/developer-documentation/updating-debunkcms.md). # Developing/Updating debunkCMS debunkCMS is available on github: License: GPL 2 debunkCMS is based on [thunder](https://thunder.org). You can find all thunder specific documentation [here](https://github.com/BurdaMagazinOrg/thunder-distribution). ## debunkCMS specific modules We created some addon modules that are all available on github: * review, providing the review contenttype and its configuration: * review\_rest, providing the REST API: * debunkCMS\_theme, a theme based on thunder\_base to overwrite some templates and colors. * debunkCMS\_demo, providing demo content: * schema\_claimreview, providing metatag support for the ClaimReview schema.org specification: ## Infos about how to work with the Composer based installation The debunkCMS repo is providing a kickstart for managing your site dependencies with [Composer](https://getcomposer.org/). ### Usage First you need to install [Composer](https://getcomposer.org/doc/00-intro.md#installation-linux-unix-osx) and [Git](https://git-scm.com/). > Note: The instructions below refer to the [global composer installation](https://getcomposer.org/doc/00-intro.md#globally). You might need to replace `composer` with `php composer.phar` (or similar) for your setup. After that you can create the project: ``` composer create-project hoaxly/debunkCMS debunkCMS ``` With `composer require ...` you can download new dependencies to your installation. ``` cd thunder composer require drupal/devel:1.* ``` The `composer create-project` command passes ownership of all files to the project that is created. You should create a new git repository, and commit all files not excluded by the .gitignore file. ### What does the template do? When installing the given `composer.json` some tasks are taken care of: * Drupal will be installed in the `docroot`-directory. * Autoloader is implemented to use the generated composer autoloader in `vendor/autoload.php`, instead of the one provided by Drupal (`docroot/vendor/autoload.php`). * Modules (packages of type `drupal-module`) will be placed in `docroot/modules/contrib/` * Theme (packages of type `drupal-theme`) will be placed in `docroot/themes/contrib/` * Profiles (packages of type `drupal-profile`) will be placed in `docroot/profiles/contrib/` * Downloads Drupal scaffold files such as `index.php`, or `.htaccess` * Creates `sites/default/files`-directory. * Latest version of drush is installed locally for use at `bin/drush`. * Latest version of DrupalConsole is installed locally for use at `bin/drupal`. ### Installing Creating the project will install the CMS into the docroot directory. You can now install it as you would with any Drupal 8 site. See: [Drupal installation guide](https://www.drupal.org/node/1839310). ### Updating To update the distro, Drupal or any module to the newest version, constrained by the specified version in `composer.json`, execute `composer update`. This command will check every dependency for a new version, downloads it and updates the `composer.lock` accordingly. After that you can run `drush updb` in the docroot folder to update the database of your site. #### File update This project will attempt to keep all of your project and drupal core files up-to-date; the project [drupal-composer/drupal-scaffold](https://github.com/drupal-composer/drupal-scaffold) is used to ensure that your scaffold files are updated every time drupal/core is updated. If you customize any of the "scaffolding" files (commonly .htaccess), you may need to merge conflicts if any of your modfied files are updated in a new release of Drupal core. Follow the steps below to update your thunder files. 1. Run `composer update hoaxly/debunkCMS` 2. Run `git diff` to determine if any of the scaffolding files have changed. Review the files for any changes and restore any customizations to `.htaccess` or `robots.txt`. 3. Commit everything all together in a single commit, so `web` will remain in sync with the `core` when checking out branches or running `git bisect`. 4. In the event that there are non-trivial conflicts in step 2, you may wish to perform these steps on a branch, and use `git merge` to combine the updated core files with your customized files. This facilitates the use of a [three-way merge tool such as kdiff3](http://www.gitshah.com/2010/12/how-to-setup-kdiff-as-diff-tool-for-git.html). This setup is not necessary if your changes are simple; keeping all of your modifications at the beginning or end of the file is a good strategy to keep merges easy.