Use of wpda_construct_where_clause filter in 3.5 Premium

Hi Charles,

Premium search is only available to premium users. Most users will use the free version and can still use your search filter. Your filter will continue to work for users of the free version.

Best regards,
Peter

Thanks Peter

My organization is using your premium version. (email ends in ogs.on.ca)

I’ll update my documentation to indicate the plug in doesn’t work with the premium version.

A follow up question. Is it possible for me, or you ;), to implement something like my plugin algorithm that works in the premium edition? I don’t think it would be needed for column search but for the main search box, yes.

Hi Charles,

So ogs.on.ca is you! ?? Great!

>>> A follow up question. Is it possible for me, or you ;), to implement something like my plugin algorithm that works in the premium edition?

Yes, that is possible! All your custom code will work in both, the free and the premium version. But you might need to give your code a higher priority for the premium version.

Good to know:
When you login to your premium version, you have access to premium support, which has a higher priority! ?? And a one to one contact form as well…

Best regards,
Peter

I am part of the OGS team. I do the custom PHP and other technical stuff.

I’ll test my filter plug in. Do you pass it the ‘custom’ search list? what about column? Just one column?

Hi Charles,

All searches within the plugin (Data Explorer, Data Publisher and Data Projects) are using the same filter logic. This is to maintain a consistent behaviour.

>>> Do you pass it the ‘custom’ search list? what about column? Just one column?

Sorry, I think I don’t understand your question. The plugin supports searching on specific columns using URL arguments. You can find the documentation here:
https://wpdataaccess.com/docs/documentation/data-publisher/adding-filters/
See section URL parameters. Is that what you mean?

Best regards,
Peter

I’m referring to this filter https://wpdataaccess.com/2020/01/29/filter-wpda-construct-where-clause-to-add-custom-search-behaviour/

These apply to when runing premium version.

what values are in the $columns parameter If the table has Define queryable columns?

what values are in the $columns parameter If it is a column search?

Hi Charles,

This is an array of table columns taken from this query:

SELECT column_name AS column_name, 
	 data_type AS data_type,
	 extra AS extra,
	 column_type AS column_type,
	 is_nullable AS is_nullable,
	 column_default
FROM information_schema.columns 
WHERE table_schema = %s
 AND table_name = %s
ORDER BY ordinal_position

The plugin does modify column_default a little. It is the same for the free and the premium version.

Does that make sense?

Best regards,
Peter

It makes sense about what is in the array but now, with the premium version, a user has the ability to define the columns that are queryable. Is the list in $columns modified to only include those columns? How will the filter know that an integer field, for example, can now be ‘searched’?

If this filter is invoked with a column filter request does the list only contain that column?

In both cases If $columns just has a full list of columns, how is the filter going to know about the premium options being used?

Peter, Forgive me if I’m missing something obvious and veing a pain.

Earlier in this thread you said

Yes, that is possible! All your custom code will work in both, the free and the premium version. But you might need to give your code a higher priority for the premium version.

I changed the priority to 1, the highest, and still my filter isn’t applied.
Here’s how I tested:

in all cases I use this test page https://ottawa.ogs.on.ca/thurso-1/

I disable premium and enable free
I typed in maclean annie in search box and I get results as either annie or maclean is found in the search.

I disable free and enable premium and repeat the test.

I get ‘no records found’ suggesting my plugin is not working as expected.

Help!!!

Hi Charles,

>>> How will the filter know that an integer field, for example, can now be ‘searched’?

If you implement your own filter and want to use the table settings, you need to read them. Something like this:
WPDA_Table_Settings_Model::query( $table_name, $schema_name )

This will return a json string, which you need to convert:
$table_settings_json = json_decode( $table_settings[0]['wpda_table_settings'] );

After that the search settings are in:
$table_settings_json->search_settings

>>> If this filter is invoked with a column filter request does the list only contain that column?

All columns are available in the array. Only columns that are disabled in Data Projects are not accessible.

>>> In both cases If $columns just has a full list of columns, how is the filter going to know about the premium options being used?

The filter does not know if it is in free or premium mode. It is the filter itself that makes the difference (uses table settings or not).

>>> I changed the priority to 1, the highest, and still my filter isn’t applied.

Can try to set it to 9? The plugin uses priority 10. Maybe 1 is to early… (I hope)

Hope this helps,
Peter

Thanks, I have work to do but know where to start.

But….

I tried a priority of 5 and a priority of 9 on the add_filter(…). Neither produced expected results.

How will the filter know it’s a column search and only generate a where for the expected column?

Charles

Ok, now I believe I understand your question! ??

A column specific search is performed with a URL parameter that equals the column name and has the prefix “wpda_search_”. For example:
wpda_search_last_name
would perform a specific column search on column last_name.

>>> I tried a priority of 5 and a priority of 9 on the add_filter(…). Neither produced expected results.

I’m gonna check this Charles! I’ll be back…

Best regards,
Peter

OK, I now understand that column search uses a query string in an URL for the search of a column. How does that, if it does, tie into the where clause filter?

Secondly, is this supposed to work from a browser or only in ajax. I tried
https://ottawa.ogs.on.ca/thurso-1/?wpda_search_family_name=maclean
and did NOT get what i get if I type maclean in the search family name box on the page.

• This reply was modified 4 years, 7 months ago by charlesgodwin.

Hi Charles,

>>> How does that, if it does, tie into the where clause filter?

Columns for which individual search is defined are added to the where clause, but this applies to to premium filter only! The free version does not use these settings.

>>> Secondly, is this supposed to work from a browser or only in ajax.

It works from the browser for all tools, except the Data Publisher. The Data Publisher uses ajax requests.

BTW, the free version allows individual column search through URL arguments as well. This is documented here:
https://wpdataaccess.com/docs/documentation/data-publisher/adding-filters/
And this works in the premium version as well! ??

Best regards,
Peter

OK.

Columns for which individual search is defined are added to the where clause

means the request is not passed through the

Filter (wpda_construct_where_clause) to add custom search behaviour

Not a problem at this point but it’s good to know.

• This reply was modified 4 years, 7 months ago by charlesgodwin.