Hi Melanie,

Sorry for the waiting time.

We don't work on weekends so it adds two days to the waiting time.

we appreciate your patience.

I will advise you in details about everything you can check/and different ways how you can try to improve the loading speed of our Tables and your Page.

Some limitations exist from WordPress itself and the number of rows in your tables, but we will elaborate in details how all that works :

The loading speed depends on a lot of factors - your hosting plan, server's performance, amount of other data on the page, internet speed, etc. 

For example, you can take a look at the table on our documentation, which contains around 2.600.000 rows, and see how it loads.

 The more data the table has, the more chance that it will impact the loading time.

Please note that Table is an SQL Query Based Table, it uses our Server-Side Processing(lazy load) feature, which dramatically improves loading speeds by using AJAX to only load one Table page at a time,

compared to non-server-side Tables which always load all rows on the HTML of the Page regardless of Table Pagination.

-

If you use non-server side Tables, like linked from Google Spreadsheet/CSV/Excel , we advise trying our cache and Auto Update Cache feature.

With our caching option, the load time is significantly lowered, but we still recommend keeping the data in these files down to around 5.000 rows.

That is when you have one Table on the Page which has ~5k rows.  But if you have two tables, as you said, and one is 7k rows with the other having ~5k rows, then we add them together, which is around 12 thousand rows.

That is too much for a Front-end HTML of the Page browser to handle, without becoming slow, even if you have a great performing Hosting Server.

If any of your Table linked from source file goes above that size - then the best is to switch to SQL based Tables, to import the data from CSV/Google Sheet or Excel.

 If you import the file, the plugin reads the source file and creates a manual table. 

Once the table is created, it is no longer linked to the source file, so changing data in the table will not show up in Excel or Google Spreadsheet, and vice-versa. 

To modify this table, you can either switch to the Excel-like view, 

and then select and copy the range of cells you want to paste from the source file, and paste it in the Excel-like view, 

or you can import a new/edited CSV to update the table, as well, in the following ways :

• Update manual tables: Replace data within an existing table.
• Update manual tables: Add data to an existing table.
•  Update manual tables: Replace the entire table with new data.

-

You can also check, in this table's filter settings for columns, how many unique filtering values there are.

If you have, for example - a string column that you set as a selectbox/multiselectbox, 

and if it has more than 50 possible filtering values,

you can go into that column setting, and check what is set for "Number of possible values to load" – 

Here you can define how many possible values per page will be loaded in selectbox filter and editor inputs. It is recommended not to be set for All if you have more than 50 possible values for this column.

So, check if that might be the case, try to lower the value to 50 and see if it helps the speed.

-

Also, it is possible for other plugins to affect the loading speed.

We had a couple of cases with users who have an "optimization plugin" with specific settings, 

such as  'SiteGround Optimizer', for example.

These plugins have certain settings that can negatively affect the performance of our tables.

If there is any JS minification going on(disable those if possible),  there can be other settings, I can't say exactly, but something to be aware of.

If you wish to do troubleshoot testing to check if an optimization/caching plugin might be slowing down tables;

you can try to disable all plugins and just leave wpDataTables active - then clear all cache and reload the page, see if it loads faster.

Then, if any optimization plugin Is used, try to revert all its settings to default, and if you use server-side tables ( such as SQL or Manual tables) ,  then exclude the pages where you have tables from caching.

That is about all the advice i can give about this, but of course, let us know how it goes if you try to import your CSV files to make SQL Based/Manual Tables, then see how they perform, and if you have additional questions. 

Thank you

Hi Melanie,

My apologies, I will clarify that part.

So, when the number of rows combined on the same Page, goes above a size that makes your Page very slow;

you can then import the data from your CSV to make a new Manual Table.

Please check this Guide on how to import your CSV.

Just to go over how this functions one more time.

When you import the CSV file, the plugin reads the source file and creates a manual table. 

Once the table is created, it is no longer linked to the source file, so changing data in the table will not show up in CSV/Excel or Google Spreadsheet, and vice-versa. 

But this table now becomes fully editable in our Plugin.

For quicker editing, you can either switch to the Excel-like view, 

and then select and copy the range of cells you want to paste from the source file, and paste it in the Excel-like view, 

or you can import a new/edited CSV to update the table, as well, in the following ways :

Update manual tables: Replace data within an existing table.
or : Add data to an existing table.
or : Replace the entire table with new data.

You will also be able to build SQL Query based Tables out of this Data.

It is for a use-case if you wish to have one main Table for Admins to see/edit everything, and another SQL Table for the Front-End users which has some 'limitations' on it, etc.

But that is another subject, let me know if you wish to try that for another scenario.

Let me know if all of this makes sense. 

If anything is unclear, we will be here to answer any questions you may have.

Thank you.

Hi Melanie,

Firstly, about your Page crashing.

When your Page crashes, you can reach out to your Hosting Support and ask them to send you a full WP_DEBUG error report.

Then you can send us the report and we can try to tell you what might be the root of the crash;

you can also ask your Hosting Support if they can try to help determine what it could be.

You are most probably reaching over the limits of what your PHP Memory limit or PHP TimeOut limit is set on the Hosting Server, because all the rows are loading at the same time in the HTML of the Page.

To mitigate that, you can either ask the Hosting, if they can confirm the PHP limitations are being reached, to increase the PHP Memory and TimeOut settings;

or you can simply switch to SQL-based ( imported) Tables, and use our server-side processing.

Then, each table only loads one Table page at a time using AJAX calls, which decreases the server load.

1. In regards to handling large data sets and making the process easier:

Thank you for that feedback, we always do our best to add improvements over time.

At this time we are not able to make it easier than that.

There are simply some limitations in general coming from WordPress and from your Hosting Server, that is not related to our Plugin.

As mentioned, when your data set becomes so large to make the Page load too slow, ( usually when all rows are combined on same Page, when they reach over 5 to 6 thousand rows, that means all rows are loading in the Page HTML all the time;

compared to our server-side (SQL based) Tables, which only load one Table Page at a time using AJAX.)

Generally speaking, when we talk about slow loads :

The loading speed depends on a lot of factors – your hosting plan, server’s performance, amount of other data on the page, internet speed, etc.

For example, you can take a look at this SQL table on our documentation , which contains around 2.600.000 rows, and see how it loads. 

The more data the table has, the more chance that it will impact the loading time.

But switching to server-side processing is definitely going to have dramatically faster loading times than non-server-side processing.

2. About updating existing Manual Tables :

When you need to update it, you can just edit your source CSV and choose which way you need it to be, either just adding new rows to exising data in the table;

or completely replacing all rows;

or replacing the entire data structure as explained here.

3. In regards to this visual issue of your front-end Table looking different from the Back-end :

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

 This means that the table should look the same both in the back-end and in the front-end. 

If your front-end table looks and behaves differently than in the back-end, this usually implies that there is another plugin (or the current theme) that's changing the behavior of our plugin.

Can you please change the theme and see if the issue is resolved?

 If not, then please deactivate all other plugins except for our plugin, refresh the page where the issue is, and see if it is resolved (it should be).

 If it is, then start activating other plugins one by one, and after each activation refresh the page to see if the issue reoccurred. 

Once it does reoccur, you will have found the plugin causing the issue.

Let me know if you isolate a conflict with these steps.

Thank you.

Hi Melanie,

Please disregard just that last part, about the visual issue you have now.

After looking again at the screenshot comparison - I can see what the issue is.

You are using an Excel-Like View in this Table shortcode, this is why it loads that View, and on the Back-End you are using the "Standard Editor".

So just edit the shortcode of your Front-End version of this Table, and remove the part "table_View=excel"

Or, for example if you are calling our Table as a "Builder Block" like in WPBakery, then choose the "Regular wpDataTable" as the "Table view type", rather than "Excel-like Table".

You can check more details about our Excel-Like Editor in the hyperlink documentation i sent above;

it is basically used for quicker editing - but the standard View is what you wish in this use-case.

Let me know if that helps and if you encounter any further issue.

Thank you.

Hi Melanie,

Sorry for the waiting time.

We don't work on weekends so it adds two days to the waiting time.

we appreciate your patience.

-

Yes, in regards to the way how the rows are exported via our Table Tools, this is a limitation we have for the server-side processing Tables.

I am truly sorry to disappoint you, but in short, there is no ideal solution currently to have your table load quick and also to export all the rows via Table Tools at the same time.

In a way, this is something like a 'compromise' that is happening now in your use-case.

We will explain how all that works in more details to clarify :

1. For example, if you were to switch to a non-server-side Table, then all rows would be exported via Export Table Tools.

But then, your Page would load extremely slow, because then all rows will be loaded in the HTML of the Page at the same time, unfortunately.

2. Or now, when you have a server-side processing Table, our Plugin uses the AJAX ( Admin-Ajax) call to only load the rows from one table Page at a time, which reduces the hosting server load dramatically and makes it quicker to load;

but on the other hand, now the Table Export Tool is only pulling the rows which are loaded in the current HTML of the Page.

3. More detailed limitations on our Export Tools and how it works :

The table tools functionalities are based on a 3rd party HTML5 library and they are not customizable. Unfortunately, the library allows very little “fine-tuning” of the generated files, so font, size, and other properties cannot be changed.

There are some limitations in this library we will emphasize for your awareness:

• For tables with server-side processing, only the visible rows will be exported to any format. If you want the entire table to be exported (or copied to a clipboard), you need to choose the “Show All” feature in the “show … entries” block, and then do the export:

*just be aware, depending on the total number of rows currently in the table, switching this to "All" can cause a slow load in this moment when it loads all rows.

For example, I tried this now, to switch the "Show number of entries" on your Table to "All" and my browser page has frozen, I had to refresh the page to only see 25 rows.

This table has 7,133 rows at the moment in total, so the WP Page tries to load all of them in the HTML and your Hosting server is currently not able to handle this many rows on the same page at the same time.

You can only try to mitigate this by contacting your Hosting Support and try to increase the PHP Memory limit as much as possible as well as the PHP TimeOut limit, to try and somehow allow the Page to load more rows, but we can't say an exact limit, this depends on your Hosting Server and in generall, WordPress itself also has limitations.

• Generated PDF, XLS, CSV are not customizable. Unfortunately, the library allows very little “fine-tuning” of the generated files, so font, size, and other properties cannot be changed (but the title can – see below).
• Conditional formatting is not reflected in any of generated export files.
• Other front-end extensions cannot be combined with Table Tools. If you have row grouping enabled for the table, or there are some customizations you did yourself, they won’t be reflected in the generated Excel, CSV or PDF document, nor in the clipboard.
• When you export tables with the wpDataTables plugin, please note that you can export values, but not formulas. WpDataTables doesn’t support exporting formulas, so a Formula column will be exported only with values; and any calculations of Average, MIN, MAX, and Total will not be exported at all.
• Exporting images is not possible at the moment, but you are able to export them as HTML with the new “Include HTML” option.
• You can’t export columns that are hidden – they will not be visible in any exporting or printing tool.
• Export numbers with comma as decimal separators have issues in the Excel report. Please use the CSV export button or change column type to string for these columns.

-

If you wish better PDF export, our advice would be to acquire something like the WP Advanced PDF plugin, which offers a lot more options when creating PDF files from our tables, along with other content on your website.

Let me know if you have any questions.