Create a new API function: plugin_advancedsearch_$plugin. Two reasons: 1) eliminates legacy parameters, 2) allows plugins to support old search method and new search method for users who haven't moved to latest/greatest GL immediately. Remember, some users will upgrade a plugin that works on GL x and GL x+1. If GL x is older than your new search code, the plugin writer has a harder time dealing with the change.
For similar reasons, leave the Plugin class alone for backward compatibility with plugin_dopluginsearch_$plugin. Turning what the plugin returns into an array or using an object is just a style issue. If you go with a class please call it SearchCriteria since that is what is being returned. YMMV. Returning as an array is more PHP4 friendly but is that something we need to still worry about? I don't know.
Also, it would be nice if plugins could return multiple SearchCriteria objects. Remember my comments from when you started. Some plugins maintain more than one type of object. If you are going to take the list of SearchCriteria and UNION all the sql together:
The UNION idea has been dropped, after doing the testing it gave substantially longer execution times.
Can you name any plugins that maintain more than one type of object so I can see how to best accommodate them?
Would it be possible to provide a API function wrapper that would support older plugins calling the current search API - but calls the new API so we don't have issues with older plugins?
There are many plugins that still work just fine but are not actively supported.
This may not be an issue, if your also suggesting that you will be updating all known plugins
We really should not break existing API's or functionality with any new upgrades - that should be the last option we consider.
In theory the calendar plugin should search both events and personalevents when looking for matches. But it doesn't.
The current calendar plugin works with the new API.
Yes older plugins are supported, and have been since I started the project. The search page is backwards compatible.
The current calendar plugin works with the new API.
As I recall you have a large DB sample to run/test - so could you generate some screenshots showing:
- several plugins returning results in compatibility mode (as it is now)
- several plugins returning results in new search result mode only
- search results page with combination of older and newer search formatting returns
- plugin specific 'advanced mode - single plugin' showing newer api version formatted returns.
If there are several options for formatted returns - show us examples.
Here are the screenshots.
Why are the dates formatted without years? Is that your user's date format or is that format chosen by the search code?
When the description displays as "not available" is that because the plugin returned not available or returned an empty string and the search code put not available in its place?
The only irritating thing is the "not available"
The only irritating thing is the "not available"
The current calendar plugin works with the new API.
Having two identical tables just seems to me as bad design...unless there is something I'm missing here. Having everything in a single table will make the searching a lot simpler.
So far I am not convinced that the search API should handle multiple objects being returned, as it would just add unnecessary processing that should be avoided by having better designed tables and SQL statements.
I agree the screenshots looks nice. And regarding "nothing available" I would definitly want to customize that. Actually it makes most sense to me to show nothing at all (i.e. an empty string).
I also agree that a plugion should be able to return several different types of items. For example my FAQ plugin could be able to return FAQ entries and FAQ categories as different object. I also have a number of (currently) non-public plugins that definitly have more than one type of object since they handle different, but related things in the same plugin.
If you're rewriting the search API it feels like a pretty bad design limiting the each plugin to only one type of search item. It's almost as bad as if each plugin only could add one menu item to the admin/user menu...
But note that the first parameter in the setName(), in this case 'faq', must stay the same across all objects.
It would also be preferable if plugins use the same separator to distinguish the result sub group. As seeing something like this on the results page may not look that great:
Story
Comment
FAQ > Entry
FAQ > Entry
Calandar - Personal
Name -> Sub Group
So shall we say that if a sub group is going to be used then separate each item with the pipe character, 'FAQ|Entries', then a simple find and replace can be performed allowing the admin to choose the separator they want from the config pages.