repos – Store Locator Plus® Internal Docs

The Docker Directory Standard

Posted by lcleveland in Development, IT, System Administration

Git repositories that support projects needing Docker images and containers should follow this directory standard. Any project that uses vendor tools or apps should store support data in a similar subdirectory structure. Notes here are relative to the Repository Root.

Docker Files

Composer

The Docker compose file should end up here:
./Vendors/Docker/Composers

This is for files the build and launch containers.

Images

This is for stuff that builds images used to launch custom containers.

The files that support building images should end up here:
./Vendors/Docker/Images
Dockerfile or Dockerfile-openclaw may live here.

Supporting files for building images go in these directories:
./Vendors/Docker/Images/Files
For files that are put in the SLP SaaS repo that support image building, public files.
This often contains subdirectories for files to copy from the host (stored in the SLP_SaaS repo) to the guest.
For example:
./apache/sites-avaiable/000-default.conf – for a Docker container with Apache websites
./php/docker-php-ext-redix.ini – for a Docker container with PHP and Redis support
./ssl/_wildcard.storelocatorplus.com+2.pem – for an SSL cert
Things in Files/* in this Docker folder are often copied via Dockerfile to build the image

./Vendors/Docker/Images/Secrets
It can contains supporting secret files that do not get commited to the repo.
For example: do-not-commit-codebuild-vars.env
This is for environment variables needed for Code Build on AWS with values set like AWS_DEFAULT_REGION=us-east-1
The README instructions would say something like “copy ./Images/Secrets-Examples/codebuild-vars.env to ./Images/Secrets/do-not-commit-codebuild-vars.env

SLP_SaaS_Docker_Directory_Standard.md

# SLP SaaS — Docker Directory Standard

This document captures the current **directory layout conventions** for Docker-related assets used with the **SLP SaaS** project, as described by Lance.

## Project roots (MBP)

- **SLP SaaS repo root**
  - `/Users/lancecleveland/phpStorm Projects/SLP_SaaS`

- **Testing area (under SLP_SaaS)**
  - `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/`

- **myslp-cypress repo (local checkout)**
  - `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/myslp-cypress`

## Canonical Docker directory structure (within myslp-cypress)

All Docker-related standards below are relative to:

- `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/myslp-cypress/Vendors/Docker/`

### 1) Compose files

**Docker Compose files** should live here:

- `Vendors/Docker/Composers/`

Example (full path):

- `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/myslp-cypress/Vendors/Docker/Composers`

Notes:
- This is the standard landing zone for any new compose setup (e.g., an E2E Eddie/OpenClaw + Cypress compose).

### 2) Image build definitions

**Files that support building images** should live here:

- `Vendors/Docker/Images/`

Example (full path):

- `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/myslp-cypress/Vendors/Docker/Images`

Notes:
- Dockerfiles may live here, including variants like `Dockerfile` or `Dockerfile-openclaw`.

### 3) Public build-support files (committed)

**Supporting files used during image builds** (intended to be committed) should live here:

- `Vendors/Docker/Images/Files/`

Example (full path):

- `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/myslp-cypress/Vendors/Docker/Images/Files`

Conventions:
- This directory often contains subdirectories that mirror container filesystem targets.
- Contents are typically copied into an image via `Dockerfile` using `COPY ...`.

Examples of typical contents:
- `./apache/sites-available/000-default.conf` — Apache site config
- `./php/docker-php-ext-redix.ini` — PHP extension/config file (example)
- `./ssl/_wildcard.storelocatorplus.com+2.pem` — SSL cert material (example)

### 4) Secrets (NOT committed)

**Supporting secret files** (not committed to the repo) should live here:

- `Vendors/Docker/Images/Secrets/`

Example (full path):

- `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/myslp-cypress/Vendors/Docker/Images/Secrets`

Conventions:
- This may contain env var files or other sensitive build/runtime inputs.
- Example secret file:
  - `do-not-commit-codebuild-vars.env`

Example usage pattern to document in READMEs:
- “Copy `./Images/Secrets-Examples/codebuild-vars.env` to `./Images/Secrets/do-not-commit-codebuild-vars.env` and edit values (e.g., `AWS_DEFAULT_REGION=us-east-1`).”

### 5) Secrets examples (committed templates)

**Example secret files** (templates that *are* committed) should live here:

- `Vendors/Docker/Images/Secrets-Examples/`

Example (full path):

- `/Users/lancecleveland/phpStorm Projects/SLP_SaaS/Testing/myslp-cypress/Vendors/Docker/Images/Secrets-Examples`

Purpose:
- Provide safe-to-commit starter files that developers can copy into `Secrets/`.

## Recommended README conventions (optional)

When adding a new compose or image:
- Put the compose YAML in `Vendors/Docker/Composers/`.
- Put the Dockerfile(s) in `Vendors/Docker/Images/`.
- Put committed build inputs in `Vendors/Docker/Images/Files/`.
- Put local-only secrets in `Vendors/Docker/Images/Secrets/`.
- Put example secrets in `Vendors/Docker/Images/Secrets-Examples/`.

## Source

Captured from Lance Cleveland’s notes in Slack (2026-03-21).

Store Locator Plus® Staging (Prerelease) Updates 2024 Edition

Posted by lcleveland in Development, Process, Store Locator Plus®

We are going to move away from manually-executed grunt tasks via the wp-dev-kit repository and move toward an AWS implemented solution. We are going to leverage AWS developer tools to get the job done.

The general process is that you work on code and merge it into the develop branch of the store-locator-plus repository on CodeCommit (the main upstream source). When that code is deemed “ready for testing” the repo manager will merge the develop branch into the staging branch for the repository. CodePipeline should see the change to the staging branch in the repo and fire off the build and deployment processes.

CodeCommit

The repo, and now official “source of truth” for the SLP code and build kit repositories.

ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/store-locator-plus

The “upstream” aws repo for Store Locator Plus®.

CodeBuild

The build manager that will compile , minify, clean, and otherwise manipulate the stuff in the main SLP repo and prepare it for release. In this case a staging release of the WordPress plugin .zip file.

CodePipeline

Watches the main SLP repo for changes on the staging branch and fires off the CodeBuild execution when that happens.

Our pipeline is the store-locator-plus-staging-release pipeline. It has 3 stages:

Source

The CodeCommit source noted above.

Build

The CodeBuild project noted above.

Note that the CodePipeline takes over the artifact generation output and will dump the final output artifact store-locator-plus.zip into a different CodePipeline specific bucket. This is NOT the same bucket that is specified in the CodeBuild configuration.

Deploy

This is a setting in CodePipeline, NOT a CodeDeploy project, that copies the output artifact (store-locator-plus.zip) from the private CodePipeline artifacts bucket over into the storelocatorplus/builds/staging bucket.

S3 Buckets

This process uses S3 buckets to store build and pipeline artifacts.

The deployment process uses a public web endpoint (HTTP, non-secure) to store the final output artifact alongside some other SLP “goodies”.

The AWS S3 SLP storage site is: http://storelocatorplus.s3-website-us-east-1.amazonaws.com/

This bucket contains an index.html that has been created “by hand” to link to the staging and production zip files.

Image by 🌼Christel🌼 from Pixabay

SOP: Code Management

Posted by lcleveland in Development, Internal Use Only, Process, Store Locator Plus®

All development is done on personal forked copies (origin) of the primary Store Locator Plus® repositories (upstream). Upstream is considered the “single source of truth” for the current code state.

Additional Reading

Forks and Pull Requests

To begin work, fork the main Store Locator Plus® repository (upstream) to a personal repo (origin).

When code is ready to be integrated with current ongoing development effort, issue a pull request for your origin:update/<something> (see branch conventions below) branch into the upstream:develop branch. When the pull request is approved and merged, the upstream:develop branch be ready for the rest of the team.

Monitor upstream:develop regularly and be sure to fetch-and-merge (aka “pull”) the upstream:develop branch into origin:develop. Any in-progress origin:update/<something> branches that have not had a pull request issues against upstream should be rebased onto the new origin:develop branch. Make sure all conflicts are resolved.