On the Modwest shared system, 777 permissions are never required and always cause an error.
Does the new auto-update process (or theme installation) automatically chmod anything to 777?
If so, is that configurable/preventable?
On the Modwest shared system, 777 permissions are never required and always cause an error.
Does the new auto-update process (or theme installation) automatically chmod anything to 777?
If so, is that configurable/preventable?
Does the new auto-update process (or theme installation) automatically chmod anything to 777?
no. only you can change permissions manually
Thanks samboll -- a recursive grep does turn up instances of chmod(), but I don't know the internals well enough to conclude anything:
$ svn info | grep URL
URL: http://svn.automattic.com/wordpress/tags/2.7.1
$ grep -irl chmod * | wc -l
35I thought I'd better rephrase my question with some technical specifics:
Since the Wordpress codebase contains many chmod() calls, I am wondering if there is a circumstance in which it does a chmod g+w or chmod 777 (or similar) that sets additional write-permission bits on folders or files.
We are seeing multiple customer instances of Wordpress spontaneously malfunction because of permissions changes.
A workaround to this problem is to edit your php.ini file
disable_functions = chmod
Search and add that directive in.
This will prevent wordpress from chmodding your files and directories.
You must log in to post.