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

Project:Omega» Omega Tools
Version:7.x-3.0» 7.x-3.0-rc4

wrong issue queue, moved to omega-tools

I 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).

I'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??

Hi 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.

Update 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.

I'm was getting this today, from drush:

$ drush omega-subtheme omegawire
file_put_contents(temporary://filej5v8QW): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed            [warning]
file.inc:1904
file_put_contents(temporary://fileKm73IA): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed            [warning]
file.inc:1904
The file could not be created.       [error]
The file could not be created.       [error]
You have successfully created the theme omegawire.    [status]

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.

I 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.

I'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) ...

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 /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

I fixed this by resetting my Private Files directory Path in 'config/media/file-system'

I 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.

I 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.

same thing. Fixed by going to Configuration>Media>File System and providing new Private file system path of: sites/default/files/private

re-saving the current private file path worked for me

clearing cache solved my problem

Changing

/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

I 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.

This 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.

Thanks 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.

Issue summary:View changes

In 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.