Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editor encounters unexpected error seemingly at random #4043

donnapep opened this Issue Dec 15, 2017 · 5 comments


None yet
6 participants
Copy link

donnapep commented Dec 15, 2017

Issue Overview

I'm getting the following message when opening any post or page on my site: "The editor has encountered an unexpected error."

Steps to Reproduce (for bugs)

This issue has been plaguing me for awhile, but unfortunately I haven't been able to reliably reproduce it. I'm logging it anyway in the hopes that someone may know what's happening. Here's the required setup:

  1. Download the add/module-block branch of the Sensei plugin.
  2. Do an npm run build before copying the plugin folder to a site and activating it.
  3. Enable Sensei's REST API by adding the following to the wp-config.php file:
  1. Go to Courses > Modules and create a new module. Be sure to include a description.
  2. Create a course by going to Courses > Add New.
  3. Add the Module block and select the module you just created from the dropdown.
  4. Save your changes and publish.
  5. Play around in the admin and on the front-end. At some point, you will eventually encounter the following error whenever you try to open a post, page or CPT in the WordPress admin:
    activatemode error
    From this point on, your site is effectively useless. Clicking on Attempt Recovery does nothing but generate another this.activateMode is not a function console error. Only by deactivating Gutenberg is the site functional again. The issue is still present after re-activating.

I haven't been able to either reliably reproduce this issue or figure out a way to get it working again once the error initially shows up.

Chrome 62.0.3202.94 on MacOS 10.12.6 and WordPress 4.9.1, Gutenberg 1.9.1.

Expected Behavior

The editor should show when I try to edit an existing post/page or add a new post/page.

Current Behavior

I receive "The editor has encountered an unexpected error." when editing an existing post/page or when adding a new post/page.

Screenshots / Video

Line 718 of index.js referenced in the console error:
screen shot 2017-12-15 at 12 11 57 pm

And line 9540:
screen shot 2017-12-15 at 12 12 22 pm

Possible Solution

There's some sort of random issue with including a third party block that does not appear to be related to anything the block is doing. Everything can be working just fine one minute, and the next I'm getting the above error message for all posts/pages/CPTs, not just the one I added the block to. Undoing any development changes to the block that I may have made does not resolve the issue. Commenting out the line that enqueues the block's JS eliminates the error, but of course that isn't a proper solution.


  • Tests
  • Documentation

@donnapep donnapep changed the title Editor encounters unexpected error Editor encounters unexpected error seemingly at random Dec 15, 2017


This comment has been minimized.

Copy link

aduth commented Dec 15, 2017


This comment has been minimized.

Copy link

billerickson commented Jan 23, 2018

I'm seeing the same issue with a custom block I developed. My block doesn't involve media in any way (it dynamically lists subpages), but when active I get the above error and the Image block doesn't work:



This comment has been minimized.

Copy link

JasonHoffmann commented Jan 27, 2018

I recently ran into a similar problem and ran into a very strange issue. After going through debugging I noticed that the issue came when I imported a module from lodash, which @billerickson module is doing as well ( We are both importing like this:

import { times } from 'lodash';

The problem is that the babel-plugin-lodash plugin ( was not installed. To fix this issue, all I did was install that babel plugin, and then add it to my .babelrc plugin to use.

Either that or import the lodash modules like:

import times from 'lodash/times';

I have no idea why this is causing an issue in activateMode, but that solved the issue for me


This comment has been minimized.

Copy link

aduth commented Jan 28, 2018

Aha, I think it may be the case that Lodash's global _ is overriding the Underscore.js global of the same name, so while this segment of code was written targeting Underscore, it's in-fact using Lodash:

Unlike Underscore.js's each method, Lodash's equivalent does not support the third context argument. Since the above code is dependent upon the context being provided for this to be bound correctly in the call to this.activeMode, it otherwise fails.

Closing as this is more of an issue with plugin authors overriding WordPress default globals. The above-mentioned workaround should work if you have a build system in place. Otherwise, the snippet below should also serve as a fix when registering your Lodash script, though I have not tested to confirm:

wp_enqueue_script( 'lodash', '...' );
wp_add_inline_script( 'lodash', 'window.lodash = _.noConflict();', 'after' );

(This would also mean you have to reference Lodash via lodash, though you could create an alias back to _ so long as it's scoped to your code and not replacing the global _ object)

@aduth aduth closed this Jan 28, 2018

keesiemeijer added a commit to keesiemeijer/related-posts-by-taxonomy that referenced this issue Feb 17, 2018

@jomurgel jomurgel referenced this issue Apr 19, 2018


Recent Posts Block #9

6 of 7 tasks complete

walfly pushed a commit to joincivil/civil-publisher-wordpress-plugin that referenced this issue Oct 11, 2018

Fix lodash/underscore conflicts and use WP-supplied underscore
The `_.noConflict` fix handles use of lodash by Civil dependencies, but
using lodash in post panel was running into this bug anyway
WordPress/gutenberg#4043 so I give up, let's
use underscore. Lodash is better, but underscore is loaded on all WP
admin pages anyway so yeah.

This comment has been minimized.

Copy link

natesymer commented Dec 15, 2018

For what it's worth, webpack users can use an external for lodash and that fixes the problem. Wordpress exposes lodash as window.lodash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.