Re: [Tiki-devel] A default for the list of plugins, whose bodies should be indexed
Adrien Maloba <[email protected]>
| Newsgroups | gmane.comp.cms.tiki.devel |
|---|---|
| Message-ID | <CAA83xJC7kpLKxrgoAP2ct-N61R12cWC7hS1PfMO2puvwfNK1xA@mail.gmail.com> |
I performed the modifications according to the suggestions. Please find the code here https://gitlab.com/adrienmaloba/tiki/-/commit/00d928814ff7c05c19b37e7e9ea34fff011f9bb6 At my level, I only have to modify the Plugins files according to the fact that they are searchable by default or not. My concern is to know the criteria determining the value of searchable_by_default. Thank you! On Wed, 12 Apr 2023 at 22:51, Benoit Grégoire <[email protected]> wrote: > On samedi 8 avril 2023 10 h 01 min 41 s EDT Volker Wysk wrote: > > > Am Montag, dem 03.04.2023 um 18:16 -0400 schrieb Benoit Grégoire: > > > > > Here is my thought: > > > > > - Add an option to each plugin (searchable="y|n"). Give the value > > > > > searchable="y" to all the plugins that we want to index by default. > > > > > > > > Please don't call it searchable, that was the name of the future > > > > "searchable" > > > > parameter in plugin syntax params, which is NOT the same thing. > > > > > > I don't find it confusing. Anyway, what about "searchable_by_default"? > > You wouldn't find it confusing that the plugin would receive: > > 1- A Boolean configuration parameter at the top level of the plugin info > array that determines if the plugin is indexed, barring any other > configuration. The one Adrien is about to code. > > Called "searchable" in your scenario. > > > 2- An object parameter one level down in the plugin info array (in > "params") that documents the usage and default values of a parameter > > Called "searchable" in your scenario. But NOT documenting the parameter > above. > > 3- The actual value of the parameter, in the $params argument of the main > function, possibly empty, representing if the page author wants the output > of that indexed for that specific plugin instance. Not the one Adrien is > about to code. > > In your scenario also called "searchable" > > > ? Maybe you wouldn't find it confusing, but I would think there is only > one parameter who's value I have to deal with! And on the oft chance I > notice or remember there is two, I'd have a hard time figuring out which > one of the two "params/searchable" is documenting/setting defaults for. > > > This sure is confusing. But we don't need all this, when we introduce the > > > "searchable" (or "searchable_by_default") setting for the plugin info > > > functions. We only need two settings which override the defaults. Perhaps > > > call them "include_plugins" and "exclude_plugins". Or "include_in_search" > > > and "exclude_from_search". Or whatever. > > When I'd read "include_in_search" I'd think that everything in the list > will always be included. At the very least, I'd think that it works the > same way as exclude_from_search. Neither is the case here, but since in > the early implementations it would effectively be, it would create even > more confusion or incorrect expectations in the future! > > > > So since the two of you seem to like searchable in every name, I propose: > > 1- Add "searchable_by_default" (name of a plugin info array key). Default > indexable value for that type of plugin. > > 2- Add "searchable" (name of a plugin syntax parameter representing the > desired indexability of a plugin instance) and "params/searchable" (plugin > info array key path that contains it's documentation/defaults). Adrien can > ignore that for now (probably I'll be the one coding it). > > 3- Keep but modify "unified_included_plugins" (name of a pref) We can't > change it's name without throwing away people's currently working list of > indexed plugins, unless someone volunteers to write a migration.) Makes > all plugins in the list act as if searchable_by_default was true. We can > name it's effective value something different inside the code (such as > unified_additional_default_searchable_plugins), but there is no need to > agree on it here. > > 4- Keep unified_excluded_plugins (name of a pref) We keep that one, it > prevents plugins from being indexed no matter the parameters of > searchable_by_default, searchable, OR unified_included_plugins. We need > this to globally disable plugins that prevent the indexing process from > finishing or otherwise damage the index, without destroying user > configuration for when a plugin is removed from the list. > > > None of this is academic. It should be pretty obvious that an author may > want: > > - To exclude a plugin (such as PluginDiv...) in one place, but include > another PluginDiv it in another place, on the same page. > > - To include the results of computations (such as a specific instance of > PluginList), but never all of them by default! > > -- > > Benoit Grégoire > _______________________________________________ > TikiWiki-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > _______________________________________________ TikiWiki-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel