Hi Alfred,

My sincerest apology, we had some big issues with this ticketing system, some tickets got marked as 'replied' when they did not get a reply and we did not see it.

It seems it is resolved now, but if any long waiting time reoccurs, please don't hesitate to contact me on my work Email [email protected] and you can just send me the link to the ticket, so we can double-check it if needed.

We will add another support system as soon as possible.
Thank you for all your patience.

Can you please provide us with more details when the issue happens?

- So as you said, this seems to not happen for smaller tables.

- Can you confirm, what is the table type, is it linked from a file, or are you trying to import a file to make a Manual table?

- If it's linked to a file, how many rows it has?

- The most common cause for this error can be, if the table takes too long to generate ( the request towards your WP hosting server) and you reach a "time out limit".

This is not a limitation of our Plugin, but rather of how your hosting server is configured and WordPress itself can have a limitation for a max number of rows, etc.

If you use a source file, can you please send me your data source and we will check if the issue is perhaps coming from the file itself?

You can send me an Excel/CSV file with your data set, either wrap it inside a zipped file or upload to weTransfer and send me a download link.

If it has any sensitive data, just ensure to mark the reply as PRIVATE, then only we can see it.

And can you confirm, when you are creating a Table from this data set, I presume you are choosing "Create a data table linked to an existing data source"?

Can you please tell me how many rows does the source Sheet have?

For example, if it has more than around 5 to 6 thousand rows - you might be reaching the current PHP limits of the Hosting Server ( such as PHP timeOut limit).

When you try to link a Table from a source file like a Google Sheet/CSV or Excel;

during this process, the plugin needs to read the entire data set coming from the spreadsheet for the initial table creation.

For this, it takes a certain time interval ( depending on how large the data set is).

So, what you can try is to increase the max_execution_time and max_input_time ( or in other words, to increase the timeout limit in php.ini file),

This way, it should prevent the table creation wizard from breaking until the table is generated.

-

When the table successfully generates on the back-end, if you wish to have improved performance, you can try enabling our cache and auto-load cache , in the table settings, 

but the plugin needs to have enough time for the server to process everything/ to read the full data set of the spreadsheet and table.

-

If you want to check what is the current configuration, you can do this from our Plugin's Dashboard, in System Info Tab.

And check the PHP Memory Limit.

 If it is only 128 MB, we recommend increasing it to at least 256 or 512 MB which should be enough for most websites ( depending how many other Plugins and data you plan to have on the site, etc).

Let me know if that helps.

Or, if your file goes over 6 thousand rows, then the best choise is to switch to importing this data to an editable/SQL based Table.

 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.

Let me know if that helps.

Hi Alfred,
- In regards to the Excel sample you sent - Yes, this file has too many rows for it to be imported/uploaded directly via WordPress (more than 30 thousand rows).
This is a limitation combined between WordPress and the WP Hosting server's PHP Limits.

But I can see you solved it - We presume you imported this directly to your Database, then called an SQL Query table from it like : SELECT * FROM imported_Table_Name

Or by using our "SQL Query helper tool" and picking your table from the DB table list.


2. In regards to the issue of sorting/filtering not working for SQL Query tables which have server-side processing :

Yes, this is a known issue, we have some limitations due to our SQL Parser. It depends how you made a certain custom Query, if there is something that disrupts our Parser when server-side is enabled.

Here are more details on that, in case if this filtering/sorting issue reoccurs with any other SQL Query table which has server-side processing :

On this documentation, there are more details which explain how our server-side processing works :

https://wpdatatables.com/documentation/table-features/server-side-processing/.

Basically, when the server-side is enabled, the wpDataTables will give the search results through the Query;

So, our Plugin sends the Query to the database.

If that Query is formatted as

 "SELECT ...

 FROM ... 

WHERE... "

but after the "FROM" if it has any complex Query, there can be errors with sorting/filtering/table search;

Our SQL Query feature does not work in the same way as a Database Management Tool ( such as PHPMyAdmin and similar),

and is not meant to be used as one;

Our logic is based on a PHP SQL parser which has full support for the SQL dialect for the following statement types

SELECT, INSERT, UPDATE, DELETE, REPLACE, RENAME, SHOW, SET, DROP, CREATE INDEX, CREATE TABLE, EXPLAIN and DESCRIBE.

Some of them are disabled for security reasons.

Filtering, sorting, and search may not work properly if you include:

• Accent graves ( ` ) around the table name
• JOIN functions
• UNION functions
• CONCAT functions
• sub-queries

-

So, first you can check for accent graves around the table name, if you have this, remove it...

Then, see if you used CONCAT to create any column.

If so, go into this column setting, and disable it from "global search" in the Filtering tab.

-

-

If none of that helps,

you can try preparing a MySQL view (which will return the data that you need, call it e.g. “view1” and then build a wpDataTables based on a simple query like "SELECT * FROM view1″.

 If you need help with that, you can see our video, where we show an example of using View in our plugin.

-

To summarize, it can happen that a specific complex Query might work in PhpMyAdmin but struggles to work perfectly for sorting/filtering through our server-side processing ( and the SQL Parser);

So when the Server-Side is enabled, our plugin sends a more complex SQL Query which in this case is too complicated for our Parser to handle,

instead of when the server-side is disabled, it just simply filters the data just by the values already seen in the column.

I hope that this helps to clarify everything.

So to solve this particular issue, there can be multiple ways :

1. You can try to simplify your SQL Query in order for our server-side processing to work;

2. Or try to make an SQL VIEW in your Database, then call it in our SQL Table like : SELECT * FROM ViewName

3. Or if you can make it work without server-side processing, if your data/number of rows of  the table does not become too large, let's say above 4, 5, 6 thousand rows,  and if the hosting server performs well,

you can 'get away' with disabling server-side on the table.

 If your SQL query based tables are not bigger than 2.000 rows, 

you can disable server-side on SQL tables, and it will work like it does for Excel tables. ( loads all rows regardless of pagination)

If you need to increase the row count while still having the "toggle" to disable server-side,

Please go to ../wp-content/plugins/wpdatatables/source/class.wpdatatable.php and around line 2176 you'll see this:

if (count($res_dataRows) > 2000) {

You can change that number to a value bigger than the number of rows in your table.

Same should be applied in ../wp-content/plugins/wpdatatables/source/class.wdtconfigcontroller.php on lines 53:

if (count($wpDataTable->getDataRows()) > 2000) {

And line 100:

if (count($wpDataTable->getDataRows()) > 2000) {

That will increase the server-side automatic limit.

I hope this helps.

3. Master Data table display problem (%field% showing instead of data).
Yes, this is a known bug we have. We still don't have a fix, but our devs are doing their best to fix it as soon as possible.
You can follow our ChangeLog during updates, so when it's added, we will make a patch note.

For the time being, it is as you are doing - You can only try to insert an empty/white space, because the Master-Details will 'regard' this as an actual value in the cell, rather than being completely blank.
When a cell is blank, then, unfortunately that bug happens, when it renders the %field% instead.


I hope this helps at least to clarify some points, or to help with future issues, but we can see you solved this, so we can consider it solved for now.

Thank you.