2

Context

  • Apache 2.4.18
  • Ubuntu 16.04.1
  • PHP 7.0.8
  • WordPress 4.6 (This may be irrelevant as this question is mainly just a PHP writing thing, but I am working within a WordPress theme's directory.)

Files

I have two files: foo.php and bar.css.

This is foo.php (located in /wp-content/themes/theme-name/):

<?php
// Write some stuff to bar.css
file_put_contents('abs/path/to/bar.css', 'Blah blah blah...');
?>

and bar.css is completely blank (also located in /wp-content/themes/theme-name/).


Goal

I'd like to allow foo.php to write to bar.css without me having to up the permissions of the bar.css file to 666 (from 644). I've tested it, and I can get it to work just fine if I change the permissions of bar.css to 666, but again, that's something I'd like avoid.


What I've tried

I know this might seem like a redundant question, but honestly, I've been looking on SO and beyond, and I still haven't found anything that fixes this. I mean, I've read around (such as this thread or that thread, etc.) and maybe there's something I'm just not getting, but to my understanding based on things I've read is once I change the permissions to at least 644 and set the file owner to www-data:www-data, PHP should be able to write to it and life should be good. But... that's not happening.

The theme editor in the WordPress admin panel (example.com/wp-admin/theme-editor.php?file=bar.css&theme=theme-name) is able to write to bar.css even when it's at 644... so what's the difference between that and what I'm trying to do? What could I be doing wrong?

Thanks for any help.

Community
  • 1
  • 1
Leon Williams
  • 674
  • 1
  • 7
  • 15
  • Doesn't this kind of defeat the purpose of file permissions? – Derek Pollard Dec 15 '16 at 01:04
  • Um... I don't know? I wouldn't think so? I mean, like I said, WordPress can do it from within the theme editor so, like I asked in the question... what's the difference? I genuinely don't know. Is this just a bad thing to attempt altogether? – Leon Williams Dec 15 '16 at 01:07
  • Are you executing foo.php from the browser or from the command line? – J_D Dec 15 '16 at 01:21
  • @Derek Maybe it does and maybe I'm just misunderstanding. My line of reasoning was like this: "Well, 644 is more secure than 666, and other stuff seems to be able to write to the very same 644 file with no problem, so there's no need to raise it to 666 if the thing I want to be done can apparently be done with it still at 644." So I don't know, that's just what I was thinking. – Leon Williams Dec 15 '16 at 01:22
  • @J_D The browser. – Leon Williams Dec 15 '16 at 01:23
  • 1
    Ok, so if you can do it via the browser on one file then you should be good so long as the file owner is the same (which you stated it is). Do you see anything in the error log? Are you getting a white screen when you run foo.php? You can also write out to a variable, like $result = file_put_contents(blah, blah); then echo out $result to see if it returns the number of bytes written or false – J_D Dec 15 '16 at 01:30
  • No white screen, but I do see some stuff in the error log regarding the files in question saying stuff like, "Unable to open... .../wp-content/wflogs/ips.php for reading and writing.", and, "failed to open stream: Permission denied", so let me look into that a bit more. And thanks for the tips. – Leon Williams Dec 15 '16 at 01:47
  • For Ubuntu 16.04 Apache user out of the box is `www-data` so the permissions are guaranteed correct, especially considering the same user account is used to process the whole wordpress application. My guess is you're not referencing the file you think you are. Try `var_dump(file_exists('abs/path/to/bar.css'));` and possibly your `'abs/path/to/bar.css'` should have a leading slash `'/abs/path/to/bar.css'` – Jeff Puckett Dec 15 '16 at 04:06

0 Answers0