Getting started with Lovat Parks

How to get Lovat Parks running locally and make your first change safely. Read [[architecture]] first — this page assumes you know the shape of the system.

What you need before you start

Thing	Why	Who grants it
Bitbucket access to StrategiQ/lovatparks.com	The repo. There is no GitHub mirror.	StrategiQ
Local by Flywheel	The supported local environment.	—
A database dump + wp-content/uploads	Both are gitignored. The site is unusable without content.	StrategiQ
A wp-config.php	Gitignored. Contains every credential the site needs.	StrategiQ
Elite Parks sandbox credentials	Nothing bookable works without them.	Client / StrategiQ
Cardstream sandbox credentials	Only needed for payment work.	Client
WP Engine access	For production and staging.	StrategiQ

Never point a local environment at production Elite Parks. Use the sandbox, and set LP_WC_EP_DRY_RUN to true unless you are specifically testing real CRM writes.

Repository shape

The whole WordPress install is committed — core, plugins and theme — not just wp-content. The repo root is the webroot. Gitignored: wp-config.php, wp-content/uploads/, caches, and node_modules.

The code you will actually work in is wp-content/themes/lovat-parks/.

Setting up

# 1. Create a Local by Flywheel site, then clone into its app/public directory.
git clone [email protected]:StrategiQ/lovatparks.com.git

# 2. Drop in wp-config.php and restore the database + uploads.

# 3. PHP dependencies (Guzzle, PHPUnit, Brain Monkey, Mockery)
cd wp-content/themes/lovat-parks
composer install

# 4. Front-end tooling
npm install

Verified on this machine: PHP 8.4.7, Node 22.22.2, Composer 2.8.9. composer test and npx gulp --version both run (gulp CLI 2.3.0, local 4.0.2).

Not verified: a clean npm install. The theme’s package.json pins gulp 4 and node-sass 4, which historically needed Node 14 — the repo README still says so. The committed node_modules works under Node 22, but a fresh install on a modern Node may need nvm use 14. Budget time for this.

Running it

cd wp-content/themes/lovat-parks

# Watch SCSS + JS (edit the theme/URL constants at the top of gulpfile.js first)
npx gulp watch

# One-off build
npx gulp compile

# Unit tests
composer test

Heads-up: the test suite is currently red

On master today: 91 tests, 15 errors, 2 failures. These are test drift, not broken product code — for example DepositCalculatorTest::testMultiLineMixedEligibility predates the current eligibility rules, and ExtrasPageControllerTest has no Brain Monkey stub for nocache_headers().

Do not assume a red suite means you broke something. Do compare against a clean checkout before and after your change. Fixing this suite is a genuinely good first task.

Feature flags to know on day one

Everything booking-related is flag-controlled. Set these in wp-config.php:

Flag	Set it to	Why
LP_WC_EP_DRY_RUN	true	No real EP traffic. Synthetic responses, logs prefixed [DRY-RUN]. Use this by default.
LP_USE_WOOCOMMERCE_CHECKOUT	leave undefined	Its absence lets the ACF options toggle wc_checkout_enabled control the flow, which is how staging and production behave.
LP_WC_EP_DEBUG_SOAP	true only while debugging	Unredacted emails in logs. Card data stays redacted regardless.

To exercise the old flow, set LP_USE_WOOCOMMERCE_CHECKOUT to false. See [[woocommerce-holiday-checkout]] and [[legacy-holiday-checkout]].

Where to look when something breaks

# New code (WooCommerce logger)
ls wp-content/uploads/wc-logs/          # sources: lovat-checkout, lovat-eliteparks, lovat-portal-cardstream

# Legacy code (hand-rolled)
tail -f wp-content/uploads/logs/strategiq-booking.log
tail -f wp-content/uploads/logs/strategiq-checkout.log
tail -f wp-content/uploads/logs/ep-payloads.log     # exact EP request/response per booking

Useful admin screens: WooCommerce → Booking Reconciliation ([[booking-reconciliation-queue]]), the Booking Dashboard and Tagging Dashboard under the booking menus, and Tools → WP Crontrol for the nine scheduled jobs.

Deployment

Bitbucket Pipelines, deploying by git ftp to SFTP targets (bitbucket-pipelines.yml):

Trigger	Target
push to development	Development
push to staging	Staging
manual deploy-production	Production — guarded by a git name-rev … master check
manual deploy-wpe-ssh	WP Engine deploy pipe

Production is never automatic. Credentials are Bitbucket repository variables; the required names are listed at the top of the pipelines file.

Note build.sh in the repo root still references the old strategiq-base theme directory and is not used by the pipelines.

A sensible first task

1. Read [[architecture]], then [[elite-parks-integration]]. Nearly every bug traces back to that layer.
2. Run composer test and fix one of the failing tests. It is contained, it teaches you the deposit and extras logic, and it leaves the repo better than you found it.
3. Then, with LP_WC_EP_DRY_RUN=true, run a booking end to end: search → /holidays/checkout/?scid=… → loading page → /cart/extras/ → checkout → payment. Watch wc-logs/lovat-eliteparks* as you go. That one pass will teach you more than any amount of reading.

House rules

• New code goes in inc/lovat-checkout/src/, PSR-4 under LovatParks\Checkout\, with a register() method and a unit test. Do not add to inc/eliteparks/ — that is the frozen legacy path.
• Never commit wp-config.php or any credential. The repo has been clean on this; keep it that way.
• Anything touching money must be tested with the WooCommerce flag both on and off. The legacy flow is the rollback net.
• Update the Atlas feature page in the same PR as the change. Read it, edit the parts your change invalidated, write the whole file back.