Problem/Motivation
Drupal 8.8 deprecations are tricky because they will not be released before December, so people cannot fix them yet. However many of the 8.8 deprecations have replacements in previous versions, meaning they could be acted on now. @mixologic prepared a list which we can use to annotate deprecation messages and categorize them appropriately.
Proposed resolution
Annotate deprecation messages with this additional information in the module. This should make them end up in different categries beyween fix now and fix later.
Remaining tasks
Do it.
User interface changes
Deprecations will end up in more accurate categories based on availability of their replacement API.
API changes
None.
Data model changes
None.
Release notes snippet
N/A
Comment | File | Size | Author |
---|---|---|---|
#14 | interdiff.txt | 645 bytes | Gábor Hojtsy |
#14 | 3074833-11.patch | 2.93 KB | Gábor Hojtsy |
#11 | interdiff.txt | 1.13 KB | Gábor Hojtsy |
#11 | 3074833-10.patch | 2.93 KB | Gábor Hojtsy |
#9 | interdiff.txt | 567 bytes | Gábor Hojtsy |
Comments
Comment #3
Gábor HojtsyAttached file from @mixologic with extra info about deprecations.
Comment #5
Gábor HojtsyStarted with some minor refactoring to help with this ^^ :)
Comment #6
Berdir> However many of the 8.8 deprecations have replacements in previous versions, meaning they could be acted on now.
Most of the things that I did used the actual core version where the replacement was initially added, even if the @trigger_error() only happened now. "Many" is a bit optimistic ;)
All the file_* stuff is new in 8.8 I think. Some functions were deprecated before, but we deprecated their replacement and moved them somewhere else now.
entity_get_display()/entity_get_form_display() is a special case, it was deprecated before but there was no useful replacement, which was only added in 8.8, which is why we bumped the version. You shouldn't update that on 8.7 or older, and I get a lot of issues/patches about that unfortunately.
Crypt functions are implicitly tied to 8.8 due to the PHP 7.0 version requirement, you could of course explicitly require PHP 7 in your module already and then replace calls to them. But not really worth it, it's a trivial 1:1 replacement anyway.
WebTestBase is obviously a candidate for this and so are a bunch of traits that were deprecated.
entityManager() related stuff is trickier than you'd think, the actual replacement existed since Drupal 8.0, sure, but those in the list refer to helper methods on traits and base classes that were really only added in 8.8. The old entity_* functions are safe, yes.
Comment #7
Gábor HojtsyThanks @berdir. Let's do WebTestBase and TestBase 8.8 deprecations then first, those sound safest. This would hopefully fail because I did not yet adjust the expected test results. It did not run properly locally, so running here while debugging local environment.
Comment #8
Gábor HojtsyLOL it helps to have valid PHP. Also of course the tests will not yet find this deprecation as it was literally introduced in 8.8 and we are not running yet our testbot tests against 8.8-dev. What I will do for now is to leave the test class there, which will start failing tests on 8.8 reminding us to add test coverage for it then. It could be better with some conditional test coverage based on which version we are running against, but I don't have capacity for that magic ATM.
Comment #9
Gábor HojtsyTestbot concerned with lack of @group annotation on the "test class" even though I put it on purpose in a different location so it does not interfere with real tests. Well.
Comment #11
Gábor HojtsyOne of the fails is a lack of test method, haha. Otherwise parenthesis problems in preg_match which locally did not seem to appear(?!$)
Comment #12
Gábor HojtsyComment #14
Gábor HojtsyNow down to the preg problems, the same preg does not have the same escaping problems locally. Let's try this double escaping.
Comment #16
Gábor HojtsyI landed the [Web]TestBase stuff, but we can still improve this to add more items later. Keeping this open.
Comment #17
Gábor HojtsyPorted this temporary hack to deprecation_status so we get more realistic directions from that too. https://git.drupalcode.org/project/deprecation_status/commit/a292a0137db...
Comment #18
Gábor HojtsyAfter further discussion with @berdir, this is probably as far as we can get here.