Search by

tacman / bedrock-civicrm

A scriptable Symfony, Roots Bedrock, WordPress, and CiviCRM project template

Maintainers

Package info

github.com/tacman/bedrock-civicrm

Type:project

pkg:composer/tacman/bedrock-civicrm

Transparency log

Statistics

Installs: 0

Dependents: 0

Suggesters: 0

Stars: 0

Open Issues: 0

v0.2.1 2026-08-28 18:46 UTC

This package is auto-updated.

Last update: 2026-08-29 22:19:48 UTC


README

A Composer project template for a scriptable WordPress and CiviCRM installation, with Roots Bedrock for dependency management and a minimal Symfony front controller for application routes.

WordPress owns authentication. CiviCRM owns contacts, households, relationships, addresses, memberships, contributions, events, attendance, and mailing preferences. CiviCRM's native UFMatch synchronization connects WordPress users to their corresponding CiviCRM contacts.

Create a site

composer create-project tacman/bedrock-civicrm my-site
cd my-site

The committed .env contains documented, non-production defaults. Put database credentials, site-specific values, and secrets in the ignored .env.local:

DB_NAME='my_site'
DB_USER='my_site'
DB_PASSWORD='database_password'
DB_HOST='127.0.0.1'
DB_PORT='3307'
WP_HOME='https://my-site.wip'
WP_SITEURL="${WP_HOME}/wp"
WP_TITLE='My organization'
WP_ADMIN_USER='admin'
WP_ADMIN_PASSWORD='change-me'
WP_ADMIN_EMAIL='admin@example.org'

For a self-contained local database, start the included MariaDB service. It binds only to 127.0.0.1:3307; PHP and the web server remain native:

docker compose up -d

The simple command uses the committed .env database defaults. If .env.local overrides those database values, pass both files to Compose in the same order used by the application:

docker compose --env-file .env --env-file .env.local up -d

Then install and start the site:

./bin/install.sh
symfony server:start -d

The installer is idempotent: it installs WordPress, activates the Ollie theme, installs CiviCRM's schema and components, and activates the CiviCRM plugin. The generated CiviCRM settings and all environment secrets remain outside Git.

Local demo with sample data

CiviCRM ships its own fixtures, so a demo site needs no invented seed script. Set the flag before the first install and you get the dataset behind CiviCRM's public demo — fake contacts, addresses, activities, contributions, events and memberships:

composer create-project tacman/bedrock-civicrm civi-demo && cd civi-demo
docker compose up -d
CIVICRM_LOAD_SAMPLE_DATA=1 ./bin/install.sh
symfony server:start -d

Then open /civicrm/contact/search and there are people in it.

This maps to loadGenerated on CiviCRM's setup model — the same switch the web installer offers as the Sample Data checkbox — which sources civicrm-core/sql/civicrm_generated.mysql (~1.6 MB). bin/install-civicrm.sh passes it through as cv core:install -m loadGenerated=1.

Two caveats, both upstream's:

  • English (United States) only. Installing with another --lang skips the sample data, by design.
  • Install-time only. The flag is read during schema creation, so it does nothing on a site that is already installed. bin/install.sh is idempotent and will report CiviCRM already installed — drop the database first if you want to start over.

Never set this on anything real: it writes fake people into the contact table.

What is included

  • PHP 8.3+
  • WordPress managed through Roots Bedrock and Composer
  • CiviCRM core, WordPress integration, assets, packages, and CLI tools
  • an optional MariaDB 11.4 container—no containerized PHP, Apache, nginx, or WordPress
  • Symfony 8.1 routes alongside WordPress
  • WP-CLI development tooling
  • an idempotent, command-line installation
  • a read-only helper for resolving a WordPress user to its CiviCRM contact
$contactId = civicrm_contact_id_for_wp_user(get_current_user_id());

The helper reads CiviCRM's native mapping. It creates no parallel table, WordPress user metadata, Symfony user entity, or Doctrine model.

Application boundary

Requests for /hello, /api, /api/health, and their /sf/* aliases are handled by Symfony. All other requests are handled by WordPress. This makes it possible to add narrow application or integration endpoints without coupling CiviCRM records to Symfony entities.

A future Grist connector should call CiviCRM APIv4 and treat CiviCRM contact IDs as its stable external identifiers. Grist should remain a workflow or reporting surface, not a second constituent system of record.

Requirements

  • PHP 8.3 or newer
  • Composer 2
  • MariaDB or MySQL
  • Docker Compose (optional, for the included database-only service)
  • Symfony CLI for the convenient local HTTPS server
  • CiviCRM's required PHP extensions, including native BCMath during initial schema installation

If BCMath is installed as a separately loadable extension, set CIVICRM_BCMATH_EXTENSION in .env.local. Production should enable the extension normally.

Useful checks

composer validate
composer audit
composer test
./vendor/bin/wp core version
./vendor/bin/wp plugin list

Publishing as a project template

This repository is a Composer package with type: project and is published on Packagist, making the short composer create-project tacman/bedrock-civicrm ... command available. The repository is also marked as a GitHub template, so GitHub's Use this template button can create an independent application repository without carrying this repository's history.

This project builds on Roots Bedrock and follows CiviCRM's Composer installation guidance.