This is strange. The file is present on the server but not served anymore by Apache for I dont know what reason.

@Samwilson Have you changed anything in Apache config recently?

Sorry about this! It's because of the switchover to a new server for T332450, and I've not set up the cronjobs for OPDS generation. Doing so now.

It's failing with:

00:03:42 CRITICAL [console] Error thrown while running command "app:opds -q -l fr --category=Bon_pour_export". Message: "end(): Argument #1 ($array) must be of type array, null given" ["exception" => TypeError { …},"command" => "app:opds -q -l fr --category=Bon_pour_export","message" => "end(): Argument #1 ($array) must be of type array, null given"]
In BookProvider.php line 316:
end(): Argument #1 ($array) must be of type array, null given

Looking at the en Ready_for_export category (because it's smaller and quicker to fail), it's failing on this code:

		$response = $this->api->queryAsync( [
			'titles' => 'File:' . $title,
			'prop' => 'imageinfo',
			'iiprop' => 'thumbmime|url|canonicaltitle',
			'iiurlparam' => $thumbParams
		] )->wait();

with an API error:

"code" => "urlparamnormal"
"info" => "Could not normalize image parameters for An_African_Millionaire_cover.tif."
"Could not parse "iiurlparam" for An_African_Millionaire_cover.tif. Using only width and height."

• $title: "An African Millionaire cover.tif"
• $thumbParams: "400px"

I'm a bit confused as to why it's ever worked: the docs say that iiurlparam is "A handler specific parameter string. For example, PDFs might use page15-100px. iiurlwidth must be used and be consistent with iiurlparam." but we don't supply iiurlwidth. I'm making a patch now, but feel like I might be missing something.

Patch: https://github.com/wikimedia/ws-export/pull/495

@Samwilson I don't think the underlying problem is the omission of the iurlwidth parameter, but rather the omission of the page number in iurlparam ?

Oh right! Good point, could be! I was testing with the following, which failed on current main and succeeds (i.e includes the cover image) with the above patch:

$ ./bin/console a:e -l en -t 'An African Millionaire' --nocache --nocredits

I guess this is about single-image TIFFs rather than multipage ones?

In T353954#9424284, @Samwilson wrote:

Oh right! Good point, could be! I was testing with the following, which failed on current main and succeeds (i.e includes the cover image) with the above patch:

$ ./bin/console a:e -l en -t 'An African Millionaire' --nocache --nocredits

I guess this is about single-image TIFFs rather than multipage ones?

Yeah I assume this is a issue with single page tiffs being treated as having no pages :(

@Samwilson Thank you so much for investigating this problem!

That one sorted, there's now a separate but related issue:

$ sudo -- sudo -u www-data php /var/www/tool/bin/console app:opds -l fr --category=Bon_pour_export
06:47:11 WARNING   [php] Warning: Undefined array key "pagecount" ["exception" => ErrorException { …}]
^ array:2 [
  "error" => array:3 [
    "code" => "invalidurlparam"
    "info" => "Invalid value for "iiurlparam" ("width=0")."

It looks like the issue is demonstrated with Paquin - Jules Faubert, le roi du papier, 1923.djvu.

It was duplicated on ws.fr... and was deleted a few hours ago.

Thanks.

I'm going to try to fix it up so that if anything goes wrong in trying to get the cover image it won't fail like this. I also wonder if it's possible to reduce the number of API requests made when trying to determine the cover (currently it's two).

Okay, it looks like it's generating correctly now: https://ws-export.wmcloud.org/opds/fr/

Works for me. Thanks!