Mark user levels as Deprecated

[dd32]

Since the new Role system was introduced in WordPress 2.0, The usage of User Levels has been deprecated (but still supported for back compatibility).

I'd like to propose (As i did on IRC recently) that user levels be marked as being deprecated, at least in documentation (which i have already done on a few Codex pages) and possibly in WordPress Core.

The major downside to this is that the many -currently being developed- themes which still use user levels for adding admin menu's may cause PHP Noices to show up (However, Unless they're running as a dev install, they may not see them) - Which also means, Many theme designers may not see the warnings either, as from my experience, most theme designers dont run with WP_DEBUG turned on either..

I'm attaching a patch to emit a PHP Notice:

Notice: Usage of User Levels by Plugins and Themes is deprecated since version 2.0! Use Roles and Capabilities instead. in C:\www\wordpress\wp-includes\functions.php on line 2942

[scribu]

But if theme designers don't have WP_DEBUG on, they won't see your notice either.

I think we have to be a little more aggressive.

[dd32]

But if theme designers don't have WP_DEBUG on, they won't see your notice either.

Which i mentioned :)

The only other options are to remove the user levels all together, Or maybe, just remove user levels < 8. 8, 9, 10 were "admin" user levels.. By removing the ability for people to use those levels, they'll be forced to use roles/caps, But those which currently use it to determine admin-functions, will continue to work...

[westi]

This sounds like a good idea.

I was already thinking of introducing a third deprecation marking function - _deprecated_arguments() which we would use to mark code which provides backward compatibility to functions to support old arguments.

[nacin]

Replying to westi:

I was already thinking of introducing a third deprecation marking function - _deprecated_arguments() which we would use to mark code which provides backward compatibility to functions to support old arguments.

That's kind of the idea that came out of #11386. If you're providing it traction I've already identified most of the deprecated arguments in that ticket (which could probably use a new name).

[hakre]

Then isn't it adviseabel to raise the prio in #11386? this patch can be improved then based on the new function in trunk.

[nacin]

Hmm, thanks for pulling me back to this.

In this patch I assume that the change to the _deprecated_argument function proposed in #11386, removing the name of the argument, is committed (first).

Hmm, I think we can also patch up get_bloginfo() as well, as 'home' and 'siteurl' are deprecated. I will create a ticket - can you think of any other instances?

[nacin]

Requires commit in #11386 first.

[nacin]

get_bloginfo() - #11652

[westi]

I think one call in has_cap where the mapping happens is better than putting the calls into current_user_can and author_can.

[westi]

(In [12585]) Mark user levels as Deprecated. Fixes #10805 props nacin.

[nacin]

Replying to westi:

I think one call in has_cap where the mapping happens is better than putting the calls into current_user_can and author_can.

Fine by me. I only patched it the other way just to pass to _deprecated_argument the names of the function a developer would call, but they're already getting good feedback in the message anyway.