Hi Charles,
At this time search works very basic. And yes, it does exactly what you wrote
column like '%<complete input string>%'
for every column of type string. Number and date columns are currently not taken into account.
Sorry, but that’s all there is right now. If you want to add your own logic, look at class WPDA_List_Table method construct_where_clause. That’s where it all happens…
Best regards,
Peter
I notice it only searches VARCHAR and ENUM fields, ignoring CHAR, TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT or is there some internal magic in WordPress.
How would you suggest I go about enhancing the method? I know I can replace the source code but that would last until your next update. Any other suggestions? I don’t see action or filter hooks.
Hi Charles,
I haven’t used any actions or hooks so far, but this sounds like an interesting experiment. What would you need to add your own search logic? Can you give me a hint? I can add it to the next release if you like.
Best regards,
Peter
Peter
I am working on a proposal for syntax for a better search.
I’ve thought a bit about how a hook / action would work and based on WordPress philosophy, I’m not sure. Perhaps a do_filter('wpda_contruct_where_clause', FALSE, $this->wpda_list_columns->get_table_columns(), $this->search_value, $pub_ID) and if you get FALSE back use your current routine, otherwise go with what you get.
Are there more than one contruct_where_clause methods, are they all the same?
Hi Charles,
There are four construct_where_clause methods in total, but your filter needs to be added to the WPDA_List_Table base class only. The other methods deal with relations and the data dictionary but inherit the base class functionality for a user based search action.
I’ll add a filter to the next release and let you know when it is available! 😊
Best regards,
Peter
Thanks. I’ve prepared a filter to just seperate each space delimited token and then construct a where clause of (column like ‘%token1%’ AND column like ‘%token2%” …..) OR (column2 like ….) …
I’d like to be ready to test as soon as you publish the next release. Two questions
1 can you give an estimate time for release?
2 can you tell me the planned parameters for your apply_filters(…..)
This is similar to WordPress, not identical. When this one works, I’ll get bolder
I will publish my filter when it works
Hi Charles,
The filter is already available in the beta version. You can download it from bitbucket to test it on a development machine. The name of the filter is construct_where_clause and it has two parameters: table columns and search value.
You find the code here:
WPDA::construct_where_clause( $columns, $search )
The filter is uese thoughout the whole plugin, so not only in the publisher. The explorer and projects are using the same filter.
I hope the release the next version next week or the week after. Let me know if you need help.
Best regards,
peter
Thanks
I look forward to it.
I’ll download the beta version but alas I don’t have a test machine so I’ll wait to execute. But I’ll be ready.
But I do have two thoughts about your filter. Both are just my ideas.
1 since the naming of WordPress items is undisciplined, there is always the possibility of conflicting names from different plugins. Have you considered naming the filter wpda_construct_where_clause to distinguish it?
2 I don’t have a need for this at this time but you never know. Could you add the schema name and table name as two more parameters in case someone want to develop table specific where clauses? Or something else to identify what is being “searched”.
Hi Charles,
1) I added the schema name and table name.
2) The name of the filter is: wpda_construct_where_clause. Sorry, I guess I pasted the wrong text… 🙈
Thanks!
Best regards,
Peter
Hi Charles,
Version 3 is out and supports the search filter you asked for. More info about the filter can be found here:
https://wpdataaccess.com/2020/01/29/filter-wpda-construct-where-clause-to-add-custom-search-behaviour/
Let me know if you need help.
Thank your for your contribution! 🙂 💪
Best regards,
Peter
Peter, it’s working. Thank you.
Once this search plugin is stable I will publish it as a GitHub repository. It’s not a lot of code.
Here’s an extract I sent to my users about my search algorythm.
You can enter multiple words or “tokens” in the search box. Separate the words with spaces. The search will examine EACH column in the database for the existence of all of the words. For example, if you type in the words john smith, it will check every column to see if it contains the value john AND the value smith. The search is case insensitive, i.e. JOHN is the same as john. The search doesn’t care about order. John smith is the same as smith john. The values can be contained in longer words. For example it will find john in Johnston and smith in Smithsonian.
If you really need to use a space as part of your search, such as le Moine, then enclose the word in double quotes. “le Moine”.
Great! 🙂 Thank you for adding functionality to the plugin. 😉
Have a nice weekend!
Best regards,
Peter
The problem with users is they are never satisfied. 😉
I’m back with more. Well, not really, as I did ask in my initial post in this topic. I asked these questions:
Does it search every field/column in the table?
Can you control/restrict the columns searched?
I have found the answer to the first and it is YES, all columns are candidates to be searched and the default is to search every string type column.
Now the other question, limiting the search to certain columns. Our site has tables with columns that are not shown in the published table for many reasons including privacy. But the current search may get a match in a column that is not displayed. This can be confusing and could be a breach of confidentiality, depending on the search.
The question is what to do about it? The new wpda_construct_where_clause filter in release 3.0 does provide the schema and table so a very customized filter could pick specific columns. But this solution has a limitation. There is only one filter but there could be many different views of the same table in either projects or publisher and each can have its own list of columns to show and it gets impossible to implement in the current filter.
A quick solution may be to add another parameter to the filter which is an array of the columns in the view. This would work for me but…..
Would it be easier if this functionality was embedded in the definition of a “view” as a field similar to Column Names (* = all) named, perhaps, Columns to search (* = all) and search for this view would search just this list of columns instead of all columns in the table.
I have no idea how complex this would be so feel free to add it to your to do list or ignore it.
My workaround for now is to create a view of just the columns I want involved in search / view.
Hi Charles,
Sorry for my late reply!
I have been experimenting in the table settings area with checkboxes to define whether a column is queryable or not. But I ran into the same issue. If you want to use a table in multiple queries, you want be able to define multiple versions of queryable columns. Using a view seems to be just the right solutions to me!
Best regards,
Peter
