Closed Bug 1001710 Opened 10 years ago Closed 10 years ago

Recent changes to wiki.mozilla.org break bugzilla plugin

Categories

(Websites :: wiki.mozilla.org, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2014-Q2

People

(Reporter: brett, Assigned: nmaul)

References

Details

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:

https://wiki.mozilla.org/AllHands/Funnel_Building

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 → wiki.mozilla.org
Product: Infrastructure & Operations → Websites
QA Contact: nmaul
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
Status: NEW → RESOLVED
Closed: 10 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.
Status: RESOLVED → REOPENED
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.
Status: REOPENED → NEW
Flags: needinfo?(ckoehler)
Oddly, when you "preview", it looks fine.
Wrapping in a DIV sorts it in the mean time (added to page noted & tested post-preview)
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)
I've worked up a commit that seems to fix this for me on wiki-dev.allizom.org (not applied until the PR lands):

https://github.com/superawesome/mediawiki-bugzilla/commit/1428a5486119e0b843fbba5524130e376c14eb44
https://github.com/mozilla/mediawiki-bugzilla/pull/48

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.
> 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.
PR merged and deployed! Works much better now. :)
Status: NEW → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Blocks: 1004616
Target Milestone: --- → 2014-Q2
You need to log in before you can comment on or make changes to this bug.