{"id":902,"date":"2025-08-04T12:04:47","date_gmt":"2025-08-04T08:04:47","guid":{"rendered":"https:\/\/hostatto.com\/blog\/?p=902"},"modified":"2026-09-01T12:52:19","modified_gmt":"2026-09-01T08:52:19","slug":"how-to-fix-the-an-unexpected-error-occurred-wordpress-plugin-directory-error","status":"publish","type":"post","link":"https:\/\/hostatto.com\/blog\/how-to-fix-the-an-unexpected-error-occurred-wordpress-plugin-directory-error.html","title":{"rendered":"How to Fix the \"An Unexpected Error Occurred\" WordPress Plugin Directory Error"},"content":{"rendered":"

If you are trying to browse or install plugins in your WordPress dashboard and meet the red error notice:<\/p>\n

\"An unexpected error occurred. Something may be wrong with WordPress.org or this server\u2019s configuration. If you continue to have problems, please try the support forums.\"<\/em><\/p><\/blockquote>\n

...you are dealing with a failure in WordPress's ability to communicate with the official WordPress.org API (api.wordpress.org<\/code>).<\/p>\n

While many tutorials suggest editing your \/etc\/hosts<\/code> file or changing DNS servers, the root cause is often not a network issue at all<\/strong>, but rather an internal plugin or theme silently intercepting and blocking WordPress\u2019s HTTP requests.<\/p>\n

Here is how to diagnose and resolve this issue step-by-step, whether you have terminal (SSH) access or not.<\/p>\n

Method 1: The No-Terminal Solution (Plugin Conflict Isolation)<\/h2>\n

If you do not have SSH access to your server or are uncomfortable using the command line, you can isolate the problem directly from your WordPress admin panel or FTP\/File Manager.<\/p>\n

In many cases, this error is caused by a security plugin, a \"disable updates\" utility, or a nulled theme\/plugin that installs a script to block WordPress from checking external servers.<\/p>\n

Step-by-Step Plugin Isolation:<\/h3>\n
    \n
  1. Deactivate All Plugins:<\/strong>\n
      \n
    • Go to Plugins \u2192 Installed Plugins<\/strong> in your dashboard.<\/li>\n
    • Select all plugins using the main checkbox.<\/li>\n
    • Choose Deactivate<\/strong> from the bulk actions dropdown and click Apply<\/strong>.<\/li>\n
    • (If you can't access your admin panel, connect via FTP or cPanel File Manager, navigate to wp-content\/<\/code>, and rename the plugins<\/code> folder to plugins_old<\/code>).<\/em><\/li>\n<\/ul>\n<\/li>\n
    • Test the Plugin Directory:<\/strong>\n
        \n
      • Go to Plugins \u2192 Add New<\/strong>.<\/li>\n
      • Check if the directory loads properly now without the error message.<\/li>\n<\/ul>\n<\/li>\n
      • Re-enable Plugins One by One:<\/strong>\n
          \n
        • If the error disappears after deactivating all plugins, one of your plugins is definitely the culprit<\/strong>.<\/li>\n
        • Go back to your plugins list and reactivate them one at a time<\/strong>.<\/li>\n
        • After activating each plugin, refresh the Add Plugins<\/strong> page to see if the error returns.<\/li>\n<\/ul>\n<\/li>\n
        • Delete the Problematic Plugin:<\/strong>\n
            \n
          • Once you find the specific plugin that triggers the error upon activation, deactivate and delete it<\/strong>.<\/li>\n
          • Look for an alternative plugin or contact its developer for support.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n

            Method 2: Advanced CLI & SSH Diagnostics (For Developers & Sysadmins)<\/h2>\n

            If you have SSH access, you can bypass guesswork and identify the exact line of code causing the issue in minutes.<\/p>\n

            Step 1: Rule Out Network & System SSL Issues<\/h3>\n

            Run a raw cURL command from your terminal to verify if your server can reach WordPress.org over HTTPS:<\/p>\n

            curl -v https:\/\/api.wordpress.org\/plugins\/info\/1.2\/<\/code><\/pre>\n
              \n
            • Expected Result:<\/strong> An HTTP\/2 200<\/code> or HTTP\/1.1 200 OK<\/code> response with a valid SSL handshake.<\/li>\n
            • If it fails:<\/strong> Fix your system DNS (\/etc\/resolv.conf<\/code> or systemd-resolved<\/code>) or update your CA certificates (sudo apt install --reinstall ca-certificates<\/code>).<\/li>\n<\/ul>\n
              Step 2: Test cURL Inside the PHP Environment<\/h3>\n
              Even if system cURL works, PHP-CLI might have different configurations. Run this code snippet inside PHP:<\/p>\n
              php << 'EOF'\r\n<?php\r\n$ch = curl_init('https:\/\/api.wordpress.org\/plugins\/info\/1.2\/');\r\ncurl_setopt($ch, CURLOPT_RETURNTRANSFER, true);\r\n$response = curl_exec($ch);\r\n\r\necho \"CURL ERROR: \" . curl_error($ch) . PHP_EOL;\r\necho \"HTTP CODE: \" . curl_getinfo($ch, CURLINFO_HTTP_CODE) . PHP_EOL;\r\nEOF<\/code><\/pre>\n
              If this returns HTTP CODE: 200<\/code> with no cURL errors, your network, cURL library, and server-level SSL certificates are 100% operational<\/strong>. The issue lies entirely inside WordPress execution.<\/p>\n
              Step 3: Test WordPress HTTP Transport (wp_remote_post)<\/h3>\n
              WordPress wraps network requests in its own functions. Test how WordPress handles the request internally:<\/p>\n
              php << 'EOF'\r\n<?php\r\nrequire_once 'wp-load.php';\r\n\r\n$url = 'https:\/\/api.wordpress.org\/plugins\/info\/1.2\/';\r\n$args = array(\r\n    'timeout' => 15,\r\n    'user-agent' => 'WordPress\/' . $GLOBALS['wp_version'] . '; ' . get_bloginfo('url'),\r\n    'body' => array(\r\n        'action' => 'query_plugins',\r\n        'request' => serialize((object)array('browse' => 'featured', 'page' => 1))\r\n    )\r\n);\r\n\r\n$response = wp_remote_post($url, $args);\r\n\r\necho \"HTTP Code: \" . wp_remote_retrieve_response_code($response) . PHP_EOL;\r\nvar_dump($response);\r\nEOF<\/code><\/pre>\n
              The \"Aha!\" Moment:<\/h4>\n
              If var_dump($response)<\/code> returns bool(true)<\/code> while HTTP Code<\/code> is completely empty<\/strong>, WordPress is not even sending a request over the network! An internal hook is hijacking the HTTP client and returning a dummy boolean response.<\/p>\n
              Step 4: Inspect pre_http_request Hooks<\/h3>\n
              WordPress provides a filter named pre_http_request<\/code> that allows developers to preemptively hijack HTTP calls. Run this script to list all active callbacks attached to this hook:<\/p>\n
              php << 'EOF'\r\n<?php\r\nrequire_once 'wp-load.php';\r\n\r\nglobal $wp_filter;\r\nif (isset($wp_filter['pre_http_request'])) {\r\n    foreach ($wp_filter['pre_http_request']->callbacks as $priority => $callbacks) {\r\n        foreach ($callbacks as $name => $details) {\r\n            echo \"Priority $priority: $name\" . PHP_EOL;\r\n        }\r\n    }\r\n}\r\nEOF<\/code><\/pre>\n
              If you see a custom function like block_wp_update_requests<\/code> or similar overriding functions attached to priority 10<\/code>, you have found the blocking filter!<\/p>\n
              Step 5: Locate and Remove the Offending Code<\/h3>\n
              Use grep<\/code> to scan your wp-content<\/code> directory for the function name found in Step 4:<\/p>\n
              grep -rnw '\/var\/www\/your-site\/wp-content\/' -e 'block_wp_update_requests'<\/code><\/pre>\n
              This will reveal the exact file path and line number (e.g., inside a rogue plugin or a theme's functions.php<\/code>). Delete or deactivate the offending plugin\/theme code, reload your dashboard, and the plugin directory will instantly work again!<\/p>\n
              Summary<\/h2>\n
              When WordPress throws \"An unexpected error occurred\"<\/em> on the plugin page:<\/p>\n
                \n
              1. Don't blindly edit \/etc\/hosts<\/code> or server configs.<\/li>\n
              2. If you don't have SSH: bulk deactivate all plugins and turn them back on one by one<\/strong>.<\/li>\n
              3. If you have SSH: check for internal WordPress hooks like pre_http_request<\/code> that might be short-circuiting network requests.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
                ...<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54],"tags":[144,151],"class_list":["post-902","post","type-post","status-publish","format-standard","hentry","category-wordpress","tag-wordpress","tag-wordpress-error"],"_links":{"self":[{"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/posts\/902","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/comments?post=902"}],"version-history":[{"count":1,"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/posts\/902\/revisions"}],"predecessor-version":[{"id":903,"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/posts\/902\/revisions\/903"}],"wp:attachment":[{"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/media?parent=902"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/categories?post=902"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hostatto.com\/blog\/wp-json\/wp\/v2\/tags?post=902"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}