4

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?

<?php
/**
 * Loads the WordPress environment and template.
 *
 * @package WordPress
 */

if ( !isset($wp_did_header) ) {

  $wp_did_header = true;

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

  wp();

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

}

?>

Any help would be greatly appreciated.

1
  • 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
2

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.

1

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?

2
  • 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
1

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.

0

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.

-1

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

<!-- start -->

<?php
/**
 * 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__ ) . '/' );
}

error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );

/*
 * 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.
    wp_fix_server_vars();

    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 );
        exit;
    }

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

    wp_check_php_mysql_versions();
    wp_load_translations_early();

    // 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." ),
        '<code>wp-config.php</code>'
    ) . '</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." ),
        '<code>wp-config.php</code>'
    ) . '</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.

3
  • 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.