I recently updated a site and received the following error message:

Fatal error: Call to undefined function wp() in /home/atlmp/public_html/wp-blog-header.php on line 14

I checked the file and there doesn't seem to be any issues, so I can't figure out what's wrong?

 * Loads the WordPress environment and template.
 * @package WordPress

if ( !isset($wp_did_header) ) {

  $wp_did_header = true;

  require_once( dirname(__FILE__) . '/wp-load.php' );


  require_once( ABSPATH . WPINC . '/template-loader.php' );



Any help would be greatly appreciated.

  • Where have you got that call? Be a little more specific and please show us the template where it appears. It looks like you're trying to access some part of wp (directly) without loading it. – kaiser Mar 25 '11 at 15:36

I just had to fix this exact issue. My site [Riverside Bartending School] went down and like the many with this issue or one similar report I too could not access the Admin Panel. So this is what I did.

Using cPanel (you can also use FTP) I deleted all the cache and super cache files.

Then I uploaded a fresh copy of Wordpress replacing all the Wordpress files except for wp-content folder and contents.

Thirdly, I changed the wp-config.php file to make sure that the database credentials were correct.

Next step was to attempt to login to the admin panel, and it was a success. Then reactivate the plugins - again a success. Test the site and viola it was up and running.


To load WordPress it is enough to load "wp-load.php" like you did. I don't recognize the wp() function and haven't found it in the source. As other people seem to have the same problem on the internet I guess it has to do with a plugin or a possibly outdated WordPress installation.

Disable all your plugins and see if that resolves the problem.

Out of curiosity: What is this file for?

  • It is a directory website. I was just updating WP from the dashboard? I have gone ahead and deleted everything and FTP'd a new install. Everything seems to be working fine now. Thanks for your help. – Marna Mar 27 '11 at 4:01
  • Ah yes, I see! Thought that this was part of your theme code. But your right, it's part of the WordPress core. Glad that a "reinstall" fixed it for you. – marvinhagemeister Mar 28 '11 at 8:01

I agree. Usually it's a plugin that causes these issues in my experience. it can be a headache, but disabling all of your plugins, then going through and enabling your plugins one by one will often pinpoint the problem.


I was facing this error when moving my site files from hostgator to other host, what I did was ZIP the files and FTP them to the new host. something messed up with compressing the files, when I compressed them with tar.gz everything worked fine. that's what helped me after several hours,

probably something with the encoding of files.


There is some WordPress issue. you please update your wp_load.php and using this code.

<!-- start -->

 * Bootstrap file for setting the ABSPATH constant
 * and loading the wp-config.php file. The wp-config.php
 * file will then load the wp-settings.php file, which
 * will then set up the WordPress environment.
 * If the wp-config.php file is not found then an error
 * will be displayed asking the visitor to set up the
 * wp-config.php file.
 * Will also search for wp-config.php in WordPress' parent
 * directory to allow the WordPress directory to remain
 * untouched.
 * @package WordPress

/** Define ABSPATH as this file's directory */
if ( ! defined( 'ABSPATH' ) ) {
    define( 'ABSPATH', dirname( __FILE__ ) . '/' );


 * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php
 * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit
 * of avoiding cases where the current directory is a nested installation, e.g. / is WordPress(a)
 * and /blog/ is WordPress(b).
 * If neither set of conditions is true, initiate loading the setup process.
if ( file_exists( ABSPATH . 'wp-config.php' ) ) {

    /** The config file resides in ABSPATH */
    require_once( ABSPATH . 'wp-config.php' );

} elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) {

    /** The config file resides one level above ABSPATH but is not part of another installation */
    require_once( dirname( ABSPATH ) . '/wp-config.php' );

} else {

    // A config file doesn't exist

    define( 'WPINC', 'wp-includes' );
    require_once( ABSPATH . WPINC . '/load.php' );

    // Standardize $_SERVER variables across setups.

    require_once( ABSPATH . WPINC . '/functions.php' );

    $path = wp_guess_url() . '/wp-admin/setup-config.php';

     * We're going to redirect to setup-config.php. While this shouldn't result
     * in an infinite loop, that's a silly thing to assume, don't you think? If
     * we're traveling in circles, our last-ditch effort is "Need more help?"
    if ( false === strpos( $_SERVER['REQUEST_URI'], 'setup-config' ) ) {
        header( 'Location: ' . $path );

    define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
    require_once( ABSPATH . WPINC . '/version.php' );


    // Die with an error message
    $die = sprintf(
        /* translators: %s: wp-config.php */
        __( "There doesn't seem to be a %s file. I need this before we can get started." ),
    ) . '</p>';
    $die .= '<p>' . sprintf(
        /* translators: %s: Documentation URL. */
        __( "Need more help? <a href='%s'>We got it</a>." ),
        __( 'https://wordpress.org/support/article/editing-wp-config-php/' )
    ) . '</p>';
    $die .= '<p>' . sprintf(
        /* translators: %s: wp-config.php */
        __( "You can create a %s file through a web interface, but this doesn't work for all server setups. The safest way is to manually create the file." ),
    ) . '</p>';
    $die .= '<p><a href="' . $path . '" class="button button-large">' . __( 'Create a Configuration File' ) . '</a>';

    wp_die( $die, __( 'WordPress &rsaquo; Error' ) );

<!-- end -->

and please change file permission 644 to 444.

  • 2
    Please edit your answer, and add an explanation: why could that solve the problem? It looks just like a very bad idea to edit core without any reason. – fuxia Jun 20 '20 at 16:23
  • Agreed @fuxia. @sumer-signh-harawat -- If you would be kind enough to tell @marna (and the rest of us reading this) why the changes to wp-load.php would fix the problem. Additionally, the changes are likely to be overwritten during a WordPress upgrade, so it should be noted that this modification must be checked to ensure it remains after every upgrade (and re-implemented every time it is changed). – Mort 1305 Jun 21 '20 at 5:30
  • You are god! some one emptied my wp-load.php you saved my hell lot of time and effort – Aayush Gupta Jan 27 at 15:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.