webcrack icon indicating copy to clipboard operation
webcrack copied to clipboard

[plugin] plugin to support WordPress Gutenberg specific blocks features (including how it injects `window.React`, `window.wp.element`, etc) within JSX decompilation

Open 0xdevalias opened this issue 9 months ago • 0 comments

Mostly creating this based on the exploration I did in https://github.com/j4k0xb/webcrack/issues/10#issuecomment-2693645060 before I realised it was likely unrelated to more core React / JSX handling.

I suspect the bulk of this is niche enough that it wouldn't make sense to include in core, but would be a good candidate for a plugin as per https://github.com/j4k0xb/webcrack/issues/143#issuecomment-2692345330 / https://github.com/j4k0xb/webcrack/issues/143#issuecomment-2692517232

This is also aligned to wakaru's proposed module-detection feature:

  • https://github.com/pionxzh/wakaru/issues/41

@j4k0xb I also don't expect this to be something you create; but figured since I already did the deeper exploration in this repo, I may as well create a standalone reference point for it, even if this issue ends up getting closed.


From my prior exploration:

Edit 2: Looking a bit deeper, I think window.wp.element relates more specifically to how the Wordpress Gutenberg editor may inject things:

  • https://github.com/search?type=code&q=window.wp.element
  • https://wordpress.org/gutenberg/
  • https://github.com/WordPress/gutenberg
    • https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/
      • https://github.com/WordPress/gutenberg/tree/trunk/packages/create-block
        • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/es5/index.js.mustache#L9-L14
          • We can see wp.element.createElement / etc usage here
          • And where it's reading from window.wp here
            • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/es5/index.js.mustache#L71

Specifically in the 'plain JS' usage:

  • https://github.com/hrsetyono/gutenberg-tutorial/blob/476f19ee0413ebf719df8981dc982b6aa5b64348/README.md?plain=1#L19-L31
  • https://developer.wordpress.org/block-editor/getting-started/fundamentals/javascript-in-the-block-editor/#javascript-without-a-build-process
    • When you opt out of a build process, you interact directly with WordPress’s JavaScript APIs through the global wp object.

      • https://developer.wordpress.org/block-editor/reference-guides/packages/#using-the-packages-via-wordpress-global
        • JavaScript packages are available as a registered script in WordPress and can be accessed using the wp global variable.

      • https://www.npmjs.com/org/wordpress

So using window.wp.element would map to a version of @wordpress/element, provided by the backend through the window.wp global:

  • https://github.com/WordPress/gutenberg/tree/trunk/packages/element
  • https://developer.wordpress.org/block-editor/reference-guides/packages/packages-element/

Whereas in the non-static version, we can see that registerBlockType directly refers to the imported Edit / Save, which seem to handle their own imports, and/or use a JSX transform defined elsewhere in the build chain:

  • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/block/index.js.mustache#L26-L43
  • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/block/edit.js.mustache
  • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/packages/create-block/lib/templates/block/save.js.mustache
  • https://developer.wordpress.org/block-editor/getting-started/fundamentals/javascript-in-the-block-editor/#javascript-with-a-build-process

We can also see that the window.React global might come from Wordpress Gutenberg as well, as we can see from this example code that injects it:

  • https://github.com/search?q=repo%3AWordPress%2Fgutenberg%20window.React&type=code
    • https://github.com/WordPress/gutenberg/tree/2103d5021066593f25f2baae9038b0cf23372b7f/packages/editor#blockcontrols
    • https://github.com/WordPress/gutenberg/tree/2103d5021066593f25f2baae9038b0cf23372b7f/packages/editor#richtext

We also get another clue here, where again window.React is injected into the function, and then a followup note to that:

  • https://github.com/WordPress/gutenberg/blob/2103d5021066593f25f2baae9038b0cf23372b7f/docs/how-to-guides/plugin-sidebar-0.md#step-1-get-a-sidebar-up-and-running
    • For this code to work, those utilities need to be available in the browser, so you must specify wp-plugins, wp-editor, and react as dependencies of your script.

    • Here is the PHP code to register your script and specify the dependencies:

      function sidebar_plugin_register() {
      	wp_register_script(
      		'plugin-sidebar-js',
      		plugins_url( 'plugin-sidebar.js', __FILE__ ),
      		array( 'wp-plugins', 'wp-editor', 'react' )
      	);
      }
      add_action( 'init', 'sidebar_plugin_register' );
      

So I guess, similar to the comment made in https://github.com/j4k0xb/webcrack/issues/143#issuecomment-2692345330, the deeper specifics of this may belong in a separate plugin instead of webcrack core.

Though.. I do wonder if the window.React (assigned to a variable) usage is generic enough that it might make sense to include in core?

  • https://github.com/search?type=code&q=window.React

Originally posted by @0xdevalias in https://github.com/j4k0xb/webcrack/issues/10#issuecomment-2693645060

See Also

  • https://github.com/j4k0xb/webcrack/issues/152

0xdevalias avatar Mar 03 '25 10:03 0xdevalias