not really sure what this means, but I get this error for all images on one of my sites:
/theywontfindushere.com/files/gimgs/th-8_8_img3240.jpg) [function.getimagesize]: failed to open stream: No such file or directory in /home/emiatc/theywontfindushere.com/ndxzsite/plugin/format.visual_index.php on line 489
any help would be very appreciated.
link to site: theywontfindushere.com
btw, this is after trying to upgrade.
it means that the file doesn't exist...
Did you upload this recently?
check if your permissions are right -
what should the permissions be?
777 - but this may vary as hosts have different setups...
for the plugin or for the images?
for the files folder and the gimgs and dimgs folder...
It's not a permissions issue. I'm helping a friend upgrade her website and am having the same issue. The problem is that somewhere a piece of code is prepending another index onto the photo name. The file /files/gimgs/th-8_img3240.jpg most likely does exist. But /files/gimgs/th-8_8_img3240.jpg doesn't. I checked the database and images are stored with a single prepended index number so the offending _8 is somewhere in the source. A quick but potentially dirty fix is to just rename all your image files with an extra *index*_ or 8_ in this instance. I've confirmed that this works but am searching for the root of the problem and possibly a better solution.
Btw I'm totally new to inexhibit but have programming experience. If someone can tell me what the index is for or where/why/how it is set I can probably find a better solution. Also, in admin>settings what does "clear dynamic images" do?
Ok, I "fixed" it. Not sure what consequences this will have down the road but It's simple to reverse it. So far everything works:
The Problem: in ndxzsite/plugin/format.visual_index.php on line 455 there is a call to page::get_images() method. In ndxzstudio/lib/page.php you'll find that the get_imgs method dynamically instantiates one of the filesource classes then calls and returns the value of filesourcexxx::getDisplayImages(). Well if you take a look at any one of the 6 getDisplayImages methods you'll notice that it sets the value of $img['media_path'] = $OBJ->basurl . $path . '/th-' . $do['media_ref_id'] . _ . $do['media_file']. If you look at the database entries in the media table you'll see that in every entry the value of media_ref_id matches the numerical beginning of the meida_file. So for a file say th-8_img3240.jpg getDisplayImages() incorrectly sets the path to th-8_8_img3240 because media_ref_id would be 8.
Solution: I'm guessing this is supposed to work so that filenames in the /files/ directory are prepended with the media_ref_id but filenames in the database AREN'T so that setting the image path to media_ref_id . _ . media_file would actually produce a valid file reference. So possibly the best solution would be to remove all the *NUMBER*_ prefixes from the database media table filenames. I have no idea why the developers want it to work this way, or why they've ended up duplicating so much code in their filesourcexxx classes. But my solution was to simply remove $do['media_ref_id'] . _ from the meida_path. So far everything works just like it should. Of course you should keep unedited copies of these files in case you need them.
UPDATE:
If you're having this problem the best solution is to simply delete all of the numbers and underscores from the the beginnings of media_file entries in the ndxzbt1_media table in your database, so that 8_img3240.jpg becomes img3240.jpg. The expression to match is [0-9]+_ and replace with blank, or empty string ''. Make sure you back-up your database first. Since this is only a one time need it may be easiest to export the ndxzbt1_media table, run the regex on the sql file, truncate ndxzbt1_media(delete all entries) then import the sql file; Rather than trying to run the regex replace thru queries with a udf. But be careful of what you're matching.
No, people don't need to do all of that...
They simply need to visit each page from the studio and it will generate all the images, thumbnails.
This thread has been closed, thank you.