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

Blank Page when adding new article #2702

Closed
karmatosed opened this issue Sep 8, 2017 · 10 comments

Comments

Projects
None yet
7 participants
@karmatosed
Copy link
Member

commented Sep 8, 2017

This was reported on the forums: https://wordpress.org/support/topic/blank-page-when-addin-new-article/

Hi, i’ve tried Gutenberg on 2 on my sites and it show blank page when i trie to add new article. The Editor show during few second and disappear. On the console, i see this error :
I have disabled all plugins, but the problem remains.

react-dom.min.912dc6cf.js:4 TypeError: Cannot read property 'level_1' of undefined at index.js:22 at n (index.js:6) at o (index.js:6) at t.value (index.js:22) at t.value (index.js:22) at d (react-dom.min.912dc6cf.js:6) at c (react-dom.min.912dc6cf.js:6) at k (react-dom.min.912dc6cf.js:6) at u (react-dom.min.912dc6cf.js:6) at p (react-dom.min.912dc6cf.js:6)

I’ve tried several themes such as generatepress, huemann or Twenty Seventeen. it’s not multisite. On Firefox, same things with error such as

TypeError: e.capabilities is undefined this.wp.editor</N</<.value/<@https://website.net/wp-content/plugins/gutenberg/editor/build/index.js?ver=1504771096:22:66406 n@https://website.net/wp-content/plugins/gutenberg/editor/build/index.js?ver=1504771096:6:21797 o@https://website.net/wp-content/plugins/gutenberg/editor/build/index.js?ver=1504771096:6:38312 this.wp.editor</N</<.value@https://website.net/wp-content/plugins/gutenberg/editor/build/index.js?ver=1504771096:22:66383 this.wp.editor</N</<.value@https://website.net/wp-content/plugins/gutenberg/editor/build/index.js?ver=1504771096:22:66477 d@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:8044 c@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:7921 k@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:10250 u@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:23202 p@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:23668 v@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:24215 k@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:26488 E@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:26060 Bu/p.enqueueSetState@https://website.net/wp-content/plugins/gutenberg/vendor/react-dom.min.912dc6cf.js:6:6195 n.prototype.setState@https://website.net/wp-content/plugins/gutenberg/vendor/react.min.c7397a88.js:4:3957 this.wp.components</t.a/</r</<.value@https://website.net/wp-content/plugins/gutenberg/components/build/index.js?ver=1504771096:6:188923 this.wp.components</t.a/</r</<.value/<@https://website.net/wp-content/plugins/gutenberg/components/build/index.js?ver=1504771096:6:189966 this.wp.components</E/</<@https://website.net/wp-content/plugins/gutenberg/components/build/index.js?ver=1504771096:6:146061 this.wp.components</E/<@https://website.net/wp-content/plugins/gutenberg/components/build/index.js?ver=1504771096:6:145931 this.wp.components</e.exports/u@https://website.net/wp-content/plugins/gutenberg/components/build/index.js?ver=1504771096:6:144182

@notnownikki

This comment has been minimized.

Copy link
Member

commented Sep 8, 2017

It looks like that particular error came from editor/sidebar/post-author/index.js were we have:

        getAuthors() {
                // While User Levels are officially deprecated, the behavior of the
                // existing users dropdown on `who=authors` tests `user_level != 0`
                //
                // See: https://github.com/WordPress/WordPress/blob/a193916/wp-includes/class-wp-user-query.php#L322-L327
                // See: https://codex.wordpress.org/Roles_and_Capabilities#User_Levels
                const { users } = this.props;
                return filter( users.data, ( user ) => {
                        return user.capabilities.level_1;
                } );
        }

There are various other places in the code where we rely on capabilities existing, so I'm not keen on patching all of those instances, it feels like we should be ensuring that it exists as an empty object.

@swissspidy

This comment has been minimized.

Copy link
Member

commented Sep 9, 2017

@mkaz

This comment has been minimized.

Copy link
Member

commented Sep 19, 2017

I host two different blogs on the same server (neither multisite, both totally separate direcrories) and I'm seeing this issue on one of them but not the other. I've done a bit of investigating but can't figure out the difference between the two, both running same version of WP. Both installed via wp-cli, both have only one user which is an Administrator.

Any suggestions on troubleshooting or gathering more data for this issue?

Without the core change, it could be solved by checking if capabilities is set or not but I'm not sure what the proper return should be - if not defined block or allow. For my situation, it would seem awkward to block an Administrator - for another it could be granting rights to someone who shouldn't.

Also @youknowriad the linked documentation discourages use of the level capabilities, not sure if that is also why it works for one instance and not another

@notnownikki

This comment has been minimized.

Copy link
Member

commented Sep 19, 2017

I saw there are a number of places where we rely on capabilities being there, although sometimes we're referencing user.data.capabilities

All the files that reference capabilities are:

editor/header/tools/publish-button.js
editor/sidebar/post-schedule/index.js
editor/sidebar/post-visibility/index.js
editor/sidebar/post-sticky/index.js
editor/sidebar/post-pending-status/index.js
editor/sidebar/post-author/index.js

Perhaps we should be defaulting this to an empty object?

@mkaz

This comment has been minimized.

Copy link
Member

commented Sep 19, 2017

@notnownikki that is my question/concern? Defaulting to empty object would fail the condition, which I think wouldn't allow me to edit since the author check is failing, I'm not sure if that is a better user experience than the blank page.

@notnownikki

This comment has been minimized.

Copy link
Member

commented Sep 19, 2017

Yes you're absolutely right... Well at least I listed the files we need to look at when solving this 😁

@Kilian

This comment has been minimized.

Copy link

commented Nov 1, 2017

Is there any intermediary solution available for this?

@mkaz

This comment has been minimized.

Copy link
Member

commented Nov 1, 2017

@Kilian I found the issue I had was either a plugin or permission conflict. I was getting an error on my install when I was trying to update WP Super Cache plugin, I fixed my permissions and updating the plugin and it resolved this issue. I'm still not quite sure why, but fixed it all for me.

@youknowriad

This comment has been minimized.

Copy link
Contributor

commented Dec 21, 2017

Fixed by #4122

@hitolonen

This comment has been minimized.

Copy link

commented Aug 20, 2018

This is still happening with:

  • new en_AU site installed with wp-cli (v 4.9.8) to localhost
  • only core plugins (which are not active)
  • theme twenty seventeen
  • role Administrator
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.