Magento2: 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

[hostep]

@piotrekkaminski: can you remove the needs update label, I don't think this is correct and removing it might lead to this ticket being picked up a little bit faster...
Also: still no MAGETWO reference number ...

Thanks! :)

[piotrekkaminski]

MAGETWO-52770

[lucvdbos]

Thanks, I changed composer.json in the root several time. But how to update magento that it will use it?

I used shh: php bin/magento setup:upgrade
php bin/magento setup:static-content:deploy
php bin/magento indexer:reindex

But it did not work.

composer update worked!

[tkn98]

@lucvdbos: Please help keeping topic, that seems to be an unrelated support issue.

[hostep]

It would be appreciated if Magento gives this a little bit more priority so we no longer depend on a beta version of composer running in our projects. Thanks! :)

[maksek]

PR #8638 addressing the ticket.

[hostep]

@maksek: great!
I assume this was what @ktomk was talking about in a comment on his magerun2 project (3rd paragraph)?

Also, don't forgot that you'll need this PR as well: https://github.com/magento/composer/pull/2

[orlangur]

@maksek, actually, not. #8638 only allows to use locally installed fresher version of Composer without problems.

The main point to resolve this issue is changing this line together with merging PR menetioned by @hostep. It's better to be changed within #8638 PR processing.

[maghamed]

I closed #8638 and now #8743 is being processed because @ktomk provided a static tests extending our XSD schema for DI.xml files on top of changes provided by @ajpevers in #8638
That will help us to prevent new classes with leading back slashes added into the codebase. Thanks, guys it's really nice to see such a robust collaboration among community members.
When #8743 would be processed and delivered to mainline we will get back to https://github.com/magento/composer/pull/2 and bump composer version

[kozie]

In my case i'm installing Magento 2 through our own composer.json. That means that there isn't a composer version configured in the root composer.json file, obviously.

I used the work-around as follows from the root directory.

composer require composer/composer "1.1.2 as 1.0.0-beta1"

[orlangur]

@maghamed,

When #8743 would be processed and delivered to mainline we will get back to magento/composer#2 and bump composer version

Something else needs to be done besides described in order to bump composer version?

[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 https://github.com/magento/magento2/issues/4359#issuecomment-298152176 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 https://github.com/magento/magento2/pull/9672
Thank you @ktomk