Hi Mark,

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.

If you need the users to choose one or more filters such as a date range, and after they hit "search" to load only the data with the filtered results after that ( while also being able to still use the filters after the table loads), you can achieve this with our Powerful Filters Add-on.

It has a feature "Hide table before filtering" which can be used combined with "search" button;

Then a user needs to choose one or more filters, and only when they hit Search, the table will load only the filtered data.

Please check more about this functionality here.

Before purchase, you can test all Powerful Filters Add-on features on our sandbox site.

Let me know if that is what you intend to achieve, or if I misunderstood the use-case, and if you have any questions.

Hi Mark,

If you wish to limit the Data in the Table during the SQL table generation;

or in other words, to completely limit the returned data as described, like "from Date X to Date Y", you can achieve this with a Custom SQL Query and adding a "WHERE" statement for the date range there.

 A solution is possible with adding "VAR1" and "VAR2" for a Date Range in the SQL "WHERE" statement;

I just made an example test to see how it would work for a dummy table with some date Column, and here is my Query :

SELECT * FROM dummy_employees
where `birthdate` between '%VAR1%' and '%VAR2%'

Now, in the Placeholders Tab you need to input some 'default' values for the table generation.

In my example, i used dates 1970-07-07  and 1980-07-07 for VAR1 and VAR2 in the Table's Back-End on the Placeholders in order to have the back-end of the Table generate some initial data,

Now , the SQL query will just pull that date range as available values in the table back-end and also front-end.

In the Table shortcode, you will be able to change this range if needed;

For example if you need Page 1 to allow different date range in the table then Page 2,

where you can have the same Table Shortcode, just with different VAR1 and VAR2 values passed in the shortcode.

If you simply wish to allow users to then have filters available to change the Date range on the front-end 'on the fly' , just enable Filtering for this Date Column, set it to "Date Range" and you will be all set.

So basically, in the SQL Query and through Table shortcode you are setting the available data for the front-end;

and then you can still set up some column filters, so a user can come in to the filters and change them on the table.

They just won't be able to see 'beyond' the scope of the dates you set in your SQL Query with the "WHERE" placeholders/ or if you change them via the shortcode, etc.

Let me know if that was the goal, or if i missunderstood.

Thanks.

Hi Mark,

We don't have any way for a dynamic shortcode creation, if you mean something like an 'automated way'.

Each shortcode for our Tables has to be manually inserted on WP Pages.

You can see our Guide here which explains all the ways how you can add wpDataTables Shortcodes.

We have built-in/native integrations with some major Page builders, such as :
Divi Page Builder integration for wpDataTables;

Avada Page Builder integration for wpDataTables;

WPBakery integration;

Elementor integration on this page;

-

So during the manual inserting of your Table shortcode, you can add variables/parameters in your table shortcode, for example if we input a %VAR% in the Table Query;

then we first need to set a 'default VAR' value in the table back-end Placeholders settings.

As you can see, in my case i use these two as VAR1 and VAR2 for the default Date Range in the SQL Query.

Then, when you are creating your table shortcode to add it on the Page, you can insert different VAR values for different dates if you wish, so for example, for Page 1 you can set one Date range to load, and on some other Page you can load a different Date range, so any dates you set as VAR1  and VAR2 in the Shortcode parameters are going to then be ran in the Query :

Let me know if that clarifies everything and if you have any additional questions.

Thank you.

Hi Gabe,

I am sorry to disappoint you, but as far as I can see from my testing, you will not be able to use multiple values for our VAR Placeholder as inteded to be used for the "IN operator" like that.

 The way how our VAR Placeholders are designed, this is only used for a single value.

It can only accept one value per each VAR1,  or VAR2, and so on...

That is why, when you try as :

WHERE column1 IN ('%VAR1%')

In that case, our Plugin 'expects' you to only insert one specific value for that VAR placeholder.

On the other hand, if you use the "IN operator" with your Custom SQL Query and you specify the actual values like :

WHERE column1 IN ('ABCD' , 'EFGH' , 'IJKL')

In that case, it works, since you are manually providing the "IN operator" with the specific values you need for it.

Can you try like this maybe :

SELECT * FROM my_table 
WHERE column1 IN ('%VAR1%' , '%VAR2%' , '%VAR3%')

Then add some default VAR values in the Back-End at the Placeholders;

and try to insert it in the Table Shortcode like :

[ wpdatatable id=12 var1='ABCD' var2='EFGH' var3='IJKL']

Let me know if that works perhaps?

If you still can't find a solution, we can try to create some alternate workaround if possible, but for that, if you can please open a new ticket from your Ticksy account, you can just copy the main description of the use-case and try to summarize what you tried so far, etc, then we can follow up there.

When you have multiple questions or issues which are for different subjects/topics,

 please open a new ticket for each subject, and we will help/advise more effectively. 

In that way, issues and questions which are related to different subjects will be in separate tickets so other users or our support agents can find them easily. 

Our policy is to have one issue or question per ticket for the reasons described already.

Thank you for understanding.

Hi Gabe,

I am truly sorry, but I am not understanding all the details of your use-case.

We usually don't have such complex scenarios when it comes to filtering tables for specific users.

Usually, there is a field which is used to predefine one filter value for each user;

or for example, we have a feature request which is still being worked on by our devs as a future release;

where we would do something similar to how our "Limit each user to only see their own rows based on user ID", as on this Documentation;

just that this feature takes the 'currently logged user ID' and filters the table like that;

but these users want to allow a 'group of users' like 'currently logged User Role' to filter the table;

so we don't have the built-in feature for that yet; it can only be achieved with a custom SQL Query.

But your use-case here, it seems you are having a lot of rows to be used only to filter the data for one user and I am not understanding that scenario well;

so, we will proceed about this use-case on the new ticket you opened, since it is completely different from the original use-case on this ticket.

Thank you.

Hi Gabe,

My apology, just forgot to answer your question in the end.

As far as I am aware, there should be no character limit for our Placeholder variables;

but we did not test exactly how much characters it might be limited to;

but if you encounter any issue like that, please open a new ticket and we will do our best to advise as quickly as possible.

When you have multiple questions or issues which are for different subjects/topics,

 please open a new ticket for each subject, and we will help/advise more effectively. 

In that way, issues and questions which are related to different subjects will be in separate tickets so other users or our support agents can find them easily. 

Our policy is to have one issue or question per ticket for the reasons described already.

Thank you for understanding.

Hi Gabe,

Just a small follow-up.

We can confirm there is definitelly a character limit for value of placeholder VAR1.

So, we will proceed about your use-case and possible workaround solutions on your ticket, since it will become impossible to keep following up on this ticket, the subject from the original topic has been covered already.

Thank you for understanding.

Hi Gabe,

No problem, I found the new ticket and we will keep following up on it.

Thank you for opening the additional ticket.