Hi Manuel,

Firstly, I would like to sincerely apologize for the delayed response as we have been experiencing an unusually high number of tickets. I am sorry that it has taken longer than usual to respond to your concern and your patience is highly appreciated.

 When it comes to only loading your filtered content from linked Tables;

It depends what kind of a table you have and what way you use to filter it.

Tables are crawlable by search engines but they are somewhat limited.

 Manual, imported, and MySQL query-based tables with server-side processing will only show the content/rows of the 1st Table's page ( if you have pagination for rows). 

For example, if you set that the table shows 10 rows per page, by default, Google and other search engines will only be able to see that page, while the other pages won't be crawlable.

Linked tables (Excel, CSV, Google Spreadsheet, XML, JSON, and PHP tables) are fully crawlable since they fetch all the rows, output the entire table to the front-end all at once, and then split it into pages using JavaScript; 

all data processing (page switching, sorting, filtering) is done on the client’s computer by JavaScript.

If you have a linked table, you will not be able to see just the filtered data because (as mentioned above) all data is already output to the front-end, and the filtering is done by the client's computer, but all data is still there.

You'd need a server-side table that uses server-side processing for filtering in order to see only the filtered data, but even in that case - it will only see the first 10 (or how many rows you configured to be default) rows. 

For example, if you take a look at this page: https://wpdatatables.com/documentation/creating-wpdatatables/creating-mysql-based-wpdatatables-with-server-side-processing/ when you view the source, you will only see the first 10 rows.

For example, if you use an SQL Query based Table, and use a "WHERE" statement to filter it, you can also add our Placeholders for filtering;

that would filter the data before it reaches the front-end.

That is the only way;

other than that, if you use a table linked from source data like Spreadsheets, that pulls the entire unfiltered data.

Let me know if you have any questions.

Hi Manuel,

2. Sorry, I forgot to mention about your second issue as you described it;

We are not sure what you mean exactly by activating the "Reading Mode".

Could you please record your screen and send us a Video so that we can see which option/setting you are enabling and how that looks on your screen?

If the Video has any sensitive data, just mark the reply as PRIVATE, for security reasons;

or if it becomes too large, you can upload it anywhere like weTransfer and send us a download link.

Thank you.

Hi Manuel, 

Firstly, I would like to sincerely apologize for the delayed response as we have been experiencing an unusually high number of tickets. I am sorry that it has taken longer than usual to respond to your concern and your patience is highly appreciated.

I will do my best to clarify how all this works.

To summarize what we wrote before, the main point is that the search engines crawl all our tables, there is just a big difference between server side tables ( Manual and SQL tables with server side option enabled) and non server side, which are tables linked from Excel, CSV and similar.

In your case, if you use a Manual table, it uses our server side processing.

That means the search engines will crawl only the rows which are visible on the first table page during the initial table load.

So if you have pagination on the table and if you use any placeholder filter such as VAR in the shortcode, then only the first filtered table page gets crawled.

If that is how you need it to be, let me know.

Or if you need the table to crawl all rows regardless of pagination;

Then you can make an additional SQL query table to pull same data from Manual one and if it has equal or less than 2 000 rows, you can disable server side processing in the Data Source settings.

Just check what is the table SQL name in the editing.

Then make a new SQL table like : SELECT * FROM tableName.

Then the search engine will crawl(index) all the rows of this table and only the filtered ones since you use that VAR predefined filter in the shortcode.

Let me know if that provides all the info you need.

Thanks.

Hi Manuel,

You're welcome, I am happy to advise.

1. Yes. It will happen exactly like that.

So, if you have pagination in table ( rows spread on multiple table pages), then you can make the SQL Query Table and disable server-side processing on it;

This way, the Search Engines will crawl the entirety of the loaded table, not only the first page of rows.

-

When it comes to filtered data, yes, if you set a "WHERE" statement in a Query like :

SELECT * FROM TableName
Where ColumnName = 'VAR1'

Then, in the Table Back-End, set some default VAR1 value in the Placeholders section to generate the table.

In the Table shortcode, you can pass a different VAR1 value if needed for a specific Page.

So, you could have Page 1 filtering the table for one VAR1 value, and another Page 2 filtering it for a different VAR1 value and so on, like :

[wpdatatable id=32 var1=58]

Then, the Search Engine is going to crawl only the filtered table rows and all the pages since you disabled server-side (otherwise, if you used a Manual table, then it would only crawl the first table page).

2. The back and front end of the Table is doing the same call towards your Server.

wpDataTables is a WYSIWYG (What You See Is What You Get) concept-based plugin.

 This means that the table should behave in the same way on both back-end and front-end. 

So any time you load a table on back-end, if server-side processing is enabled on it, that makes an Admin-Ajax call towards the server.

That would be good, we advise not having so many tabs ( as you had before, like ~15) open at the same time while editing many tables, it will be best if you can reduce the number of open tabs like that.

So any time you edit a Manual table ( or SQL Query table that has server-side enabled), and if you hit "save changes" or save editing, that makes a new Admin-Ajax call, etc.

In regards to the question, when you move this to a live site and many people start visiting the front end;

if you will still be using Manual Tables - yes, it depends on how many users/visitors it will be, are you going to use Auto Refresh in tables, and so on...

Auto Refresh is also important - let's say if you set it to refresh every 10 seconds, that means all tables will make one Admin-Ajax call to the server in that interval, etc.

So we advise to disable it if it is not important to you. This way, the table only refreshes with updated data when the page is refreshed, or loaded.

It is possible that the issue you had before was perhaps just because you were editing so many tables at once, so there is a chance that you won't experience a high CPU load when you move it to a live server;

but we can't say with 100% certainty, there are multiple factors 'at play'.

If you do encounter any issues like that, as high CPU load, etc, and if you have a small number of rows in tables ( less than 1 to 2 thousand rows);

you can just create one separate SQL Query table for each Manual Table as we advised earlier.

Then use the Manual Table as Admin only for editing on back-end, while on front-end you can post the SQL Query version shortcode for users and disable server-side on it - then there won't be any additional Admin-Ajax calls from front-end.

So you can decide what will be the best for the use-case, we will be here to advise.

3. DATA REFRESH: If I implement the SQL tables, will the SQL table automatically refresh with the new data every time I update the manual table?

We mentioned that at some point above.

If you disable server-side processing, you won't have the "Auto refresh" option on the table.

So the table updates with new data only when the page is refreshed, or loaded, it won't do the 'automated AJAX call' on the fly anymore.

But on the other hand, that reduces the hosting server load by reducing the number of Admin-Ajax calls.

So you will need to find a balance what would be the best, depending on how many tables you will have, how many visitors, what will be the frequency for the auto-refresh, and so on...

I hope that helps, but let me know if you have any questions.