It's not clear to new core contributors that CMI is now a part of core, and that we're in the process of migrating to config and state. We should mark the variable_* functions as @depreciated to try and head off patches being rolled still using those functions.

variable-depreciated.patch1.38 KBdeviantintegral
PASSED: [[SimpleTest]]: [MySQL] 48,736 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


jhodgdon’s picture

Component: documentation » configuration system
Status: Needs review » Needs work

We do not support any @deprecated tag at this time in the API module, so this is not the right way to mark a function as deprecated (we don't have a standard way to do this actually). Even if we did have @deprecated as a tag, it would not include a paragraph of explanation.

I'm also putting this into the config component for now because I won't commit a patch marking these as deprecated without the approval of the component maintainers... why not just remove the functions when they're supposed to be removed? What's the schedule for that?

sun’s picture

Title: Mark variable functions as depreciated until they are removed » Mark variable functions as deprecated until they are removed
Issue tags: -CMI +Configuration system, +State system
+++ b/core/includes/
@@ -994,6 +994,10 @@ function variable_initialize($conf = array()) {
+ * @depreciated

@@ -1018,6 +1022,10 @@ function variable_get($name, $default = NULL) {
+ * @depreciated

@@ -1044,6 +1052,10 @@ function variable_set($name, $value) {
+ * @depreciated

Typo in all three: s/depreciated/deprecated/

The description can follow directly after the directive.

Also, can we shorten the description?

@deprecated Use config() or state() instead.

...should be sufficient, IMHO.

jhodgdon’s picture

There's a discussion on #1876842: [policy, no patch] Use @deprecated to indicate a deprecated method or function about what syntax to use for deprecated functions. This patch should probably follow that proposal, or that proposal should be amended to match what is proposed here.

sun’s picture

The proposed code here is scheduled for *total* removal before D8 gets released, so I don't think we're blocked on that policy issue, or need to be strict in how exactly the phpDoc should look like. It is a very very temporary measure only, as an attempt to prevent developers from introducing new variables in D8 code.

jhodgdon’s picture

On that other issue, several people commenting made the point that this was actually the normal circumstance -- temporarily marking things as deprecated during the dev cycle. So, I'm not sure that's a compelling argument for not following the standard. If we even need a standard (which I questioned on that other issue) then it applies to this case as the main use for @deprecated...

swentel’s picture

Status: Needs work » Closed (fixed)

They have been marked deprecated already.