Edit Category Button and New Category Button not working

I have a production instance and testing instance, both at 1.3.0.beta7, and on both, as an admin, I cannot edit a category or create a new category. When the edit category or create category buttons are clicked, the transparent gray modal appears, but there is no dialog for edit or new.

The failing behaviour has been verified in different browsers. There are no javascript or network errors taking place. Nothing obvious shows up in discourse’s syslog.

I’ve disabled plugins and recent changes for SSO with no change in behavior. We have, in the past used these features. Any clues/hints on troubleshooting to understand root cause?

3 Likes

I cannot repro this, here (we’re on the Ember 1.11 branch temporarily) or on a new Digital Ocean install.

Same issue @Eric_Hoxworth described is happening for other modals in the admin. For example, when I go to Profile>Preferences and try to edit the avatar or bg image, the same thing happens.

What plugins do you have installed?

instance 1 plugins - zendesk, discourse-tagging 0.1, docker_manager 0.1, lazyYT 1.0.1, poll 0.9
instance 2 plugins - docker_manager 0.1, lazyYT 1.0.1, poll 0.9

Both instances are at Discourse v1.3.0.beta7 +17 and both are exhibiting this behavior.

I’m running 1.3.0.beta7+20 and I can’t recreate this either. The modal opens 100% of the time for both New Category and Edit Category. Do you see any errors in the Console window of your browser?

Additional info:

I upgraded instance 2 to v1.3.0.beta7 +20 which resulted in no change in behavior - I didn’t expect this to work, but noticed the 3 commits since last night and thought I would give it a try.

I launched a new container instance (same server) and on this new instance I am not seeing the faulty behavior.

I decided to remove the custom CSS/HTML on our instance 2 and the faulty behavior no longer appears. Narrowing down the culprit, it seems our usage of Bootstrap v3.3.4 css for some of our header area styling is causing this error. Once the link to the Bootstrap css is removed, the site behaves as expected.

We were calling Bootstrap v3.3.4 css with the following in the tab on Customize CSS/HTML in admin settings:

<!-- Latest compiled and minified CSS -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.min.css">

Thinking we might have a cross-site calling issue, I copied the contents of the destination into the tab, but still experienced the faulty behavior.

Looks like there might be a conflict with Bootstrap v3.3.4 css and Discourse css causing the “cannot launch modal” issue we are seeing.

1 Like

Well that is good that you were able to narrow it down to Bootstrap. Very odd that it caused such a conflict though (not something I would have expected).

@cpradio - There are no errors in the Console window.

Can I ask what your dependency is for needing Bootstrap 3.3.4? Any way you can just use the version that ships within Discourse?

Looks like Discourse is using v2.0.4 (https://github.com/discourse/discourse/blob/17d07a8b9a3db9d963f9d7d5bd73504984ef3188/app/assets/stylesheets/vendor/bootstrap.scss).

Bootstrap 3.3.4 gives us better link formatting in the header area. Bootstrap 2.0.4 did not provide the correct styling.

IMHO, if Discourse provides a way to update then there probably should be a “do so at your own risk” warning so users know this may be an issue.

Discourse initially used the Bootstrap CSS, but it was gradually ripped out; the styles that were actually used were copied into the Discourse stylesheets. I recommend that you do this as well.

@riking - Pretty much what we’ve done. Just ripped out what we needed from bootstrap and updated the Customize->CSS/HTML section. Things are now working as expected.

It’s obvious now, but the moral of the story is if you are having issues with wonky page behavior, check your CSS and other customization in the Customize->CSS/HTML section.

2 Likes