@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.
@@ -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