Problem
After elementor-cli push to a production site, the page still serves stale CSS/content despite the CLI reporting "✔ Invalidated CSS cache". Manual intervention via SSH is required to actually flush the cache.
Root Cause
Two issues in the current invalidation logic:
1. invalidateCss() sets meta to empty string instead of deleting it
In src/services/wordpress-client.ts (L164-176), the method sets _elementor_css and _elementor_element_cache to "" (empty string) via REST API PUT. Elementor does not treat an empty string the same as a deleted/absent meta field — it needs the meta to be fully removed to trigger CSS regeneration.
What works: wp post meta delete <page-id> _elementor_css
What does not work: Setting _elementor_css to "" via REST API
The fix should use null instead of "" to delete the meta via REST API:
meta: {
_elementor_css: null,
_elementor_element_cache: null,
}
2. No wp elementor flush-css / wp cache flush for remote (SSH) sites
In src/commands/push.ts (L360-369), the container-based wp elementor flush-css only runs for sites with a container config (local Docker/Podman). Remote/production sites only get the (broken) REST API invalidation.
The CLI already supports SSH for db dump (--ssh and --ssh-path flags). The same SSH config should be usable for running wp elementor flush-css and wp cache flush on remote sites after push.
Steps to Reproduce
- Configure a production site without
container config in .elementor-cli.yaml
elementor-cli pull <page-id> --site production
- Make changes to the local page data
elementor-cli push <page-id> --site production
- Observe: CLI reports success + "✔ Invalidated CSS cache"
- Load the page in browser (even with hard refresh) — old content/CSS is still served
Workaround
Manually run via SSH after pushing:
ssh user@host "wp --path=/path/to/wp post meta delete <page-id> _elementor_css"
ssh user@host "wp --path=/path/to/wp elementor flush-css"
ssh user@host "wp --path=/path/to/wp cache flush"
Proposed Solution
- Change
invalidateCss() to delete meta fields (set to null) instead of empty string
- Add optional SSH config to site definitions in
.elementor-cli.yaml:
sites:
production:
url: https://example.com
username: admin
appPassword: "..."
ssh:
connection: user@host
wpPath: /path/to/wordpress
- After REST API invalidation, if
ssh config is present, also run wp elementor flush-css and wp cache flush via SSH
- The
regenerate-css command should also support the SSH flush path
Problem
After
elementor-cli pushto a production site, the page still serves stale CSS/content despite the CLI reporting "✔ Invalidated CSS cache". Manual intervention via SSH is required to actually flush the cache.Root Cause
Two issues in the current invalidation logic:
1.
invalidateCss()sets meta to empty string instead of deleting itIn
src/services/wordpress-client.ts(L164-176), the method sets_elementor_cssand_elementor_element_cacheto""(empty string) via REST API PUT. Elementor does not treat an empty string the same as a deleted/absent meta field — it needs the meta to be fully removed to trigger CSS regeneration.What works:
wp post meta delete <page-id> _elementor_cssWhat does not work: Setting
_elementor_cssto""via REST APIThe fix should use
nullinstead of""to delete the meta via REST API:2. No
wp elementor flush-css/wp cache flushfor remote (SSH) sitesIn
src/commands/push.ts(L360-369), the container-basedwp elementor flush-cssonly runs for sites with acontainerconfig (local Docker/Podman). Remote/production sites only get the (broken) REST API invalidation.The CLI already supports SSH for
db dump(--sshand--ssh-pathflags). The same SSH config should be usable for runningwp elementor flush-cssandwp cache flushon remote sites after push.Steps to Reproduce
containerconfig in.elementor-cli.yamlelementor-cli pull <page-id> --site productionelementor-cli push <page-id> --site productionWorkaround
Manually run via SSH after pushing:
Proposed Solution
invalidateCss()to delete meta fields (set tonull) instead of empty string.elementor-cli.yaml:sshconfig is present, also runwp elementor flush-cssandwp cache flushvia SSHregenerate-csscommand should also support the SSH flush path