Can't click login button after being logged out.

Describe the bug

After being logged out of the CMS, there seems to be a lot of z-index issues with the login flow. I can’t click the Login with Netlify Identity button at all.

To Reproduce

1. Log out of your admin, or clear your application cache so you are forced to login with Netlify Identity again.
2. Navigate to your admin dashboard to get to the login flow.
3. Try clicking the Login with Netlify Identity button

Expected behavior

Clicking the Login with Netlify Identity button should prompt an email and password modal to pop up over the button

Screenshots

Applicable Versions:

• Netlify CMS version: 2.11.11
• Git provider: GitHub
• OS: MacOS 10.14.6
• Browser version Chrome 79

CMS configuration

CMS.init({
  config: {
    backend: {
      name: 'git-gateway',
      repo: 'https://github.com/mixmaxhq/mixmax-website',
      branch: process.env.NETLIFY_BRANCH || 'master',
      use_large_media_transforms_in_media_library: true,
    },
    load_config_file: false,
    display_url: 'https://mixmax.com',
    media_folder: 'static/assets',
    public_folder: '/assets',
    publish_mode: 'editorial_workflow',
    show_preview_links: true,
    collections: [
      primary,
      feature,
      integrations,
      useCases,
      blog,
      hub,
      legal,
      landingPages,
    ],
  },
});

Additional context

[bobbymart1n]

Closing this issue. Adding enableIdentityWidget: false, to gatsby-plugin-netlify-cms options in gatsby-config.js solved the problem. I’m now running into another issue where adding that property breaks page previews in the CMS.

Edit: From further investigations gatsby-plugin-netlify-cms overrides the regular Netlify CMS login flow with iframes that seem to have additional functionality like Forgot password. Turns out the issue we were having is that we were manually initing the CMS, and for some reason, the load_config_file: false property and value is causing the iframes to override the Login with Netlify Identity button. Commenting that line in the init fixed the issue.

We are still investigating further, and I’ll update more soon.

[tomrutgers]

This is actually a separate issue I’ve been having. If you use /admin/ it should direct properly

You can read up on that discussion here: #332