The existing site had grown across WPBakery and more recent native WordPress work. The result was not one editable system but overlapping structures, inconsistent presentation and a growing number of content and frontend errors.

A full wireframe defined the new information architecture: core company pages, approximately twenty service and subservice pages, fourteen homepage service cards and a dedicated Industry News section. The aesthetic had to align with a newer sibling site without copying its implementation constraints.

The news archive added migration risk. Legacy articles under /news/ could carry search value, so the rebuild needed a deliberate path into /industry-news/, including redirects and a structure that supports future editorial automation.

The page brings regulatory updates, research, events and reference material into one structured publishing surface. Taxonomies, query loops and shared cards let new material enter the system without rebuilding the page around every article.

Behind it, a published n8n workflow turns a newsletter inbox into a controlled preparation queue. A Gmail trigger collects messages, a loop handles them one at a time, and dedicated parsing steps extract the useful newsletter content before an AI request is assembled.

Claude returns the contextualised material, which is parsed and checked before n8n sends a structured item to the custom WordPress carb-news endpoint. Failed AI parsing follows a separate Gmail notification branch, so an exception does not disappear silently inside the automation.

The boundary is deliberate: n8n prepares; the EngineCert team decides. Generated content remains unpublished until a reviewer checks the source, technical framing and relevance, then chooses publish or discard. Final payload handling, permissions and failure behaviour remain part of the pre-launch audit.

Schools moving from another system rarely arrive with a clean template. Grade levels appear as “3”, “Grade 3” or “3rd Grade”; states may be names or abbreviations; phone formats vary; required columns are missing or named differently.

The records are also connected. A class needs a teacher already present in Staff, and one person can have an additional teaching role that must become a separate record in Gradelink’s target model. A flat file alone cannot preserve those rules.

The whole process happens before the school has an account. It has to survive page navigation, reloads and Save & Continue while still behaving like one coherent dataset inside a multi-page Gravity Forms flow.

Each entity remains a separate nested Gravity Form, so field configuration and validation stay manageable in WordPress. The Vue application receives those form definitions from PHP and presents them as a single tabbed import workspace.

Rows are stored in dedicated MySQL tables generated for each linked form, keyed to the main form’s Save & Continue token. The dataset can be paginated, edited and resumed without packing hundreds of records into serialized entry metadata.

On final submission, the import session is attached to the Gravity Forms entry and one CSV is generated for each required entity. Hash-verified download and regenerate links make those artifacts available from the entry-detail screen without exposing the underlying upload directory.

Air-cargo companies need current records for drivers, security threat assessments, mandatory training, facilities, vehicles, screening equipment and supporting documents. When those records live in spreadsheets, folders and email threads, answering a compliance question becomes a search exercise.

The data is relational. A user belongs to a company; a company can operate several facilities; each facility has its own employees, evidence, assets and subscription state. A flat membership plugin cannot represent that hierarchy safely or clearly.

The supply chain adds a second problem. An Indirect Air Carrier may need to work with an authorised representative in another market. Finding that facility, requesting a connection and exchanging authorisation evidence are part of the same operational workflow as the underlying compliance records.

The custom domain plugin separates models, controllers, data stores, enumerations and email classes behind a namespaced autoloader. Business rules have a defined home instead of accumulating in a theme file or a chain of page-builder callbacks.

WooCommerce handles products, orders and recurring payments; the application layer maps those events onto companies and facilities. A custom theme and a partial Vue.js frontend provide the account experience without forcing every screen into a single frontend framework.

Google Places supports structured facility addresses. Secure document handlers keep upload and download permissions inside the platform, while a custom HTML-to-PDF layer turns signed authorisation records into portable evidence.

People land on a family-law site in the middle of a divorce, a custody dispute or a support modification. They arrive overwhelmed, and they are holding one question: can this firm help me, and what do I do next?

The old site answered neither quickly. Practice areas sat behind a dropdown, the attorney herself appeared well below the fold, reviews were not visible at all, and every heading on the page was set in capitals — which flattens hierarchy and makes a page harder to scan precisely when a visitor has the least patience for scanning it.

Underneath the design problem was a structural one. The frontend was built in Elementor, which meant every page carried the builder’s markup and asset weight, and any future change meant editing inside the builder rather than reusing a component.

The site had years of accumulated search equity on URLs that were working. A from-scratch rebuild would have meant a new permalink structure, a redirect map to maintain, and a period of ranking volatility for a practice whose enquiries come largely from local search.

So the live site was cloned, and Elementor was swapped out for GeneratePress and GenerateBlocks in place, slug for slug. Blog posts were clean prose and moved across directly; the builder-made service pages were rebuilt as blocks. Almost nothing needed redirecting.

A new estate-planning practice area was added as a proper silo — one landing page with four service pages nested under it — using copy the owner had already written, used as supplied.

The contact form was written directly rather than pulled in from a form plugin: fewer moving parts, no plugin licence to renew, and no third-party script on the page carrying the firm’s most sensitive traffic. Scheduling runs through an embedded booking tool, and tag management was consolidated into the client’s own container so she owns her tracking outright.