Fixing Meow Lightbox on GenerateBlocks Images After BerqWP Caching

Meow Lightbox worked correctly with standard WordPress Image blocks on my websites, but it would not open images placed with the GenerateBlocks Image block after BerqWP cached and optimized the page.

The problem was not immediately obvious. The images displayed normally, GenerateBlocks continued working, and Meow Lightbox still worked with images in the Meow Gallery Block or the WP Image Block on the same page. The failure only affected the combination of:

• A GenerateBlocks Image block
• Meow Lightbox
• A page processed by BerqWP caching

The issue occurred on websites using the same basic configuration, including Dee Zunker Photography and West Loop Rental Studio.

After comparing the HTML generated by the two image blocks, I found that the standard WordPress Image block retained an important piece of Media Library information that the GenerateBlocks Image block did not.

The Lightbox Problem

On an uncached page, Meow Lightbox could recognize and open the GenerateBlocks image. After BerqWP processed the page, the image still appeared normally, but clicking it no longer opened the lightbox.

A standard WordPress Image block placed beside it continued to work on the same cached page.

That comparison helped isolate the problem. Meow Lightbox was active, its JavaScript was loading, and BerqWP was not preventing every lightbox image from working. Something about the GenerateBlocks image markup was different.

Testing the WordPress and GenerateBlocks Image Blocks

I created a test page containing two copies of an image:

1. One placed with the standard WordPress Image block
2. One placed with the GenerateBlocks Image block

Before caching, Meow Lightbox could recognize both images. After BerqWP generated the optimized page, only the standard WordPress image continued to work.

Disabling Meow Gallery and Meow Lightbox optimization in BerqWP was not a practical solution. It affected site performance and did not address why one type of image block worked while the other failed.

Adding a custom meow class to the GenerateBlocks image also did not solve the problem. The class allowed the image to match a lightbox selector, but it did not give Meow the Media Library information needed to identify the attachment.

The Important Markup Difference

A standard WordPress Image block normally includes a class containing its Media Library attachment ID:

class="wp-image-12345"

The number corresponds to the image’s attachment record in the WordPress Media Library.

The GenerateBlocks image contained GenerateBlocks-specific classes, including a class beginning with gb-media-, but it did not include the standard wp-image-{ID} class.

This distinction became important after BerqWP optimized the page.

Why The Image Worked Before Caching

When the original local image URL was present, Meow Lightbox could apparently use that URL to connect the image displayed on the page with its Media Library attachment.

BerqWP subsequently rewrote or optimized the image URL for cached delivery. Once that happened, the URL was no longer a reliable way for Meow to identify the original WordPress attachment.

The standard WordPress Image block survived the change because its wp-image-{ID} class remained in the HTML. The attachment ID continued to identify the image even when the delivered image URL changed.

The GenerateBlocks Image block did not have that persistent identifier. Once its URL was rewritten, Meow Lightbox could no longer reliably associate it with its Media Library record.

Why Adding a Lightbox Class Did Not Work

A custom class and a lightbox selector answer one question:

Which images should be eligible to open in the lightbox?

They do not necessarily answer another:

Which WordPress Media Library attachment does this image represent?

Adding a meow class made the GenerateBlocks image eligible for lightbox processing, but the attachment identity was still missing. Also, .entry-content was already included in the Meow Lightbox selector settings, so the GenerateBlocks image was already within the eligible content area.

The working solution was to add the standard WordPress attachment class to the generated image markup.

The Solution

I used a PHP snippet that checks rendered GenerateBlocks images, finds the corresponding Media Library attachment ID and adds the standard wp-image-{ID} class to the <img> element.

The change happens while WordPress renders the block, before BerqWP stores the optimized page.

/**
 * Add the standard WordPress attachment class to GenerateBlocks images.
 *
 * This helps plugins such as Meow Lightbox identify the Media Library
 * attachment after a cache or CDN rewrites the image URL.
 */
function geeky_add_attachment_class_to_gb_images( $block_content, $block ) {

	// Skip content that does not contain a GenerateBlocks image.
	if (
		false === strpos( $block_content, '<img' ) ||
		false === strpos( $block_content, 'gb-media-' )
	) {
		return $block_content;
	}

	// WP_HTML_Tag_Processor was introduced in WordPress 6.2.
	if ( ! class_exists( 'WP_HTML_Tag_Processor' ) ) {
		return $block_content;
	}

	$processor = new WP_HTML_Tag_Processor( $block_content );

	// Avoid repeating the same Media Library lookup during one request.
	static $attachment_cache = array();

	while ( $processor->next_tag( 'img' ) ) {
		$classes = (string) $processor->get_attribute( 'class' );

		// Only modify GenerateBlocks images.
		if ( false === strpos( $classes, 'gb-media-' ) ) {
			continue;
		}

		// Leave images that already have a WordPress attachment class alone.
		if ( preg_match( '/(?:^|\s)wp-image-\d+(?:\s|$)/', $classes ) ) {
			continue;
		}

		$image_url = $processor->get_attribute( 'src' );

		if ( empty( $image_url ) ) {
			continue;
		}

		// Remove query parameters before looking up the attachment.
		$lookup_url = strtok( $image_url, '?' );

		if ( isset( $attachment_cache[ $lookup_url ] ) ) {
			$attachment_id = $attachment_cache[ $lookup_url ];
		} else {
			$attachment_id = attachment_url_to_postid( $lookup_url );
			$attachment_cache[ $lookup_url ] = $attachment_id;
		}

		if ( ! $attachment_id ) {
			continue;
		}

		$processor->add_class( 'wp-image-' . absint( $attachment_id ) );
	}

	return $processor->get_updated_html();
}

add_filter( 'render_block', 'geeky_add_attachment_class_to_gb_images', 10, 2 );

How to Install the Fix

I added the PHP through the Code Snippets plugin rather than placing it in the theme’s functions.php file.

The basic process was:

1. Create a new PHP snippet.
2. Paste the code into the snippet editor.
3. Set it to run on the public-facing website or everywhere.
4. Save and activate the snippet.
5. Purge the entire BerqWP cache.
6. Open the affected page in an incognito window.
7. Confirm that the GenerateBlocks images open in Meow Lightbox.

Purging BerqWP is essential. Previously cached pages will still contain the older image markup until the cache is regenerated.

What the Snippet Changes

The snippet does not replace images, change Media Library records or edit existing page content.

It only modifies the HTML generated for qualifying GenerateBlocks images. For example, an image class might change from:

class="gb-media-abc123"

to:

class="gb-media-abc123 wp-image-12345"

BerqWP can then optimize or rewrite the image URL while the attachment ID remains available to Meow Lightbox.

Images that already have a wp-image-{ID} class are skipped. External images or images that WordPress cannot match to a Media Library attachment are also left unchanged.

Safety, Performance, and Plugin Compatibility

Performance Considerations

Resolving an image URL to a Media Library attachment requires a WordPress lookup. The snippet includes a small per-request cache so the same URL is not repeatedly resolved during one page request.

On a BerqWP-cached website, this processing generally occurs when WordPress generates the page that BerqWP will cache. It is not necessarily repeated for every visitor receiving the cached version.

Even so, it is worth testing pages with large numbers of images and monitoring uncached page-generation performance.

Whose Plugin Should Fix This?

This appears to be an interoperability gap rather than a simple failure by one plugin.

GenerateBlocks could potentially include the standard WordPress wp-image-{ID} class when an image is selected from the Media Library. Meow Lightbox could potentially recognize another attachment-ID attribute supplied by GenerateBlocks. BerqWP might also preserve the original attachment reference when it rewrites an image URL.

Ultimately, I think the GenerateBlocks image block is the best way to handle this issue. There are probably other plugins and caching systems that need the original image ID to function, and the GB image block seems the logical place to start.

The PHP snippet supplies the missing connection without requiring changes to any of the three plugins.

Results on my websites

After activating the snippet and purging the BerqWP cache, Meow Lightbox began working with GenerateBlocks images on the cached test page.

I use this general WordPress configuration on Dee Zunker Photography and West Loop Rental Studio. The fix allows me to continue using:

• GenerateBlocks for page layouts and individual image blocks
• Meow Gallery and Meow Lightbox for image presentation
• BerqWP for caching, optimization and CDN delivery

The standard WordPress Image block did not require the fix because it already included the attachment-ID class.

Final Takeaway

If Meow Lightbox works with standard WordPress Image blocks but fails with GenerateBlocks images after BerqWP caching, compare the rendered image classes.

The missing piece may not be the lightbox selector. It may be the WordPress Media Library attachment ID.

Adding the standard wp-image-{ID} class to the GenerateBlocks image provides a persistent identifier that remains useful even after a caching or CDN service rewrites the image URL.