Hello Connor.

Thank you for reaching out to us.

If I understand correctly, the current SQL was working fine until you added CSS to show 1 column 1 row table?

The single-cell shortcode should work quite well in this case, but if you still have the CSS in place, it may be conflicting with the single-cell shortcode, meaning the CSS may be targeting an old ID, which is now the single row value.

Can you please record your screen and show me what you're doing with the CSS and the single-cell shortcode?

Hey Connor.

Based on all this info, neither I nor our QA team can come to any conclusions. When we test the single-cell shortcode on our end, with MySQL query-based tables, it works well.

Please provide me a temporary WP-admin (administrator) user for your site where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue. 

We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties. 

You can write credentials here just check PRIVATE Reply so nobody can see them except us.

Hi Connor,

My sincerest apologies for all this waiting time.

1. Using the placeholder %CURRENT_POST_ID% with our Single Cell Shortcode :

I checked with our QA Team and sorry to disappoint you, but at this time, we do not have a valid solution via our built-in functionalities to use the %CURRENT_POST_ID% with the single cell shortcode.

If you wish to see a native option for this in the future, you can make a development suggestion, but we can't promise an ETA on it.

Please feel free to search on our suggestions page, 

 to see if someone may be already suggested this feature. If you can't see it, feel free to add your suggestion there,  and as more people vote, the feature will move higher on the priority list.

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.

If you have coding skills and wish to try to make a custom solution now,

you can check out our available hooks for Developers on this documentation and see if you can find any hook that might help.

We also added this new developer's handbook, which can allow users with coding skills to make custom add-ons.

Our developers will keep adding more custom hooks/examples there over time.

Please be advised that custom solutions with hooks are not included in our support.

You can also research resources such as Stack Overflow to see if any other user perhaps found a workaround.

( We do like to give examples for certain solutions, but for this use-case, we, unfortunately, don't have anything yet)

If our developers find a custom workaround for this specific use-case (Adding the "Current POST ID" in Single Cell Shortcode) soon, I will report back to share it with you, but please keep a lookout on the Developer handbook Page periodically as advised, they will keep adding more custom workaround examples there over time.

2. Would the Single Cell Shortcode be better for performance for your scenario (compared to SQL Queries with 1 row filtered) :

With the use-case you plan to achieve with the Single-Cell Shortcode, you will not gain any performance improvement when compared to the previous way of just using the one row SQL Tables;

because, when the Single Cell Shortcode is called, it will still call the data from the source SQL table and the underlying database.

In other words, the performance will still be the same, compared from, if you limit the filtered data only from the Query itself, or if you call the same table's data through the Single Cell Shortcode.

So if you add the WHERE in the Query with the "Current Post ID", then set any default POST ID value in the Placeholder settings (which exists in the table and from your Posts) to generate the table on the back-end;

then the front-end table is going to dynamically change to that Post's ID in the Table Query's filter.

3. The data being cached : You mentioned this at one point, as an idea of better performance.

It depends on what you mean exactly by caching.

If you mean to use our Plugin's 'cache' feature as per this Documentation - This is not possible for SQL based tables, because their data is stored in your SQL Database.

Or if you mean to use active caching on your Pages, you can do that only if you disable the SQL table's server-side processing as per my recommendation.

Otherwise, if you use active caching on a Page (via a caching Plugin for example), where you combine our server-side processing, you will periodically get 'invalid JSON response' issues on that Page and sometimes the table won't load.

If that happens, you can exclude any URL of page with table that has server-side enabled or completely disable caching on front-end;

or if you disable the server-side processing in the SQL table, you can use active caching on the front-end Page.

4. Difference how the Query is handled with or without our server-side option :

When the Server-Side is enabled, our plugin sends a more complex SQL Query and any time the table loads it sends an Admin-Ajax call to your Hosting server;

instead of when the server-side is disabled, it just simply filters the data just by the values already seen in the column and this will reduce the CPU load on the Hosting Server, because it does not send Admin-ajax calls so often from our SQL tables.

5. If you plan to make large source tables via SQL( more than 2 thousand rows), on the PHPMyAdmin side ( or via our Manual table) and in our Plugin's Table Query, if you pre-filter the data through the Query itself, then our Plugin will only pull that 1 filtered row.

If the source SQL data has not more than ~ 4, 5 thousand rows, you can 'get away' with disabling server-side processing on that table.

So, if your SQL query based tables are not bigger than 2.000 rows, you can disable server-side on SQL tables by default.

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 3188 you'll see this:

if (is_array($res_dataRows) && count($res_dataRows) > 2000) {

The lines of code can change during Updates because our Developers add new lines from time to time, so it is best to search for the line in any Code Editor with CTRL+F to get the right line.

You can change the number 2000 to a value bigger than the number of rows in your table in order to still have that 'toggle option' for server-side processing.

Another PHP file in this path :

../wp-content/plugins/wpdatatables/source/class.wdtconfigcontroller.php

In this file, please search for this, there should be two occurrences, first one around line 82 as :

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

And second one around line 143:

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

That will increase the server-side processing option automatic limit.

We just advise caution not to increase that number 'too high' to avoid going over the limit what your Hosting Server's PHP Limitations can handle.

Usually, up to around 5 to 6 thousand rows should pose no significant performance issues, but if you go higher than that data size without server-side processing, you could experience slow loading times.

You can certainly test to see how a Table behaves on front-end, and if it loads too slow/or freezes the browser's Page, you can go back in the Table's Back-End and enable server-side processing for that Table.

6. It can help performance if you additionally increase the PHP Memory limit.

As mentioned earlier, you currently have 256 MB - You can first make a test, if you can reproduce any Page crashing, request a full error report from the time of the crash from your Hosting Support from WP_DEBUG and the error should show more details, if it is perhaps "Memory limit reached" - then you can try increasing the PHP Memory limit on the Hosting server, that could mitigate the issue, but only up to a certain extent.

You can still go back to my previous replies and see if I added some additional useful details there - This reply was more like trying to summarize everything.

I will additionally speak with our developers - If they find any correction in my statements, I will report back right away to correct any wrong detail, or if we find a custom (better) workaround, we will also let you know.

I hope that helps.

Hi Connor,

Just a follow-up, our developers advised on a new custom way how you can achieve adding any of our dynamic placeholders, such as in your case the "Current POST ID" to the single cell shortcode.

When it comes to built-in 'out of the box' options, at the moment you can just pass the "%CURRENT_USER_ID%" placeholder in the Single Cell Shortcode.

The other placeholders are still not available as built-in/out of the box option as a parameter, but if you have coding skills or your own developer, we will share the advice by our developers how you can achieve this with a hook.

Our developers are working to add examples of these new hooks to the Developer's handbook Documentation, so please keep a lookout there periodically for new custom examples/hooks.

-

For now, here is an example they shared of a hook you can use with the placeholder of "%CURRENT_USER_EMAIL%", but you can use any other dynamic placeholder in the same way.

It would be something like this :

function filterColumnIDValue( $columnIDValue, $columnKey, $rowID, $columnID, $table_id){
    // For specific table id - in your case 1
    if ($table_id == 1) {
        // Filter for specific name of the column that contains unique values (origin header* of the column) - in your case 'Email'
        if ($columnID == 'Email') {
            // Filter for specific column ( origin header* of the column)- in your case 'recu' if this is the orig header
            if ($columnKey == 'recu') {
                if ($columnIDValue == '%CURRENT_USER_EMAIL%'){
                    $current_user = wp_get_current_user();
                    $columnIDValue = $current_user->user_email;
                }
            }
        }
    }
    return $columnIDValue;
}
add_filter('wpdatatables_cell_filter_column_id_value','filterColumnIDValue', 10, 5);

As mentioned on the Developer's handbook Documentation :

Filters (hooks) in WordPress are a type of callback function that can be defined by the user and are applied to certain values – strings, integers, objects, etc. It is a simple way to adjust code output without actually having to modify the code. Essentially, you add a given function on top of an existing one, to override the logic. Then, when the plugin is updated later, you won’t lose any of your changes.

You can get a detailed description of WordPress hooks here in WP Codex. In this section, we will go through all the filters available in wpDataTables.

Please note that using hooks requires a certain level of programming skills and included support refers only to advice.

I hope this could help as a custom idea of what you can try for the single cell shortcode filter.

Hi Connor,

1. I am happy to see you managed to create this custom workaround solution for the single cell shortcode.

Thanks for sharing it with us - I am passing it to our devs, they will take a look, it will be useful for updating of our documentation for developers in the future.

2. In regards to setting up a column filter for "current Post id" in the similar way/scenario, via an SQL Query based Table, here is a detailed example :

Please check if you set an existing Post ID from your WordPress to the placeholder of this table.

It is needed to be set in order to initially generate the table - then it will dynamically change on the front end according to the current Post ID.

Here is my Test example.  I choose any random post id from my existing Posts, and place it as this SQL Table Placeholder "current post id", just to be able to initially generate the table.

This is how my source data looks ( without any filtering):

Now i create this new SQL Query table :

select * FROM wp_wpdatatable_34
WHERE postid=%CURRENT_POST_ID%

You can easily check any Post ID by going to Posts > Edit a Post > And on top you will see it

I chose any existing Post ID, and set it in Table's Placeholders Tab as "Current Post ID" :

Then, if i open a Post with this table's shortcode, it is going to dynamically change, and it will filter the table by the current POST ID :

This is the front-end of the table loaded on that Post 279, it filters only the rows that match the value of the current POST ID :

Let me know if that helps.

Thank you

Hi Connor,

1. In regards to the scenario when you have a lot of SQL tables on the same Page, there is no way to avoid the data being called from the database, unfortunately, so you can only try to see with your Hosting provider - if your Page gets a "timeOut error", to increase the PHP TimeOut limit as much as possible;
   Or if you see a "PHP Memory limit reached" error - to increase the PHP Memory limit;
   but other than that, there is nothing which we can do from our Plugin's end.
   Our Plugin itself does not have any limitations for this, but WordPress in general and the hosting servers have their own limits of how much data can be loaded at the same time on a Page, etc, and especially, as you said, if multiple users load them at the same time.
   
   I will advise everything about 'slow load/page freeze/time out issues' and you can go through these to try and mitigate it as much as possible :
   
   

   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 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.

   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,  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.

    

   -

   Another thing to consider is how many 'Default rows per page' are set in the Display settings.

   

   Try setting this as low as possible and test if that improves performance for that table.

   I recommend it is best to use our new 'Custom rows per page', so if you allow front-end users to be able to use the dropdown for Rows per page on front-end, this will limit their options, to avoid loading 'All rows' and if you wish to get as much performance as possible, you can even remove the 100 and 50 options, or even 25 if that helps. 

   

    

   -

   Check if you have the "auto-refresh" enabled on the Tables.

   

    

   If you have a large number of tables and enabled this at a high frequency, such as every 5 or 10 seconds, then the Hosting Server will often make Admin-Ajax calls from the Hosting Server to the SQL Database to pull the data, which can increase the server's load.

   You can try disabling it and see if that helps.

   -

   Lastly, if you use an external Database connection ( not the default WordPress database), in some cases it can help the performance if you can move those SQL tables to pull them directly from the same DB where WordPress is on the Hosting server, so you can try that as well.

   -

   2. In regards to using any kind of filtering via our Single Cell Shortcode, such as with placeholders, I spoke with our developers again, there is a custom way with hooks.

   Here are more details :
   
   

When it comes to built-in 'out of the box' options, at the moment you can just pass the "%CURRENT_USER_ID%" placeholder in the Single Cell Shortcode.

The other placeholders are still not available as built-in/out of the box option as a parameter, but if you have coding skills or your own developer, we will share the advice by our developers how you can achieve this with a hook.
These hooks are still not added to the documentation since they are new, but our developers are working to add examples of these new hooks to the Developer's handbook Documentation, so please keep a lookout there periodically for new custom examples/hooks.

-

For now, here is an example they shared of a hook you can use with the placeholder of "%CURRENT_USER_EMAIL%", but you can use any other dynamic placeholder in the same way.

It would be something like this :

function filterColumnIDValue( $columnIDValue, $columnKey, $rowID, $columnID, $table_id){
    // For specific table id - in your case 1
    if ($table_id == 1) {
        // Filter for specific name of the column that contains unique values (origin header* of the column) - in your case 'Email'
        if ($columnID == 'Email') {
            // Filter for specific column ( origin header* of the column)- in your case 'recu' if this is the orig header
            if ($columnKey == 'recu') {
                if ($columnIDValue == '%CURRENT_USER_EMAIL%'){
                    $current_user = wp_get_current_user();
                    $columnIDValue = $current_user->user_email;
                }
            }
        }
    }
    return $columnIDValue;
}
add_filter('wpdatatables_cell_filter_column_id_value','filterColumnIDValue', 10, 5);

As mentioned on the Developer's handbook Documentation :

Filters (hooks) in WordPress are a type of callback function that can be defined by the user and are applied to certain values – strings, integers, objects, etc. It is a simple way to adjust code output without actually having to modify the code. Essentially, you add a given function on top of an existing one, to override the logic. Then, when the plugin is updated later, you won’t lose any of your changes.

You can get a detailed description of WordPress hooks here in WP Codex. 

Please note that using hooks requires a certain level of programming skills and included support refers only to advice.

I hope this could help as a custom idea of what you can try for the single cell shortcode filter.