133 lines
4.3 KiB
Markdown
133 lines
4.3 KiB
Markdown
# 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:
|
|
|
|
1. `wp_insert_post()` caches `_elementor_data` as empty in the object cache
|
|
2. Each `elementor_add_container()` call reads the cache → gets `[]` → adds one element → saves to DB
|
|
3. 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`.
|
|
|
|
```php
|
|
// 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:
|
|
```php
|
|
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:
|
|
|
|
```php
|
|
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:
|
|
|
|
```php
|
|
// 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:
|
|
|
|
1. **PHP ini override:** `/usr/local/etc/php/conf.d/mcp-mail.ini`
|
|
```
|
|
sendmail_path = /bin/true
|
|
```
|
|
Routes all mail to `/bin/true` (a no-op binary) for CLI context.
|
|
|
|
2. **mu-plugin:** `/var/www/html/wp-content/mu-plugins/null_sendmail.php`
|
|
```php
|
|
if (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:
|
|
```php
|
|
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.
|