Recent changes to break bugzilla plugin



5 years ago
5 years ago


(Reporter: brett, Assigned: nmaul)


Dependency tree / graph




5 years ago
Hello, we've been editing the wiki page for our upcoming Foundation all hands next Monday, and some recent changes seem to have broken our css here:

ie the embedded BZ tickets are now too wide.  

the Webmaker team uses embedded bugzilla tickets as our sprint and roadmapping tool, so this is a fairly troublesome issue for us.

Could we please roll these changes back, or let us know how we could use the BZ embed differently?

This is particularly pressing for us as we are planning a series of sprints for our work week on Monday.

Thank you
Depends on: 858844
Assignee: server-ops-webops → nobody
Component: WebOps: IT-Managed Tools →
Product: Infrastructure & Operations → Websites
QA Contact: nmaul


5 years ago
Assignee: nobody → nmaul
The cause of this was nothing to do with recent changes, but due to the use of HTML instead of wiki markup in the content (or more precisely, an error in the HTML markup).

I've sorted out the relevant section and you should have no more problems with the width.
Assignee: nmaul → nobody
Last Resolved: 5 years ago
Resolution: --- → FIXED
Cancel that (in part). Initially it operated correctly for me post-edit (ie aligned left) but now it and other bugzilla-listing tables are not.
Resolution: FIXED → ---
Assignee: nobody → nmaul
Yeah, it's still happening with the GMO theme, the default theme when you sign out.
Flags: needinfo?(ckoehler)
OS: Mac OS X → All
Hardware: x86 → All
Ooops sorry, wrong needinfo.
Flags: needinfo?(ckoehler)

Comment 5

5 years ago
Oddly, when you "preview", it looks fine.
Wrapping in a DIV sorts it in the mean time (added to page noted & tested post-preview)

Comment 7

5 years ago
Allison, you are a livesaver. We'll take that for now!
(one 'L' ;-P )

Blame it on still being up as upgrading a server and watching the RedSox (01:38 where I am)

Comment 9

5 years ago
I've worked up a commit that seems to fix this for me on (not applied until the PR lands):

It worked for me whilst writing it up, but I have not thoroughly checked for regressions. Once that's landed we can do more thorough testing in dev or stage, then roll out to prod. I'm not too worried, but definitely would like someone else to look over it. r+ anyone? I don't know what I'm doing. :)

The main problem here is that the Bugzilla extension is written to MediaWiki pre-1.17 standards, and isn't playing well with more modern versions. Specifically, 1.17 introduced the "ResourceLoader" system for loading Javascript and CSS resources, including dependencies. This Bugzilla extension uses the old scheme of simply hacking in calls to load things- no real dependency management, no way for different extensions to do different things.

Once we stopped the Bugzilla extension from loading its own jQuery (which was done to fix normal MW tables not being sortable), the formatting here went wonky.

This commit is a reasonable hack (IMO), but should not be considered a complete fix. In reality I believe the Bugzilla extension needs a more thorough comb-over to bring it up to MW 1.17+ standards. Off the bat I notice the footer wraps oddly now. I'm sure there are other quirks as well. But, this at least fixes the main issue.

Comment 10

5 years ago
> Blame it on still being up as upgrading a server and watching the RedSox
> (01:38 where I am)

I'll thank those two :) Cheers, Alison.

And thanks for these efforts, Jake. Much appreciated.
Duplicate of this bug: 1002411

Comment 12

5 years ago
PR merged and deployed! Works much better now. :)
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1002577
Duplicate of this bug: 1001774
Target Milestone: --- → 2014-Q2
You need to log in before you can comment on or make changes to this bug.