Fixing a DataTables View that shows “This table could not load” or stays on “Loading data…”
A DataTables View set to Ajax (Server-side) processing gets its entries from your site in a background request. When that request fails, the page shows “This table could not load. Please try again.” and a Retry button above the table. The table underneath reads “This search returned no results.” even though the View has entries. If the View’s “No Search Results” Text setting holds your own text, the table shows that instead.
A table can also stay on “Loading data…” for a while when your site is slow to answer. It keeps waiting and shows the entries when the answer arrives. If “Loading data…” stays on top of a table’s rows after a sort, see the GravityCharts section below.
Click Retry first. It asks your site for the entries again, which is all a momentary failure needs.
Finding the failed request #
Your browser shows the table’s request and your site’s answer. Open the page as a user who sees the error, then:
- Open your browser’s developer tools and click the Network tab.
- Reload the page. If the table only fails after a page change, a sort, or a search, do that now.
- Find the request to
/wp-json/gravityview/v1/views/<View ID>/refresh. Typingrefreshin the tab’s filter box finds it. - Check its status, then click it and open its Response.
| Status | What it means |
|---|---|
| 401 or 403 | Something refused the request. See the sections below on pages left open for a long time, security plugins, and the REST API. |
| 500, with the message “Results are unavailable right now.” | A PHP error stopped the request. See the section on PHP errors. |
| 500, with the message “There has been a critical error on this website.” | PHP stopped before it finished, most often because it ran out of memory. See the section on PHP running out of memory. |
200, with text before the { that starts the data | A plugin or theme printed something into the answer. See the section on printed output. |
If the table fails for visitors but loads for you, repeat these steps in a private browser window, or logged in as a user with the role that sees the problem.
Common causes #
Another plugin printing into the response
A plugin or theme prints a PHP notice or a debug line in front of the table’s entries, and the browser can no longer read them. The request answers 200, and its Response starts with the printed text. A PHP notice names the file that printed it, which tells you the plugin. Update it or ask its developer to fix the notice, and deactivate it until then.
A PHP error part-way through
When something fails while the table’s rows are built, the request answers 500 with “Results are unavailable right now.” GravityKit’s log records the PHP error behind it. Turn on GravityKit logging at the default level, load the page again, and look in the log for View refresh payload failed. The PHP error message follows it. If it names a function or a file from a plugin, deactivate that plugin temporarily to confirm.
PHP running out of memory
The table’s rows come from a separate request after the page loads. When that request uses up PHP’s memory limit, PHP stops it. The request answers 500, its Response says “There has been a critical error on this website.”, and the table reads “This search returned no results.” Your server’s PHP error log has the cause, a line with Allowed memory size of 134217728 bytes exhausted, and so does the WordPress debug log when it’s turned on. The number is the limit in bytes, and 134217728 is 128 MB.
To raise the limit, add define( 'WP_MEMORY_LIMIT', '512M' ); to wp-config.php, above the line that reads That's all, stop editing! Happy publishing. WordPress raises PHP’s limit to that value when the server allows it.
To confirm the new limit, go to Tools, then Site Health, open the Info tab, and read PHP memory limit in the Server section. If it still shows the old value, the server is setting its own limit. Make the change in your host’s PHP settings for the PHP version your site runs, or ask your host to do it. On a server that runs PHP as FPM, a memory setting in .htaccess doesn’t apply, and a .user.ini file in the site’s root folder does.
A page left open for a long time
When a logged-in user opens a page, the table gets a security token that expires within a day. If the page stays open longer, the table’s next request answers 403 and the table fails. Retry reloads the page, which gets a new token. Logged-out visitors don’t use this token, so a page that a cache serves to visitors doesn’t fail this way.
A security plugin or firewall blocking the request
Firewalls and security plugins sometimes block or challenge the table’s request to /wp-json/gravityview/v1/views/<View ID>/refresh, particularly for visitors who aren’t logged in. If the table works for you but not for visitors, check this first, and allow requests to that address.
A plugin that turns off the REST API for some users
Some performance and security plugins can turn off the WordPress REST API for everyone except administrators, or for visitors who aren’t logged in. When that happens, a table set to Ajax (Server-side) processing loads for administrators and shows “This table could not load. Please try again.” to everyone else, including logged-in users with other roles. A table set to Preloaded (Client-side) still shows its entries, but a Search Bar search on it fails the same way.
In Perfmatters, this is the Disable REST API option on the General tab. Disable for Non-Admins blocks every user who isn’t an administrator, and the blocked request answers 401 with the code rest_authentication_error and the message “Sorry, you do not have permission to make REST API requests.” If only logged-in users view the table, Disable When Logged Out keeps the REST API available to them. Turning the option off works for every visitor, and Perfmatters also explains how to add an exception for a specific plugin.
A GravityCharts widget on a Preloaded View
On a View set to Preloaded (Client-side) processing, a GravityCharts widget in GravityCharts 1.23.0 or earlier stops the table from hiding “Loading data…” after a visitor sorts it. The rows are sorted underneath, and the message stays on top of them until the page is reloaded. Update GravityCharts to 1.23.1 or later to fix it.
Narrowing it down #
- Check whether the table also fails for administrators. If it only fails for other users, start with the sections above on security plugins and on the REST API.
- Check the status and the response of the failed request, as described in “Finding the failed request” above.
- Deactivate the plugin named in the printed text or in the GravityKit log, and reload.
- If nothing is named, deactivate other plugins in batches until the table loads, then reactivate one at a time.
- Switch temporarily to a default theme to rule the theme out.
- Check whether the problem follows a specific View or affects all of them. If one View fails, check its settings. If every View fails, the cause is elsewhere on the site.
Note: If the table still fails, contact support with the status and the response of the /refresh request, the GravityKit log line when it answered 500, and whether the problem happens for logged-out visitors or for users who aren’t administrators.
