Removing named anchors.

Author: grasmash

template/readme/best-practices.md

@@ -4,16 +4,7 @@
 
 _This document is a work in progress._ Unlinked items are planned topics, feel free to contribute.
 
-* [Standards](#standards)
-* [Exporting configuration](#exporting-config)
-* [Configuration updates](#config-updates)
-* [Caching strategies](#caching)
-* [Patching](#patching)
-* [Building Views](#views)
-* [Logging](#logging)
-* [Building content types](#content-types)
-
-## <a name="standards"></a>Standards
+## Standards
 
 All work must conform to established best practices and coding standards. Code quality is ensured in a variety of ways:
 
@@ -24,7 +15,7 @@ All work must conform to established best practices and coding standards. Code q
 
 Please peruse the [examples](examples) directory for examples of various coding best practices.
 
-## <a name="exporting-config"></a>Exporting configuration
+## Exporting configuration
 
 All site functionality should be represented in version-controlled code. This includes all configuration. Drupal configuration is typically exported via [Features](https://www.drupal.org/project/features). 
 
@@ -53,7 +44,7 @@ Common mistakes:
 * Each feature has too many dependencies, so no one feature can be used in isolation, or a single feature becomes impossible to disable. E.g., the "Workflow" feature depends on the "Press Room" feature because it requires field_body which is provided by "Press Room."
 * Features are too granular. E.g., there is a separate feature for each role, a feature contains only a single view, etc.
 
-## <a name="config-updates"></a>Configuration updates
+## Configuration updates
 
 * If a change is happening, that change needs to be documented in code, preferably an update hook. E.g.,
     * Reverting features and feature components `features_revert_module()`
@@ -62,7 +53,7 @@ Common mistakes:
 * Updates needs to be actively monitored. This should be done using NewRelic, SumoLogic, Logstreaming, and/or other monitoring tools.
 * Updates need to be intentional. E.g., don't use cloud hooks or cron jobs to automatically execute updates or clear caches.
 
-## <a name="caching"></a>Caching
+## Caching
 
 Without caching, Drupal is slow. As a general rule of thumb, _try to cache everything that you can_ and _try to invalidate that cache only when it is likely to be stale_. 
 
@@ -89,22 +80,22 @@ Specifically, ensure that you are properly caching data at every level possible,
 
 See the [Drupal 8 Cache API](https://www.drupal.org/developing/api/8/cache) documentation for information in implementing your caching strategy.
 
-## <a name="patching"></a>Patching
+## Patching
 
 All modifications to contributed code should be performed via a patch. For detailed information on how to patch projects, please see [../patches/README.md]
 (../patches/README.md)
 
-## <a name="views"></a>Views
+## Views
 
 Please see [views.md](views.md).
 
-## <a name="logging"></a>Logging
+## 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 destructive actions **must** be logged
 
 
-## <a name="content-types"></a>Building content types
+## Building content types
 
 @todo Document:
 * Appropriate time to use fields

template/readme/ci.md

@@ -1,4 +1,4 @@
-## <a name="ci"></a> Continuous Integration
+## Continuous Integration
 
 Integration with Travis CI is included, although Phing tasks can be used with any CI tool. The default Travis CI build process is as follows:
 

template/readme/deploy.md

@@ -33,7 +33,7 @@ This task is analogous to `setup:build` but with a few critical differences:
 
 After the artifact is created, you can inspect it or even run it as a website locally. You may also manually commit and push it to ACE.
 
-## <a name="build-artifact"></a>Create and deploy the build artifact
+## Create and deploy the build artifact
 
 To both create and deploy the build artifact in a single command, run the following command
 

template/readme/local-development.md

@@ -3,7 +3,7 @@
 Acquia currently recommends the use of either:
 
   * [Drupal VM](#drupal-vm): An isolated virtual machine, built with Vagrant and Ansible.
-  * [Acquia Dev Desktop](#dd): A turn-key LAMP stack tailored specifically for Acquia-hosted Drupal sites.
+  * [Acquia Dev Desktop](#acquia-dev-desktop): A turn-key LAMP stack tailored specifically for Acquia-hosted Drupal sites.
 
 No matter what local environment you choose to use, the following guidelines should be followed:
 
@@ -23,7 +23,7 @@ If you must use Windows, we recommend that:
     * [cmder](http://cmder.net/)
     * [cygwin](https://www.cygwin.com/)
 
-## <a name="drupal-vm"></a>Using Drupal VM for BLT-generated projects
+## Using Drupal VM for BLT-generated projects
 
 _BLT support for Drupal VM is experimental. Not all BLT features currently work with Drupal VM. Additionally, Drupal VM integration with BLT cannot be tested via Travis CI, and is prone to regressions._
 
@@ -54,7 +54,7 @@ To execute Behat tests using the 'drupal' driver on a Drupal VM environment, you
 
 You may choose to write only behat tests that utilize the Drupal Extension's "drupal" driver. Doing this will allow you to run `blt tests:behat` from the host machine without modificaitons to the Behat local.yml configuration.
 
-## <a name="dd"></a>Using Acquia Dev Desktop for BLT-generated projects
+## Using Acquia Dev Desktop for BLT-generated projects
 
 ### Project creation and installation changes
 

template/readme/project-tasks.md

@@ -2,14 +2,7 @@
 
 “how do I _____ on my local machine?”
 
-* [(re)Install Drupal](#install-drupal)
-* [Update dependencies (module, theme, core, etc.)](#update-dependency)
-* [Patch a project](#patch)
-* [Deploy to cloud](#deploy)
-* [Run tests & code validation](#tests)
-* [Build frontend assets](#frontend)
-
-## <a name="install-drupal"></a>(re)Install Drupal
+## (re)Install Drupal
 
 Pre-requisites to installation:
 
@@ -19,7 +12,7 @@ Pre-requisites to installation:
 
 To re-install Drupal, execute: `blt setup:drupal:install`. Note that this will drop the existing database tables and install Drupal from scratch!
 
-## <a name="update-dependency"></a>Update dependencies (core, profile, module, theme, libraries)
+## Update dependencies (core, profile, module, theme, libraries)
 
 Composer should be used to manage Drupal core, all contributed dependencies, and most third party libraries. The primary exception to this is front end libraries that may be managed via a front-end specific dependency manager, such as [Bower](http://bower.io/) or [NPM](https://www.npmjs.com/).
 
@@ -50,15 +43,15 @@ To update drupal core:
 4. Use git to review changes to committed files. E.g., changes to .htaccess, robots.txt, etc.
 5. Add and commit desired changes.
 
-## <a name="patch"></a>Patch a project
+## Patch a project
 
 Please see [patches/README.md](../patches/README.md) for information on patch naming, patch application, and patch contribution guidance.
 
-## <a name="deploy"></a>Deploy to cloud
+## Deploy to cloud
 
 Please see [Deploy](deploy.md) for a detailed description of how to deploy to Acquia Cloud.
 
-## <a name="tests"></a>Run tests & code validation
+## Run tests & code validation
 
 Please see [tests/README.md](../tests/README.md) for information on running tests.
 
@@ -68,7 +61,7 @@ To execute PHP codesniffer and PHP lint against the project codebase, run:
 blt validate:all
 ```
 
-## <a name="frontend"></a>Build front end assets
+## Build front end assets
 
 Ideally, you will be using a theme that uses SASS/SCSS, a styleguide, and other tools that require compilation. Like dependencies, the compiled assets should not be directly committed to the project repository. Instead, they should be built during the creation of a production-ready build artifact.
 
@@ -98,7 +91,7 @@ This command will be executed when dependencies are built in a local or CI envir
 blt frontend:build
 ```
 
-## <a name="local-tasks"></a>Updating your local environment
+## Updating your local environment
 
 The project is configured to update the local environment with a local drush alias and a remote alias as defined in `project.yml` or `project.local.yml`. Given that these aliases match, those in `drush/site-aliases/`, you can update the site with BLT. Please see [drush/README.md](../drush/README.md) for details on how to create these aliases.
 

template/readme/release-process.md

@@ -1,33 +1,24 @@
-# Release Process
+# Release Processs
 
-This document is a work in progress.
-
-* [Generating a build artifact](#build-artifact)
-* [Branching strategies](#branching)
-* [Tagging](#tagging)
-* [Release Notes](#release-notes)
-* [Deploying tag and executing updates](#deploy-tag)
-* [Notifications](#notifications) (slack, hipchat, etc)
-
-## <a name="branching"></a>Branching strategies
+## Branching strategies
 
 @todo Document this!
 
-## <a name="build-artifact"></a>Generating a build artifact
+## Generating a build artifact
 
 See [Create and deploy the build artifact](deploy.md#build-artifact) in [deploy.md](deploy.md).
 
-## <a name="tagging"></a>Tagging
+## Tagging
 
 @todo Document this!
 
-## <a name="release-notes"></a>Release notes
+## Release notes
 
 Each release should be accompanied by a set of release notes, which can be easily generated using the [Release Notes Script](../scripts/release-notes/README.md).
 
 This script will automatically aggregate all of the descriptions from Pull Requests since a specified date. The generated tet aggregate can then be copied and pasted into release notes on GitHub.
 
-## <a name="deploy-tag"></a>Deploying tag and executing updates
+## Deploying tag and executing updates
 
 Deploying Drupal across environments can be daunting, but if due diligence has been taken with configuration management, the process of deployment is actually quite simple.
 
@@ -48,7 +39,7 @@ A few things that you should (almost) never do on production:
 
 There might be some extra steps depending on the infrastructure and the extent of site changes. For example, a major application change might require a flush of other caches in the system such as Varnish or Memcached. 
 
-# <a name="notifications">Notifications
+# Notifications
 
 You can configure various tools to provide notifications of deployment related events. For instance:
 

template/tests/README.md

@@ -65,7 +65,7 @@ This directory contains all projects tests, grouped by testing technology. For a
     ├── jmeter  - contains all jMeter tests
     └── phpunit - contains all PHP Unit tests
 
-## <a name="executing-tests"></a>Executing tests
+## Executing tests
 
 Before attempting to execute any tests, verify that composer dependencies are built by running `composer install` in the project root.
 
@@ -85,7 +85,7 @@ For more information on the commands, run:
 * `./vendor/bin/phpunit --help`
 * `./vendor/bin/behat --help`
 
-## <a name="behat"></a>Behat
+## Behat
 
 The high-level purpose BDD is to create a strong connection between business requirements and the actual tests. Behat tests should mirror ticket acceptance criteria as closely as possible.
 
@@ -144,7 +144,7 @@ PHP based BDD library. Best practices for tests writing apply to both
 * [The training wheels came off](http://aslakhellesoy.com/post/11055981222/the-training-wheels-came-off)
 
 
-## <a name="phpunit"></a>PHPUnit
+## PHPUnit
 
 Project level, functional PHPUnit tests are included in `tests/phpunit`. Any PHPUnit tests that affect specific modules or application level features should be placed in the same directory as that module, not in this directory.