update: I checked the logging page and there are multiple errors that say:
(DG_GhostscriptThumber->getThumbnail) Ghostscript failed: 1
Could that be a problem with Ghostscript not being enabled on hosting environment or its location moved? any help is appreciated.
Hi,
Yes, Ghostscript moving would absolutely result in GS generation failing if the DG-configured path is not updated accordingly. Can you verify that the GS path (under Dashboard -> Settings -> Document Gallery -> Advanced points to an actual file? If it does not, you’ll need to update accordingly in order for things to begin working again.
-Dan
PS: If you’ve found this plugin useful, please take a moment to rate it. Thanks! 🙂
In the Advanced Tab of the Document Gallery Settings, it does say “Successfully auto-detected the location of Ghostscript.” and the absolute path is set to: /usr/bin/gs.
The pattern of messages in the log are like this:
(DG_Thumb->save) Saving thumb with post_id = 86
January 20, 2016 3:45 am ERROR (DG_GhostscriptThumber->getThumbnail) Ghostscript fa
(DG_GhostscriptThumber->getThumbnail) Ghostscript failed: 1
(DG_Thumber->getThumbnail) Attempting to generate thumbnail for attachment #86 with (DG_GhostscriptThumber)
I am including the Options Array Dump:
Array
(
[thumber] => Array
(
[gs] => /usr/bin/gs
[active] => Array
(
[av] => 1
[gs] => 1
[imagick] =>
[thumber-co] =>
)
[width] => 200
[height] => 200
)
[gallery] => Array
(
[columns] => 4
[fancy] => 1
[order] => ASC
[orderby] => menu_order
[relation] => AND
[limit] => -1
[mime_types] => application,video,text,audio,image
[new_window] => 1
[paginate] => 1
[post_status] => any
[post_type] => attachment
[attachment_pg] =>
[descriptions] =>
[skip] => 0
)
[css] => Array
(
[text] =>
)
[meta] => Array
(
[version] => 4.1.10
[donate_link] => https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=EE5LWRLG933EN&lc=US&item_name=Document%20Gallery%20Plugin&item_number=document%2dgallery¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted
[items_per_page] => 25
)
[logging] => Array
(
[enabled] => 1
[purge_interval] => 7
)
[thumber-co] => Array
(
[uid] =>
[secret] =>
[subscription] => Array
(
)
[direct_upload] =>
[mime_types] => Array
(
)
)
)
So that message indicates that upon DG installation the Ghostscript path was auto-detected, but you mentioned you thought the host might have moved the Ghostscript install. If that’s the case then you need to manually update the location where Ghostscript can be found.
The first thing you want to do is verify that there is actually a Ghostscript install at the location DG is looking (/usr/bin/gs).
-Dan
Since there has been no update to this post in over a month, I’m going to go ahead and mark it as resolved. Feel free to re-open if you have any additional information.
-Dan
While this has been marked as resolved, I was having the same problem as Ivaylo and came across this page when looking in Google for possible solutions (document images were PDF images, but not thumbnails; deleting thumbnail images only made it worse).
I enabled logging, refreshed the page that had Document Gallery running on it, then checked logs. Saw multiple errors regarding Ghostscript. Went to advanced tab, it said Ghostscript was auto-detected. Decided to not trust it, and opened SSH (of course, this solution is assuming you have SSH access). Once in SSH, I did this:
updatedb
find / -name "gs"
It came back and said “/usr/bin/gs”, which definitely was different than what the auto-detect said. So I erased what auto-detect had, and put in what I found in SSH. Now thumbnails are working like a charm.
Just wanted to post this here in case it can help someone having a similiar problem.
Hi Doncullen,
DG first performs a which call, then falls back to an explicit check for /usr/bin/gs. If /usr/bin/gs was not detected then it means which is returning something for gs other than the correct location.
Glad you got it sorted!
-Dan
Perhaps adjust your code so when it experiences an error trying to use Ghostscript, it performs a ‘which’ lookup to see if the path is now different, if so, automatically adjust to new path and retry. This would increase reliability.
Doncullen,
It’s not as simple as that. It becomes a performance issue if every time a thumbnail generation method fails we run a shell script to check where the executable moved or if it’s now available where it was not previously.
Now, a solution that would potentially work is periodically re-checking the GS location, say once a day, but implementing that would require that the plugin track thumbnail generation failures and also that it know when a GS path had been detected vs. manually entered by the user. If it’s the latter, then DG shouldn’t ever overwrite the value. We trust the user’s input more than us hoping we can find the exe.
The general view on this has been that if GS is present on the box, it’s going to generally stay in the same place. If it moves, then we provide a method for updating the path, but the overhead associated with automatically updating the path on system changes is not worth the limited benefit.
I hope that clarifies things 🙂
-Dan
