Fix “Call to undefined method PatternsHelper::get_image_url()” in WooCommerce Blocks AI content

Seeing a fatal error with Automattic\WooCommerce\Blocks\AIContent\PatternsHelper::get_image_url()? In current WooCommerce versions, the PatternsHelper class in the AI content system is deprecated and empty, so any call to get_image_url() will crash PHP. This usually happens after a WooCommerce update where an old pattern file is still on disk, or from custom theme or plugin code that still calls the old helper. Below is a safe way to get your site back online, fix WooCommerce itself, then track down custom code if needed.

WooCommerce is throwing a fatal error about “Call to undefined method Automattic\WooCommerce\Blocks\AIContent\PatternsHelper::get_image_url()”. It mentions Blocks or AI content patterns. How do I fix this without breaking my store?

Short version: WooCommerce AI content tried to call a helper method that no longer exists. PHP treats that as a hard stop, so your admin or site goes down.

In current WooCommerce, the PatternsHelper class for AI content is just an empty, deprecated stub. It has no methods at all. If any code calls PatternsHelper::get_image_url(), you get the fatal error.

Most real sites hit this in one of two ways:

  • An old WooCommerce pattern file is still on disk after an update and still calls get_image_url()
  • A theme or plugin (or custom code) still calls PatternsHelper::get_image_url() directly

Your orders and data are not gone. This is a code loading problem, not a database loss.

We will do this in three passes:


Step 1: Get the site back online

If you can still reach Plugins in wp admin:

  1. Go to Plugins → Installed Plugins
  2. Deactivate WooCommerce

That should immediately remove the fatal error. The store front will be off while WooCommerce is inactive, but your admin will load.

If you cannot open the admin at all and just see a critical error screen, disable WooCommerce by renaming its folder.

Disable WooCommerce over FTP or file manager

  1. Open your hosting file manager or connect with SFTP
  2. Go to wp-content/plugins/
  3. Rename the woocommerce folder to something like woocommerce-disabled
  4. Reload your site and wp admin

WordPress will see WooCommerce as inactive and stop loading its code. You should now get back into wp admin.

Later, you will:

  • Rename the folder back to woocommerce
  • Activate WooCommerce again after the fix

Step 2: Fix WooCommerce files and clear outdated patterns

For many sites, this error started right after a WooCommerce update. Often the cause is that some files from an older version stayed on disk. One common example is an old pattern file in wp-content/plugins/woocommerce/patterns/ that still calls PatternsHelper::get_image_url().

You want to make sure you have a clean, complete WooCommerce install and that its update routines have run.

2.1 Update WooCommerce the normal way

If you can use wp admin:

  1. Go to Plugins → Installed Plugins
  2. If WooCommerce is active, deactivate it
  3. Click Delete under WooCommerce
  4. In Plugins → Add New search for WooCommerce and install the latest version again

Deleting the plugin folder this way does not delete your orders or products. Data stays in the database.

If you deploy with Git or copy files manually between environments, it is easy to end up with WooCommerce files that changed, but update routines did not run. WooCommerce support specifically recommends forcing an update by running it through the normal update hooks.

If you have WP CLI, after you push files you can run:

wp plugin update woocommerce --force

That makes WordPress run the WooCommerce update process even if the files already look current.

2.2 Clear cache and old code

After reinstall or update:

  1. Clear any hosting cache from your control panel
  2. Clear your caching plugin cache if you use one
  3. If your host exposes OPcache or PHP cache reset, use that
  4. If you use a CDN, purge its cache too

The goal is to be sure PHP is loading only the current WooCommerce files.

2.3 Look for leftover pattern files calling get_image_url()

In some cases, the fatal comes from a WooCommerce pattern like:

wp-content/plugins/woocommerce/patterns/discount-banner-with-image.php

or another .php file inside woocommerce/patterns that calls PatternsHelper::get_image_url().

If your fatal error message shows a path under wp-content/plugins/woocommerce/patterns/:

  1. Copy the full path from the error message
  2. In FTP or the file manager, locate that file
  3. Download a copy as a backup
  4. Rename it to end with .bak or move it out of the patterns folder

WooCommerce will skip that pattern file, so it can no longer crash your site. Your store can run fine without a single promotional pattern.

Once future WooCommerce versions on your site no longer reference this helper, you can restore or replace the file if needed. For most stores, it is safe to leave it disabled.

2.4 Reactivate WooCommerce and test

Now turn WooCommerce back on.

  1. Rename the plugin folder back to woocommerce if you changed it
  2. In wp admin, go to Plugins and activate WooCommerce
  3. Open WooCommerce → Status and confirm there are no new fatal errors
  4. Open a few admin pages and a shop page and check they load

If the fatal error about PatternsHelper::get_image_url() is gone, your issue was probably an outdated pattern file or a half updated plugin.


Step 3: Find custom code that still calls PatternsHelper::get_image_url()

If the error is still there after a clean reinstall and cache clear, chances are there is custom code in your theme or another plugin that still calls this deprecated helper.

The key clue is the file path in the error.

Example:

PHP Fatal error: Uncaught Error: Call to undefined method Automattic\WooCommerce\Blocks\AIContent\PatternsHelper::get_image_url()
in /home/account/public_html/wp-content/themes/your-theme/inc/custom-wc-patterns.php on line 47

That path tells you which file is calling the method.

3.1 Turn on debug logging to see the full stack trace

If you do not already have a debug.log:

  1. Install the WP Debugging plugin or enable WP_DEBUG_LOG in wp-config.php
  2. Trigger the error again by visiting an affected admin page
  3. Download wp-content/debug.log and open it

Look for the PatternsHelper::get_image_url() entry and note the first file path inside wp-content/themes or wp-content/plugins. That file is your main suspect.

3.2 Search your code for get_image_url()

If you have SSH, you can scan your whole wp-content directory.

cd /path/to/your/site
grep -R "PatternsHelper::get_image_url" wp-content

If you only have a file manager, use its search feature across your theme and plugin folders.

Any match outside the WooCommerce plugin itself is something you or another plugin author added.

3.3 Remove or update the offending call

In each file that calls PatternsHelper::get_image_url():

  1. Make a backup copy of the file
  2. Open it in a code editor
  3. Comment out or remove the line that calls get_image_url()

For example, change something like:

<!-- old, broken code -->
<img src="<?php echo esc_url( PatternsHelper::get_image_url( $pattern ) ); ?>" alt="">

to something safe that does not use the helper. For example, a static placeholder or another image URL you control:

<!-- temporary safe version -->
<img src="<?php echo esc_url( get_template_directory_uri() . '/assets/img/pattern-placeholder.jpg' ); ?>" alt="">

After editing, upload the file back to the server if needed, refresh, and confirm the fatal error is gone.

3.4 Optional: guard the call for future compatibility

If you really need to keep custom AI pattern behavior and want a defensive guard, at minimum wrap the call:

<?php
use Automattic\WooCommerce\Blocks\AIContent\PatternsHelper;

$image_url = '';

if ( class_exists( PatternsHelper::class ) && method_exists( PatternsHelper::class, 'get_image_url' ) ) {
    $image_url = PatternsHelper::get_image_url( $pattern );
}

if ( $image_url ) {
    echo '<img src="' . esc_url( $image_url ) . '" alt="">';
}
?>

Today this condition will fail on modern WooCommerce because the method no longer exists, so your fallback code runs and keeps the site stable. If a future version reintroduces a compatible method, this guard will start using it automatically.


Verification checklist

You are in good shape when:

  • WooCommerce is active and wp admin loads without a fatal error
  • There are no new entries mentioning PatternsHelper::get_image_url() in debug.log
  • Your shop, product, and checkout pages load normally
  • If you edited or removed a specific pattern file, the rest of the store works without it

Still stuck?

For AI help

Hit Continue Chat below and tell me:

  • The exact fatal error message and full file path shown
  • Your WooCommerce version and WordPress version
  • How you updated WooCommerce most recently
  • Whether you have any custom WooCommerce patterns or AI content customizations

I can then help you map that to the exact pattern file or custom code that is causing the crash and suggest a safe patch for your setup.

For expert human help

Scroll down to the contact form below. Enter your name, email, and WordPress needs. Atiba will get back to you as soon as possible.

Need human WordPress help?

WP Assistant is a free tool created by Atiba Software, a WordPress design and development company located in Nashville, TN. If you need more personalized WordPress assistance let us know, and we’ll get back to you ASAP!