Closed Bug 743994 Opened 10 years ago Closed 9 years ago

mediawiki-bugzilla table not rendered correctly

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lmandel, Assigned: brandon)

Details

Attachments

(2 files)

The mediawiki-bugzilla table as deployed to production is not styled. The column headings do not allow me to sort and I can't select the size of the result set. I can do all of these things in my test environment with the same code that I pushed to be deployed. There is some disconnect between dev and deployment. I would like to resolve the issue in order to expose this additional functionality.
This appears to be (yet another) problem with our Mediawiki skin.

If you append this to whatever page you're testing, it should work normally:

?useskin=vector

For example, my page (used for testing this kind of thing:

https://wiki.mozilla.org/User:Nmaul (broken)
https://wiki.mozilla.org/User:Nmaul?useskin=vector (works)

Sorry, nothing IT can do about this... our skin is broken and needs some TLC.
Is the current wikimo skin located in Hg or github? Who is responsible for this aspect of wikimo?
Neither, SVN: http://svn.mozilla.org/projects/wikimo/tags/production

Wikimo has no developer resources officially allocated to it. That's the problem... *nobody* is responsible for it.

As I've mentioned in other wikimo skin bugs, the issue is that Wikimedia does not go to significant lengths to maintain backwards compatibility with skins. The skinning system is as much for their own convenience as actual 3rd-party skin development. Skinning documentation is basically non-existent. The only reliable method I'm aware of for porting a mediawiki skin from one major version to the next is to entirely rewrite it, based on the official Vector (or Monobook) skin. We have done major version upgrades (and need to do so again) without rewriting the skin, and thus we have problems.
For somereason mediawiki includes extension CSS *before* the skin css...lame
Inspecting the page shows significant differences in the table (not strictly html table but the elements required to construct the bugzilla table) structure for the gmo (Mozilla) and vector skins:

gmo
------
<table class="bugzilla ui-helper-reset">
    <thead>
        <tr>
            <th>ID</th>
            <th>Summary</th>
            <th>Status</th>
            <th>Priority</th>
        </tr>
    </thead>
    <tbody>
            
    </tbody>
</table>

vector
------
<div class="dataTables_wrapper"><div class="fg-toolbar ui-toolbar ui-widget-header ui-corner-tl ui-corner-tr ui-helper-clearfix"><div class="dataTables_length"><label>Show <select size="1"><option selected="selected" value="10">10</option><option value="25">25</option><option value="50">50</option><option value="100">100</option></select> entries</label></div><div class="dataTables_filter"><label>Search: <input type="text"></label></div></div><table class="bugzilla ui-helper-reset">
    <thead>
        <tr><th style="width: 13px;" colspan="1" rowspan="1" class="ui-state-default"><div class="DataTables_sort_wrapper">ID<span class="DataTables_sort_icon css_right ui-icon ui-icon-triangle-1-n"></span></div></th><th style="width: 55px;" colspan="1" rowspan="1" class="ui-state-default"><div class="DataTables_sort_wrapper">Summary<span class="DataTables_sort_icon css_right ui-icon ui-icon-carat-2-n-s"></span></div></th><th style="width: 36px;" colspan="1" rowspan="1" class="ui-state-default"><div class="DataTables_sort_wrapper">Status<span class="DataTables_sort_icon css_right ui-icon ui-icon-carat-2-n-s"></span></div></th><th style="width: 40px;" colspan="1" rowspan="1" class="ui-state-default"><div class="DataTables_sort_wrapper">Priority<span class="DataTables_sort_icon css_right ui-icon ui-icon-carat-2-n-s"></span></div></th></tr>
    </thead>
    
<tbody><tr class="odd"><td class="dataTables_empty" colspan="4" valign="top">No data available in table</td></tr></tbody></table><div class="fg-toolbar ui-toolbar ui-widget-header ui-corner-bl ui-corner-br ui-helper-clearfix"><div class="dataTables_info">Showing 0 to 0 of 0 entries</div><div class="dataTables_paginate fg-buttonset ui-buttonset fg-buttonset-multi ui-buttonset-multi paging_two_button"><a title="Previous" class="fg-button ui-button ui-state-default ui-corner-left ui-state-disabled"><span class="ui-icon ui-icon-circle-arrow-w"></span></a><a title="Next" class="fg-button ui-button ui-state-default ui-corner-right ui-state-disabled"><span class="ui-icon ui-icon-circle-arrow-e"></span></a></div></div></div>
It looks like $wgBugzillaJqueryTable is on in your local branch and off on production (?). FYI, I just pushed a fix to my github repo to make the jquery stuff better / actually work.
(In reply to Christian Legnitto [:LegNeato] from comment #7)
> It looks like $wgBugzillaJqueryTable is on in your local branch and off on
> production (?). FYI, I just pushed a fix to my github repo to make the
> jquery stuff better / actually work.

Is this relevant? I can try flipping it on in production... don't want to flip it on without some kind of ack/direction to do so, in case there are known issues. :)
My two samples from comment 6 were both taken from wiki.mozilla.org. All I did was change the skin from gmo to vector to get the table to render as expected.
The HTML is different because the javascript writes the HTML at runtime when it finds what it's looking for.

This is not a mediawiki-bugzilla bug, but a theme bug. It should be fixed, but is not related to the maintenance of mediawiki-bugzilla.
Whiteboard: [mediawiki-bugzilla]
(In reply to Brandon Savage [:brandon] from comment #10)
> The HTML is different because the javascript writes the HTML at runtime when
> it finds what it's looking for.
> 
> This is not a mediawiki-bugzilla bug, but a theme bug. It should be fixed,
> but is not related to the maintenance of mediawiki-bugzilla.

This bug hampers the ability to sort Bugzilla data in mediawiki-bugzilla. How do we get some attention on this bug?
Short answer: pressure morgamic to allocate webdev resources to wikimo.

It's in an awful state right now because it does not get regular attention... only occasional (mostly community) attention. IT cannot effectively make the required changes.

A community member contributed a new build of the main skin a while back. It has not been integrated, because of disagreement by the primary skin maintainer about how it should be organized in the repo, and for lack of his sign-off on the changes. That means IT is basically stalled on deploying it. Even so, I can't say if it would have any impact on your particular issue, but it speaks to the heart of the matter, which is that this is a critical tool that is effectively unmaintained.


The only feasible alternative is to revert to a stock Mediawiki theme and give up on maintaining our own. IT cannot maintain it. The community has (statistically) not effectively maintained it... harsh, but that's the reality... it ain't working. The only remaining options I see are for webdev to step in and take over, or to abandon our custom skins.
(In reply to Jake Maul [:jakem] from comment #12) 
> A community member contributed a new build of the main skin a while back. It
> has not been integrated, because of disagreement by the primary skin
> maintainer about how it should be organized in the repo, and for lack of his
> sign-off on the changes. That means IT is basically stalled on deploying it.
> Even so, I can't say if it would have any impact on your particular issue,
> but it speaks to the heart of the matter, which is that this is a critical
> tool that is effectively unmaintained.

Do you have a bug reference for this? Can you tell me who is the primary skin maintainer?
Laura has told me I am free to fix this bug, but the larger issue of theme ownership is an issue. I don't have the time to own it, though I may be one of the few PHP people left in Webdev so it may end up being mine. I've CC'ed both Laura and Morgamic on this bug for their thoughts.
Assignee: nobody → bsavage
This is fixed in the latest version of wikimo.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.