• Resolved jiml-in-pdx

    (@jiml-in-pdx)


    I want to avoid having group-writable directories that WordPress writes to. I was drawn to this plug-in because I can have my customers upload securely to the USER-writable uploads folder, and link the media directly into their library, rather than using WordPress’s insecure upload method.

    But it seems that this plugin always wants to copy the file somewhere, and thus still has to have write access. I want to let my customers put the file right into the uploads folder (or a sub-folder thereof), and then tell WordPress where it is, and voila! It’s now part of their media library.

    How can I avoid the need to copy the file? This wastes disk space (these are large files!) and wastes human effort (having to go back and delete the uploaded original). I’d like to make it easy for the customer and not waste their storage quota by storing two copies of hundreds of large files.

    Thank you!

    Jim

    https://www.ads-software.com/plugins/add-from-server/

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Dion Hulse

    (@dd32)

    Meta Developer

    As stated in the FAQ, if you upload to a folder outside of the uploads directory, then it’ll copy to the uploads directory.

    Create the user-writable folders in wp-content/uploads/* and it won’t attempt to copy the files.

    Thread Starter jiml-in-pdx

    (@jiml-in-pdx)

    Thanks for the reply. The problem I found was that I was using the ‘chroot’ feature of the Add From Server browser to prevent the user from browsing above the uploads folder, but this particular user has a very large home directory, and thus their home directory path (and therefore their uploads path) contains a symbolic link to a filesystem with sufficient free space to hold their data. WordPress however resolved the symbolic link to a physical path, and I surmise that the string comparison of the symlink path vs. the physical path failed, and so the plugin thought that a copy was necessary. Not sure why the ‘already exists’ error happened. I suspect it had succeeded once but I didn’t notice it, and when I tried again I got the ‘already exists’ message.

    The “fix” for my situation was to specify the chroot folder using the physical path, not the symbolic link path, so that the string comparison succeeds.

    Thank you, for this plugin. I think I’m close to having a workflow that I can document and give to the customer. They’ll be pleased.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘How can I avoid copying the file? (error: Sorry, That file already exists)’ is closed to new replies.