#10805 closed enhancement (fixed)
Mark user levels as Deprecated
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | 3.0 |
| Component: | Role/Capability | Version: | 2.9 |
| Severity: | normal | Keywords: | has-patch |
| Cc: |
Description (last modified by 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
Attachments (2)
Change History (14)
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...
- Owner set to westi
- Status changed from new to accepted
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.
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).
Then isn't it adviseabel to raise the prio in #11386? this patch can be improved then based on the new function in trunk.
- Keywords dev-feedback 2nd-opinion removed
- Milestone changed from Future Release to 3.0
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?
comment:10
follow-up:
↓ 12
westi — 3 years ago
I think one call in has_cap where the mapping happens is better than putting the calls into current_user_can and author_can.
comment:11
westi — 3 years ago
- Resolution set to fixed
- Status changed from accepted to closed
comment:12
in reply to:
↑ 10
nacin — 3 years ago
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.

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.