When using Omega Tools to create a subtheme, on the "Step 1: Theme information " page, I got the same error 18 times:
Warning: file_put_contents(public:///.htaccess) [function.file-put-contents]: failed to open stream: "DrupalPublicStreamWrapper::stream_open" call failed in file_create_htaccess() (line 505 of /Users/kendalltotten/Sites/omega_sandbox (trunk)/drupal-7.x-dev/includes/file.inc).
This is a clean D7 installation. The only module installed outside of core is Omega Tools, the only theme is Omega. I chose the following options on the install subtheme page:
-Install Automatically
-Default Destination
-Base Theme Omega
-HTML5 Starterkit
I was still able to create the subtheme even with the error messages, but then upon saving, the admin/appearance page displayed the error messages again.
Comments
Comment #1
marcoka CreditAttribution: marcoka commentedwrong issue queue, moved to omega-tools
Comment #2
Kendall Totten CreditAttribution: Kendall Totten commentedI get this same error every time too. No idea what it means, but it doesn't seem to interfere:
Warning: file_put_contents(private:///.htaccess) [function.file-put-contents]: failed to open stream: "DrupalPrivateStreamWrapper::stream_open" call failed in file_create_htaccess() (line 505 of /Users/MY_USERNAME/Sites/MY_SITENAME/sitename (trunk)/docroot/includes/file.inc).
Comment #3
himerus CreditAttribution: himerus commentedI've generated hundreds of subthemes (via UI and via drush) and never seen anything like this...
sounds like a permissions/ownership issue, possibly a conflict between the user/group that is running apache and the user that owns the location where it's trying to write to??
Will definitely need a bit more info on environment and how this is happening in order to debug in anyway. Also, is it trying to manually place the theme, are you trying to auto enable/install/etc. Any details on exactly WHEN this error happens in the subtheme creation process will be helpful.
Also, since this error was moved in from the Omega queue, can you verify it happens in the latest (rc4) release??
Comment #4
quantos CreditAttribution: quantos commentedHi guys/Himerus,
I'm getting this today after upgrading to the latest version. In fact I'm getting this and nothing else. The whole site went white (WSOD) the moment I tried to refresh the homepage after running authorize.php.
To be precise I'm getting:
Warning: include(/home/peachydev/peachydev.dreamhosters.com/sites/all/themes/omega/omega/omega/templates/block.tpl.php) [function.include]: failed to open stream: No such file or directory in theme_render_template() (line 1397 of /home/peachydev/peachydev.dreamhosters.com/includes/theme.inc).
Repeating approx 20 times. I'm not a programmer either but had to add error_reporting(E_ALL) to the index file to see anything at all on my test site. See here: http://peachydev.dreamhosters.com/. The same site seems to be running without problems locally though (where I tested the update first). The update was the HTML5 one.
I.E. Full steps (localhost Windows 7/64bit XAMPP install, Drupal 7.12)
1. Ran Available Updates report on local version first.
2. Downloaded and installed the latest Omega Tools - as well as Webform latest.
3. Checked local files were fine post install - which they were.
4. GiT committed module changes and pulled files up to the dev site (via our repository)
5. Succesfully ran update.php and then authorize.php.
6. Authorize.php only referenced db changes to the webform module, btw. No errors reported.
7. Clicked on homepage link and got the WSOD (white screen, no error messages, no source code either).
8. Added error reporting to the index page (error_reporting(E_ALL)) to locate problem which revealed all these "no such file" errors.
Can't see how/why the site is running locally but not on the dev server. Can roll back to previous versions but is it known what this is? I'll leave that update off until I know further.
Thanks in advance for any pointers.
Comment #5
quantos CreditAttribution: quantos commentedUpdate of above post:
Himerus: I've just got round to opening my back-up files and have noticed that the latest Omega files had installed to the "wrong" subdirectory (sites/all/themes/omega/omega/omega/omega/omega.info etc) instead of the previous sites/all/themes/omega/omega/omega/omega.info etc. Not at my request. All steps above are correct.
This means that:
1. When I git committed the files Git deleted all the old files while uploading the new
2. My local version is still using the old files, without problems, but explains why I don't have the WSOD error locally.
I'll attempt an update again within a day or two and let you know but this this point to local vs dev server difference or que?
Thanks.
Comment #6
John Pitcairn CreditAttribution: John Pitcairn commentedI'm was getting this today, from drush:
This suggests that a temp file can't be written. In this case, the temp directory needs to be writable by the webserver and by the user running drush.
Comment #7
Kendall Totten CreditAttribution: Kendall Totten commentedI made a video to document how these errors are showing up:
http://www.youtube.com/watch?v=G4gN1hT9FM4
In the video I mentioned that I'm using a multi-site installation and I chose a sub/base theme as my parent theme, but that actually doesn't make a difference. If I chose Omega as the parent and use the HTML5 Starterkit, I get the same errors.
Comment #8
himerus CreditAttribution: himerus commentedI'm thinking this seems like an issue with the filesystem... the file_put_contents(private:///.htaccess) or file_put_contents(temporary://filej5v8QW) (in another comment) seem like it's unable to write to the temp directory (check settings to make sure it's a valid location)
But the error listing file_put_contents(private:///.htaccess) (staryeyes024) seems odd as I'm not aware (off the top of my head) why it'd be attempting to write to the private filesystem. Seems like that would be an issue.
The only issues I've ever had (usually after moving a site between systems/servers) is that the temp directory isn't the same, and needs to be updated, then sometimes also an issue with the sites/all/themes directory not having the right permissions to be written to... This can also be caused when the owner of the directory isn't the same that is running the scripts (drush) or the web user (in UI) ...
Comment #9
gowrann CreditAttribution: gowrann commentedWarning: file_put_contents(private:///.htaccess) [function.file-put-contents]: failed to open stream: "DrupalPrivateStreamWrapper::stream_open" call failed in file_create_htaccess() (line 505 of /home/coolest/public_html/downtown/includes/file.inc).
I got this but am not using omega tools - after the GUI failed to install upgrade modules I installed drush and ran drush up - modules where upgraded - but this error was in my status report
Comment #10
gowrann CreditAttribution: gowrann commentedI fixed this by resetting my Private Files directory Path in 'config/media/file-system'
Comment #11
omega.OFN CreditAttribution: omega.OFN commentedI ran into the same error when upgrading Drupal Core. The problem was most likely that I deleted the directory defined for Private Files under Configuration>Media>File System in the Drupal directory of the site, when preparing for the upgrade to copy the new files. Going into Configuration>Media>File System to confirm the path for the private files got rid of all error messages, so the file system seems to be a good clue for error search.
Comment #12
welly CreditAttribution: welly commentedI was having the same problem. #10 worked for me. I'm running MAMP 2.0.5 as my development stack and changing the temporary directory to /tmp resolved it.
Comment #13
calefilm CreditAttribution: calefilm commentedsame thing. Fixed by going to Configuration>Media>File System and providing new Private file system path of: sites/default/files/private
Comment #14
ambaum2 CreditAttribution: ambaum2 commentedre-saving the current private file path worked for me
Comment #15
jcir CreditAttribution: jcir commentedclearing cache solved my problem
Comment #16
TWD CreditAttribution: TWD commentedChanging
/tmp
to
tmp
at /admin/config/media/file-system
worked for me. i.e. remove the leading slash and save.
See thread:
https://drupal.org/node/1106492
Comment #17
2¢ CreditAttribution: 2¢ commentedI got this error because I had moved an install to root, instead of a sub-directory.
Site was set to a relative path '../../private' for private file location.
When site moved up the hierarchy this placed the directory into an area of the server I did not have permission to access.
Like #13
Go to /admin/config/media/file-system and try to save. It will fix it or errors will give you clues.
Comment #18
ARUN AK CreditAttribution: ARUN AK commentedThis error is showing because of the directory that mentioned in file system path does not exist.
according to comment #13 by re-submittig this form(/admin/config/media/file-system) a new folder name as private will automatically created in sites/default/files/ folder. It will resolve the problem.
Comment #19
katin CreditAttribution: katin commentedThanks for the clarification of the issue, ARUN AK. Sure enough, I was seeing this error message and when I went to look for the directory specified in the error message, it was missing. Adding it, then clearing cache and resetting the media file-system parms cleared it all up.
FWIW, I suspect the directories were missing from the install because I had the wrong owner on the default/files directory when I first powered up the site after running the standard installation. I copied the folder from another site and didn't update the ownership. Things ran, but the image module couldn't/didn't create the directories it needs, thus creating this error problem later, whenever anyone tried to upload something like a profile picture, for example.
Anyway, thank for #18.
Comment #20
idiaz.ronceroIn my case, the error was displayed when backing up database after a git clone of an existing repo
I discovered the issue, it's pretty simple. By default Drupal's .gitignore avoids syncronisation of the default/files folder.
Therefore, the new cloned installation (if no content is created) is lacking a proper public::// folder and drush becomes crazy.
I assume this may not be evreybodys' cause, but it is a cause that's easy to solve... and easy to forget to check.
Comment #21
vijithaepa CreditAttribution: vijithaepa commentedI also got the warning,
Warning: file_put_contents(private:///.htaccess): failed to open stream: "DrupalPrivateStreamWrapper::stream_open" call failed in file_create_htaccess() (line 494 of C:\Application\xampp\htdocs\myProject\includes\file.inc).
It was fixed by following the steps mentioned in #11 by omega.OFN. Thanks for the information.
Comment #22
ltrainI'm getting this error but I can't access admin/config/media/file-system (or any other page) because: WSOD.
Can someone tell me how to change the temp directory in the files or database?
I'm using Drupal 8.
Thank you!
Comment #23
timfletcher CreditAttribution: timfletcher as a volunteer commented@Laura Johnson better late than never :)
This post covers how to change the file locations in Drupal 8 and 9.
You can verify where Drupal thinks the filesystems live by checking
/admin/config/media/file-system
Comment #24
saqibsarwar CreditAttribution: saqibsarwar as a volunteer and commentedWhile using Docksal ( Docker ) Following steps fixed it for me.
1. Checking configurations at
/admin/config/media/file-system
2. Creating required directory in Docker using bash
docker@cli:/var/www/sites/mysite.com$ sudo mkdir mysite_come_private_files
3. Changing owner to docker
docker@cli:/var/www/sites/mysite.com$ sudo chown docker mysite_come_private_files
4. resaving configuration at
/admin/config/media/file-system
Hopefully it will help.