-
Notifications
You must be signed in to change notification settings - Fork 201
[Symfony 2.7] Fix deprecation warnings #1221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
7096233 to
10ec462
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bit unsure what factory w/o method means, so is this by any chance a left over?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weird...
Ping @bdunogier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not to familiar with these Fake services, so unsure if it is another/better way without big refactoring of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be a problem for us, for sure... I don't see how to workaround this future removal.
Ping @fabpot maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be:
ezpublish.cache_pool:
class: %ezpublish.cache_pool.class%
factory: ["@ezpublish.cache_pool.factory", getCachePool]
arguments: [@ezpublish.config.resolver]
@lolautruche hmm, it might actually be on second thought on this. In regards to the link issue today on linking from one site access to another there is basically a need to swap out current site access temporary right? So there is a possible need for stack here as well. |
|
@andrerom The issue discussed with @larseirik has nothing to do with this. The SiteAccess is unique for requests/sub-requests. When doing a cross-siteaccess link, we don't swap out the current SiteAccess, we do a reverse lookup and complement generated link. |
|
ok, assumed the reverse lookup would have to swap siteaccess as well to make sure whole system generates the Url using the right settings, including taking right rootLocationId setting into account. |
That might be the missing part of EZP-24470, but I still need to take some time to check what is wrong. |
|
ok |
|
Besides, as said on Skype, I'm ok with the proposed backports so +1 on those for master and 5.4. As for my suggestion on splitting this branch, I was thinking you needed a few of the commits in master for the version bump, while others can mature a bit if needed. |
|
I'll maybe just split out the SiteAccess commit, because it's incomplete and also has its separate issue. |
.travis.yml
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As composer is bumped to use 2.7 by default we should rather change any use of SYMFONY_VERSION="~2.7" to SYMFONY_VERSION="~2.8@dev", no need to add additional job given 2.3 is out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But isn't it what I did?
This PR has been rebased against master, so test with ~2.8@dev is in allow_failures. I was not adding a new test here. Or did I overlook something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the diff above does add a new test in include section, while the change:
- env: TEST_CONFIG="phpunit.xml" SYMFONY_VERSION="~2.7@dev"
+ env: TEST_CONFIG="phpunit.xml" SYMFONY_VERSION="~2.7"could have just been:
- env: TEST_CONFIG="phpunit.xml" SYMFONY_VERSION="~2.7@dev"
+ env: TEST_CONFIG="phpunit.xml" SYMFONY_VERSION="~2.8@dev"hence making the change I comment on unneeded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, but then we won't test with PHP 5.5 and Symfony 2.7... But I think that's OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. We can't test everything on everything as it would lead to 30 or more jobs, so we spread the tests out. alternative is to not test 2.8.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK fixed
|
Ok, I'm +1 with SiteAccess separated, and nitpick above about on how we can test 2.8 w/o adding additional jobs covered. |
(dynamic settings)
|
Removed SiteAccess change from the commit list. I'll do another PR for this. |
|
+1 if/when travis agrees :) |
It's not possible to silent the deprecation warning from YAML.
|
Just added 36fb72c to fix tests. |
|
Another round of review? I thought everyone was +1 |
[Symfony 2.7] Fix deprecation warnings
|
missed the one from pspanja, but otherwise you have a broad definition of |
|
everyone => Everyone involved in the discussion |
> https://jira.ez.no/browse/EZP-24459 Follow-up of #1221. After investigation, it is actually not necessary to *fix* ContentPreview since the previewed SiteAccess is already correctly handled, as the content preview is rendered through a sub-request. In this regard, SiteAccess match done normally (not limited to master request).
Candidates for backports to 5.4
Follow-ups