Dan Rossiter

Hi zman8,

Yes, this could definitely be done. Let me throw something together tonight and I’ll get it to you.

-Dan

addkolon,

Have you tried the same steps I provided jcimb above?

DG uses built-in WP info to get the attachment paths, so the issue is either going to be an issue with WP configuration or another plugin interfering in some way. The trick is figuring out what exactly is unhappy.

-Dan

Hi lilyandthetwins,

I’ve just tested this functionality on DG 4.4 and it works on my system. Could you please do me a favor and go through some test steps to rule out interference from another WP plugin or theme?

1. Disable all plugins.
2. Switch to a default theme.
3. Re-attempt the manual thumbnail.
4. If step #3 works, then one-by-one re-enable plugins and your theme, retesting #3 each time until it fails.

If when you reattempt it still fails, then this is likely not an interference from another plugin/theme.

-Dan

• This reply was modified 9 years, 2 months ago by Dan Rossiter.

Hi dc2010,

I’m sorry to hear you are having issues. I’ll be happy to help! 🙂

Let’s first address the IMagick issue, since I think that is likely related to your Apache upgrade. In order for DG to be able to use IMagick, the IMagick module must be enabled. Since you upgraded Apache, maybe you already know how to view enabled modules? If so, confirm that imagick module is enabled and if it is not you will need to enable it.

Next, the Ghostscript issue. I wonder if your PATH changed when you upgraded Apache. Whether it did or not, we can resolve the Ghostscript executable not being found automatically by simply setting the full path to the gs executable in the Dashboard -> Settings -> Document Gallery -> Advanced tab. To find the value for that field, simply run which gs on your server to find the fully-qualified path to Ghostscript.

Once you’ve tried the above or if you need additional help, please don’t hesitate to ask 🙂

-Dan

Hi entrapped,

This is not the first time this request has showed up, but unfortunately it is unlikely to happen due to how Document Gallery is implemented. Internally, it relies significantly on the WordPress API to perform the various operations necessary to get a gallery displayed. Since WordPress itself does not support operations on arbitrary directories, we would have to re implement a lot of the plugin from the ground up.

That said, I appreciate the suggestion and it is on our list of future enhancements, just not very high on the list right now 🙂

-Dan

Hi jefferisp7,

Thanks for your interest in Thumber.co!

Right now, Thumber just generates a thumbnail for your files. There are future plans to support searchable attachments (such as Word docs), but this is still in the planning phase.

-Dan

Hi mlgirard,

I’m not sure I quite understand what the problem is that you are experiencing. Can you provide an example of something you’re doing and what you expect Document Gallery to do?

Thanks,
Dan

ihaider,

I’ve done some more research on this topic, and unfortunately it will not be as easy as I had hoped. It’s not impossible, I don’t believe, but it’s going to be a pain. The following is very high level framework of what would need to happen in order for DG to support processing remote files.

• Everything in the DG logic relies on WP attachments. Even if you bypassed this, most of the thumbnail generation methods (including IMagick & Ghostscript — the two thumbnail generation methods other than Thumber.co that support PDF processing) require a local file in order to generate a thumbnail.
• Supporting “remote attachments” in WP should be possible, though it looks like no plugin adding this functionality has been developed (at least, not that I could find). If you wanted to do this, you would want to look closely at the logic starting under WordPress’ wp-admin/media-new.php. Throughout the process of creating a new attachment, there are numerous places behavior can be overridden, starting with wp_handle_upload_prefilter. The changes would require handling the backend logic and also exposing a way to “upload” remote files, where uploading would probably just be passing a URL to be referenced as the file location without anything ever being downloaded to the server.

The other option, which is probably less involved, but would require re-implementing most of DG logic for displaying galleries of files, would be to copy the logic from class-ghostscript-thumber.php in the getThumbnail method and adapting it to handle remote files (downloading the remote file long enough to generate a thumbnail, then removing the temp file once a thumbnail has been generated).

I will tell you, the concept of true “remote attachments” and piqued my interest. Depending on my availability, I may poke at implementing a plugin to provide support for this as it seems like a very useful feature, but I can’t make any promises that I’ll 1) find the time to tackle this and 2) that even if I do find the time, I find a way to make it all work.

All of that said, if you do decide to implement remote attachment support, I will commit to updating DG to support remote attachments.

Please do let me know what you decide on. And I’m sorry I couldn’t give you better news.

-Dan

• This reply was modified 9 years, 4 months ago by Dan Rossiter.