lingfish
Forum Replies Created
-
I think I know why it is making the gallery/ subdirectory under DOCROOT. Within modules/ngglegacy/admin/functions.php:
// define relative path to gallery inside wp root folder $nggpath = $defaultpath . $name; // 2. Create new gallery folder if ( !wp_mkdir_p (WINABSPATH . $nggpath) )And it would appear that wp_mkdir_p() creates relative to DOCROOT, and not WP_CONTENT_DIR 🙁
Adding more to this again — I just created/uploaded my first gallery, and it has been created under the “real” part of the filesystem, not the symlinked variant 🙁 Almost like, the plugin did its own choosing of paths at a filesystem level (I assume to create the wp-content/gallery parent), but of course when referring to images/thumbs, is relying on URI pathing.
Gah, what a mess.
The issue, at least for me, is much larger. Most of the css etc isn’t loading either, due to WP_CONTENT_DIR buggery, or the wrong use of get_document_root().
This is my first-time installed NGG, and it basically doesn’t work 🙁
I’ll probably have to get around this by using mod_rewrite, until both Photocrati and/or the WP developers finalise the bugfixes. My issue is a double-punch — the NGG bug, and symlinking (due to using Debian).
I’m in agreement with @kwisatz — the problem, and fix as per @avocado works. There has been a long-standing and ongoing WP bug running on this topic too, that affects other plugins (like, W3TC), found here. Although it refers to symlinked plugins, the concept and issue is the same.
For anyone lazy, here’s a patch as another way to roll this fix out:
--- class.mvc_view.php.ORIG 2013-12-22 13:34:23.000000000 +1100 +++ class.mvc_view.php 2013-12-27 19:35:53.000000000 +1100 @@ -240,7 +240,7 @@ $path = $path . '.php'; $retval = $fs->join_paths( - $fs->get_document_root(), +# $fs->get_document_root(), $this->object->get_registry()->get_module_dir($module), $settings->mvc_template_dirname, $pathNope. Especially in my case, using Rackspace CDN, I would have to use some third party uploader tool, etc etc blah blah… and then how to tell W3 to rewrite URLs appropriately, etc.
Well, technically there is a workaround, and that’s to hack W3 code… but that will then break based on if you’re using Debian’s idea of multisite, only partially offloading to CDN (say only themes), etc. It shouldn’t be this hard.
I’ve heard nothing more from the author, and cannot fathom why he strips the leading / off paths for upload; his filesystem level code seems to assume paths are relative, when they’re not.
I’ve been following this bugreport, and have tried the realpath tricks with no luck as well.
Last I got was this:
For the other issue it seems that the symlink usage causes strlen to return different filelength than what is used with wp_content_dir path. That is the “root” path part of wp_content_dir differs from the site/docroot path. Which means a letter is dropped. You could try add -1 so the strlen looks like
trim(substr(WP_CONTENT_DIR, strlen($site_root)-1),’/\\’);
until a proper fix is released.
Didn’t seem to work, universally.
Still happening for me, and it isn’t just custom files. Did some work with the author but didn’t get far.
Hi, I’ve done some work on this… will post soon, just don’t have time right now.
I’m getting this too, or similiar.
My paths as per the error log though are merely missing the leading slash:
var/lib/wordpress/wp-content/themes/graphene/screenshot.png Source file not found.I _think_ this is related to Debian’s 2.5.1 in unstable moving to use a FHS standard for wp-content (ie. under /var), but I’m not sure.