Skip to content
This repository has been archived by the owner on Oct 16, 2024. It is now read-only.

Fix some issues with block pattern previews #152

Merged
merged 15 commits into from
May 4, 2023

Conversation

johnstonphilip
Copy link
Contributor

@johnstonphilip johnstonphilip commented May 1, 2023

Tasks

Summary of changes

This PR fixes some issues with block pattern previews, especially ones relating to Genesis Framework.

How to test

  1. Install a Genesis theme, like Navigation Pro, and save the home page blocks to a pattern using Pattern Manager
  2. Notice the pattern preview is not accurate to how the pattern should look.
  3. On this branch, it should look correct again

Notes & Screenshots

Before this branch (broken)

Screenshot 2023-05-01 at 4 05 32 PM

On this branched (fixed)

Screenshot 2023-05-01 at 4 05 54 PM

@johnstonphilip
Copy link
Contributor Author

I will be attempting to replicate/fix this one next:
https://wordpress.org/support/topic/pattern-preview-is-distorted/

@johnstonphilip
Copy link
Contributor Author

johnstonphilip commented May 2, 2023

By hooking to wp instead of init, it fixes the issue with GenerateBlocks as well, because it allows the generateblocks styles to be hooked on init, making them render on wp, which fires after.

Before (using init hook):

Screenshot 2023-05-02 at 1 53 59 PM

After (fixed, using the wp hook)

Screenshot 2023-05-02 at 1 53 48 PM

@kienstra
Copy link
Contributor

kienstra commented May 2, 2023

Reviewing this now 🚀

Copy link
Contributor

@kienstra kienstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @johnstonphilip,
This fixes it! Nice work!

Before

Screenshot 2023-05-02 at 12 52 33 PM

After

Screenshot 2023-05-02 at 12 52 46 PM

);
}
}
add_action( 'patternmanager_after_pattern_preview', __NAMESPACE__ . '\after_pattern_preview' );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea to create a module for this.


$this->assertSame(
$the_expected_returned_content,
do_the_content_things( $the_raw_content_to_test )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, great test!

* @param string $content The html content to run through the filters.
* @return bool
*/
function do_the_content_things( $content ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need its own module, given that it's only called in wp-modules/pattern-preview-renderer/pattern-preview-renderer.php ?

Copy link
Contributor Author

@johnstonphilip johnstonphilip May 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved it out because do_the_content_things was being used in 2 different modules, but since #148 I guess that's no longer the case.

I don't mind having some of these "module agnostic" functions in a dedicated module. It might perhaps make sense as part of @mike-day's work in #141 though. Maybe we leave it for now and look at moving it into his module once that's ready?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That kind of thing could definitely live in patternmanager-common (or equivalent)!

I would agree with leaving it for now and moving into the common module when that PR is ready.

Copy link
Contributor

@kienstra kienstra May 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't mind having some of these "module agnostic" functions in a dedicated module. It might perhaps make sense as part of @mike-day's work in #141 though. Maybe we leave it for now and look at moving it into his module once that's ready?

Good idea!


$pattern = \PatternManager\PatternDataHandlers\get_pattern_by_name( $pattern_name );

// Handle Genesis themes, who enqueue their stylesheets using genesis_meta.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very useful comment 🚀




<p>🙂 &lt;3</p>
Copy link
Contributor

@kienstra kienstra May 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea to test emoji rendering

<?php
/**
* Module Name: Pattern Preview Renderer
* Description: This module makes a front-end render of a block pattern, useful inside iframes or other places you wish to preview a block pattern.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea to add 'useful inside iframes'

@mike-day
Copy link
Contributor

mike-day commented May 3, 2023

Nice work tackling this, @johnstonphilip! It was a tricky one.

@kienstra
Copy link
Contributor

kienstra commented May 3, 2023

Extra points: this also fixes GF-3778 for Genesis themes (Resolve preview errors in PM)

@johnstonphilip
Copy link
Contributor Author

johnstonphilip commented May 3, 2023

I had an odd hour this morning where generateblocks things weren't being styled right in the previews, but with no changes, it fixed itself.

I'm leaving myself a breadcrumb here in case it happens again, but the styles from GenerateBlocks are output as an inline style in the tag like this:
<style id='generateblocks-inline-css'>

@johnstonphilip
Copy link
Contributor Author

I've found that generateblocks seems to attach post meta to posts called _generateblocks_dynamic_css_version, which determines whether any generate blocks inline css gets loaded:

https://github.com/tomusborne/generateblocks/blob/e0b4e467256bfe7543ef82c395b175c5cabc250f/includes/class-enqueue-css.php#L210

Since we are not in a post context here (pattern only), there's no post meta, and thus, the CSS doesn't load.

The reason why it worked unexpectedly is because while I was testing, I had created a new post in WP, and put generateblocks on that post. When I saved, it added that post meta to the post.

In our preview, the global $post object WordPress sets up is just the latest post. So because I had done that, the post_meta did suddenly exist, and cause the generateblocks inline styles to load.

So to fix this, we'll have to mock that post meta, possibly in a compat file for generate blocks.

@johnstonphilip
Copy link
Contributor Author

I was able to mock the entire post object following this awesome tutorial (kudos @andykeith!):
https://barn2.com/blog/create-fake-wordpress-post-fly/

This fixes a few of the workarounds we had to do. By using the block pattern code as the post_content on the mocked post object, we can get rid of our entire do_the_content_things function, and just rely on core's normal rendering with the_content.

@kienstra
Copy link
Contributor

kienstra commented May 3, 2023

I was able to mock the entire post object…

Oh nice, that should make #153 not needed

Copy link
Contributor

@dreamwhisper dreamwhisper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@johnstonphilip I think this is good! Nice work!

@johnstonphilip
Copy link
Contributor Author

Awesome, I shall merge now.

@johnstonphilip johnstonphilip merged commit e308589 into main May 4, 2023
@johnstonphilip johnstonphilip deleted the try/fix-preview-issues branch May 4, 2023 19:03
Comment on lines +104 to +128
$wp_query->is_single = false;
$wp_query->is_attachment = false;
$wp_query->is_archive = false;
$wp_query->is_category = false;
$wp_query->is_tag = false;
$wp_query->is_tax = false;
$wp_query->is_author = false;
$wp_query->is_date = false;
$wp_query->is_year = false;
$wp_query->is_month = false;
$wp_query->is_day = false;
$wp_query->is_time = false;
$wp_query->is_search = false;
$wp_query->is_feed = false;
$wp_query->is_comment_feed = false;
$wp_query->is_trackback = false;
$wp_query->is_home = false;
$wp_query->is_embed = false;
$wp_query->is_404 = false;
$wp_query->is_paged = false;
$wp_query->is_admin = false;
$wp_query->is_preview = false;
$wp_query->is_robots = false;
$wp_query->is_posts_page = false;
$wp_query->is_post_type_archive = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to comment after merge, but are these = false; statements needed?

Many are false by default.

$wp_query->is_post_type_archive = false;

// Update globals.
$GLOBALS['wp_query'] = $wp_query; // phpcs:ignore WordPress.WP.GlobalVariablesOverride.Prohibited
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed? The lines above mutate the global $wp_query

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to comment after the fact.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants