#16810 closed defect (bug) (fixed)
hide-if-no-js not working on Most Used link
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | 3.3 |
| Component: | Administration | Version: | |
| Severity: | minor | Keywords: | has-patch 3.3-early |
| Cc: | azizur |
Description
The Most Used link of hierarchical taxonomy like Category is shown on Post page with Java script disabled, which should get hidden by default.
The tab has hide-if-no-js class but it gets overridden with display:inline somehow.
Also shows on WordPress.com sites.
Attachments (2)
Change History (16)
comment:2
in reply to:
↑ 1
deepak.seth — 2 years ago
Replying to hakre:
Can you add a link on a wp.org install to reproduce it more easily?
To recreate the problem: disable the javascript->open the add new post page->here you can see the most used link on category widget,though i think it shouldn't be visible and it doesn't work either.
solarissmoke — 2 years ago
make sure -no-js styling doesn't get overridden by more specific instructions elsewhere
comment:3
solarissmoke — 2 years ago
- Keywords has-patch added
- Keywords 3.3-early added
- Milestone changed from Awaiting Review to Future Release
I'm comfortable with this patch. Early 3.3.
comment:6
SergeyBiryukov — 21 months ago
- Milestone changed from Future Release to 3.3
I'm generally very much against using !important anywhere but perhaps it's warranted in this case.
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In [18664]:
comment:9
solarissmoke — 21 months ago
Turns out this causing some undesirable side-effects, maybe !important is a bad idea after all. See #18656.
comment:10
solarissmoke — 21 months ago
- Resolution fixed deleted
- Status changed from closed to reopened
SergeyBiryukov — 21 months ago
So this probably should be fixed on a case-by-case basis.
16810.patch fixes the initial reported issue with the "Most Used" link.
comment:12
solarissmoke — 21 months ago
When I looked into this the first time I found at least 3-4 other cases where the same thing was happening. I can't remember where they were now but will see if I can find them.
Fixing them on a case-by-case basis is going to be tedious to maintain, because any change to the specificity of the selectors in future could cause the problem to resurface. That said, I can't think of a less awkward solution either.
comment:13
azaozz — 21 months ago
- Resolution set to fixed
- Status changed from reopened to closed
In [18668]:
comment:14
duck_ — 19 months ago
In [19179]:

Can you add a link on a wp.org install to reproduce it more easily?