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:
get_image_url()PatternsHelper::get_image_url() directlyYour orders and data are not gone. This is a code loading problem, not a database loss.
We will do this in three passes:
get_image_url()If you can still reach Plugins in wp admin:
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.
wp-content/plugins/woocommerce folder to something like woocommerce-disabledWordPress will see WooCommerce as inactive and stop loading its code. You should now get back into wp admin.
Later, you will:
woocommerceFor 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.
If you can use wp admin:
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.
After reinstall or update:
The goal is to be sure PHP is loading only the current WooCommerce files.
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/:
.bak or move it out of the patterns folderWooCommerce 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.
Now turn WooCommerce back on.
woocommerce if you changed itIf the fatal error about PatternsHelper::get_image_url() is gone, your issue was probably an outdated pattern file or a half updated plugin.
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.
If you do not already have a debug.log:
WP_DEBUG_LOG in wp-config.phpwp-content/debug.log and open itLook 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.
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.
In each file that calls PatternsHelper::get_image_url():
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.
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.
You are in good shape when:
PatternsHelper::get_image_url() in debug.logHit Continue Chat below and tell me:
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.
Scroll down to the contact form below. Enter your name, email, and WordPress needs. Atiba will get back to you as soon as possible.
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!