Development and maintenance

Use this workflow for theme, integration, and plugin changes. The goal is to keep database-managed content, commerce behavior, and persisted identifiers stable.

Before changing code

1. Reproduce the issue on the local URL.
2. Identify the owner: WordPress, Elementor, theme, WooCommerce, YITH, another plugin, or a saved snippet.
3. Export a database backup and preserve the current wp-content.
4. Record the pages and flows affected by the change.
5. Check the browser console, network requests, WordPress debug log, and PHP output.

Theme change workflow

1. Read functions.php and the relevant active module.
2. Search for the hook, class, handle, option key, shortcode, AJAX action, or template before adding a new one.
3. Prefer a WordPress hook or a focused inc/ module over duplicating a full template.
4. Keep markup compatible with saved Elementor and WooCommerce content.
5. Escape output with the correct WordPress escaping function.
6. Sanitize input, verify nonces, and check capabilities for every write action.
7. Update source assets and generated assets together if a build step exists.
8. Document any new persisted identifier or operational setting.

Minimum validation

Run checks appropriate to the files changed:

# WordPress and plugin state
H:\smith\wp\wp.cmd core version
H:\smith\wp\wp.cmd theme list
H:\smith\wp\wp.cmd plugin list

# Example PHP syntax check
php -l path\to\changed-file.php

# Theme-defined checks, when dependencies are installed
cd H:\smith\wp\site\wp-content\themes\smith-sons-1
npm run check:js
npm run lint:js
composer run lint:php

Use npm run build:gallery when the product-gallery source changes. Do not assume every script exists or passes on an inherited working tree. Read package.json and composer.json first, then record any pre-existing failure separately from your change.

Browser regression set

At minimum, check:

• homepage at desktop and mobile widths;
• header navigation, search, account, and cart;
• one Elementor content page;
• search results and 404;
• shop archive with filters;
• simple product;
• auction product and bid state;
• product images and video;
• cart quantity changes;
• checkout using a safe sandbox path only;
• My Account/login;
• contact and signup forms;
• footer links and social integrations.

Capture before/after screenshots for visible changes.

WooCommerce changes

Before editing an override in woocommerce/, compare it with the same template in the installed WooCommerce plugin. Preserve the upstream @version header and re-test every product type affected.

Prefer hooks for small presentation changes. Template overrides are justified when markup must substantially differ, but they create an ongoing upgrade obligation.

Elementor changes

Custom widgets are bootstrapped by inc/elementor/bootstrap.php. Keep widget names, control IDs, and saved setting keys stable. Renaming a PHP class is possible only if Elementor can still resolve existing saved widget data.

After a widget or stylesheet change:

1. load an existing page using the widget;
2. open it in the Elementor editor;
3. verify controls and responsive settings;
4. regenerate Elementor CSS/data if required;
5. confirm frontend output with no console errors.

Plugin maintenance

• Never update all commerce and page-builder plugins in one batch.
• Use payment sandbox modes; never place live test orders without approval.
• Review release notes and minimum PHP/WordPress requirements.
• Check Code Snippets and WPCode before concluding a behavior is theme-owned.
• Remove an inactive plugin only after confirming it is not needed for rollback, migration, or stored content.
• Restrict high-privilege tools such as migration, file manager, code injection, security, and payment plugins.

Rollback

A change is ready only when its rollback is clear:

1. retain the previous file/package state;
2. know which database tables or options changed;
3. restore both database and uploads when content/media changed;
4. clear caches after rollback;
5. repeat the same regression set;
6. document the cause and final resolution.

Release checklist

• Active theme version and release metadata agree.
• PHP, JavaScript, JSON, and stylesheet checks pass.
• No new PHP notices, deprecations, console errors, or failed requests appear.
• WooCommerce overrides were reviewed against the installed version.
• Elementor, catalog, auctions, cart, forms, and account flows pass.
• No secrets or personal/customer data are present in source, logs, screenshots, or documentation.
• Backup and rollback were verified.
• Production deployment has explicit approval and a separate plan.