Please assign this issue to me once it's moved to EB, as I'll get started on it early in this sprint and aim to have it ready for early testing 👍🏻

@tofumatt could you please expand IB to have more details because right now it is just a set of requirements that we want to achieve in this task? I want to know how we are going to use the new script, how we are going to register the block, how the new script will be loaded in gutenberg (using block.json?), how we are going to use the buttons render function to render them as block content, etc.

@eugene-manuilov Understood.

I added a proof-of-concept PR, as writing it out in the IB for this issue seemed quite awkward and I think the proof-of-concept PR does a better job expressing the general approach we'd take for this. I did amend the IB slightly but I think the proof-of-concept PR shows how we would approach this, please let me know if that's okay or if anything's unclear.

@tofumatt

I think the proof-of-concept PR does a better job expressing the general approach we'd take for this

This is true only when we are 100% sure that the taken approach is correct, but if something is off then this approach turns into a time waste approach. This is why we strongly discourage PR-as-IB approach and breaking this rule is not good because it encourages other engineers with less experience follow the same logic to start coding instead of thinking through how it should be implemented and writing it down as IB. 😄

I don't say that your PR is wrong, but this is the 30 points ticket and we need to think out everything well. Plus, I already see some things there that might be done differently or require additional work after you changed the approach how buttons were rendered. This is something that we should discuss here instead of PR comments. So, could you please write detailed IB with all what you think we need to do to achieve the goal of this ticket?

Here are some points that we need to think through or pay attention to when writing IB:

• If we use a magic class to render sign-in buttons, then we should probably update how we render them for WooCommerce and also use a magic placeholder to have less mess in the javascript script.
• We need to make sure that buttons do not render if the user is already logged in if this is not the WP login page (currently your PR breaks this).
• Do we really need to keep blocks in module files? I think this is a completely different asset type (a mix of js and css) which is worth keeping in its own folder. We can probably put it into ./blocks and implement blocks loading in the Assets class that can be extended with module specific blocks using a filter.
• The PHP class that is responsible for registering the block should have the register method that registers the block in a hook for the init action.
• Do we really need to use webpack to bundle block files? This is probably something that we can leave as is (unbundled) if we don't use imports but use global.wp.... when we need to get something from a WP package. Not sure what is the best practice here, WDYT?

If we use a magic class to render sign-in buttons, then we should probably update how we render them for WooCommerce and also use a magic placeholder to have less mess in the javascript script.

I don't understand—we use the existing WooCommerce class to attach a div to render the button in:

We need to make sure that buttons do not render if the user is already logged in if this is not the WP login page (currently your PR breaks this).

Good point, I've added it to the IB. I had planned to do this but mentioned it explicitly.

Do we really need to keep blocks in module files? I think this is a completely different asset type (a mix of js and css) which is worth keeping in its own folder. We can probably put it into ./blocks and implement blocks loading in the Assets class that can be extended with module specific blocks using a filter.

I figured keeping them close to their related modules made sense, but your approach makes sense too. But blocks are not just JS/CSS; this block is dynamic but all blocks need some PHP. Still, I've updated the IB to put the block code (including the PHP) in its own folder, elsewhere in the repo 👍🏻

The PHP class that is responsible for registering the block should have the register method that registers the block in a hook for the init action.

I've noted this in the IB 👍🏻

Do we really need to use webpack to bundle block files? This is probably something that we can leave as is (unbundled) if we don't use imports but use global.wp.... when we need to get something from a WP package. Not sure what is the best practice here, WDYT?

Block files include JSX that needs to be compiled, plus we might want to use modules in them eventually. Even if we didn't want to use code from a node module outside of what WordPress offers in the global.wp variables, we need to use Babel to compile the JSX.

Ok, knowing this is a time sensitive issue, i am going to approve IB and we will continue discussing it in PR if something is missing 👍. IB ✔. Moving it to Execution and assigning to you, @tofumatt.

Now we have the workspaces setup we could use workspaces here as the block does not need to share any plugin packages and might even be easier to develop with more up to date packages.

This could be a follow up issue if needed because of the time sensitive nature of this issue.

@mohitwp

1. I can't reproduce the issue, can you provide a screen recording and exact steps to reproduce? I'm not sure what's happening there but I can see the SiwG block using Twenty Twenty-Five without issue.
2. The Sign in with Google block can be a bit variable in width on the front-end too, but we can probably improve the block in edit mode. Gutenberg blocks aren't exactly meant to be a WYSIWYG editor, so if the blocks and frontend are slightly different that's okay. But improving this along with alignment (part 3) is worth doing in a follow-up issue, I think.
3. That makes sense. Can you please open a new issue for block improvements and I'll get it moving through the board for a subsequent release? 👍🏻

@tofumatt

I attached the video under details, but it is a bit long. Here is a shorter version—In this video, when I add the SIWG block to the header or footer, the editor does not show its preview. However, if I add it under the page content, the preview is displayed correctly.

Steps-

• Open Frontend of the site.
• Click on 'Edit site' option under Admin bar.
• You will get navigate to WP editor.
• Now add 'SIWG' Block under Site header or Footer.
• Under editor block will not appear.
• Now add 'SIWG' block under the page content.
• This time block will appear under the editor.

QA Update ⚠

Tested on main environment.

@tofumatt
I tested this again, and I'm still able to reproduce the issue. The block is not appearing in the backend under the WP editor when added to the Header or Footer. Could you please check again?

@mohitwp This is now ready to test on main (and on develop, it was previously not merged there). 👍🏻

QA Update ✅

• Tested on main environment.
• Verified observation 1 and 2 mentioned above is resolved now.
• Tested on WordPress versions 5.8, 5.9, 6.0.3, 6.1.1, 6.6.2, 6.7.1, and 6.7.2 using default WordPress themes.
• Verified that the block preview now displays correctly when adding a block inside the header or footer template.
• Confirmed that the block preview in the WordPress editor now more closely matches its actual size as it appears on the front end.

cc @wpdarren

Note: I tested this across different WordPress versions and noticed that the SIWG module throws a fatal error on WordPress 6.0.3 and earlier versions. Additionally, the SIWG option and block do not appear on the front end even after connecting SIWG.

I created a separate issue #10266 for this.