Sticking <script></script> tags referring an external resource in the middle of your HTML code will hang the loading of your page while your browser gets the missing script.

This is usually a problem with the loading of the AddToAny sharing script and a quantcast tag (which has since been removed). Check to make sure there are no other custom scripts that are slowing down your site.

The solution is generic and simple. Use this code to load your Javascript asynchronously:

<script type="text/javascript">

(function() {
    var s = document.createElement('script');
    s.type = 'text/javascript';
    s.async = true;
    s.src = '';
    var x = document.getElementsByTagName('script')[0];
    x.parentNode.insertBefore(s, x);


Instead of loading it synchronously:

<script type="text/javascript" src=""></script>

One thing to consider is that asynchronous loaded Javascript will not block jQuery’s document.ready handlers. Synchronous scripts will. If your jQuery code depends on a plugin (e.g., the simple modal dialog) it may be better to load it synchronously instead.

The fix for me was to use the force-upgrade.php. But you’ve already done that, so here’s what else I found out.

I found that the most common solution seemed to have to do with a mis-match between your wp-config.php. First of all, make sure you (or the WordPress install) has correctly set up the database name, database user name, database password, and database host. See this link:

Secondly, make sure the database table prefix in your config.php matches the table name prefixes in your database. The default is wp_, but if you (or your wordpress install) changed your prefix to something else, it must match the database itself.

Here’s an example of the fields I’m talking about in the wp-config.php.

/** WordPress's config file **/
/**   **/

// ** MySQL settings ** //
define('DB_NAME', 'madeupname');     // The name of the database
define('DB_USER', 'madeupuser');     // Your MySQL username
define('DB_PASSWORD', 'madeuppw'); // ...and password
define('DB_HOST', '');     // ...and the server MySQL is running on
// Change the prefix if you want to have multiple blogs in a single database.
$table_prefix  = 'wp_';   // example: 'wp_' or 'b2' or 'mylogin_'

In your database, using phpMyAdmin, check that the tables all begin with the same prefix that you have in your wp-config.php. For example if you changed your table prefix to “b2”, the tables would be “b2_commentmeta”, b2_comments”, etc.
Also, you have to check inside two tables to see that certain field names are also changed. So, using the same prefix as above, in b2_options, the field wp_user_roles has to be changed to b2_user_roles. And in the b2_usermeta table, the fields wp_capabilities, wp_user_level, wp_user-settings, wp_user-settings-time, and wp_dashboard_quick_press_last_post_id should all have the prefix b2_ instead of wp_.

And lastly, within your database, look at the values in the wp_usermeta table as follows:

wp_capabilities should be a:1:{s:13:”administrator”;s:1:”1″;}

wp_user_level should be 10

All of this should automatically work if you used a quick install, but if you’ve changed anything along the way, or if your install did not work, it could be messed up. I did have this problem initially, and found out that the quick install done by Dreamhost was incomplete. Though I fixed the prefix problem, I still had the “permissions” error. However, when I tried that force.upgrade.php, all was resolved.