4.3 KiB
Known Issues & Fixes Applied
1. Elementor Data — WP Object Cache Stale Reads in CLI
Problem
When building Elementor pages in a CLI PHP script, get_post_meta() and update_post_meta() operate through WP's object cache. In a long-running CLI process:
wp_insert_post()caches_elementor_dataas empty in the object cache- Each
elementor_add_container()call reads the cache → gets[]→ adds one element → saves to DB - The NEXT call reads cache again → still sees
[](cache wasn't properly invalidated) → overwrites DB with only that one element
Result: every add_container call overwrites all previous elements. Final page has only the last element.
Fix Applied
ElementorData::save_page_data() and get_page_data() now use raw $wpdb queries (bypassing WP object cache entirely) when PHP_SAPI === 'cli' OR defined('DOING_CRON') && DOING_CRON.
// save_page_data() CLI branch:
global $wpdb;
$exists = $wpdb->get_var($wpdb->prepare(
"SELECT meta_id FROM {$wpdb->postmeta} WHERE post_id=%d AND meta_key='_elementor_data' LIMIT 1",
$post_id
));
if ($exists) {
$wpdb->query($wpdb->prepare("UPDATE {$wpdb->postmeta} SET meta_value=%s WHERE meta_id=%d", $json, $exists));
} else {
$wpdb->query($wpdb->prepare("INSERT INTO {$wpdb->postmeta} (post_id, meta_key, meta_value) VALUES (%d, '_elementor_data', %s)", $post_id, $json));
}
wp_cache_delete($post_id, 'post_meta');
Requirement
All CLI scripts that build Elementor pages MUST include:
define('DOING_CRON', true);
before require '/var/www/html/wp-load.php';
File: includes/Elementor/Data/ElementorData.php
2. Page Template Validation Fails in CLI
Problem
Passing page_template to wp_update_post() in CLI context:
wp_update_post(['ID' => $pid, 'page_template' => 'elementor-full-width']); // FAILS
WP validates the template slug against registered templates. Page templates are only registered during HTTP requests (via theme_page_templates filter). In CLI context, no templates are registered, so WP returns WP_Error: Invalid page template.
Fix Applied
Never pass page_template to wp_update_post(). Set it via update_post_meta() AFTER publishing:
// Correct pattern:
wp_update_post(['ID' => $pid, 'post_status' => 'publish']); // no page_template here
update_post_meta($pid, '_wp_page_template', 'elementor-full-width'); // set after
File: includes/Tools/PageTools.php
3. wp_mail Fatal in CLI — No sendmail Binary
Problem
Calling wp_update_post() to publish a post triggers wp_new_post_notification() which calls wp_mail(). The container has no sendmail binary at /usr/sbin/sendmail, causing a PHP fatal error.
Fix Applied
Two-layer fix:
-
PHP ini override:
/usr/local/etc/php/conf.d/mcp-mail.inisendmail_path = /bin/trueRoutes all mail to
/bin/true(a no-op binary) for CLI context. -
mu-plugin:
/var/www/html/wp-content/mu-plugins/null_sendmail.phpif (PHP_SAPI === 'cli') { ini_set('sendmail_path', '/bin/true'); }
Do not remove either of these. On web requests, wp_mail works normally through the configured SMTP.
4. wp_update_post Triggers wp_die in CLI (Historical)
Problem (resolved)
During early development, $document->save() inside ElementorData::save_page_data() called wp_update_post() which triggered WP hooks that called wp_die() — killing the script mid-execution.
Fix Applied
The CLI branch of save_page_data() no longer calls $document->save() at all. It writes directly to the DB via $wpdb->query(). This completely bypasses the Elementor document save flow and all WP hooks triggered by wp_update_post().
5. Duplicate Slug on Repeated Test Runs
Symptom
When a build script runs multiple times with the same page title, WordPress appends -2, -3 etc. to the slug. The page URL ends up as /my-page-4/ instead of /my-page/.
Fix
Update slug directly in DB after publishing:
global $wpdb;
$wpdb->update($wpdb->posts, ['post_name' => 'desired-slug'], ['ID' => $pid]);
flush_rewrite_rules(true);
Do not use WP-CLI wp post update for this — it triggers template validation and fails with "Invalid page template".
Pending Issues
None currently open. All known blockers resolved as of 2026-05-31.