Fixing indentation.

Author: grasmash

INSTALL.md

@@ -32,18 +32,18 @@ You should be able to use the following tools on the command line of your native
         ./vendor/bin/blt install-alias
 
 1. Customize BLT configuration files:
-  * `project.yml`
-  * `docroot/sites/default/settings/local.settings.php`
-    * Add your local DB credentials to `$databases`
+    * `project.yml`
+    * `docroot/sites/default/settings/local.settings.php`
+        * Add your local DB credentials to `$databases`
 1. Replace tokens in new BLT-generated files with your custom values in project.yml:
 
 
         blt configure
 
 1. (optional) Modify project files. Important files that you may want to modify include:
-  * composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
-  * Project’s root README.md.
-  * Other project documentation in the readme directory.
+    * composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
+    * Project’s root README.md.
+    * Other project documentation in the readme directory.
 1. (optional) Follow instructions for <a href="#install">installing Drupal locally</a>.
 
 ## Adding BLT to an existing project
@@ -59,9 +59,9 @@ To add BLT to a pre-existing Drupal project, do the following:
         ./vendor/acquia/blt/blt.sh init
 
 1. (optional) Modify project files. Important files that you may want to modify include:
-  * composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
-  * Project’s root README.md.
-  * Other project documentation in the readme directory.
+    * composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
+    * Project’s root README.md.
+    * Other project documentation in the readme directory.
 1. (optional) Follow instructions for <a href="#install">installing Drupal locally</a>.
 
 ## Updating BLT
@@ -109,9 +109,9 @@ Before building your project dependencies and installing Drupal, you must have a
 
 Please see [Local Development](template/readme/local-development.md) for more information on setting up your \*AMP stack:
 
-  * [Acquia Dev Desktop](template/readme/local-development.md#using-acquia-dev-desktop-for-blt-generated-projects)
-  * [Drupal VM](template/readme/local-development.md#using-drupal-vm-for-blt-generated-projects)
-  * [Other](https://github.com/acquia/blt/blob/8.x/template/readme/local-development.md#alternative-local-development-environments)
+* [Acquia Dev Desktop](template/readme/local-development.md#using-acquia-dev-desktop-for-blt-generated-projects)
+* [Drupal VM](template/readme/local-development.md#using-drupal-vm-for-blt-generated-projects)
+* [Other](https://github.com/acquia/blt/blob/8.x/template/readme/local-development.md#alternative-local-development-environments)
 
 When you have completed setting up your local \*AMP stack, double check that the following pieces of information are still correct:
 

template/readme/best-practices.md

@@ -8,7 +8,7 @@ _This document is a work in progress._ Unlinked items are planned topics, feel f
 
 All work must conform to established best practices and coding standards. Code quality is ensured in a variety of ways:
 
-* All code must conform to [Drupal Coding Standards](https://www.drupal.org/coding-standards). This is enforced via [local git hooks](../scripts/git-hooks/README.md) and [code checks](../build/ performed during continuous integration.
+* All code must conform to [Drupal Coding Standards](https://www.drupal.org/coding-standards). This is enforced via [local git hooks](../scripts/git-hooks/README.md) and code checks performed during continuous integration.
 * All front end code must follow Drupal Theming Best Practices.
 * All code must be reviewed by a peer or established integrator before being merged into the master branch.
 * All new features must covered by an automated test that mirrors the ticket acceptance criteria.
@@ -91,13 +91,14 @@ Please see [views.md](views.md).
 
 ## Logging
 
-* Any configuration changes from custom modules should be logged to watchdog (also [Acquia Library recommendations|https://docs.acquia.com/articles/how-audit-authenticated-user-actions-better-risk-management])
+* Any configuration changes from custom modules should be logged to watchdog (also [Acquia Library recommendations](https://docs.acquia.com/articles/how-audit-authenticated-user-actions-better-risk-management)
 * Any destructive actions **must** be logged
 
 
 ## Building content types
 
 @todo Document:
+
 * Appropriate time to use fields
 * Audit for overly complex content types
     * Reason: All fields loaded for each node load

template/readme/ci.md

@@ -21,17 +21,15 @@ Automated testing of live content is easy to set up with two simple steps:
 
 1. Add the hostname of your staging server to .travis.yml:
 
-     ```
-     ssh_known_hosts:
-       - staging-12345.prod.hosting.acquia.com
-     ```
+         ssh_known_hosts:
+           - staging-12345.prod.hosting.acquia.com
+
 2. Override the default `ci:build:validate:test` target by adding the following to `build/custom/phing/build.xml`:
 
-     ```
-     <!-- Override the core ci:build:validate:test target to include a local refresh-->
-     <target name="ci:build:validate:test" description="Builds, validates, tests, and deploys an artifact."
-       depends="validate:all, ci:setup, tests:security-updates, tests:phpunit, local:sync, local:update, tests:behat" />
-     ```
+         <!-- Override the core ci:build:validate:test target to include a local refresh-->
+         <target name="ci:build:validate:test" description="Builds, validates, tests, and deploys an artifact."
+           depends="validate:all, ci:setup, tests:security-updates, tests:phpunit, local:sync, local:update, tests:behat" />
+
 
 ### Setting Up Travis CI for automated deployments
 
@@ -46,31 +44,26 @@ To set up this workflow, you must configure Acquia Cloud, GitHub, and Travis CI
 
 1. Generate an SSH key locally. E.g.,
 
-     ```
-     cd ~/.ssh
-     ssh-keygen -t rsa -b 4096
-     ```
+         cd ~/.ssh
+         ssh-keygen -t rsa -b 4096
 
    Do not use a passphrase!
+   
 1. Create a new Acquia Cloud account to be used exclusively as a container for the SSH keys that will grant Travis push access to Acquia Cloud. This can be done by inviting a new team member on the "Teams" tab in Acquia Cloud. You can use an email address like `<email>[email protected]`. The team member must have SSH push access.
 1. Login the your new Acquia Cloud account and add the public SSH key from the key pair that was generated in step 1 by visiting `https://accounts.acquia.com/account/[uid]/security`.
 1. Add the same public SSH key to the "Deployment Keys" section on your project's GitHub settings page, located at `https://github.com/acquia-pso/[project-name]/settings/keys`.
 1. Add the _private SSH key_ to your project's Travis CI settings located at `https://magnum.travis-ci.com/acquia-pso/[project-name]/settings`.
 1. Uncomment the example deployment steps in your .travis.yml file and customize them to deploy your desired branch.
 1. Add your cloud git repository to the remotes section of your project.yml file:
-
-    ```
-    remotes:
-       - [email protected]:example.git`
-    ```
+    
+        remotes:
+           - [email protected]:example.git`
 
 1. Add your cloud git repository's server host name to `ssh_known_hosts` in your .travis.yml file.
 
-    ```
-    addons:
-      ssh_known_hosts:
-      - svn-14671.prod.hosting.acquia.com
-    ```
+        addons:
+          ssh_known_hosts:
+          - svn-14671.prod.hosting.acquia.com
 
 1. Commits or merges to the develop branch on GitHub should now trigger a fully built artifact to be deployed to your specified remotes.
 

template/readme/local-development.md

@@ -66,17 +66,14 @@ In order to use a custom version of Drush (required by BLT) with Dev Desktop, yo
 
 1. Add the following lines to `~/.bash_profile`:
 
-  ```
-  export PATH="/Applications/DevDesktop/mysql/bin:$PATH"
-  export DEVDESKTOP_DRUPAL_SETTINGS_DIR="~/.acquia/DevDesktop/DrupalSettings"
-  
-  ```
+        export PATH="/Applications/DevDesktop/mysql/bin:$PATH"
+        export DEVDESKTOP_DRUPAL_SETTINGS_DIR="~/.acquia/DevDesktop/DrupalSettings"
+
 1. Ensure that Dev Desktop's PHP binary is being used on the CLI. You can check this via `which php`. 
 1. Enable the usage of environmental variables by adding the following line to `php.ini`, which you can locate with `php --ini`:
 
-  ```
-  variables_order = "EGPCS"
-  ```
+        variables_order = "EGPCS"
+
 1. Restart your terminal session after making the aforementioned changes.
 
 ## Alternative local development environments
@@ -85,10 +82,10 @@ For reasons, some teams may prefer to use a different development environment. D
 
 It is up to each team to choose how to handle local development, but some of the main things that help a project's velocity with regard to local development include:
 
-  - Uniformity and the same configuration across all developer environments.
-  - Ease of initial environment configuration (if it takes more than an hour to get a new developer running your project locally, you're doing it wrong).
-  - Ability to emulate all aspects of the production environment with minimal hassle (e.g. Varnish, Memcached, Solr, Elasticsearch, different PHP versions, etc.).
-  - Helpful built-in developer tools (e.g. XHProf, Xdebug, Adminer, PimpMyLog).
-  - Ease of use across Windows, Mac, or Linux workstations.
+* Uniformity and the same configuration across all developer environments.
+* Ease of initial environment configuration (if it takes more than an hour to get a new developer running your project locally, you're doing it wrong).
+* Ability to emulate all aspects of the production environment with minimal hassle (e.g. Varnish, Memcached, Solr, Elasticsearch, different PHP versions, etc.).
+* Helpful built-in developer tools (e.g. XHProf, Xdebug, Adminer, PimpMyLog).
+* Ease of use across Windows, Mac, or Linux workstations.
 
 If you choose to use a different solution than recommended here, please make sure it fits all the needs of your team and project, and will not be a hindrance to project development velocity!

template/readme/onboarding.md

@@ -44,19 +44,13 @@ If you need to make requests via a proxy server, please [configure git to use a
 1. [Fork](https://help.github.com/articles/fork-a-repo) the primary GitHub repository
 1. Clone your fork to your local machine:
 
-       ```
-       git clone [email protected]:username/project-repo.git -b develop
-       git remote add upstream [email protected]:acquia-pso/project-repo.git
-       ```
+         git clone [email protected]:username/project-repo.git -b develop
+         git remote add upstream [email protected]:acquia-pso/project-repo.git
 
 1. Checkout the `develop` branch. `git checkout develop`
 1. Run `composer install` (you must already have Composer installed).
-1. Run `blt setup:drupal:settings` This will generate
-  `docroot/sites/default/settings/local.settings.php` and
-  `docroot/sites/default/local.drushrc.php`. Update these with your local
-  database credentials and your local site URL.
-1. Run `blt local:setup`. This will build all project dependencies and install
-   drupal.
+1. Run `blt setup:drupal:settings` This will generate `docroot/sites/default/settings/local.settings.php` and `docroot/sites/default/local.drushrc.php`. Update these with your local database credentials and your local site URL.
+1. Run `blt local:setup`. This will build all project dependencies and install drupal.
 1. Create and edit your local drush alias file. Copy `drush/site-aliases/example.local.aliases.drushrc.php` to `drush/site-aliases/local.aliases.drushrc.php`. Edit the new alias file with your local path.
 
 After this initial setup, you should only need to run `blt setup:build` when composer.json is updated, and `blt local:drupal:install` when you need to reinstall the site.

template/readme/views.md

@@ -5,23 +5,23 @@
 The following are guidelines for building new views.
 
 * _Caching_ 
-  * For all public facing views, always use some form of caching. A non time-based cache is preferable because it often permits the longest cache lifetimes, and invalidates caches only when necessary. Possible options are:
-    * [Views content cache](https://www.drupal.org/project/views_content_cache)
-    * [Views argument cache](https://www.drupal.org/project/views_arg_cache)
-    * Time based
+    * For all public facing views, always use some form of caching. A non time-based cache is preferable because it often permits the longest cache lifetimes, and invalidates caches only when necessary. Possible options are:
+        * [Views content cache](https://www.drupal.org/project/views_content_cache)
+        * [Views argument cache](https://www.drupal.org/project/views_arg_cache)
+        * Time based
 * _Pagination_
-  * Always specify either a fixed number of results or a pager. Never display all results. 
-  * Whenever possible, use Views lite pager rather than a full pager. 
-    * Note that this is unfortunately mutually exclusive with caching due to bugs in Views Lite Pager. @see https://www.drupal.org/node/2285591.
+    * Always specify either a fixed number of results or a pager. Never display all results. 
+    * Whenever possible, use Views lite pager rather than a full pager. 
+        * Note that this is unfortunately mutually exclusive with caching due to bugs in Views Lite Pager. @see https://www.drupal.org/node/2285591.
 * _Advanced_
-  * Always add a semantically descriptive machine name to views displays. E.g., use `press_releases_all` rather than `page_1`. This makes all PHP, CSS, and JS related to the view display more readable.
+    * Always add a semantically descriptive machine name to views displays. E.g., use `press_releases_all` rather than `page_1`. This makes all PHP, CSS, and JS related to the view display more readable.
 * _Relationships_
-  * Whenever possible, use "require this relationship" for all views relationships. This causes views to perform an inner join rather than a left join, and is almost always faster.
-  * Never use the `Taxonomy Terms on Node` relationship or filter. Instead, use a relationship or filter for the specific taxonomy reference field. This has a tremendous performance impact.
+    * Whenever possible, use "require this relationship" for all views relationships. This causes views to perform an inner join rather than a left join, and is almost always faster.
+    * Never use the `Taxonomy Terms on Node` relationship or filter. Instead, use a relationship or filter for the specific taxonomy reference field. This has a tremendous performance impact.
 * _Filters_ 
-  * For all exposed filters, manually set the fitler identifier to something end-user friendly. This should not contain drupalisms. E.g., use `type` rather than `field_type`.
+    * For all exposed filters, manually set the fitler identifier to something end-user friendly. This should not contain drupalisms. E.g., use `type` rather than `field_type`.
 * _No Results Behavior_
-  * Always add "No Results behavior" of some type. This is typically text informing that user that no results were found.
+    * Always add "No Results behavior" of some type. This is typically text informing that user that no results were found.
 
 @todos: