tacman / bedrock-civicrm
A scriptable Symfony, Roots Bedrock, WordPress, and CiviCRM project template
Requires
- php: >=8.3
- ext-bcmath: *
- civicrm/civicrm-asset-plugin: ^1.2
- civicrm/civicrm-core: ^6.17
- civicrm/civicrm-packages: ^6.17
- civicrm/civicrm-wordpress: ^6.17
- civicrm/cli-tools: ^2026.03
- composer/installers: ^2.0
- nanasess/bcmath-polyfill: ^1.1
- oscarotero/env: ^2.0
- roots/bedrock-autoloader: ^1.0
- roots/bedrock-disallow-indexing: ^2.0
- roots/wordpress: ^7.1
- roots/wp-config: ^1.0
- survos/bedrock: ^2.24
- symfony/framework-bundle: 8.1.*
- symfony/runtime: 8.1.*
- vlucas/phpdotenv: ^5.0
- wp-theme/ollie: ^1.6
- wp-theme/twentytwentyfive: ^1.0
Requires (Dev)
- laravel/pint: ^1.0
- wp-cli/wp-cli-bundle: ^2.11
Suggests
None
Provides
None
Conflicts
None
Replaces
None
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
--langskips 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.shis idempotent and will reportCiviCRM 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.