Welcome to WebmasterWorld Guest from 184.108.40.206
Forum Moderators: bakedjake
MagpieRss requires that the following permissions are set for the cache folder, in order for caching to work properly:
I used my favourite WS_FTP (ver. 5.08) to change the permissions for the cache folder by highlighting/right-click and setting them accordingly. But for some reason, I realised that *all* folders have acquired the new set of permissions. I thought that permissions are applied in a top-down manner and not the opposite. I remember that permissions for other folders before I apply the change, were:
Can anyone shed some light into this. I am not sure that having read, write and execute for owner and group is a good idea. I only needed that for that particular folder so Magpie can store the RSS cache.
Caching doesn't seem to be working, whats wrong?
Is is a very frequent question. A number of things could be wrong, the most common is that the your web server does not have permission to write to your working directory. In this case you'll want to manually create the cache directory and make it web writeable. How to do this varies from platform to platform, and host to host, but the basic idea is:
chown _web-user_:_web-group_ /var/www/mysite/cache;
On Debian web-user and web-group by default will be www-data and www-data
On Redhat..... (I don't know, help?)
On BSD...... (I don't know, help?)
On OS X web-user and _web-group are www and www
I can't follow the above example because I don't have sufficient permissions (or I don't have a shell account, or I don't understand)
Turning off caching is never a good idea so I recommend figuring out someway to make it work. A few options are:
put your cache in the /tmp directory like so
this approach has some security issues that will be addressed in a future version of Magpie.
make your cache directory world writeable.
always a bad idea, I'm not going to cover how to do this
move your cache into a database
won't be as fast, but is one solution, I'll discuss more in the future
As far as why all your folders' perms got changed, it must be a glitch in the ftp program.
Did you left-click to highlight, then right-click or did you just put your pointer over the folder and right-click?
Do you have ssh available so you can run command-line? If so, try using chmod command.
chmod go=rwx /var/www/domain/public_html/magpie_cache
But again, it is dangerous to make a web-accessible folder world-writable.
One option that I can think of is to move the cache folder above the public_html folder. Then you can tell magpie where it is in the config file like this:
I added the following line at the beginning of where I call Magpie, so that it overrides the default cache folder:
As I am really not into Unix Security, would you say this is a good place to have the cache folder?
It seems there might be an issue with my version of WS_FTP. I had definitely selected the folder, prior right-clicking it. Fortunately, my host console has a web-based file manager from which I can set the permissions without worries.
The '/tmp/' folder seemed to have all permissions checked for all 3 groups (I haven't touched anything there!). After I added the above line, the 'magpie_cache' folder was created by Magpie itself, within tmp, with the following permissions:
Also, having screwed up my permissions with WS_FTP elsewhere within my website, do you know what they need setting to? Is the following o.k.?
'755' definitely rings a bell;)
Just checked that all web folders are 755ed - they actually already were. Might have a look around to find another FTP utility so that I can be a bit more confident while setting permissions in the future.
So far, wasn't able to find any documentation from my host as to how to connect using SSH. I d love to. I used WinSCP in the past and have had good impressions from it.
I browsed around and tmp seemed to be one of the few with sufficient permissions. I 'Googled' around for quite a while and this was one of the most common ones that seemed to be used in Magpie config tutorials. The other one was /var/cache. Not sure if I made the best choice. Still, both directories are well above the public_html folder :)