You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
1. Replace tokens in new BLT-generated files with your custom values in project.yml:
49
39
50
-
```
51
-
blt configure
52
-
```
40
+
41
+
blt configure
42
+
53
43
1. (optional) Modify project files. Important files that you may want to modify include:
54
-
* composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
55
-
* Project’s root README.md.
56
-
* Other project documentation in the readme directory.
44
+
* composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
45
+
* Project’s root README.md.
46
+
* Other project documentation in the readme directory.
57
47
1. (optional) Follow instructions for <ahref="#install">installing Drupal locally</a>.
58
48
59
-
## <aname="existing-project"></a>Adding BLT to an existing project
49
+
## Adding BLT to an existing project
60
50
61
51
To add BLT to a pre-existing Drupal project, do the following:
62
52
63
53
1. Ensure that your project directory structure is Acquia-cloud compatible by asserting that the Drupal root is in a top-level folder called `docroot`.
64
54
1. If you currently manage your dependencies via Composer, ensure that they are all up to date via `composer update`. Assert that these updates do not break your project.
65
55
1.`cd` into your existing project directory.
66
56
1. Add BLT via composer and initialize it:
67
-
```
68
-
composer require acquia/blt:~8
69
-
./vendor/acquia/blt/blt.sh init
70
-
```
57
+
58
+
composer require acquia/blt:~8
59
+
./vendor/acquia/blt/blt.sh init
60
+
71
61
1. (optional) Modify project files. Important files that you may want to modify include:
72
-
* composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
73
-
* Project’s root README.md.
74
-
* Other project documentation in the readme directory.
62
+
* composer.json. Note that Drupal core, contrib, and third party dependencies are all managed here.
63
+
* Project’s root README.md.
64
+
* Other project documentation in the readme directory.
75
65
1. (optional) Follow instructions for <ahref="#install">installing Drupal locally</a>.
76
66
77
-
## <aname="updating"></a>Updating BLT
67
+
## Updating BLT
78
68
79
-
### <aname="update-composered"></a>Updating a composer-managed version
69
+
### Updating a composer-managed version
80
70
81
71
If you are already using BLT via Composer, you can update to the latest version of BLT by running the following commands from your project's root directory:
82
72
83
-
```
84
-
composer update acquia/blt
85
-
blt update
86
-
```
73
+
composer update acquia/blt
74
+
blt update
75
+
87
76
88
-
### <aname="update-non-composered"></a>Updating from a non-Composer-managed version
77
+
### Updating from a non-Composer-managed version
89
78
90
79
If you are using an older version of BLT that was not installed using Composer, you may update to the Composer-managed version by running the following commands:
91
80
92
81
1. Remove any dependencies that may conflict with upstream acquia/blt. You may add these back later after the upgrade, if necessary.
Note that all of the steps from this point forward are the same steps that would be used by a newly onboarded developer setting up your existing project on their local machine for the first time.
121
105
@@ -124,16 +108,17 @@ Note that all of the steps from this point forward are the same steps that would
124
108
Before building your project dependencies and installing Drupal, you must have a fully functional \*AMP stack on your local machine. BLT intentionally does not provide this local development environment--that is outside of the scope of BLT’s intended responsibilities. It does, however, make recommendations for which tools you should use to manage your stack.
125
109
126
110
Please see [Local Development](template/readme/local-development.md) for more information on setting up your \*AMP stack:
127
-
*[Acquia Dev Desktop](template/readme/local-development.md#using-acquia-dev-desktop-for-blt-generated-projects)
Copy file name to clipboardexpand all lines: template/readme/best-practices.md
+11-19
Original file line number
Diff line number
Diff line change
@@ -4,27 +4,18 @@
4
4
5
5
_This document is a work in progress._ Unlinked items are planned topics, feel free to contribute.
6
6
7
-
*[Standards](#standards)
8
-
*[Exporting configuration](#exporting-config)
9
-
*[Configuration updates](#config-updates)
10
-
*[Caching strategies](#caching)
11
-
*[Patching](#patching)
12
-
*[Building Views](#views)
13
-
*[Logging](#logging)
14
-
*[Building content types](#content-types)
15
-
16
-
## <aname="standards"></a>Standards
7
+
## Standards
17
8
18
9
All work must conform to established best practices and coding standards. Code quality is ensured in a variety of ways:
19
10
20
-
* 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.
11
+
* 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.
21
12
* All front end code must follow Drupal Theming Best Practices.
22
13
* All code must be reviewed by a peer or established integrator before being merged into the master branch.
23
14
* All new features must covered by an automated test that mirrors the ticket acceptance criteria.
24
15
25
16
Please peruse the [examples](examples) directory for examples of various coding best practices.
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).
30
21
@@ -53,7 +44,7 @@ Common mistakes:
53
44
* 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."
54
45
* Features are too granular. E.g., there is a separate feature for each role, a feature contains only a single view, etc.
* If a change is happening, that change needs to be documented in code, preferably an update hook. E.g.,
59
50
* Reverting features and feature components `features_revert_module()`
@@ -62,7 +53,7 @@ Common mistakes:
62
53
* Updates needs to be actively monitored. This should be done using NewRelic, SumoLogic, Logstreaming, and/or other monitoring tools.
63
54
* Updates need to be intentional. E.g., don't use cloud hooks or cron jobs to automatically execute updates or clear caches.
64
55
65
-
## <aname="caching"></a>Caching
56
+
## Caching
66
57
67
58
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_.
68
59
@@ -89,24 +80,25 @@ Specifically, ensure that you are properly caching data at every level possible,
89
80
90
81
See the [Drupal 8 Cache API](https://www.drupal.org/developing/api/8/cache) documentation for information in implementing your caching strategy.
91
82
92
-
## <aname="patching"></a>Patching
83
+
## Patching
93
84
94
85
All modifications to contributed code should be performed via a patch. For detailed information on how to patch projects, please see [../patches/README.md]
95
86
(../patches/README.md)
96
87
97
-
## <aname="views"></a>Views
88
+
## Views
98
89
99
90
Please see [views.md](views.md).
100
91
101
-
## <aname="logging"></a>Logging
92
+
## Logging
102
93
103
-
* 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])
94
+
* 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)
### Setting Up Travis CI for automated deployments
37
35
@@ -46,31 +44,26 @@ To set up this workflow, you must configure Acquia Cloud, GitHub, and Travis CI
46
44
47
45
1. Generate an SSH key locally. E.g.,
48
46
49
-
```
50
-
cd ~/.ssh
51
-
ssh-keygen -t rsa -b 4096
52
-
```
47
+
cd ~/.ssh
48
+
ssh-keygen -t rsa -b 4096
53
49
54
50
Do not use a passphrase!
51
+
55
52
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.
56
53
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`.
57
54
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`.
58
55
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`.
59
56
1. Uncomment the example deployment steps in your .travis.yml file and customize them to deploy your desired branch.
60
57
1. Add your cloud git repository to the remotes section of your project.yml file:
0 commit comments