Hi John,

I just did some tests with our dummy SQL Tables and I can confirm this works, our SQL Parser allows the LIKE operator.

Just make sure to 'wrap' your value inside quotes, like this, for example, you can try on our Demo Table 1 on this back-end Page :

https://sandbox.wpdatatables.com/wp-admin/admin.php?page=wpdatatables-constructor&source&table_id=1

Try the Query like this, to filter the 'firstname' column as any names which contain the letter m as part of the value, like :

SELECT * FROM dummy_employees
WHERE firstname LIKE 'm%'

Let me know if that works for your use-case/ table.

Thank you.

Hi John,

My apologies, I just made a typo there and edited the Query, now it looks like this :

SELECT * FROM dummy_employees
WHERE firstname LIKE '%m%'

So now the LIKE operator is actually doing what it's supposed to on that Table :

As mentioned, you can test this on our Demo SQL Table #1 back-end and see how it works;

then try to implement it in the same way on your table;

Let me know how it goes and if you encounter further issues.

Thanks.

Hi John,

I am glad to see it initially worked, at least to show the data in the table as expected.

Now, to the new questions :

1. As a small aside, is there a way to make table rows have a CSS height, (odd and even classes)? I tried with CSS but it doesn't seem to work.

-

If you just need to manipulate the row height for the cells data,  not including the Header row,

you can try this CSS :

table.wpDataTable tr > td {
    height: 300px !important;
}

You can choose either "line height" property, or "pixels" for the height and see what is best for your use-case.

If you need it just for one table, add it to table's settings/Customize/Custom CSS,

or if you need same style for all tables, add it to main plugin settings/Custom JS and CSS/Custom CSS.

-

For the header row, you can use this selector :

.wpDataTablesWrapper table.wpDataTable thead tr th {
  
  line-height: 4 !important;
 }

And that will affect the row height of the header row, too.

If you have multiple Tables on the same Page, and you wish to 'target' a specific Table ID with CSS, you can add the table ID like this :

table.wpDataTable.wpDataTableID-1 thead tr th { 
   line-height: 6 !important;}
table.wpDataTable.wpDataTableID-1 tr > td { 
   height: 300px !important;}

Just make sure to change the "1" to your Table ID.

So, you can try with either line-height or with pixel height, and see what works best for your use-case.

When it comes to odd having one height and even row having another height :

For the 'odd rows', you can do :

table.wpDataTable tr.odd td {
    height: 200px !important;
}

For only targetting 'even rows', you can do this selector :

table.wpDataTable tr.even td {
    height: 120px !important;
}

3. For not being able to properly filter with the "LIKE" operator, it might take some time for our end to test to create the same use-case as you did in order to determine the behaviour.

It could help us to save time if you already have this setup on your own table so if we can make a duplicate from your table on your Site and to investigate it remotely, it can help us to copy what you did quicker and to isolate it.

So could you please first record a Video of your screen to show us the steps, how the filtering issue happens;

and if you have another duplicate of the same SQL Query, only without the "LIKE", how that behaves differently?

If the Video gets too large, you can upload it to weTransfer and send a download link.

And please make sure to send this in a PRIVATE reply, just to be safe, since you will be showing us the details of your back-end setup, etc.

Let me know if that sounds OK and if you can send us the Video.

Then if you can send me the URL of the Site and Administrator User credentials so we can try to isolate it on your Site;

and we can try to reproduce a similar setup here to see if it is a bug or just a current limitation of our filtering with the SQL Parser, etc.

Thank you.

Hi John,

Thank you for the Video, I can now see how it happens on your Page.

If I see it on the video correctly, it seems that the Table is hiding correctly on the Back-End before filtering and it is somehow not hidden only on the front-end Page when you add that "LIKE" in the Query?

-

When I tried on one of my SQL Tables, I used the same 'method' to use the LIKE and to filter on a current POST ID from the Page, but I was not able to reproduce any issues.

Please download my Video here, you can see how it works for us to add the "LIKE" in the Query along with the Placeholder Current Post ID and on our Page, the table is properly hidden.

- Can you try removing the "ORDER BY" part of your Query, and check if that helps?

- If not, can you try what happens if you disable 'server-side processing' option?

Our goal is to isolate what seems to be causing that strange behaviour of not hiding the table before filtering on your end.

If you still can't isolate it, can we take a remote look?

Please provide me a temporary WP-admin (administrator) user for your website where this happens, 

as well as FTP credentials and access to the database ( either link with credentials for PHPmyAdmin, or access to Hosting Panel),

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.

And please send me the URL of the Table's front-end Page.

Thank you.

Hi John,

My apology for the delay.

We are investigating this now, and I will advise you when we check all the details.

I am able to log in as Admin and going to check both tables, pages and all the details with tabs as you advised on the second Page.

We will report back with an update as quickly as possible.

Thank you for your patience and cooperation.

Hi John,

Thank you for these updates from your end.

I can see this is turning out to be a much more complicated issue than it originally seemed, unfortunately.

My apologies for all the waiting time, we will do our best to try to isolate it with your updates and the details as described.

As soon as we check everything, we will report back as quickly as possible.

Thank you for your patience and cooperation once again.