WP 6.6 RC1: plugin breaks after update #62923

Activity

1. elzadj

   added

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   on Jun 27, 2024
2. tomusborne commented on Jun 27, 2024

   

   tomusborne

   on Jun 27, 2024

   Last edited by tomusborne

   More actions

   I'm experiencing this as well.

   Something as simple as this causes this same error to occur:

   async function testing() {
       return true;
   }
   
   function App() {
       useEffect( () => {
           testing();
       }, [] );
       
       return null;
   }
   

   This results in the following error: Uncaught TypeError: Cannot read properties of undefined (reading 'mark')

   UPDATE - managed to fix this. We had wp-polyfill loading on the page that was causing this error. Removed the code requiring that dep and all is well.

   👀React with 👀1Reacted by Fauzan Edris
3. t-hamano

   added

   Needs TestingNeeds further testing to be confirmed.Needs further testing to be confirmed.

   on Jun 28, 2024
4. elzadj commented on Jun 28, 2024

   

   elzadj

   on Jun 28, 2024

   Last edited by elzadj

   Author

   More actions

   UPDATE - managed to fix this. We had wp-polyfill loading on the page that was causing this error. Removed the code requiring that dep and all is well.

   Thanks for your help! I can confirm that the cause of the Uncaught TypeError: Cannot read properties of undefined (reading 'mark') is indeed the wp-polyfill script, or something connected to it.

   It comes from build/index.asset.php dependency by default.

   However, our custom blocks don't work.

   and we still get

   Warning: You are importing createRoot from "react-dom" which is not supported. You should instead import it from "react-dom/client".
     | printWarning | @ | react-dom.development.js:86
   -- | -- | -- | --
     | error | @ | react-dom.development.js:60
     | createRoot$1 | @ | react-dom.development.js:29846
     | initializeEditor | @ | edit-post.js?ver=67d…9060f223df7e7e:3312
     | (anonymous) | @ | post.php?post=396406&action=edit:2084
   

   The error comes from the file edit-post.js, from the line const root = (0,external_wp_element_namespaceObject.createRoot)(target); , I see it even with all the plugins deactivated:

   /**
    * Initializes and returns an instance of Editor.
    *
    * @param {string}  id           Unique identifier for editor instance.
    * @param {string}  postType     Post type of the post to edit.
    * @param {Object}  postId       ID of the post to edit.
    * @param {?Object} settings     Editor settings object.
    * @param {Object}  initialEdits Programmatic edits to apply initially, to be
    *                               considered as non-user-initiated (bypass for
    *                               unsaved changes prompt).
    */
   function initializeEditor(id, postType, postId, settings, initialEdits) {
     const isMediumOrBigger = window.matchMedia('(min-width: 782px)').matches;
     const target = document.getElementById(id);
     const root = (0,external_wp_element_namespaceObject.createRoot)(target);
     (0,external_wp_data_namespaceObject.dispatch)(external_wp_preferences_namespaceObject.store).setDefaults('core/edit-post', {
       fullscreenMode: true,
       themeStyles: true,
       welcomeGuide: true,
       welcomeGuideTemplate: true
     });
     (0,external_wp_data_namespaceObject.dispatch)(external_wp_preferences_namespaceObject.store).setDefaults('core', {
       allowRightClickOverrides: true,
       editorMode: 'visual',
       fixedToolbar: false,
       hiddenBlockTypes: [],
       inactivePanels: [],
       openPanels: ['post-status'],
       showBlockBreadcrumbs: true,
       showIconLabels: false,
       showListViewByDefault: false,
       isPublishSidebarEnabled: true
     });
     (0,external_wp_data_namespaceObject.dispatch)(external_wp_blocks_namespaceObject.store).reapplyBlockTypeFilters();
   
5. elzadj commented on Jun 29, 2024

   

   elzadj

   on Jun 29, 2024

   Author

   More actions

   After some digging, managed to find this:

   1. Regarding Uncaught TypeError: Cannot read properties of undefined (reading 'mark') and polyfill: looks like @babel/preset-env doesn't really work with WP 6.6 RC1. I've tried the latest release and the latest alpha versions of the package, but ended up removing it from .babelrc.js - that fixed the error, and now our custom blocks work, aside of the point 2 problems:
   2. Regarding Warning: You are importing createRoot from "react-dom" which is not supported. You should instead import it from "react-dom/client". - this warning shows for createRoot that we import from @wordpress/element package, I've tried versions 6.2.0 and 5.35.0 - they both show that error for import { createRoot } from '@wordpress/element'; .
      I also see that error with all plugins deactivated, with 2024 theme, on a new page (note: I have scripts debug enabled):
      
6. swissspidy commented on Jul 1, 2024

   

   swissspidy

   on Jul 1, 2024

   Member

   More actions

   FWIW, the You are importing createRoot from "react-dom" which is not supported warning is a known issue in Gutenberg itself and not caused by other plugins or anything. AFAIK it has to do with the way React is bundled in @wordpress/element. You can safely ignore this warning. (It's just a warning, not an error)

   ---

   As for the other issue at hand, it is indeed related to wp-polyfill. For context, as noted in this dev note, the wp-polyfill dependency is no longer included by default in WordPress, as it is only relevant for when you are targeting older browsers.

   Specifically, you are using generator functions in your code base while still targeting abandoned browsers like IE 11 that do not support generators.

   To address this, you need to either manually load the wp-polyfill dependency or you simply remove this line here in your Babel config:

   https://github.com/maxi-blocks/maxi-blocks/blob/6a47440d6a6eb8952f416ab8983397f245515f60/.babelrc.js#L23

   Your Babel config in general contains polyfills for things that have been added to browsers a long time ago. Those polyfills have long been deprecated because of that. You can basically remove all of them. I recommend just using @wordpress/babel-preset-default

   👍React with 👍4Reacted by Svitlana, mrleemon, Arie Cristian and Anh Tran
7. elzadj commented on Jul 1, 2024

   

   elzadj

   on Jul 1, 2024

   Author

   More actions

   To address this, you need to either manually load the wp-polyfill dependency

   Thanks for your help, now most of our custom blocks work, aside of blocks that use typesense-instantsearch-adapter. We are getting the same .mark error for lines like this one https://github.com/typesense/typesense-instantsearch-adapter/blob/20d7d9616a7829f87d806c73653dacef8e5d3fca/lib/SearchRequestAdapter.js#L478

   But I guess that's a question for typesense devs, going to create an issue there.
8. swissspidy commented on Jul 1, 2024

   

   swissspidy

   on Jul 1, 2024

   Member

   More actions

   Looks like typesense/typesense-instantsearch-adapter#112 applies to you

   In short: This script was built targeting older browsers such as IE11, where generators were not supported. It thus requires the regenerator runtime to be available (which wp-polyfill provides). You can either manually load wp-polyfill to make it available or try to follow the steps mentioned in that issue to load the script from source and let your webpack config do the bundling. That might be as simple as this:

   -import TypesenseInstantSearchAdapter from 'typesense-instantsearch-adapter';
   +import TypesenseInstantSearchAdapter from 'typesense-instantsearch-adapter/src/TypesenseInstantsearchAdapter.js';

   👍React with 👍1Reacted by Svitlana
9. swissspidy commented on Jul 3, 2024

   

   swissspidy

   on Jul 3, 2024

   Member

   More actions

   @elzadj Quick follow-up after looking into it again: I of course meant regenerator-runtime would need to be added manually, not wp-polyfill.

   👍React with 👍2Reacted by Svitlana and Gan Eng Chin
10. mboynes commented on Jul 10, 2024

    

    mboynes

    on Jul 10, 2024

    Contributor

    More actions

    I ran into this issue on a plugin as well even though that plugin uses @wordpress/dependency-extraction-webpack-plugin and, through that, was including wp-polyfill as a script dependency (and FWIW I confirmed that the wp-polyfill script was successfully being loaded in source HTML).

    I couldn't find a path to resolution, so I had to update the plugin's browserslist in order to get it working again.
11. swissspidy commented on Jul 10, 2024

    

    swissspidy

    on Jul 10, 2024

    Member

    More actions

    Yeah if you target Internet Explorer (which is abandoned) then you would include the regenerator code for no reason and would need to manually add regenerator-runtime as a dependency (instead of wp-polyfill -- the latest version of @wordpress/dependency-extraction-webpack-plugin fixes that for you). But just updating the browserslist config makes so much more sense and your users will be thankful for the smaller bundles :)

    👍React with 👍1Reacted by Fauzan Edris
12. swissspidy

    closed this as completedon Jul 11, 2024
13. FauzanEdris commented on Jul 18, 2024

    

    FauzanEdris

    on Jul 18, 2024

    More actions

    updated the @wordpress/dependency-extraction-webpack-plugin to version 6.3.0 solve the issue.

    https://www.npmjs.com/package/@wordpress/dependency-extraction-webpack-plugin/v/6.3.0

    thanks!
14. yonnic commented on Jul 18, 2024

    

    yonnic

    on Jul 18, 2024

    More actions

    The Pods Plugin is also affected by this problem and its minified code.
    How can i fix it manually with this wp-polyfill issue ?
    contacting Pods Author is no option as their support is dead
15. swissspidy commented on Jul 18, 2024

    

    swissspidy

    on Jul 18, 2024

    Member

    More actions

    @yonnic Their support is well and alive and they are working on this. See https://wordpress.org/support/topic/pods-not-working-with-wordpress-6-6-update/.

    👍React with 👍1Reacted by Svitlana

    👀React with 👀1Reacted by yonnic
16. rilwis commented on Sep 10, 2024

    

    rilwis

    on Sep 10, 2024

    Contributor

    More actions

    @swissspidy Is there any update about this issue?

    FWIW, the You are importing createRoot from "react-dom" which is not supported warning is a known issue in Gutenberg itself and not caused by other plugins or anything. AFAIK it has to do with the way React is bundled in @wordpress/element. You can safely ignore this warning. (It's just a warning, not an error)
17. swissspidy commented on Sep 10, 2024

    

    swissspidy

    on Sep 10, 2024

    Member

    More actions

    AFAIK it is supposed to be fixed in 6.7

    👍React with 👍3Reacted by Anh Tran, Stefan Lindberg and badasswp