@bostonuniversity/buwp-local 0.5.3 → 0.6.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/ROADMAP.md +2 -1
- package/docs/ARCHITECTURE.md +838 -0
- package/docs/CHANGELOG.md +149 -0
- package/docs/COMMANDS.md +462 -0
- package/docs/CREDENTIALS.md +484 -0
- package/docs/GETTING_STARTED.md +234 -0
- package/docs/MIGRATION_FROM_VM.md +237 -0
- package/docs/MULTI_PROJECT.md +513 -0
- package/docs/ROADMAP.md +237 -0
- package/lib/commands/destroy.js +1 -1
- package/lib/commands/init.js +2 -1
- package/lib/commands/keychain.js +1 -1
- package/lib/commands/start.js +233 -8
- package/package.json +1 -1
- package/readme.md +26 -0
- /package/{IMPLEMENTATION_NOTES_V0.5.0_PHASE3.md → docs/archive/IMPLEMENTATION_NOTES_V0.5.0_PHASE3.md} +0 -0
- /package/{IMPLEMENTATION_SUMMARY.md → docs/archive/IMPLEMENTATION_SUMMARY.md} +0 -0
- /package/{KEYCHAIN_IMPLEMENTATION.md → docs/archive/KEYCHAIN_IMPLEMENTATION.md} +0 -0
- /package/{macos-keychain-notes.md → docs/archive/macos-keychain-notes.md} +0 -0
|
@@ -0,0 +1,237 @@
|
|
|
1
|
+
# Migration from VM Sandboxes
|
|
2
|
+
|
|
3
|
+
This guide explains the architectural advantages of buwp-local compared to traditional VM sandbox environments and provides practical migration advice.
|
|
4
|
+
|
|
5
|
+
## Difficulties with VM Sandboxes
|
|
6
|
+
|
|
7
|
+
1. DV01 sandboxes are very slow.
|
|
8
|
+
2. The shared server is a single point of failure, and stability issues impact all developers.
|
|
9
|
+
3. Reliance on SFTP for code editing is becoming outdated and hard to support.
|
|
10
|
+
4. VM Sandboxes need periodic updates.
|
|
11
|
+
|
|
12
|
+
## The VM Sandbox Updates Problem
|
|
13
|
+
|
|
14
|
+
In traditional VM-based development environments:
|
|
15
|
+
|
|
16
|
+
1. **Monthly rebuild cycles** - VM sandboxes must be periodically replaced with fresh builds to keep WordPress core, plugins, and infrastructure up to date
|
|
17
|
+
3. **Manual preservation** - Developers must manually back up their work before each rebuild and restore it afterward
|
|
18
|
+
4. **Coordination overhead** - Team-wide rebuild schedules require coordination and can interrupt active development
|
|
19
|
+
5. **All-or-nothing updates** - The entire team must update together, regardless of individual project needs
|
|
20
|
+
|
|
21
|
+
## How buwp-local Solves This
|
|
22
|
+
|
|
23
|
+
buwp-local uses **Docker's volume mapping architecture** to fundamentally separate concerns:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
┌─────────────────────────────────────┐
|
|
27
|
+
│ Your Local Filesystem │
|
|
28
|
+
│ (Your code lives here permanently) │
|
|
29
|
+
│ │
|
|
30
|
+
│ /path/to/your-plugin/ │
|
|
31
|
+
│ ├── plugin.php │
|
|
32
|
+
│ ├── includes/ │
|
|
33
|
+
│ └── assets/ │
|
|
34
|
+
└─────────────┬───────────────────────┘
|
|
35
|
+
│ Volume mapping
|
|
36
|
+
↓
|
|
37
|
+
┌─────────────────────────────────────┐
|
|
38
|
+
│ Docker Container │
|
|
39
|
+
│ (WordPress core lives here) │
|
|
40
|
+
│ │
|
|
41
|
+
│ /var/www/html/ │
|
|
42
|
+
│ ├── wp-admin/ (from image) │
|
|
43
|
+
│ ├── wp-includes/ (from image) │
|
|
44
|
+
│ └── wp-content/ │
|
|
45
|
+
│ └── plugins/ │
|
|
46
|
+
│ └── your-plugin/ ←──── │ (mapped from local)
|
|
47
|
+
└─────────────────────────────────────┘
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### Key Architectural Differences
|
|
51
|
+
|
|
52
|
+
| Aspect | VM Sandbox | buwp-local |
|
|
53
|
+
|--------|------------|------------|
|
|
54
|
+
| **Code location** | Inside VM filesystem | Your local filesystem |
|
|
55
|
+
| **WordPress core** | Inside VM filesystem | Inside disposable container |
|
|
56
|
+
| **Update mechanism** | Deploy entire WP build | Pull new Docker image |
|
|
57
|
+
| **Your code** | Overwritten on rebuild | Always preserved |
|
|
58
|
+
| **Update schedule** | Team-wide coordination | Individual developer choice |
|
|
59
|
+
|
|
60
|
+
## Advantages
|
|
61
|
+
|
|
62
|
+
### 1. Persistent Code
|
|
63
|
+
|
|
64
|
+
Your development work lives on your Mac's filesystem. Even if you destroy and recreate containers hundreds of times, your code remains untouched.
|
|
65
|
+
|
|
66
|
+
```bash
|
|
67
|
+
# This destroys the container but NOT your code
|
|
68
|
+
npx buwp-local destroy
|
|
69
|
+
|
|
70
|
+
# Start fresh - your code is still there
|
|
71
|
+
npx buwp-local start
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### 2. Individual Update Schedules
|
|
75
|
+
|
|
76
|
+
Only those plugin and themes that you explicitly map into the container are fixed to the working code in your local filesystem. All of the other code resources from the BU WordPress build come from the container and can be updated independently.
|
|
77
|
+
|
|
78
|
+
Update WordPress whenever it makes sense for YOUR project:
|
|
79
|
+
|
|
80
|
+
```bash
|
|
81
|
+
# You in January: Pull latest image
|
|
82
|
+
docker pull ghcr.io/bu-ist/buwp:latest
|
|
83
|
+
|
|
84
|
+
# Colleague in February: Still working on older version
|
|
85
|
+
# No problem - they update when ready
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
### 3. Instant Version Switching
|
|
89
|
+
|
|
90
|
+
Test different WordPress versions without losing work:
|
|
91
|
+
|
|
92
|
+
```yaml
|
|
93
|
+
# .buwp-local.json
|
|
94
|
+
{
|
|
95
|
+
"image": "ghcr.io/bu-ist/bu-wp-docker-mod_shib:arm64-wp5-8" # Stable version
|
|
96
|
+
}
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
```yaml
|
|
100
|
+
# Switch to test new features
|
|
101
|
+
{
|
|
102
|
+
"image": "ghcr.io/bu-ist/bu-wp-docker-mod_shib:arm64-wp6-0" # Release candidate
|
|
103
|
+
}
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
Your code stays the same - only the WordPress version changes.
|
|
107
|
+
|
|
108
|
+
### 4. No Rebuild Coordination
|
|
109
|
+
|
|
110
|
+
Every developer controls their own environment:
|
|
111
|
+
|
|
112
|
+
- No team-wide rebuild meetings
|
|
113
|
+
- No "freeze" periods before rebuilds
|
|
114
|
+
- No coordination overhead
|
|
115
|
+
- No waiting for others
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## What Changes in Your Workflow
|
|
121
|
+
|
|
122
|
+
### Before (VM Sandbox)
|
|
123
|
+
|
|
124
|
+
```
|
|
125
|
+
1. Connect to VM via SSH SFTP
|
|
126
|
+
2. Edit code in VM filesystem
|
|
127
|
+
3. Test changes in VM's WordPress (dv01 is slow!)
|
|
128
|
+
4. Before monthly rebuild: Back up your changes
|
|
129
|
+
5. After rebuild: Restore changes and pray
|
|
130
|
+
6. Repeat monthly
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
### After (buwp-local)
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
1. Edit code in your favorite local editor
|
|
137
|
+
2. Changes instantly sync to container
|
|
138
|
+
3. Test changes at http://yourproject.local
|
|
139
|
+
4. When WordPress update available: docker pull
|
|
140
|
+
5. That's it - your code was never touched
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
## Frequently Asked Questions
|
|
144
|
+
|
|
145
|
+
### "What if I need the old VM for something?"
|
|
146
|
+
|
|
147
|
+
Keep it! buwp-local and VM sandboxes can coexist. Use buwp-local for active development and VMs for other purposes.
|
|
148
|
+
|
|
149
|
+
### "What about database snapshots?"
|
|
150
|
+
|
|
151
|
+
buwp-local includes the same `wp site-manager snapshot-pull` command as production. Pull from production/staging anytime:
|
|
152
|
+
|
|
153
|
+
```bash
|
|
154
|
+
npx buwp-local wp site-manager snapshot-pull --source=https://www.bu.edu/site/
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
### "Can I share my environment with teammates?"
|
|
158
|
+
|
|
159
|
+
Your `.buwp-local.json` configuration can be committed to version control. Teammates run:
|
|
160
|
+
|
|
161
|
+
```bash
|
|
162
|
+
git clone your-repo
|
|
163
|
+
npm install
|
|
164
|
+
npx buwp-local start
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
Everyone gets an identical environment with their own isolated containers.
|
|
168
|
+
|
|
169
|
+
### "What happens to my database when I update?"
|
|
170
|
+
|
|
171
|
+
Docker volumes persist your database across container updates:
|
|
172
|
+
|
|
173
|
+
```bash
|
|
174
|
+
# Your database lives in a named volume
|
|
175
|
+
docker volume ls | grep wordpress-db
|
|
176
|
+
|
|
177
|
+
# It survives container recreation
|
|
178
|
+
npx buwp-local destroy # Removes container
|
|
179
|
+
npx buwp-local start # Database still intact
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
### "How do I completely start fresh?"
|
|
183
|
+
|
|
184
|
+
```bash
|
|
185
|
+
# Remove everything including database (this is notional, the actual command does not yet support the --volumes flag)
|
|
186
|
+
npx buwp-local destroy --volumes
|
|
187
|
+
|
|
188
|
+
# Or keep database, just refresh WordPress
|
|
189
|
+
npx buwp-local stop
|
|
190
|
+
docker pull ghcr.io/bu-ist/bu-wordpress:new-tag
|
|
191
|
+
npx buwp-local start
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
## Troubleshooting
|
|
195
|
+
|
|
196
|
+
### Container won't start
|
|
197
|
+
|
|
198
|
+
```bash
|
|
199
|
+
# Check Docker Desktop is running
|
|
200
|
+
docker info
|
|
201
|
+
|
|
202
|
+
# Check port conflicts
|
|
203
|
+
npx buwp-local start --verbose
|
|
204
|
+
```
|
|
205
|
+
|
|
206
|
+
### Code changes not appearing
|
|
207
|
+
|
|
208
|
+
Check volume mappings in `.buwp-local.json`:
|
|
209
|
+
|
|
210
|
+
```json
|
|
211
|
+
{
|
|
212
|
+
"volumeMappings": [
|
|
213
|
+
{
|
|
214
|
+
"localPath": "./",
|
|
215
|
+
"containerPath": "/var/www/html/wp-content/plugins/your-plugin"
|
|
216
|
+
}
|
|
217
|
+
]
|
|
218
|
+
}
|
|
219
|
+
```
|
|
220
|
+
|
|
221
|
+
### Credentials not loading
|
|
222
|
+
|
|
223
|
+
```bash
|
|
224
|
+
# Verify Keychain entries
|
|
225
|
+
npx buwp-local keychain list
|
|
226
|
+
|
|
227
|
+
# Or use .env.local fallback
|
|
228
|
+
npx buwp-local keychain export > .env.local
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
See [CREDENTIALS.md](CREDENTIALS.md) for detailed credential management.
|
|
232
|
+
|
|
233
|
+
## Additional Resources
|
|
234
|
+
|
|
235
|
+
- [Getting Started Guide](GETTING_STARTED.md) - Step-by-step setup
|
|
236
|
+
- [Command Reference](COMMANDS.md) - Complete CLI documentation
|
|
237
|
+
- [Architecture Guide](ARCHITECTURE.md) - Technical deep-dive
|