Open GoogleCodeExporter opened 9 years ago
thumb.php Re-uploaded.
This is the valid one !! (Sorry, forgot to save the file after last changes).
Original comment by inbytes...@gmail.com
on 7 Oct 2010 at 11:13
Attachments:
Hi - I see what you have done but am not sure I understand why you did it.
Could you try to explain the problem again please?
Original comment by BinaryMoon
on 3 Dec 2010 at 4:42
Happy New Year, and sorry for answering so late. I don't use this account as
often as others.
I'll try to explain you in another way:
You assume that if someone is using...
"www.myweb.com/wordpress/wp-content/uploads/2010/image.jpg"
...its folder structure would be...
FTP: \\root\wordpress\wp-content\uploads\2010\image.jpg
But sometimes, in certain situations you need to create a virtual folder. Let's
say you have this folder structure...
FTP: \\root\mywebs\mycompany\wp-content\uploads\2010\image.jpg
... and you want to simplify your URL in this way...
"www.myweb.com/wordpress/wp-content/uploads/2010/image.jpg
What is happening is that you are creating a virtual folder in your web server,
called "wordpress", that is equivalent to "\mywebs\mycompany\".
So, you are never going to reach the "image.jpg" file, because in the function
"get_document_root" you use the URL parameter as if it were a real folder path.
In my fix, I keep trying with the URL, removing the first folders one by one
(just in case any of them would be virtual) till the real path is found. For
each first folder I remove, I use your original code (almost):
foreach ($paths as $path) {
if(file_exists($path . '/' . $newsrc)) {
return $path . '/' . $newsrc;
}
}
I hope I had explain myself now.
Thanks.
Original comment by inbytes...@gmail.com
on 4 Jan 2011 at 10:36
I'm having exactly the same problem in Wordpress, for the same reason. The real
location of my images is aliased from somewhere else that's nowhere near my doc
root. So my URL might be:
http://www.example.com/uploads/2011/06/image.jpg
but the file on disk is in:
/mnt/shared/wp-uploads/2011/06/image.jpg
I've told wordpress about those two locations and told apache to map one to the
other, and all works fine in there.
There is not necessarily any direct correspondance between URLs and file paths,
and assuming there is is an error.
The only way I can think of to work around this is to allow a config value in
your script to specify a local path.
Original comment by marcus.b...@gmail.com
on 11 Jan 2011 at 11:16
I'm having exactly the same problem in Wordpress, for the same reason. The real
location of my images is aliased from somewhere else that's nowhere near my doc
root. So my URL might be:
http://www.example.com/uploads/2011/06/image.jpg
but the file on disk is in:
/mnt/shared/wp-uploads/2011/06/image.jpg
I've told wordpress about those two locations and told apache to map one to the
other, and all works fine in there.
There is not necessarily any direct correspondance between URLs and file paths,
and assuming there is is an error.
The only way I can think of to work around this is to allow a config value in
your script to specify a local path.
Original comment by marcus.b...@gmail.com
on 11 Jan 2011 at 11:16
I worked around this using two things:
Made the get_document_root function return a fixed string pointing to my image
root (I'm not interested in processing images from elsewhere).
Created a symlink with a name that matched what's in the URL so that timthumb's
path processing would work.
Ugly but functional.
Original comment by marcus.b...@gmail.com
on 11 Jan 2011 at 11:55
Also if develelping on a site that does not have domain a work around needs to
be used.
Say if using Cpanel, a site might be at http://domain.com/~uername/
In such cases the image will not be found.
Here is a dirty workaround, that I hope someone will know how to make properly.
Insert around line 40, after
--------
if ($src == '' || strlen ($src) <= 3) {
display_error ('no image specified');
}
---------
//Fix if on a virtual Cpanel domain
$src = str_replace('/~USERNAME','',$src);
Original comment by zenant...@gmail.com
on 5 Feb 2011 at 6:41
/~USERNAME needs to be changed manually to your actual username if you use this
dirty fix
Original comment by zenant...@gmail.com
on 5 Feb 2011 at 6:43
[deleted comment]
Issue 114 has been merged into this issue.
Original comment by BinaryMoon
on 20 Jun 2011 at 3:46
I have same with new script version. Any ideas how to fix it?
Original comment by f1talks...@gmail.com
on 16 Aug 2011 at 8:10
This appears to have returned in the new version.
Original comment by ipctest...@gmail.com
on 24 Aug 2011 at 4:28
I need to use timthumb on a replicated site using post affiliate pro and it
just doesn't work.
Original comment by rollerco...@gmail.com
on 5 Sep 2011 at 1:14
Issue 263 has been merged into this issue.
Original comment by BinaryMoon
on 22 Nov 2011 at 8:07
I'm affected by this as well. I'm running it from my home folder on a mac os x
install.
@zenanthor: I'm trying to find where to insert your quick fix in trunk but I
cannot find it. I checked out revision 113 and made your changes.
I'm only using this for development so it'll work for now. Thanks a lot!
Original comment by lindberg...@gmail.com
on 2 Dec 2011 at 9:55
@lindberg...@gmail.com
Do you know about the hosts file? You can assign your computer a real hostname
that only works locally.
http://lmgtfy.com/?q=editing+the+hosts+file
Original comment by earthsph...@gmail.com
on 2 Dec 2011 at 4:00
i also have this issue and solved it thanks to the sggestion of #6 to create a
symlink in the root.
i'm using version 2.8 that was included in a WP theme in a multisite
installation on a nginx/php-fpm server.
i'll try looking at the new version but i think adding a configuration to
define a path within the docroot as the 'files' directory and having that added
to the $src would be the idea solution.
Original comment by smiro2...@gmail.com
on 24 Dec 2011 at 3:14
I think i was having a similar issue, when trying to use timthumb.php 2.7
version on a clients server i noticed it was not working because it could not
find the images.
calcDocRoot() was getting the wrong value for the document route because
$_SERVER['DOCUMENT_ROOT'] was not returning the correct path.
While $_SERVER['PATH_TRANSLATED'] did return the correct path. According to <a
href="http://php.net/manual/kr/reserved.variables.server.php">php.net</a> the
PATH_TRANSLATED variable gets the path based on the current script, after the
server has done any virtual-to-real mapping.
So possibly my clients server used this real to real mapping and that's the
same as virtual folders that the original poster of this issue mentioned. Or my
clients server just has the document root setup wrong.
Either way i solved it by putting this in the top of my timthumb:
$_SERVER['DOCUMENT_ROOT'] = $_SERVER['PATH_TRANSLATED'];
I notice in your code that you are trying to use PATH_TRANSLATED if $docRoot is
not set. But in my case the $docRoot was set but just set wrong.
Currently if an image cannot be found on the url path you throw an error. I was
thinking that just before this you could put a piece of code in to try the
PATH_TRANSLATED version of the url and then if that fails too throw the error
of the file not being found.
Might help out some users who have a similar issue to me.
Original comment by ralcus....@gmail.com
on 5 Jan 2012 at 1:21
Here is the fix when using virtual directories in the URL:
http://elementdesignllc.com/2012/01/how-to-fix-timthumb-using-a-virtual-director
y-url-contains-tildes/
Using "$_SERVER['DOCUMENT_ROOT'] = $_SERVER['PATH_TRANSLATED'];" did not work
for me, however the above fix does.
Original comment by chadhunt...@gmail.com
on 6 Jan 2012 at 2:10
same problem, none of the above fixes works.
Original comment by vcausar...@gmail.com
on 6 Feb 2012 at 11:54
could you try the latest version please. Some changes have been made that will
hopefully fix this.
Original comment by BinaryMoon
on 20 Feb 2012 at 1:06
I had the same issue when I tried to install Woothemes Simplicty Theme.
I was getting the "Could not find the internal image you specified." error
message for all images. I verified that the images existed and were readable by
the script.
The server reported:
$_SERVER['DOCUMENT_ROOT'] = '/var/www/html'
$_SERVER['SCRIPT_FILENAME'] =
/var/users/foo/htdocs/wp-content/themes/simplicity/functions/thumb.php
In this situation TimThumb never finds the image as it always prepends the
contents of $_SERVER['DOCUMENT_ROOT'] when searching through the elements of
$_SERVER['SCRIPT_FILENAME']. I was able to get it working by commenting out
$base = $this->docRoot;
Hope that helps
/Eoin/
Original comment by e...@alittlelightisblinking.co.nz
on 15 Mar 2012 at 7:00
Hi,
I use version 2.8 and this is my solution:
....
define ('VERSION', '2.8');
$_SERVER['DOCUMENT_ROOT'] =
dirname(dirname(dirname($_SERVER['SCRIPT_FILENAME'])));
....
Hope that helps
Nana
Original comment by duere...@gmail.com
on 23 Mar 2012 at 8:49
Hello here my fix proposition on the latest timthumb version (2.8.20).
I added à configuration constant FETCH_LOCAL_URL.
If set to true = timthumb will remotely fetch image even they are stored on the
same server as timthumb.
if set to false (default) = timthumb will keep working as usual trying to read
localy the image.
this helps me when using timthumb with wordpress multisite.
Hope it helps.
Benjamin AZAN
Original comment by Benjamin...@gmail.com
on 23 Aug 2012 at 9:52
Attachments:
I've made changes to the script that will make the script work for paths
outside the web server document root. For this purpose, I've created a new
parameter, named IS_OUTSIDE_WEBROOT (boolean). This works for paths like
/home/user/public_html/.... where the web server doc root is eg.
/var/www/htdocs.
I hope this helps.
Original comment by v.lourdas
on 28 Nov 2012 at 9:11
Attachments:
[deleted comment]
[deleted comment]
I like Benjamin's implementation above (#24).
However, a problem arises with the fix above if your site is not in
$ALLOWED_HOSTS, so I've added that to the default array and made a patch.
Would love to see this in the next update, we're now going to start using it on
timthumb that ships with our plugin Events Manager -
http://wordpress.org/extend/plugins/events-manager/ because this causes problem
with MultiSite and mod_rewrite image paths for network blogs.
Thanks for all the hard work!
Original comment by msy...@gmail.com
on 3 Mar 2013 at 8:02
Attachments:
Original issue reported on code.google.com by
inbytes...@gmail.com
on 7 Oct 2010 at 11:08Attachments: