Can't see images in 5.3

Permalink
Guys,
please help. I installed 5.3 and all seems good, but I can not see any default images (or any other images) in dashboard and my site.
Can you please help? I tried rescanning - no luck.

Thank you

 
andrew replied on at Permalink Reply
andrew
If so, can you be more specific? Do they show up but without thumbnails? Are they in the site? If you click them and click "view" in the menu do they show up?
goon replied on at Permalink Reply
andrew,
thanks for looking into it.
I can see the files (outline of the boxes) listed in concrete FM. However the images can not be displayed. They are blank. The same result on the site as well. box is there, but image not visible. when I click view no image shows up. Hope this helps. Please let me know if you need more info.
If I go to my control panel, i can click and view the images in the files or files/incoming folder. But concrete5 and my site can not display them.

Please help. Thanks
kutis replied on at Permalink Reply
kutis
or clean install?

same thing happens to me when i upgrade, i've decided to start clean for all sites that has 0 data in it.

if you also upgrade, try edit the image, it'll then launch picnic, dan just save it.. it'll work after that
goon replied on at Permalink Reply
thanx for the info.
I tried to edit the image, i get error retrieving the picture
tomdrops replied on at Permalink Reply
Actually, the pictures are invisible...
Richt-clicking the spot werhe the picture is supposed to be and trying to dispay it ends up with an error 500...

http://www.taomanagement.com/files/1912/4030/3686/inneroptics_dot_n...

ends up in 500: internal server error

Tom
tomdrops replied on at Permalink Reply
Actually, removing the .htaccess file in /files solved the problem.

Keeping people from browsing the /files directory can easily be done from from your httpd config file, either in httpd.conf or in your config file for your virtual host:

<Directory /absoulte_pathname/files>
Order deny,allow
Allow from all
Options -Indexes
</Directory>

prevents visitors from browsing your files directory but pictures will work.

Tom
goon replied on at Permalink Reply
tomdrop
thanx so much, this helps a lot.
works like a charm
bhosmer replied on at Permalink Reply
I just came across this thread and am experiencing this same issue with 5.3.3.1

I don't have an .htaccess file in my files folder. I've tried changing permissions for my /file directory as well, but to no avail. The file manager says they are there, but will not display any thumbnails for ANY images including the inneroptics default images for yogurt.

I've searched and searched for a solution to this. Does anyone have any ideas?
frz replied on at Permalink Reply
frz
something goofy with your install.

try clearing your site cache in dashboard, if that doesnt help reinstall from scratch.
bhosmer replied on at Permalink Reply
I have cleared my cache through he dashboard, and manually deleted the cache. I also tried turning off caching entirely. I have also reinstalled clean twice.
bhosmer replied on at Permalink Reply
This seems to be an issue relating to 5.3.3 I downgraded and completed a fresh install of 5.3.2 and now my images appear fine. I had to change permissions in the file directory though and it seems that whenever concrete adds a new file to the files directory, the permissions prevent it from displaying. After changing them though the images are visible.

It is almost as if concrete dynamically changes permissions as it adds files.

I will stick with 5.3.2 for now.
aeroclown replied on at Permalink Reply
aeroclown
Have you verified ownership of the affected files ? Another thing that might stop you from having access to something is if the files and folders are not owned by the user the apache instance uses to pull your information off the driver for display. Different permission levels enable specific items on files and folders for instance when you look at permissions each number represents a level of access for a specific group of permission. IE Owner, Group, Other or
rxwrxwrxw.

Check this out if you are not familiar with linux permissions though there are alot of other versions of this information so feel free to google around if these don't help you:

http://www.tuxfiles.org/linuxhelp/filepermissions.html#view...

That isn't to say there isn't a problem, its just a potential thing for you to look at outside of just the permissions. If you are changing the files and folder to for instance, chmod 777, then what you are doing is basically giving the Group, the Owner, and ALL GUEST the ability to Read, Write, and Execute the Files and Folders. So the question is what are the permissions you see before you change them and what is the owner and group. Because apache has to either be the owner of these files, or it has to be in a group that can read,write, or execute these files. I hope that is helpful. There are a number of things that can cause that to occur, but its strange that it only does when you upgrade to 5.3.3.1
bhosmer replied on at Permalink Reply
The odd part about this is that C5 works beautifully right out of the box on a free host I am trying out, host56.com

I am using webhero, and have had to downgrade to 5.2 just in order to get it to function properly. I suspect it may have something to do with that they aren't running the latest PHP.

After contacting support with my host and going around with them for a while, I managed to get this error from one of the admins while he tried to duplicate my problem:

pcfg_openfile: unable to check htaccess file

I don't have an .htaccess file, so this could be the culprit.

Again, I am having an issue with files being visible in the file manger. The images upload fine, and show a placeholder, however the permissions when using the file manger are not by default 755 after they are uploaded.

I really like C5 and want to get this bug worked out so I can use it for production.
notcholas replied on at Permalink Reply
I've just come across something interesting re the file permissions issue.
In 'File Manager > Access' I've set the 'Alternate Storage Directory' to a different directory then once I've uploaded a file, I went to 'Access & Permissions' for the image then changed the storage location to the new alternative one.

This allowed the image to be viewed in the front end.
The odd thing is if you use the same location as the 'Standard File Location' for the Alternative then do as I mentioned above it works fine.

The only thing now is that the Thumbnail folders within 'files' also have the same permission problem!

I wouldn't know how to fix but it seems something is wrong somewhere.
bhosmer replied on at Permalink Reply
I hadn't considered that. I hope one of the developers reads this and can track down what is happening with the way the backend stores the files. For now I suppose we are stuck with manually changing the permissions every time we add new images. What are host are you using by the way?
notcholas replied on at Permalink Reply
The site was done for a client, which means he wont know how or want to change the file permissions every time he updates his site.

The site's hosted with these guys:
http://www.webfusion.co.uk/

Yes, I hope one of the developers can resolve the problem as C5 is great.
bhosmer replied on at Permalink Reply
I feel your pain with this. You and I have no problem changing the permissions and debugging, however a client who paid for it would have no knowledge or interest in monkeying with command lines and ftp'ing into his server.

This negates the ease of use.

Do you have an .htaccess file in place?

I haven't added one myself.

Do you have any way of looking at the php errors that come across during the file transfers?

It seems C5 for some reason sets the default permissions of any new files to 6xx instead of 755, which prevents the images from being displayed.

I don't know enough about PHP to look at what C5 is doing and figure it out.

The admin with my server company is adamant that this is a C5 problem. Initially I suspected it was a configuration issue with my hosting company, since C5 worked fine with another hosting company and I imagine others don't have this issue.

I would add an .htaccess file, but I'm not sure what to put in it to make it work. I am guessing C5 is trying to determine the rules for adding a new file and since it can't find any it defaults to a very safe permission for new files.
frz replied on at Permalink Reply
frz
some things to check:

Was your concrete5 installed via simplescripts? They typically break something with every release we do, so try doing a install from scratch.

Are you running PHP in CGI mode or on a wimblows box? While not impossible, you're certainly not running concrete5 in the desired way.

Default settings for your server? The permission changes that you guys are describing aren't things we do on our boxes, so perhaps there's some kind of defaults that are off..

Wish I had something more clear to tell you to do, but obviously every server is different.
bhosmer replied on at Permalink Reply
Thanks for the reply!

I will try to answer your questions as best I can, I will also forward this to the admin that hosts my site. Some of these questions I won't be able to answer since the site is a hosted site.

No, I did not use simplescripts. I FTP'd and then ran the installer as described in the readme.

The PHP I am not sure, however I suspect it is a linux box.

Can you give me a list of settings you use that works so that I can forward these to the admin of my hosted site.

Once again, you guys have a great product and I appreciate you taking the time out to help me (us).
mrtorrent replied on at Permalink Reply
mrtorrent
I seem to be having the same (or similar) problem. When I upload an image via the file manager, C5 saves it and creates the thumbnail, but it creates the directories with 764 permissions and the file with 664, which results in the image being unviewable.

Changing directory permissions to 777 seems to fix it, but having to do this every time an image is uploaded is obviously less than ideal. Any suggestions would be appreciated.

I have already tried reinstalling from scratch, to no avail.
mrtorrent replied on at Permalink Reply
mrtorrent
Right, I've investigated it further and found that the web host in this instance has a umask of 011 set. The ConcreteFileHelper::mapSystemPath() method (concrete/helpers/concrete/file.php:75) does not account for a umask being set, however, and this is where the problem lies.

You can temporarily alter the umask but, as perhttp://uk.php.net/manual/en/function.umask.php,... the recommended method is to change permissions after creating the file.

Here is a diff, for anyone interested:
--- file-old.php   2009-12-02 22:03:15.000000000 +0000
+++ file-new.php   2009-12-02 22:02:47.000000000 +0000
@@ -83,12 +83,15 @@
             if ($createDirectories) { 
                if (!is_dir($base . '/' . $d1)) { 
                   mkdir($base . '/' . $d1, 0777, TRUE); 
+            chmod($base . '/' . $d1, 0777);
                } 
                if (!is_dir($base . '/' . $d1 . '/' . $d2)) { 
                   mkdir($base . '/' . $d1 . '/' . $d2, 0777, TRUE); 
+                  chmod($base . '/' . $d1 . '/' . $d2, 0777);
                } 
                if (!is_dir($base . '/' . $d1 . '/' . $d2 . '/' . $d3)) { 
                   mkdir($base . '/' . $d1 . '/' . $d2 . '/' . $d3, 0777, TRUE); 
+                  chmod($base . '/' . $d1 . '/' . $d2 . '/' . $d3, 0777);


There may well be more instances of this issue, but setting the right permissions on the generated directories solved it for me and I don't have time to explore further at the moment. Hopefully knowing the source of the problem will allow the C5 developers to sort out any other spots they know of.
notcholas replied on at Permalink Reply
Thanks. your code seems to have fixed the problem for me.
Are there any security issues for using the code?
mrtorrent replied on at Permalink Reply
mrtorrent
@Huub: You'll have to find the code that handles file uploads and add a chmod() call in an appropriate place.

Unfortunately, I'm not able to point you in the right direction myself, as this is only my first foray into Concrete5 and I'm not very familiar with the internals yet.
Huub replied on at Permalink Reply
I tried this code but first without result. I found that the attributes on the file itself was blocking the access. On a new uploaded file it was set on 660. Changing it to 664 made it work. I tried again with the old, unchanged file.php and only changing file attributes into 664 made things work.
Directory attributes were set on 771.

Could the file.php being changed so that the attributes on the file will put on 664.
mrtorrent replied on at Permalink Reply
mrtorrent
@notcholas: Yes, you should be aware that those permissions (0777) will give any user on your server full read/write/execute access to the directories that the code creates.
spiny replied on at Permalink Reply
Thanks for the code, this resolved part of the issue for me. However, my particular shared webhost also changed the permissions of the files and thumbnails themselves to 660. I added the chmod call to 2 more files, and now I (and more importantly, the owner of the website :) ) can upload and view the images as expected.

The files are:
- concrete/helpers/image.php, lines 70-76:
if ($im) {
         $res = @imageCopyResampled($image, $im, 0, 0, 0, 0, $finalWidth, $finalHeight, $oWidth, $oHeight);
         if ($res) {
            $res2 = @imageJPEG($image, $newPath, 80);
         }
      }

Change to:
if ($im) {
         $res = @imageCopyResampled($image, $im, 0, 0, 0, 0, $finalWidth, $finalHeight, $oWidth, $oHeight);
         if ($res) {
            $res2 = @imageJPEG($image, $newPath, 80);
                chmod($newPath, 0777);
         }
      }


And
concrete/libraries/file/importer.php
if ($path == false) {
         $path = $fi->mapSystemPath($prefix, $filename, true);
      }
        return copy($pointer, $path);

Change to:
if ($path == false) {
         $path = $fi->mapSystemPath($prefix, $filename, true);
      }
        $success = copy($pointer, $path);
        chmod($path, 0777);
        return $success;


Hope someone can use this.

Martin
marcusmorris replied on at Permalink Reply
Thanks spiny! With mrtorrent's fix to file.php and your fixes to image.php and importer.php, my problems went away! Even the thumbnails came back! Andrew Embler (concrete5) had changed his code since you published the fixes but it was still quite straightforward to work out where the chmods should go.

This has been a really useful tip - thanks again!
woody replied on at Permalink Reply
Hi

My hosting company is Webfusion and I get exactly the same issue, cant view thumbs, or images unless I chmod the folder and images to 777.

I have 5.4.1.1 installed and none of the suggested code works. There seems to be a few diffidences between the above code and the actual code.

Does any one know how to edit 5.4.1.1 to solve this issue?