The PDF files of one of our repository’s collections for some unknown reason do not generate thumbnails (it must be the PDF format, they’re all the same), so every item is using the fallback PDF image. So far, so good.
Problem is that in the index page, public side, the featured collection box is not showing the fallback image, as one would expect; in fact, it’s not showing anything.
I’m using Thanks Roy as a theme, but I’m pretty sure that’s not the problem: trying to track it back, I think it might reside in the getFile() function, because in FileMarkup.php the following returns false:
// Use the default representative file.
$file = $record->getFile();
if (!$file) {
return false;
}
Any idea how to solve the problem?
Thanks in advance.
checked if the PDF files are valid ones (they are, “the document does conform to the PDF 1.6 standard”; still missing their thumbnail, so there’s a problem there too, but that’s a different one);
tried loading a completely different PDF, and putting it into a new collection the thumbnail shows up (as expected);
putting that same PDF into the collection that contains the “weird” ones, does not cause any thumbnail to appear.
So, I guess there are two issues here:
my PDFs have got something wrong (as there are 125 of them, I suppose they were generated in some strange way);
Omeka doesn’t default to fallback image (as it’s doing for the documents) when showing the collection (neither in “featured collection” in index page, nor in “browse collections”).
http://www.bitoteko.it = index page, with “Collezione in evidenza” meaning “featured collection”; as you can see, no thumbnail is shown, and that’s because that’s the collection with the ‘weird’ PDF’s;
http://www.bitoteko.it/collections/browse = list of 15 collections, of which the only one that does not show a thumbnail is, again, the “Esperanto 125” with weird PDF’s (compare, for instance, to http://www.bitoteko.it/collections/show/11, another PDF’s collection, displaying both file thumbnails and one of them as collection’s thumbnail);
BTW: I’ve disabled the More Media Types feature, that was showing a PDF fallback image, leaving the Omeka original one, just to be sure that it was not interfering.
I’ve also created new documents, with different mime types, for which the fallback image works well, but when I try to put them into a collection no thumbnail for the collection is shown; so, it seems it’s not a problem with a specific fallback image, but something more general.
Could it be that, if the function that’s choosing the thumbnail for the collection/featured collection does not find any generated thumbnail, it fails to fall back even to the very default one? Shouldn’t it use a fallback one, if available, as it is doing for the single items?
Update: I’ve found out, in the meantime, that the problem with the PDF files was caused by having batch-imported them (Dropbox + CSV import plugins), as the filenames contained the original filepath and maybe the system didn’t like all those slashes; reuploading the same files, with normal Item file tab, did the trick. The main issue still stands.
So, the function is looking for Items with an image. If, like in my case, no Item was available with an Image, it would return null, and so image_tag function in FileMarkup.php would return false.
In my opinion, before returning null, the function getFile() should check whether there was a fallback image available and, in that case, return that (the sorting criteria could be the same). Also, if image_tag was returning false, the collection should still show the default fallback image.
What do you think? And could the following be a fix?
public function getFile()
{
$itemTable = $this->getDb()->getTable('Item');
$itemArray = $itemTable->findBy(array(
'collection' => $this->id,
'hasImage' => true,
'sort_field' => 'featured',
'sort_dir' => 'd',
), 1);
if ($itemArray) {
return ($itemArray[0]->getFile());
} else {
// case no Item with image was found
$itemArray = $itemTable->findBy(array(
'collection' => $this->id,
'sort_field' => 'featured',
'sort_dir' => 'd'
), 1);
if ($itemArray) {
return ($itemArray[0]->getFile());
} else {
return null;
}
}
}
The issue is exactly as you say but it’s purposely like that, at least to a certain degree: the idea being that people mostly didn’t want to “showcase” the fallback thumbnails as being what’s in a collection with a preference toward just not having one at all.
So the question is more one of what we should do here rather than a technical question. The calculus changes a bit once you’re using custom fallback thumbnails which you’re more likely to actually want to see.
I see, John.
I’m not sure I understand why one would choose not to show any image at all, but maybe an approach that serves both scenarios could be to have a config option (in admin/appearance/edit-settings, for instance) to choose whether to show a fallback image or not.