-
Let’s get frozen (the future of our legacy APIs)
Back in July last year, the Drupal 8 API froze. Except it didn’t. It couldn’t – Drupal 8 wasn’t anywhere near ready enough. We still had thousands of lines of code that needed bringing up to the new standards and parts of the new API that still needed to be completed. To me, what the code freeze really meant was: stop breaking things, stop adding new features, and start concentrating on getting Drupal 8 ready to ship.
As we approach the first beta, core’s need for this backwards-compatibility code is reducing, as seen by the recent removal of variable_get() and friends. But we’re also moving closer to the point where the API needs to be properly frozen, so that contrib modules don’t get caught out by functions suddenly disappearing. Some functions were marked @deprecated, but there was confusion about whether these functions would be shipped with Drupal 8.
What are we’re doing now?
Issue #2187735 has recently been committed, which should clear up much of the confusion about @deprecated: the documentation for these functions will now typically say “@deprecated in Drupal 8.x-dev, will be removed before Drupal 8.0.”
If you’re using any of these functions in your Drupal 8 code, then now is the time to update them. Ideally your code will be object-orientated and most of these function calls can be replaced with method calls on the relevant services, seeĀ Services and dependency injection in Drupal 8. If that’s too much work, then there’s often a method on the global \Drupal class that you can use as a drop-in replacement (but without the benefits of OO).
How can I help?
Anyone developing with Drupal 8 should keep an eye out for procedural functions being called when reviewing patches – most of these functions now have OO replacements, often via the \Drupal class. If you’re using an IDE it may highlight deprecated functions, for example by striking a line through the function name.
If you’re already a core developer, please have a look over the APIs that are documented as @deprecated. Are any missing? Please file new issues using the issue tag @deprecated, or we may be forced into shipping with them. Have we marked any APIs “will be removed before Drupal 8.0” that we actually want to ship with? Please open an issue and explain why.
If you’re interested in getting into core development, there are lots of issues to update core from the old APIs to the new, some of which are great first issues. These will usually have the @deprecated issue tag, and the issue title will often start “Remove” or “Replace”. Come along to a core mentoring session on irc or see if there’s a meet up happening near you soon.
If you’re happier developing in contrib, there’ll be a lot of work needed to upgrade contrib modules to use the new APIs. If you use any modules that already have a Drupal 8 version, check to see if they are using any of the deprecated API. If they are, open an issue and/or submit a patch, ideally before the API gets removed.
RE: Drupal 8: Hello, Configuration Management UK National Skydiving Championships
Let’s get frozen (the future of our legacy APIs)
Recent Posts
Recent Comments
Archives
Categories
Tags