
What the notice means
WordPress 4.5, released in April 2016, deprecated get_currentuserinfo(). The function still ran for a while but triggered a notice when debugging was on, and deprecated functions can be removed in later releases. The post on this domain explaining the fix was linked widely at the time because many popular plugins, including newsletter tools, showed the notice at once.
The full text reads "Function get_currentuserinfo is deprecated since version 4.5! Use wp_get_current_user() instead." WordPress produces it through its _deprecated_function() helper, which fires only when WP_DEBUG is true, so a site that never saw the notice is not free of the call; it simply has debugging off. The old function set a global variable named $current_user as a side effect, and that side effect is the reason the fix is slightly more than a rename.
The fix
// old
global $current_user;
get_currentuserinfo();
echo $current_user->user_email;
// new
$current_user = wp_get_current_user();
echo $current_user->user_email;wp_get_current_user() returns a WP_User object. If no one is logged in, the object's ID is 0, so check is_user_logged_in() or $current_user->exists() before using the email or name.
A worked example: a newsletter widget
The notice below is the shape most people see. It names a widget file inside a plugin folder, which tells you the caller is a plugin, and it gives the line number. In our worked example the plugin is a subscription form that pre-fills the email field for logged-in readers.
PHP Deprecated: Function get_currentuserinfo is deprecated since version 4.5!
Use wp_get_current_user() instead. in /var/www/html/wp-includes/functions.php on line 6114
# the caller, found by searching wp-content
wp-content/plugins/example-newsletter/includes/widget.php:41: get_currentuserinfo();The fix keeps the widget's behaviour for logged-in readers and stops it from printing an empty email for visitors, which the old code did because a visitor's $current_user had blank fields.
// widget.php, before
global $current_user;
get_currentuserinfo();
$email = $current_user->user_email;
// widget.php, after
$email = '';
if ( is_user_logged_in() ) {
$user = wp_get_current_user();
$email = $user->user_email;
}
echo '<input type="email" name="email" value="' . esc_attr( $email ) . '">';Three lines changed. The replacement returns the user object instead of filling a global, the logged-in check replaces the old habit of testing whether $current_user->ID was zero, and esc_attr() escapes the value on output, which the old snippet skipped. If the plugin is not yours, do not edit it in place; the next update overwrites the file. Check for an update first, and if none exists, the plugin troubleshooting order covers how to replace a plugin safely.
Find the code that calls it
Read the notice
With
WP_DEBUGon, the notice names the file and line. The path shows whether it is a plugin or your theme.Search if needed
Search
wp-contentforget_currentuserinfo.Update first
If it is a plugin, check for an update; most fixed this years ago. A plugin still calling it is probably abandoned.
Patch your own code
If it is your theme or custom plugin, apply the change above.
Turn off display
On production, log notices instead of showing them:
WP_DEBUG_DISPLAYfalse andWP_DEBUG_LOGtrue.
# find every caller in one pass (shell access)
grep -rn "get_currentuserinfo" wp-content/plugins wp-content/themes --include=*.phpSymptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| Notice at the top of every admin page | WP_DEBUG_DISPLAY is on and a plugin calls the old function | Log instead of display; update or patch the caller |
Notice only in debug.log | Display is off, the call is still there | Same fix; the log shows the file and line |
| "Headers already sent" errors after the notice | The notice is printed before a redirect or a cookie is set | Turn display off first, then fix the caller |
Notice names functions.php in wp-includes | That is where the notice is raised, not where the call is | Search wp-content for the function name |
| Notice returns after a plugin update | The plugin was patched by you and the update replaced the file | Report upstream, or replace the plugin |
| Empty name or email in a form for visitors | The old code read a blank user object | Check is_user_logged_in() before reading fields |
Pitfalls when fixing the get_currentuserinfo deprecated notice
- Editing a third-party plugin in place. The fix lasts until the next update. Patch your own code, or replace the plugin.
- Keeping
global $current_useralongside the new call. It works, because WordPress still fills that global, but it hides the fact that the code depends on a side effect. Use the returned object. - Reading
user_emailordisplay_namewithout a logged-in check. Visitors get a user with ID 0 and empty fields, which shows up as blank form values or empty greetings. - Assuming the notice is harmless because the page still renders. Deprecated functions can be removed in a later release; the notice is the only warning you get.
- Hiding notices by setting
WP_DEBUGfalse and stopping there. The call is still made. Log to a file, fix the cause, then turn logging down.
Why deprecation notices matter
A deprecation notice is a warning that code will break in a future release. It is also a useful signal: a plugin that still triggers notices for functions deprecated years ago is not being maintained, and that is a reason to plan its replacement before it causes a real failure.
The same signal applies to share plugins. The closed plugin this domain once sold shipped its last compatibility fixes for PHP 8.2 and then stopped, and the notices its add-ons raise on newer PHP versions are the same early warning; removing MashShare cleanly shows what to do about them. Scheduled tasks that stop running are the other quiet failure on older sites, covered in external cron jobs for WordPress; both belong to the WordPress troubleshooting notes.
Sources
- WordPress developer reference: get_currentuserinfo() (deprecated)
- WordPress developer reference: wp_get_current_user()
- WordPress.org news: WordPress 4.5 "Coleman" release post (April 2016)
- WordPress developer reference: _deprecated_function()
Questions
What replaces get_currentuserinfo()?
wp_get_current_user(), which returns the current WP_User object.
Is the deprecated notice dangerous?
Not by itself, but it signals code that may break in a future WordPress release.
How do I hide deprecated notices?
Keep WP_DEBUG_DISPLAY off on production and log to a file instead. Fix the cause when you can.
Does get_currentuserinfo() still run in current WordPress?
As of the cited developer reference it remains in the deprecated functions file and still calls wp_get_current_user() internally, so pages render. Deprecated functions are kept for compatibility and can be removed in a future release without further notice.
Why does the notice point at wp-includes/functions.php?
That file contains the helper that raises deprecation notices. The line it names is where the notice is generated. The caller is somewhere in wp-content; search there for the function name.
Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.
Related reading
- Plugin troubleshooting: what to try firstTroubleshoot a WordPress plugin problem in a safe order: caches, conflicts, debug logging, recovery mode, and disabling a plugin when the admin is down.6 min read
- External cron jobs for WordPress, the right wayReplace WP-Cron's visit-triggered schedule with a real server cron job: disable WP-Cron, call wp-cron.php or WP-CLI on a schedule, and check tasks run.6 min read
- Removing MashShare cleanly from a WordPress siteRemove MashShare from WordPress without breaking posts: find leftover shortcodes and theme calls, decide what to do with stored counts, and clean options.7 min read