Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By Darrell on
drupal 4.6.3 image.module 4.6.0 on a LINIX server.
When I create content Image, I fill in all the blanks and browse to the .jpg file on my computer. When I click on submit the .jpg file is loaded into the /files/images/temp directory but then nothing else happens. No error messages. Nothing shows up anywhere.
When I first started trying, I had the /files directory created with permissions of 777. The first time I tried to create an image, drupal created /images in the files directory but nothing else. The permissions for /images as created are 740 and I am not able to rename,edit or delete the directory.
My work around was to rename /files and create a new /files. while I was at it I created /files/images and /files/images/temp and set all of the permissions to 777.
After doing that, I now get the .jpg files to load into the /temp directory but the permissions are set to 644 and I can not rename or delete them.
I am lost.
Comments
Image.module
After doing some checking, I find that my server does not have Imagemagik it has GD 2.
Where do I find "image.gd.inc"???
I think GD2 support is...
...built in by default.
--
Anton
Please how about some help!!
I finally found "image.gd.inc" and put it the place of "image.imagemagick.inc" in the /modules/image directory.
I wiped the database and re installed all of the .mysql files.
The only module that I enabled is images other than the initial drupal modules.
Still all that happens is that the .jpg file ends up in the /files/images/temp directory. No errors. No content created.
I NEED some help.
Need more info
On /admin/settings what are your file system and image handling settings?
What are the settings on /admin/settings/image?
Is there anything in your logs?
Where did you find image.gd.inc? Try putting that in your includes directory rather than your modules directory. Although you shouldn't actually need it as far as I can tell. I use gd2 and don't have that file on my system.
What are the directory ownerships (important) and file permissions of your "files" "images" and "tmp" directories?
--
Anton
Settings
/admin/settings
Name=drupal
E mail address my address
Slogan, Mission and Footer are blank. Anonymous user:Anonymous
Default front page:node Clean URLs:Enabled
Error reporting:To log and screen
File system path:files Temporary directory:/tmp
Image handling The built-in GD2 toolkit is installed and working properly.
settings on /admin/settings/image
Default image path:images
thumbnail 100 X 100 preview 640 X 640
Gallery settings
Images per page: 6
Nothing in the log or to screen
Permissions for files, images, tpm and images/temp are all 777.
I found image.gd2.inc at http://drupal.org/files/issues/image.gd2.inc
Settings again
I just discovered that my problem is related to the file size of the image.
Small file size (40-50KB) work fine.
Just tried one 268Kb and it worked but a 400Kb file didn't load and there are no errors.
I remember seeing a file size parameter somewhere but now I can't find it.
Shouldn't there be an error message?
Getting somewhere now
This is a fairly common and annoying problem, and you might need the cooperation of your webhost to fix it. I'm assuming you are on shared hosting - the problem is easier to fix if you are running your own server.
There are 3 or 4 different Apache and PHP settings relating to max HTTP POST size, max memory usage, max upload size etc.
If you can do a phpinfo() on your site, look for the following settings:
memory_limit
post_max_size
upload_max_filesize
If any of these are too small, you might be able to change these in your settings.php file or if you are lucky (ie running your own server) in your php.ini file.
--
Anton
More settings
phpinfo() on my site:
memory_limit= 18388608
post_max_size= 8M
upload_max_filesize= 2097152
I remember seeing an image file size in Kb in admin/user/configure but it is set at 30Kb and I think that is for avatars.
I would like to set the image size larger but I at least need some error messages.
hmm
Those PHP numbers should all be high enough (I think) to upload a 400kB file - you might be limited by an Apache setting. You'll probably need to talk to your webhost about it.
But yeah, this problem generally doesn't leave error messages. The upload just seem to hang.
--
Anton
File size image upload. No constant action
Upon experimenting I have found the following results:
create content image results today:
274Kb file and smaller uploads to files/images/temp makes preview & thumbnail in /temp directory and are promoted to front page.
447Kb, 479Kb, 740Kb and 989Kb files uploads to files/images/temp but do not or create errors.
1483Kb file uploads to files/images/temp makes preview & thumbnail in /temp directory and is promoted to front page.
2495Kb file creates error in log:
Invalid argument supplied for foreach() in /home/machin/machinemaster-www/member/modules/image/image.module on line 316.
Does not load file in /temp but creates content and promotes the title to front page with no image then creates error in log:
Cannot modify header information - headers already sent by (output started at /home/machin/machinemaster-www/member/includes/common.inc:384) in /home/machin/machinemaster-www/member/includes/common.inc on line 192.
All of the files that do upload are only in the /temp directory and no where else. They don't get deleted when you edit/delete the content so the /temp directory will keep everything ever loaded.
Getting wierder
But I'm all out of ideas sorry.
I suspect its environmental rather than anything in the code. Do you know what your host is running for a platform?
I've never had any of these kinds of problems with Debian Sarge using both GD2 and ImageMagick.
--
Anton
it is the pixel not the bytes
I had the same problem when installing image.module. I had to recreate the image folder by myself and chmod it to 777, after renaming the original stucked image folder to something else.
Then I began testing on uploading.
I found out that these has something to do with the admin -> settings ->image
When we set the preview size to 640 x 640, any image that is larger than 640 pixel will be having problem (I got "cannot find server" error).
These is the result of my testing:
300x225 pixel - 15kb - success
300x225 pixel - 26kb - success
500x375 pixel - 52kb - success
640x480 pixel - 72kb - success
640x480 pixel - 83kb - success
641x480 pixel - 82kb - failed
800x600 pixel - 99kb - failed
1024x768 pixel - 293kb - failed
But when we change the setting, let say preview for 800x800, then image up to 800 pixel width or height will able to upload.
I hope somebody can think of a solution here.
I want my visitors to upload any size of image and image.module would resize it to my standard.
It is not friendly to ask visitors to resize their image to our standard BEFORE uploading when we want to encourage them to visit us!
Similar problem, different error messages
I had very similar problems (image.module works with smaller files, fails with larger ones), although I got different error messages from php.
Here's where I've posted the details of my situation:
http://drupal.org/node/73986#comment-129412
The solution turned out to be to use ImageMagick in place of the GD toolkit.
IIRC, upload size for image
IIRC, upload size for image files is controlled by upload modules file size settings.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
uploads and images
Don't worry about not being able to rename or delete the uploaded files and images directory etc. It is a side effect of how the web server is set up and which user it runs under.
See this thread for more details:
http://drupal.org/node/31766#comment-55359
Don't worry that you can't access them. Just set /files to 777 then let Drupal take care of creating the subdirectories. If you do need to access the files later, you will need to use a php script to reset the permissions - it can do that because it runs as the same user account as the web server does, which is also the same user account that created (ie and now owns) the files you uploaded.
It's a little tricky to explain in a couple of sentences though - an understanding of unix and apache setups helps. Hopefully that other thread should elaborate enough.
If after all that, and Drupal is happily uploading images that you now can't rename anymore (due to the ownership issues) - does the image module still give problems?
--
Anton
Chmod.php
I found and tried Chmod.php and I can change permissions but is it possible to change permissions using a wild card? Is it possible to change the owner?
chmod
You can pass the unix chmod shell command wildcards, as well as a recursive flag that will descend into subdirectories. But I don't know about how the PHP chmod function operates.
If the PHP chmod can't do it, you could try using the system function to run the unix one:
http://php.net/manual/en/function.system.php
http://www.openbsd.org/cgi-bin/man.cgi?query=chmod
But generally the only user that can change the owner or the group on a unix filesystem is root. So on the most part this can only really be done by those running their own servers.
--
Anton
System.php
Thank you. System.php is great. It lets me use Linux commands.
I can Chmod, mv, rm and I don't know what else.
So where are we now...
Like many others I want to use the image module in a simple way.
So I was quiet surprised: why do a lot of people have the same kind of trouble with a module that might become part of the core? Just because of some permissions they cannot control? Why is use of the generated files directory (and its subdirectories) a must? Can't it be changed to something else, i.e. a custom image directory? Is it really necessary to care about things like Unix, permissions, 740, 777, memory_limit, post_max_size, upload_max_filesize, chmod.php, system.php, et cetera?
Trying to get this module to work, it just generated some directories I can not even change or delete... Where is that for?
Security
The reason it is more complicated when you need to upload files and/or images is because you are now operating the web server in a different way.
With standard HTML only Drupal configuration, Drupal is not creating any files on the web servers filesystem. When in that mode it runs like a standard web site - all the web server needs to do is read the files, it doesn't need to write anything. All the content you submit to the site is going into the database not the filesystem.
But to be able to upload files or images through the Drupal interface, now Drupal needs to be able to write files to the filesystem on the server.
This gets tricky because most of the time you don't want the webserver to be able to write files into your site directory. Just think what would happen if some exploited a vulnerability in someone else's website on that server - they could now overwrite any of your website files very easily. Just think what you could get up to just by uploading PHP files if other peoples sites had wide open write access - no don't try this.
So generally web servers aren't allowed to write files in peoples websites. If you do want to Drupal to be able to write files into a subdirectory - you will have to manually weaken the filesystem security to make it work.
This isn't a Drupal issue - any code (eg PHP, Perl, Python etc etc) run by the web server will need those permissions weakened if they are to be able to write files to part of your web directory.
One side-effect of the web server writing those files is that you are not the owner of those files - the web server is. So unless you get the web server to loosen permission (eg via chmod.php) you won't be able to change or delete them.
The memory_limit, post_max_size, upload_max_filesize settings are there to limit what any one website can do with the server. If these are too high, it allows one site to completely overload the server causing trouble to all the other sites.
Its all just the nature of sharing a server with lots of other people. There will be security and resource limits put in place to stop a badly behaved user causing trouble for the others.
All these environmental issues are not problems with Drupal - they are issues between you and your webhost. If your webhost doesn't give you the environment to run Drupal how you want, you should either find a new webhost or find another CMS that will work how you want on that webhost. The first option is probably the easiest though - ask here for recommendations.
Disclaimer - there are other ways of setting up a webhost service that don't have these same issues, but could very well have different issues.
--
Anton
Security
Does the security issue mean that I should not leave Chmod.php or system.php anywhere on my server?
Can someone else access these files?
Also on a drupal site that I am experimenting on, I created /files, /images and /temp before drupal had a chance so that I own them.
They all have 713 permissions. Should I change any of this? Should I delete these directories and let drupal create them?
This is all new to me. This is my first step away from html.
How paranoid are you?
Strictly speaking yes. Whether or not you remove them depends on whether you want other people to be able to run them or not. Don't forget that you have advertised in a public forum that your site has them.
I'd remove them myself, but I then again I remove everything that isn't vital to Drupal anyway.
It shouldn't matter that you own them as long as Drupal can create new files in them. Do the upload and image modules work?
713 permissions? That is a fairly unusual combination ie rwx--x-wx, but if it works it works and don't worry about it.
The most important thing to worry about is that only you can write to any directories where your PHP files live. And that other accounts (eg the web server) can only read the PHP files not write to them.
--
Anton
Permissions
I am seeing this error when poormanscron runs:
opendir(files/images/temp): failed to open dir: Permission denied
and:
Unable to initialize embedded Gallery
Would this be caused because there is no read permission for the last two groups?
Unsure
I'm not sure what kind of access is needed for your configuration.
If the Gallery component needs to use some sort of directory listing, it will need read access on the directory.
Changing permissions to 717 for a little while should let you know whether it is required or not.
--
Anton
Permissions
Trying to sort out Owner - Group - Others
I looks like when drupal creates a directory that my host or apache is the owner. In that case, when I ftp in, who am I? Am I Group or Others?
When I ftp in and create a directory I am the owner. In that case who is drupal?
As you can see, I am new to Linux.
guessing
But assume 'other' (ie world) in both cases.
When you FTP in, you are the user name you logged into FTP with (eg 'darrell'). Drupal in most cases will be the user the web server runs as (ie on Debian it will be 'www-data').
Chances are group doesn't come into it, unless you have asked your host to add www-data to the darrell group or darrell to the www-data group etc.
But I am still guessing as to exactly what your host does though :)
--
Anton
Thanks for the explanation
Hi Anton,
Thanks for your patience and explanation about the need of creating and protecting permissions. Now I see why things are done the way they're done.
Doesn't mean I still prefer uploading images (using FTP) to some custom directories, and let the image module refer to these directories...
Well, I will contact the hosting company, and see what happens.
Marc
___________________
discover new oceans
lose sight of the shore
Yep
I can see how an image module that just let you refer to images the webmaster had pre-uploaded (eg via FTP) into a directory could be useful, but it would only really suit a site where only the webmaster uploads images (eg like a brochure site). For a community site where lots of users can upload images (and you don't want to give them all FTP access), it would probably need to be done the way the current image module works now. There is nothing stopping anyone creating a module to access FTPed images though.
I haven't tried this, but you should still be able to refer to FTPed images by just entering your own <img> elements into the HTML. The only complication I can forsee, would be that you might need to play with some of the rules in the .htaccess file to stop Drupal intercepting the HTTP requests for those images itself.
--
Anton