fix: prevent default fallback image from entering the import pipeline

[Alexia-Soare]

Imports triggered by WP-CLI-based cron runners (common on managed hosts) injected the bundled img/feedzy.svg as the item image and tried to upload it to the Media Library, which WordPress rejects — filling customer logs with Cannot upload the image to Media Library errors (#1277). Imports now never use the display fallback image and rely on the default thumbnail setting instead.

What changed

The old guard in feedzy_define_default_image() detected imports by runtime context (wp_doing_cron() + the run_now AJAX check), which WP-CLI cron runners bypass. Every import run already carries $options['__jobID'], so the guard now keys off that.

• feedzy_retrieve_image() skips the feedzy_default_image fallback when $sc['__jobID'] is set; all import entry points (Run Now, wp-cron, WP-CLI cron) now behave identically.
• Imageless items with no fallback configured: used to download the SVG and fail sideloading with an error per item; now no download and an accurate "unable to find an image" report.
• Imageless items with a fallback configured: used to re-download the attachment over HTTP per item and sideload a duplicate; now the attachment ID is reused via set_post_thumbnail() with no HTTP request.
• featured_image filter conditions: used to match every item on the leaky path (the injected SVG counted as the item's image); now they evaluate the item's real image.
• Display contexts (shortcode, block, import preview) are unchanged — they carry no __jobID, so the fallback image still renders.
• The Saved featured image… debug line fired even when saving failed; it now reports Success: yes/no.

Import flow

flowchart TD
    A[Feed item has no image] --> B{__jobID in options?}
    B -- "no (display: shortcode/block)" --> C[feedzy_default_image filter renders fallback in img tag]
    B -- "yes (import)" --> D[Skip display fallback]:::changed
    D --> E{Default thumbnail configured?}
    E -- yes --> F[set_post_thumbnail with attachment ID]
    E -- no --> G[Post imported without featured image, accurate log]:::changed

    classDef changed fill:#9a6700,color:#fff,stroke:#9a6700

Loading

🟨 changed by this PR, gray/default unchanged.

Verification

• PHPUnit: full suite passes locally and on CI (96 tests, 811 assertions), including four new tests — three unit tests on feedzy_retrieve_image() (import suppresses the fallback, display keeps it, real item images unaffected) and one end-to-end run_cron() test asserting the fallback thumbnail is applied with no Media Library upload and no fallback-image HTTP fetch.
• The end-to-end test fails against the pre-fix code (verified by running it with feedzy_retrieve_image() from development): it records two HTTP fetches of the fallback attachment.
• E2E (Playwright) and PHPStan pass on CI; PHPCS is clean on all touched files.
• Manual, beyond automation:
  1. On a real install, import a feed whose items have no images and run wp eval 'do_action("feedzy_cron", 100, <job_id>);' with Logging Level set to Debug. Expected: posts import; logs contain no feedzy.svg and no Cannot upload the image to Media Library.
  2. Render a [feedzy-rss] shortcode or Feedzy block for the same feed in a browser. Expected: the default image still appears for imageless items.

Risk: Feedzy PRO already passes __jobID around (see the _dry_run_tags_ handling in the abstract class); if PRO builds import options anywhere without routing through run_job(), that path would miss the guard — worth a quick check on the PRO side.

🤖 Generated with Claude Code

[pirate-bot]

Plugin build for 02f6299 is ready 🛎️!

• Download build

Note

You can preview the changes in the Playground