Unable to create path: /.../site/assets/cache/MarkupCache/

[Reid Bramblett]

Trying to work the kinks out of my first live PW site. Most of it displays beautifully on the front end (save, oddly, one rather important page throwing a 404, but I'll try to troubleshoot that once I get this bigger issue resolved). I can also log into admin and browse the pages tree and open pages in edit.

However, whenever I try to save a page (whether an existing one I have edited, or a new one I am attempting to create), I get the following error message:

Quote

Session: Unable to create path: /usr/www/users/reid/reidsengland/site/assets/cache/MarkupCache/

In addition, if the page happens to contain an image field, prior to that "unable to create path" error I also get:

Quote

 Session: destinationPath is not writable (images)

L'il help?

[rick]

Howdy again

The last quote gives you the cause of the error, destination path is not writable. <-- The permissions of your folder structure are not correct, and ProcessWire can't write to the destination.

In your /site/config.php file is listed the permissions ProcessWire needs, as shown below.
 

/**
 * Installer: File Permission Configuration
 *
 */
$config->chmodDir = '0755'; // permission for directories created by ProcessWire
$config->chmodFile = '0644'; // permission for files created by ProcessWire

I'm not sure what control panel you are using to access your document root, but most, if not all, have some mechanism to set/change permissions. In your /site/ folder, you will see a folder named, assets. Select this folder and then set the permissions for it and ALL folders and content below it.

That should do it.

Post back if you have any more questions.

[Reid Bramblett]

Thanks for the quick reply again, Rick, but that doesn't seem to be the issue. It looks as if every directory/file is at least at 775/644 or better (a few are even 777).

I did not actually check every single one, because I am using a hierarchical interface rather than some kind of Terminal/SSH window (I do not really understand those, and am worried a typo will wipe out everything), however I checked every directory, sub-directory, and file (or exemplar thereof).

Any other advice?

[Robin S]

26 minutes ago, Reid Bramblett said:

a few are even 777

Some hosts don't like 777 permissions - I suggest you change all directories to 755 and all files to 644 (apart from /site/config.php which should be more restricted). A good FTP client will be able to change permissions recursively, with separate permissions for directories and files.

Another thing that could cause your issue is lack of disk space - check to make sure you haven't run out.

[Reid Bramblett]

Plenty of disk space.

The permissions really don't seem to be the issue. I changed the handful of 777s to 755, and no dice. (The only directory/file permissions that aren't 755/644 are the session files within site/assets/sessions, all of which are 600 and unchangeable). 

For the record, I am running PW 2.7.3

[cstevensjr]

1 hour ago, Reid Bramblett said:

For the record, I am running PW 2.7.3

Is there a critical reason that you are still working on an older version of ProcessWire?  Have you tried to update to a current version?  Thanks.

[Reid Bramblett]

On 6/7/2017 at 0:57 PM, cstevensjr said:

Is there a critical reason that you are still working on an older version of ProcessWire?  Have you tried to update to a current version?  Thanks.

Frankly, I was so close to launching I didn't want to run the risk of having PW 3 break the site and setting me back. I just wanted it out there and live before I started fiddling in dev with a new PW version.

[cstevensjr]

Sorry about that, I fully understand.  You can also try the Legacy Version 2.8.62. "Same as 3.x but without namespace, for full 2.x compatibility."

 

Upgrading from ProcessWire 2.7

Upgrading from 2.7 to 2.8.x

1. Login to the admin of your site.

2. Edit your /site/config.php and set $config->debug = true; to ensure you can see error messages.

3. Replace your /wire/ directory and /index.php file with the ones from here.

4. When you've confirmed a successful upgrade:

   • Replace your .htaccess file with the included htaccess.txt file, OR if you have made changes to your .htaccess file, you may want to apply any changes manually (see instructions in section above).

   • Remember to restore the $config->debug setting back to false in your /site/config.php file.

[Reid Bramblett]

OK, so that was fun. I decided to try the PW3 upgrade, got it working swimmingly on the local server, but when I pushed it live it all went haywire (multiple reloads in admin did not do the trick). Spent several hours trying to get it to work, then several more trying to flush out the system and replace it with the 2.7 that had at least been mostly working.

Now I am back almost to where I started—though I managed to fix one of the two errors. I got rid of...

Quote

Session: Unable to create path: /usr/www/users/reid/reidsengland/site/assets/cache/MarkupCache/

 

...by simply creating an empty MarkupCache directory in that spot and the warnings went away. 

However, the more troublesome one remains:

Quote

Session: destinationPath is not writable (images)

 

I can edit all the other fields on a given page just fine, and they save properly. However, I cannot save edits anything within the image field, nor can I upload new images.

Any ideas? 

[cstevensjr]

23 hours ago, cstevensjr said:

 You can also try the Legacy Version 2.8.62. "Same as 3.x but without namespace, for full 2.x compatibility."

Sorry you ran into those problems, however it was suggested that you try the 2.8 version instead of going for 3.x version right away.

[fbg13]

Did you look at the error log? Might tell you something more.

[Reid Bramblett]

The error logs have nothing in the past three days. There's just that one line that pops up at the top of the screen every time I try to save a page with an image field:

Quote

 Session: destinationPath is not writable (images)

I am afraid I don't understand enough about the inner workings of PW to know why this field and no others is throwing an error. 

The only other bit of intel I can think to provide is that I am using the Type "CroppableImage" for the images field (and I have the most up-to-date version of that running).