Stabilize Composer

[ktomk]

IIRC minimum stability is alpha only because of composer. At 4th of April (or around that day) composer finally went stable and 2.0.5 yet still has the alpha version tagged, doesn't it?

So I think it would be worth to move to ^1.0.0, we did this in magerun as well the last month and it's just straight forward.

[piotrekkaminski]

+1

[thaiphan]

I was trying to use the path repository feature in Composer but wasn't able to until I manually updated Composer. Would be good if Magento updates Composer for us.

[ktomk]

Stabilizing composer is not yet possible because one of its dependencies, magento/composer 1.0.3, pins the composer version to 1.0.0-beta1. I therefore opened a PR to get magento/composer 1.0.4 with a stabilized composer requirement so to become able to update here.

[hostep]

Hi guys

Another vote for stabilizing composer/composer.

We run into an issue on our hosting with Magento 2.1-rc2, because Magento ships with version 1.0.0-beta1

When we try to login to our backend, a PHP warning is thrown:

Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/var/www/example.com:/var/www/example.com/wwwroot:/usr/share/pear:/usr/share/php:/usr/share/phpmyadmin:/tmp:/usr/local/lib/php:/usr/share/misc) in /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php on line 914
#1 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(915): is_dir('/etc/pki/tls/ce...')
#2 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(801): Composer\Util\RemoteFilesystem->getSystemCaRootBundlePath()
#3 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(61): Composer\Util\RemoteFilesystem->getTlsDefaults(Array)
...

This happens because in version 1.0.0-beta1 of composer this line fails:
https://github.com/composer/composer/blob/1.0.0-beta1/src/Composer/Util/RemoteFilesystem.php#L914

In a later version (not exactly sure which one) it was fixed by adding an @ sign in front of the is_dir function call:
https://github.com/composer/ca-bundle/blob/205ee8426c0461c9ab14712069ed5c92a7518646/src/CaBundle.php#L115

If we manually add the @ sign to the composer source files, our open_basedir problem is fixed

Please, consider putting a stable composer/composer version in Magento 2.1 GA, so we can actually run it on our hosting.

Thanks!

[hostep]

@piotrekkaminski: can you try to get this change into Magento 2.1 GA?

We currently work around it by changing this line in our composer.json file:

"composer/composer": "@alpha"

to:

"composer/composer": "1.1.2 as 1.0.0-beta1",

Which gets us around the issue, but it feels a bit like a hack.

We've been using it for about a week now, and haven't noticed any downsides to it yet.

[tkn98]

It would be tremendously great in our eyes if we could see some traction here.

[AydinHassan]

Chiming it to get some action on this. Composer was stable ages ago - it would be nice to not have to include alpha software (even if I don't doubt the quality of Composer).

[piotrekkaminski]

It is on the roadmap @AydinHassan to upgrade to latest.

[ktomk]

Can we share where on that roadmap? :) I think this is a perfect fit for "developer experience".

[jameshalsall]

@piotrekkaminski when? where is the product roadmap?

[MrLei]

Hello what is solution this problem but i'm too instal clear Mag 2.1 and see this problem.
Mag 2.1 i get today in oficial site.

[mombrea]

For anyone else stuck here after upgrading to 2.1, @hostep solution to

"composer/composer": "@Alpha"
to:
"composer/composer": "1.1.2 as 1.0.0-beta1"

works great but required a composer update afterward. I also ran composer selfupdate but I'm not sure that was necessary.

[ktomk]

@mombrea: Thanks for sharing, especially as it looks like this ticket is getting really slow and late.

@alankent Can you weight in and progress this a little? That would be wonderful.

[jaimiedijstra]

I also have this problem after upgrading from Magento 2.0.7 to Magento 2.1:

Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/home/example:/usr/lib/php:/usr/local/lib/php:/tmp) in /home/example/public_html/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php on line 914

Disabling open_basedir works but is not ideal but I am not in any kind of live environment. Will there be a patch for this, or could anyone expand on the fix presented by @hostep or @mombrea ?

[jameshalsall]

@jaimiedijstra just add :/etc/pki/tls/certs to the end of your current open_basedir INI setting value

[jaimiedijstra]

Thanks @jameshalsall I have done this for the time being, seems the best solution. Hoping a later update will change this.

[hostep]

I just noticed this ticket is lacking a MAGETWO reference number. @piotrekkaminski: are you guys tracking this request in your internal system?

[ktomk]

@hostep: Good point, I'll escalate this via enterprise gold support after a bag of sleep.

[tkn98]

Ref: magentocommerce.com Ticket #03188454

[insaurabh]

"config": {
"use-include-path": true,
"disable-tls":true
},

I used this code to solve a:4:{i:0;s:270:"Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/var/www/vhosts/websitename.in/:/tmp/)

[ktomk]

@maddyboy: Disabling TLS is counter-productive and your last comment therefore a flawed example.

To deal with the error take the information given in the error message directly. Configure the open_basedir setting to allow access to the TLS certificates in the file-system. That's all that is needed.

You don't want such a basedir restriction on certificates (you normally want these certificates read-only but accessible from the PHP process).

/r Just in case my comment might sound harsh, it's not meant so. I only address my personal opinion saying what I think is wrong and provide as well what I think is right. If a concrete example is missing or there are any further questions or critique: as open my comment is, as open I'm to feedback. I'm also aware of the good parts, e.g. providing the error message in text-form allows indexing so is identifiable by future users leading to the issue and the solution discussion. So thank you for your contribution.

[orlangur]

Composer version was bumped to stable one, but minimum stability is still alpha: https://github.com/magento/magento2/blob/develop/composer.json#L261 (maybe it's due to Zend Code 3.x or something?).

[ktomk]

@orlangur: Most likely this is a left-over and can be removed. I just gave it a try with a clean clone from develop, removing composer.lock and the minimum-stability setting and I did not run into any install problems. Maybe @hostep can provide another pair of eyes.

[orlangur]

I see... Planned to check by myself as well. Could you prepare a PR with regenerated composer.lock then?

[ktomk]

Sure I can do that, I have a test build running currently on Travis already and can use the composer.lock from my local install test.

[hostep]

@ktomk: removing "minimum-stability": "alpha" is very good. I just tested this manually on the latest revision of the develop branch and experienced no issues.
The PR looks perfectly fine.

Just a small hint: if you only want to update the composer.lock file's "metadata" (this is probably not the correct term), and not update all the dependencies to the latest versions, you can run: composer update --lock or composer update nothing. It makes cleaner diffs if you only update the metadata in one commit and update the dependencies in another commit. Although updating the composer.lock with the latest versions of all dependencies is always a good idea.

Anyway, very happy this is (finally) happening, thanks to everyone involved!

[ktomk]

@hostep; Thanks for the feedback. You're right update nothing works with changed stability setting,. But the two updates it does are fine, too. Thank you, too!

[bunhin]

Hi all,
I just install Magento CE 2.1.7 downloaded from official magento site, still get the error:
is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): ...and so on still long and many line in var/report file.

I am install it in shared hosting, and i belive dont have access to /etc/pki/tls/certs. I also try to add the folder open_basedir via custom php ini, but the directory still not included in open_basedir of php status info.

I believe this problem is still related to this thread, has it been solved? how do i need to do in order get the error solved without opening other issues, thank you.

[ktomk]

@bunhin: Support requests don't belong into the Github bug tracker but the forums. Search the existing reports there, e.g. https://magento.stackexchange.com/questions/137516/error-on-admin-login-magento-2-1/144254#144254

[orlangur]

This particular issue can be closed as it is already fixed in develop branch by merging corresponding PR. @okorshenko, please confirm.

@bunhin thanks for searching for an open issue before filling a new one, you really have the same error mentioned in this thread. Please use solution from #4359 (comment) or previous comment.

Fix will be available in 2.2 Magento release, I'm not even sure it could be backported to 2.1 due to backward compatibility constraints.

[bunhin]

On shared hosting, it is not easy to upgrade composer because can not login into magento backend, i have tried to change composer version, but the error persist, is it any other way round? such as replacing a file ?

[magento-engcom-team]

Fixed in #9672
Thank you @ktomk