Re: [Tiki-devel] A default for the list of plugins, whose bodies should be indexed

Hi all !

Thanks to everyone for your contributions. I have launched a request that
is already merged in Tiki Trunk (26.x). Here is the link
https://gitlab.com/tikiwiki/tiki/-/merge_requests/2532

This merge request is about the default indexing of the few plugins, those
that were on the list provided by Volker.


On Mon, 17 Apr 2023 at 23:28, Adrien Maloba <[email protected]> wrote:

> 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