21 replies to this topic

[landitus]

Hi, all! I've encountered the following error message when trying to upload images in the server: "destinationPath is not writable". I've tried modifying permissions on the assets/files folder to "777" but no luck. I'll appreciate any help!!

[Soma]

Hello landitus,

not sure, are you using latest PW2.1? There used to be such an issue which was fixed. Any more infos you might can give can be helpful.

[landitus]

Thanks for the reply! I am indeed using ProcessWire 2.1.0. and the server uses PHP Version 5.2.17. Anything else you need to know?

[12345j]

hey,
try opening up wire/modules/inputfield/inputfield.module and change this line

if(!is_writable($this->destinationPath)) return $this->error("destinationPath is not writable");

to

if(!is_writable($this->destinationPath)) return $this->error($this->destinationPath." is not writable");

and see what the error is.

[landitus]

When I change that line, I don't get any errors and get a green session saved flash notice. The problem still remains and no image is saved.  :-\ Is this a permissions problems? What can I do?

[Soma]

Do you have debug mode on? In your site/config.php ... There might be more errors showing.

Not sure what the problem could be. Safe Mode on/off? in php? Have you manually uploaded the pw folders over ftp , so ftp user/group permission doesn't allow php to write in even if 0777... there can be many reasons.

[ryan]

When I change that line, I don't get any errors and get a green session saved flash notice.

That's unexpected. I have no idea what that would be. Doesn't sound like something coming from ProcessWire.

I agree with everything Soma and 12345J said.

When you get a "destinationPath is not writable" message, that only comes as a result of a permission issue. 12345J's suggestion was just to rule out the possibility that destinationPath isn't what we think it is for one reason or another, as well as to point out what the directory is so that we know what we're troubleshooting. But if you aren't even getting an error message when changing to his suggested code, that's a bit unusual. Why don't you just try changing it to this temporarily:

if(!is_writable($this->destinationPath)) die($this->destinationPath . " is not writable");

That will halt execution and give you the message indicating exactly what directory isn't writable.

Most likely there is a permission issue affecting the directory due to some change at the server or a site migration that didn't retain permissions. If you have shell access, a simple way to resolve it would be this:

cd /your/web/root/ 
chmod -R og+rw ./site/assets

If that doesn't do it, or you don't have shell access to do that, then I'd suggest creating a simple test script that you can use to help resolve it without having to upload an image every time. Place this in your web root in a file called test.php:

/test.php:

<?php
if(is_writable('./site/assets/files/1/')) echo "Writable!";
    else echo "NOT writable!";

If you know the ID of your page, replace the "1" in the path above with the ID of your page. For instance, ID 123 would be: ./site/assets/files/123/

[landitus]

Thanks for all the answers.

I have debug mode ON, and right know, I do not get any errors and all images upload but are not saved/not displayed. The is writable test was successful, and it displays: Writable!

I am really lost... 

[landitus]

I've noticed that a folder for the ID (1420) was created under site/assets/files, but it's empty. Maybe it helps. I did transfer all files with an FTP and then manually changed permissions on the assets folder. That's when the error message disappeared. The result now is no errors but no image is saved on the server.

It really looks like a server issue, isn't it?

[ryan]

It's hard to tell because the conditions seem to be changing. It also sounds like session messages were appearing that aren't part of ProcessWire. It may be good to replace your /wire/ directory with one from a fresh download of ProcessWire 2.1. Though lets look at your phpinfo() first.

That's good that the directory appears to be writable, but if your uploads aren't going there, then not good. If you want, PM me a link to your phpinfo() and I can have a look to see if there's anything about the server's configuration that might be causing a problem. To get the PHP info, just paste the following into your /test.php, and then send me the URL:

<?php phpinfo();

[ryan]

Thanks I got your PM. The only thing I see as a possible issue in your phpinfo is that safe_mode is ON. I can't say as though I've come across a hosting environment with this turned on before. But my understanding of it is that if a server has safe_mode on, then the PHP script can't move/copy files unless it is the owner of those files. PHP appears to be running as an apache module rather than as a CGI on your server. So there is going to be some variation in permissions between your account and that of Apache. Usually not a problem at all, except when combined with safe_mode, that creates some headaches and could definitely interfere with file uploads.

The first thing I want you to try is to create this directory and make it writable to all. Later on, once you know it's working, it'd be better to make it just writable to PHP (if you know what user it's running as). But if this is a dedicated server or the accounts are well jailed, then not a big deal. But for now create this directory and make it 777 (rwxrwxrwx):

/site/assets/cache/uploads/

Then add this to your /site/config.php at the bottom:

ini_set('upload_tmp_dir', $config->paths->cache . 'uploads/');

See if that resolves it. If not, the next thing to try is to see if your web host lets you create your own php.ini, or modify the php settings for your account. Many web hosts let you do this, but you might have to search around in their support docs. You will want to disable safe_mode, which can't be done at runtime with ini_set(). Let me know if you get to this point and I can help you figure it out.

If none of those are an option, then I'd be willing to experiment on the server to find a solution if you don't mind giving me access temporarily.

Btw, the site you have running on that server is gorgeous–beautiful design.

[Soma]

Ryan that's exactly the combination I'm facing with a website hosting I need to do a relaunch. I installed PW and got the same error, so I figured out that save_mode is on. That's why I was asking this.

Having only faced 2-3 such configuration yet in all the years from friends... I for myself decided to simply tell the owner to change hosting provider.  Everytime it got chaotic and it took them ages and 1000000 emails to get them the configuration only nearly right. Often they are shared hostings with php running as a module to save money and have no clue.

[ryan]

Yeah I'm not sure why any web hosts would be using safe_mode when running PHP as an apache module, but it does point to possible issues at the host. However, I would like to find a way to make PW recognize and adapt to the situation if at all possible. Thankfully in PHP6 things like safe_mode and magic_quotes will be permanently gone.

[martind]

just want to note here, I had the same issue on an installation reachable with 3 subdomains on the same webspace. Everything worked fine while the url was the same than on installation. Problems as described above came up after the first call with the new subdomain. no login possible (resolved by delete all session files), errors about the unwritable img path on saving entries. the solution for me was to chmod 777 /assets, /session, /cache, /files and all it`s subdirectories. safe_mode is off. maybe this has something to do with sessionFingerprint and sessionChallenge, but haven`t looked further in this because everything works fine now.

[ryan]

ProcessWire assumes that the entire /site/assets/ structure is writable. As long as PW can write to any directories in there it should be happy. What you have to do to make that writable depends on the server environment. If Apache is running as your user account (like PHP as a cgi) then it only needs to be writable to you. If PHP is running as a module on Apache (as is most common) then that directory needs to be writable to whatever user PHP is running as. In a dedicated environment or a reasonably secure server environment where accounts are well jailed from each other (as are many major hosting providers) 777 (drwxrwxrwx) on those dirs ensures PHP can write to it without you having to determine what user PHP running as. This is the default that ProcessWire uses for the directories it creates in /assets/ (according to the predefined setting in /site/config.php). In a less secure hosting environment where accounts aren't well jailed from each other, it's preferable to use PHP as a CGI and use permissions where only your account can write to the /assets/ directories (and likewise update the permissions in /site/config.php). But that's for long term. When you are running into write errors in /assets/, do what you need to do to get it working, then determine if you need to lock it down further.

[landitus]

Finally, the server provider turned off safe_mode and now everything is working properly. Unfortunately, I couldn't get any feedback to getting it to work with safe_mode on, but at least they changed the setting for me.

I wan't to thank everyone for all the help and patience!! I'm very happy everything is working ok!! 

[ejdamd]

My provider doesn't want to turn safe_mode off, he thinks it's too unsecure. Unfortunately it's a bit complicated as my client doesn't want to change provider. Provider told me if folder is made by PHP script, it will be writable for PHP. I'm just thinking why you don't include creating assets folder into installation process.That should resolve similar problems with safe_mode as I have, shouldn't it?

[Soma]

As far as I know PW does write all the assets from the install folder already.

[ejdamd]

As far as I know PW does write all the assets from the install folder already.

But it's not creating assets folder itself.

[ryan]

ProcessWire will give you a warning at install time if the /site/assets/ dir isn't writable. This part really shouldn't matter with regard to safe_mode.

Ejdamd, is some part of PW not working in your case? Let me know, as PW should be safe_mode compatible. But if you are finding it's not we can find out why not and tweak as needed.

Also, I would suggest sending your provider this link. The PHP team strongly recommends not using safe_mode. Servers relying on it tend to be less secure, not more secure. They have deprecated it and it won't be around much longer:
http://php.net/manua...s.safe-mode.php