Error creating directory: public://composer in composer_manager_file_dir()

Looks good to me. Thanks!

I can confirm this error still occurs in the latest version (7.x-1.8) of this module (I'm also using Drupal 7.41)

Here's the log:
RuntimeException: Error creating directory: ../ in composer_manager_file_dir() (line 299 of /mnt/www/html/site/docroot/sites/all/modules/contrib/composer_manager/composer_manager.module)

Same error and versions as above.

Also this error in logs:

RuntimeException: Autoloader not found: /app/public/sites/default/files/composer/vendor/autoload.php in composer_manager_register_autoloader() (line 173 of /usr/home/kiwicustom/public_html/d7/drupal-7.41/profiles/agency/modules/contrib/composer_manager/composer_manager.module).

Exact same error as #8

RuntimeException: Error creating directory: /app/public/sites/default/files/composer in composer_manager_file_dir() (line 299 of /Applications/MAMP/htdocs/RoomyfyAgency/sites/all/modules/contrib/composer_manager/composer_manager.module).

and

RuntimeException: Autoloader not found: /app/public/sites/default/files/composer/vendor/autoload.php in composer_manager_register_autoloader() (line 173 of /Applications/MAMP/htdocs/RoomyfyAgency/sites/all/modules/contrib/composer_manager/composer_manager.module).

Has any one found a solution yet?

Same error now, I'm unable to install anything right now.

After reading the code, I've succeeded to get it working by settings my libraries like shown in the screenshot.

Setting this bug as critical.

Actually, I had this bug because I had Symfony 3 installed in /home/pol/.composer.
I reintalled Symfony 2.8.x and everything went fine after that.

I had this same error until I ran the permissions and ownership fix from https://www.drupal.org/node/244924. Everything is now working.

Is there a bug here still?

I had the "RuntimeException: Error creating directory" solved with permission change.

Now Composer seems to keep asking for "sensiolabs/security-checker" and I have tried to no avail.

Also the following error has popped up:

Warning: file_get_contents(): Filename cannot be empty in composer_manager_sa_cache_cid() (line 128 of /home/mysite/public_html/sites/all/modules/composer_manager/composer_manager_sa/composer_manager_sa.module).

What is this ?
I cannot even go to my settings page!
where can I found settings of composer module in database ?
Thanks a lot :)

We got this issue while working with a deployment-platform where the composer folder is set as writable, but the entire filesystem is read-only.
We never update composer dependencies, this we do not need write permissions to be applied to our composer directories.

The patch applies RW permissions only if needed.

Updated patch, please discard the previous one.

without looking too deeply into the cause, my issue was also a permission problem.

running from drupal root:

sudo chown -R www-data:www-data sites/default/files/

resolved the issue for me....

My use case of getting this bug:
- auto-build and auto-generate options are disabled
- all manipulations with composer happen on dev server
- prod server have different users for cli and web; the composer file directory is owner by the cli user
As a result, composer_manager cannot be used on prod server.

Attached patch fixes this by changing the default behaviour of the composer_manager_file_dir() to not check the write permission. It only ensures that directory exists.

UPD: please ignore this patch... I made something wrong. Working on a new one.

Okay, this one works well for me.

@Leksat : I guess we're addressing the same issue with two different patches :)

ps: are you using Platform?

@thePanz,

I guess we're addressing the same issue with two different patches :)

Absolutely :)

ps: are you using Platform?

No. It's client's server.

I'm having the same or a very similar issue. Setting composer_manager_autobuild_file to 0 helps most of the time, but when using this module on an environment that does not allow you to write to the server (i.e. Acquia), I still receive an error because composer_manager_file_dir is trying to create the file directory. This is happening in hook_requirements().

My patch simply checks if composer_manager_autobuild_file is 0 in composer_manager_requirements() before attempting to create the file directory.

@jh3, do you have time/possibility to check if #22 works for you? It would be nice to have a single patch that fixes all cases.

@Leksat Looks good. Seems to provide the same result.

@jh3: Could you give a try to my patch in #19? It has the same aim, and following your same path.

@thePanz #19 is good. It gets to the root of the problem, and it's cleaner than mine :)

+1 #22 fixed the issue for me thanks @Leksat

@here: could we choose a patch between #19 and #22 to be labeled as "Ready to be committed"? :)

+1 for #19

Let's move to RTBC :)

+1 for RTBC testing this for Pantheon. This bug currently causes the module to tank several pages when used in git mode on our platform. The patch in #25 resolves the problem for us in testing.

+1 for #19, seems the most logical for me, although I could be swayed to #22 or #25 as well. I'm currently running with #19.

Even with the patch in #19, I still get the following:

RuntimeException: Error creating directory: public://composer in composer_manager_file_dir() (line 299 of /home/davereid/Sync/projects/drupal7/sites/all/modules/contrib/composer_manager/composer_manager.module).

I noticed that my public://composer directory was created and owned by my shell user instead of www-data, because I ran drush pm-enable composer_manager. I changed the ownership of the directory and it seemed to resolve things, but I'm getting a WSOD on my admin/reports/status and admin/config pages, which seems to indicate that #19 needs to be merged with #2620348: Unnecessary folder write permission requirement causes WSOD somehow.

Should I be using #19? #22? This is confusing.

Tested #22 as well, I still get WSOD on admin/reports/status and admin/config

#19 WSOD on admin/config remained
#22 solved my WSOD problems on admin/config

Encountered this issue on Pantheon (though it will crop up on literally every platform where code is deployed in a read-only state).

#22 resolves the issue. +1 for RTBC.

I was unable to reproduce the errors Dave was running into in #38.

#22 resolves the issue. +1 for RTBC.

+1 for #22 which solves this, critical for me, issue on Acquia.

#22 solved WSOD on admin/reports/status.
I did not review the code changes, no opinion there.

#22 worked for me!

I've faced with a problem on file systems without write access. Initially, patch #22 solved the problem but later, when I've tried to install a new site, it was appeared again - in hook_requirements.

So, this patch is just combination of #22 and #25 which are helped.

#45 doesn't apply to 1.8 version of composer_manager
patching file composer_manager.drush.inc
patching file composer_manager.install
patching file composer_manager.module
Hunk #3 FAILED at 298.
1 out of 3 hunks FAILED -- saving rejects to file composer_manager.module.rej

@SocialNicheGuru, but applies for 7.x-1.x-dev which is specified in summary of this issue. We're not going to guarantee that this patch could be applied for every possible version.

As a quick fix, +1 for #20 above, worked for me:

sudo chown -R www-data:www-data sites/default/files/

we had the same issue in some of the envs where we don't have writting permissions (Acquia Cloud). Applying this patch solves the access error to admin/config

+1 for RTBC

This issue / commit has rendered the patch from #45 invalid.

Here's a new patch that'll respect the solution of #2620348: Unnecessary folder write permission requirement causes WSOD and applies cleanly to latest dev.

+1 for #52, worker for me.

#52 also fixed it for me

Just one question: will this be committed?

Here's the same patch off of 7.x-1.8.

I'd actually like it to be less strict on the directory entirely.

What about interdiff, @RobLoach?

You should likely just ignore that patch, since it's off of 1.8, rather then dev. I missed adding an ignore- prefix. Re-uploading #52 so it's retained as the latest patch listed.

As others have mentioned here, I resolved this problem with the following command sudo chown -R user-ommited:apache files/. You'll have to sub in the name of the proper owner for your server, my user won't help you :)

Apache couldn't write to my public files directory.

For me it was a file permissions issue on sites/default/files.

For me this issue occured with 7.x-1.8, because sites/SITENAME/files/composer/ directory existed, but had owner + group myself:myself instead of www-data:www-data.

Upgrade from 7.x-1.8 to 7.x-1.8+1-dev fixed this problem, even without the patch from #60.

Maybe it is a different situation if sites/SITENAME/files itself is not writable.

Time for a new release!

See #2847521: [Composer Manager] Stable 7.x-2.0 release and all the 7.x-2.x issues that need to be fixed.

We can likely prioritize some for the initial release, but there are a few that are fundamental architectural changes (breaks BC) that will need to be made before any release.

Can't we backport some stuff to 7.x-1.x, so that a stable working branch is available?

Can we focus on the new code and get it out the door instead of splitting focus?

Added #3244517 for the 7.x-1.x backport.