At least PHP works since that generates https://doc.wikimedia.org/

The file /srv/docroot/org/wikimedia/doc/mediawiki-core/master/php/search.php has literally the same content:

<div id="main-nav"></div>
<script language="php">
require_once "search_functions.php";
main();
</script>
</div><!-- doc-content -->

Generated by Doxygen 1.8.13

Maybe that was interpreted by PHP 5 and is not since we switched to PHP 7?

Yes from http://php.net/manual/en/language.basic-syntax.phptags.php

Changelog

Doxygen comes from Debian Stretch https://packages.debian.org/stretch/doxygen

One would have to look at Doxygen upstream to check whether there is a commit fixing it. And then we need a patch to be send to Debian to patch the Stretch package.

If we don't want to wait for Upstream Doxygen or Debian, we can always fork the Debian package, include the fix and upload it on our apt.wikimedia.org (then rebuild the affected CI containers).

https://github.com/doxygen/doxygen/issues/3545

PHP was not parsed properly when it appeared in a <script language="php"> section.

doxygen closed this on 2 Jul 2018

Fixed by https://github.com/doxygen/doxygen/pull/680 / 22b67836d678cea695b977ec648c0aa013339c55.

Released in 1.8.15:

$ git tag --contains 22b67836d678cea695b977ec648c0aa013339c55
Release_1_8_15

Looks like all the Debian channels (jessie, stretch, buster, sid) are still on 1.8.13. Last update was last year (1.8.13-10) indicating that the package no longer has a Debian maintainer (discussion).

I suppose a cherry-pick to our own repo would be the quickest way for now. Alternatively, one of our own Debian maintainers might be able to patch in Debian instead.

I have send a bug to Debian but I have not received the automatic acknowledgement yet :(

My local email server configuration was screwed up. The bug is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925068

From: Paolo Greppi
Date: Wed, 20 Mar 2019 18:52:04 +0100

Hi Antoine,

and thanks for the good and well documented report.

I agree that for consistency doxygen search should work with the PHP version we ship in any given
Debian release.
And this issue also applies to buster as it will ship doxygen 1.8.13 and php 7.3.

Fixing it for buster is higher priority, and a solution could be to backport doxygen 1.8.15,
but before that we need it in testing: https://bugs.debian.org/919413
Then for stretch, backporting it to stretch too is an option if it is painless.

Another option is to just backport the upstream fix.

I propose that we keep this on hold for now.

Paolo

From: Antoine Musso
Date: Wed, 20 Mar 2019, 22:24

Hello Paolo,

Thank you for the quick reply and all the context with 1.8.15 status. I hope it makes it to testing and get included in buster!

Regarding this bug, I will get our team to rebuild the Debian package with the patch included (22b67836), test it, deploy it and monitor how our documentations behave. At least that will fix it for us.

Then maybe that will build enough confidence to have the patch included in the Stretch package?

In T218233#5036593, @Krinkle wrote:

Looks like all the Debian channels (jessie, stretch, buster, sid) are still on 1.8.13. Last update was last year (1.8.13-10) indicating that the package no longer has a Debian maintainer (discussion).

There is a maintainer but he is willing to step back since Doxygen has a lot of Javascript and it causes other packages to fail eventually. so that ends up being a burden. At least Paolo replied to my bug ;]

I suppose a cherry-pick to our own repo would be the quickest way for now.

Yes we can fork it to our Gerrit, pick the patch and get Operations to rebuild and upload the package. Then we would have to mess a bit with apt configuration to fetch it but it is not the end of the world usually.

Alternatively, one of our own Debian maintainers might be able to patch in Debian instead.

That is a nmu (non maintainer upload) and I have absolutely no idea what the policy is on that regard. Maybe after we tested/deployed the cherry pick that will give the package maintainer enough confidence to include the patch and release it for Debian.

@hashar I built patched debs for buster at https://people.debian.org/~legoktm/doxygen/, could you test those out before I build fixed versions for stretch (assuming the defacto Debian maintainer is OK with my plan)?

stretch was easier than I expected, patched packages are at https://people.debian.org/~legoktm/doxygen-stretch/ - please test :)

Bump. This came up again at the Hackathon and made documentation significantly harder to navigate for developers.

Basically, you have to be an experienced contributor and an experienced Doxygen user to 1) Know that search is broken - the blank results page isn't just a fluke, 2) Know the exact name of the class you are looking for, search by description or method is not possible, 3) Know that Doxygen has an "all class list" somewhere and where that somewhere is and use that.

Failing that, MediaWiki PHP documentation is currently unavailable to users.

I poked a different upstream meanwhile.

@MoritzMuehlenhoff we would need to fork the Stretch Debian package for Doxygen. What would be the best course of action for that please? Kunal already rebuild it with a patch at https://people.debian.org/~legoktm/doxygen-stretch/ , but I am not sure what are SRE requirements. Should it be first forked to our Gerrit repo then rebuild by SRE and uploaded to apt.wikimedia.org ?

There's two angles to address:

1. Getting this fixed internally

@hashar Did you confirm that Kunal's test package fixes the problem? If so we can rebuild on boron as 1.8.13-4~wmf1 and import to stretch-wikimedia/main.

2. Getting this fixed in unstable/buster (which is also a requirement that the patch can land in a Stretch point release which obsoletes our internal update):

doxygen is orphaned and while an "adoption" is in progress every DD can do a "QA upload", i.e. apply https://github.com/doxygen/doxygen/commit/22b67836d678cea695b977ec648c0aa013339c55 and upload as 1.8.13-5. The patch is small enough and fixes a genuine issue, so I assume it would still be eligible to enter buster in the freeze phase (while a new 1.8.15 release would not). I don't have the time currently to commit do that myself, though.