Page MenuHomePhabricator

Bugzilla uses invalid markup or wrong doctype [fixed in Bugzilla 5.0]
Closed, DeclinedPublic


Author: n-roeser

for example.
The MediaZilla pages seem to use many empty tags without closing them (e.g.
"<br>" instead of "<br/>"). There are other bugs, too.

MediaWiki makes a constant effort to use valid markup (and it works very well),
so MediaZilla should do that, too.

Version: unspecified
Severity: trivial
See Also:


TitleReferenceAuthorSource BranchDest Branch
Update mjolnir to v2.4.0repos/search-platform/mjolnir-deploy!1ebernhardsonwork/ebernhardson/python-3.10master
search: Update mjolnir to python 3.10repos/data-engineering/airflow-dags!527ebernhardsonwork/ebernhardson/mjolnir-py310main
Update python to 3.10repos/search-platform/mjolnir!7ebernhardsonwork/ebernhardson/libmambamain
ingress-nginx: Use fourohfour for tools with active ingressesrepos/cloud/toolforge/toolforge-deploy!93taavitaavi/fourohfourmain
Improve message when ingress existstoolforge-repos/fourohfour!6taavitaavi/ingress-errorsmaster
deploy: backward compatibility for stage 'restart_service'repos/releng/scap!187jnucherestart-service-stage-supportedmaster
add job to set runner configrepos/releng/gitlab-trusted-runner!46jeltoset-runner-configmain
Hide some pod informationtoolforge-repos/k8s-status!2taavitaavi/podsmain
add miscweb static-codereview to Trusted Runnersrepos/releng/gitlab-trusted-runner!45jeltoadd-static-codereviewmain
Update get-feed.js to require a date argumentrepos/mediawiki/services/ipoid!69stranimplement-getfeed-with-parametersmain
Customize query in GitLab

Related Objects

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:10 PM
bzimport set Reference to bz1463.
bzimport added a subscriber: Unknown Object (MLST).

rowan.collins wrote:

I wondered if this, like most issues with "MediaZilla" was actually an issue
with Bugzilla [] - we could really do with a prominent
explanation that "MediaZilla" is just a few cosmetic changes to someone else's
program, and >90% of problems with it are their fault not ours.

However, plugging in Mozilla's installation of Bugzilla
I notice that while it doesn't validate, it doesn't give an XHTML doctype
either, so doesn't have these particular errors. So I'll hold off on closing
this until someone comes along who knows what *has* been customised.

n-roeser wrote:

I checked bugzilla-2.20, it has:
<!DOCTYPE html PUBLIC "-W3CDTD HTML 4.01 Transitional//EN"

This is different from the MediaZilla setup, which has:
<!DOCTYPE html PUBLIC "-W3CDTD XHTML 1.0 Transitional//EN"

Therefore, this is not a Bugzilla, but a MediaZilla bug.

Whether Bugzilla should offer an option to output XHTML instead of HTML is
another thing. If you want that, file a Bugzilla feature request if it's not
already there.

Worth poking again after the 3.4 install is done, not worth wasting time on before that. Also not a blocker to 9025.

Bulk assign Bugzilla related issues to pdhanda: current maintainer

Issue still valid on current Bugzilla version 3.4.5. Observed behaviour from comment 1 and comment 2 are still true.

Current validation issues:

  • there's no longer a doctype declaration at all -- validator's going per HTML 4.01 transitional. (Should probably change to a modern <!DOCTYPE html> alone.)
  • some output in our custom theme _does_ include XML-style self-closing tags ("<link .... />") which makes the HTML 4.01 transitional parser whinge. If we've switching to non-XHTML (HTML 4.01 transitional or HTML 5) then we should remove the slashes when fixing up the custom theme in future. (Do not *add* slashes per earlier comments in this bug.)
  • one element has double 'class' attributes -- the second one should be removed.

pdhanda wrote:

Bugmeister is the new Bugzilla maintainer and default assignee.

Thehelpfulonewiki wrote:

Resetting to default per bug 37789

I have opened a bug request upstream and even submitted a lame patch:

Assigning bug to self. I have lowered both severity and priority to the minimal. That is really not killing us and is definitely an easy upstream change.

The bugzilla team is not going to update the doctype till some HTML5 is used. I would personally mark our bug as invalid / wont fix, but I am just going to step out of it (removing self of assignee, and un cc). Let this bug rot for a few more years :-)

That will be eventually fixed by Bugzilla team one day. Meanwhile, this does not cause any harm to use Bugzilla some I am closing this bug.

Just wont fix that bug. Not worth keeping it around I guess. (un ccing myself).

a.koppad wrote:

I am not sure if this bug is worth following. I tried to validate some of the best known websites on the link, it gives me errors on websites. Can this bug be closed with that?

(In reply to comment #15)

I tried to validate some of the best known websites on the link,
it gives me errors on websites.

Not exactly sure what that means. This bug report is about the Wikimedia Bugzilla website not validating against the W3C validator.

While we currently do not plan to fix this in Wikimedia Bugzilla, I'm not against fixing either (so I will not close this as RESOLVED WONTFIX).
However, any contributions should go into fixing the upstream report at first. After that is fixed we can validate which issues are downstream code issues in WM Bugzilla.

Ticket solved upstream:

A commit is updating the HTML templates to change the DOCTYPE from HTML 4.01 Transitional to HTML :D

Wikimedia has migrated from Bugzilla to Phabricator. Learn more about it here: - This task does not make sense anymore in the concept of Phabricator, hence closing as declined.