#16971 closed defect (bug) (invalid)
Creation of .htaccess file leads to a 500 Error
Reported by: | hakre | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Rewrite Rules | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
Turning on permalinks can render the whole blog into a 500 error situation under certain conditions.
The issue has been experienced with a WP 3.0.5 setup, other versions seem affected as well.
The creation of the .htaccess file does not reflect the systems umask setting which can result in creating a file that is not accessible by the server.
That triggers the 500 then.
Normally WP chmod's all files it creates. This is not done with the .htaccess file if it did not existed already.
Attachments (2)
Change History (14)
#2
follow-up:
↓ 4
@
13 years ago
you say it also happens in other versions than 3.0.5
does that include 3.1?
#5
@
13 years ago
The flow in that function could be simplified to first check if a file exists or not and handle everything related to file creation upfront.
See the example attached which demonstrates this next to the following:
Then the replacement of the area(s) defined by $marker could be buffered and thanks to that simplified as well.
The second benefit of a buffer is that it can be written buffered to disc reducing I/O.
The function can benefit from defining the input variables, it's a bit unclear if $insertion must or can be an array. Not addressed in the example, just came to my mind.
#6
in reply to:
↑ 4
@
13 years ago
- Component changed from General to Rewrite Rules
- Keywords dev-feedback removed
- Severity changed from normal to major
- Version changed from 3.0.5 to 3.1
#7
@
13 years ago
- Version changed from 3.1 to 3.0
OP said he could reproduce this on the 3.0 branch.
#10
@
9 years ago
- Keywords needs-testing good-first-bug added; needs-refresh removed
- Severity changed from major to normal
Good first bug: Report if can reproduce
#11
@
8 years ago
- Resolution set to invalid
- Status changed from new to closed
I tried reproducing this on a few environments with several different settings but was unsuccessful. Even using the noted FS_CHMOD_FILE setting and forcing umask() before this was called wouldn't cause the issue. If I just couldn't write to the directory in general, I would be told to manually create the .htaccess file as expected.
Tested 3.0.3 & 3.0.5
Patch against trunk.
I'm not sure if FS_CHMOD_FILE is the correct value to refer to, for my case the 0644 (rw-r--r) would have done it which is the default for FS_CHMOD_FILE.
Related: #10170