Hi Mark,

I am not familiar with CloudFlare and all these details, but it seems to me your Firewall is blocking Admin-Ajax calls from a Table which uses our server-side processing, right?

Can you please check what is this table type, is it a Manual table?

If so, the Manual tables always use server-side processing.

Or if it is an SQL Query table - please check do you have the server-side processing option enabled on it.

If you use our server-side processing on a Table while having active caching on a Page, then we will advise on that scenario :

We currently have this issue which only happens for server-side processing tables when you have caching active on the page.

Our developers are intensively working to resolve this issue, as soon as possible. I can't say an ETA on it, unfortunately.

You can certainly follow our changeLog page if you'd like ( it is also available in the plugin dashboard), where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

-

For the time being, the only two possible solutions will be:

1.  To disable caching only for pages where you have the tables, or perhaps disable caching entirely, if possible.

Most caching Plugins have the option to add URL's that will be excluded, so if possible, see if you can add the Pages with tables there, and that should solve it for now.

2. Or you can try disabling the server-side processing option in your Table.

For the Manual Tables, it is not possible to disable server-side processing,

but you can make a new SQL Query based table from the same data which is stored in a Manual Table.

This is how that is done.

First, check what is the MySQL Table name inside the Editing settings,

then make an SQL Query like : 

 SELECT * FROM TableName  

For any SQL Query based Table which has less than 2 thousand rows, you will be able to toggle server-side processing in the Data Source settings.

Let me know if that helps and if you have any questions. 

2. Or, if this is not a cache combined with server-side processing issue, your firewall might be simply blocking the Admin-Ajax call from the Table.

In order to isolate that, if you see any 'loading spinner icon' on our Table, so it just seems to be 'infinite loading';

please check under the developer console of your browser, can you find an error 403 there?

If so, please try opening the Network Tab in browser's developer console and catch more text there;

It is under the "Preview tab", where you can see something like :  "Firewall blocked Admin-Ajax call" and some other details hidden behind that error.

If that is the case, I will advise you from other cases experience :

We had another couple of users,  that had this issue, it was blocked by the site firewall,

and in the end, their hosting support realised that this should not happen, so they have resolved it / lifted the block from Admin/Ajax calls for our tables.

-  But, i will elaborate more to clarify everything:

Basically, this Admin-Ajax call is a request coming from our server-side processing feature. Here are more details that explain the process :

• wpDataTables with server-side processing enabled fetches only those rows needed on the page at the exact moment. By default, it equals to the number of rows that administrator defines for the table in the “Display length” setting; the front-user can however, change it. For example: if the table is configured to show 10 rows by default, only 10 rows would be queried from MySQL. When the user switches to the next page, and sorts the table by some column, or filters by some column, an AJAX-request is sent to the server, the query is processed by MySQL, and 10 more rows are returned. This may slow down the processing, search, filtering and sorting (of smaller tables also), but for larger tables it may be the only option.

If you wish, you can see more about our server-side processing process here.

Here is the screenshot from another user who had the same "false positive" block by their site firewall ( i blurred their website and IP, just to be safe)

If you have a similar 'blocked by firewall' error on your Site, we cannot say why your site firewall blocks the admin-ajax call. 

That's a question for the hosting provider. There could be a number of reasons. 

If you search/Google for admin-ajax (https://www.google.com/search?q=what+are+admin-ajax+calls&oq=what+are+admin-ajax+calls&aqs=chrome..69i57.6300j0j4&sourceid=chrome-mobile&ie=UTF-8) 

you can find that this is one of the most common methods for routing requests,

and it is one of the most crucial methods in Wordpress.

Maybe your hosting provider is not optimized for WordPress, we can only guess why they block it,

but we don't wish to guess too much.

Until your hosting support does not resolve this, you won't be able to load server-side tables. 

Please let us know if you reach out to your hosting support if they shed some light on this matter.

Thank you.

Hi Mark,

Thanks for the URL where we can see the tables.

On the first Page, I can see that is a Manual table type.

Same on the second page.

We are unable to see any error/issue at this time, on both pages the Manual table loads for us.

This Manual table type in our Plugin, it is always using our server-side processing in the background.

So any time the table loads - for example when the page is loaded or refreshed, our server-side feature sends an Admin-Ajax call to your SQL database via the Hosting server.

If you also have the "auto refresh" feature activated in the Manual table - that means any time that time interval 'triggers', it also sends additional Admin-Ajax call to auto-refresh the table.

So, please check if you catch the error in the Network Tab of the developer console, when the table 'spins' and can't load.

If you can see something like "Error 403/  The Site firewall blocked the Admin-Ajax call", in the 'preview tab' of the Network tab in the Browser developer console, then the Site firewall is somehow blocking our Admin-Ajax call.

Please refer to the details from my previous reply, where we wrote everythign we know on that subject.

If this is the case, our Support is not able to say what could be blocking our Admin-Ajax call, that is a question for the Hosting Support.

They need to find what blocks it and to lift the block.

2. Another possible issue can happen, if you have active caching on the Page with a Manual table.

As mentioned in the previous reply - Manual tables always have our server-side processing active, you can't disable it for this table type.

The only two ways what you can do ( if that is the case) is :

- Either to exclude the URL with the Manual table from caching on the Site

- Or to completely disable caching on Site.

- There is a third workaround option, to make an SQL Query table which calls same data source from the Manual table, and disable our server-side processing on that SQL table.

Then you can have caching without issues on the Page.

But we already wrote full details on all these points/and methods you can try in the previous reply, so we can copy them again, but it would basically be the same text.

It is best if you can refer to these points in more details in the previous reply, which has more detailed versions;

on this reply we just tried to 'summarize' the main points what you can try.

I sincerely hope it helps, if you can try all of these and one of them should work to isolate/resolve the issue.

Hi Joe,

Unfortunately, we still haven't made progress on this issue of caching combined with server-side processing on the same Page.

If you have any active caching on a Page, where a Manual table is ( the manual table can't disable its server-side option) or an SQL Query table with server-side enabled;

in that case, this issue happens.

When you clear the cache - that solves the issue temporarily, that is what happened on your end, too.

I can see you use Manual tables on that Page. So now, if you completely disabled cache - the issue won't happen.

Or, you can disable cache only for URL's where you have tables.

If cache needs to be enabled for the page with a Manual table;

In that case, the only remaining option is to build an additional SQL Query table and disable server-side option on it.

You will find more details on how that works on this comment.

I hope it helps.

If you have further questions on this, please create a new ticket from your Ticksy account, and we will keep following up.

Thank you.