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

Hi Benoit, Volker and all

That's some pretty impressive feature creep, i was going to just add that list:

> On 6 Jan 2023, at 11:57, Volker Wysk <[email protected]> wrote:
> 
> Here it is:      
> 
> attach,box,code,copyright,div,dl,fancylist,fancytable,file,files,font,footnote,indent,lang,list,markdown,mono,quote,scroll,sort,split,sub,sup

to the index exclude pref defaults, but i agree we can do this better probably.

One issue i foresee is nested plugins, what if you have a non-indexed plugin containing an indexed one? Plugin code rapidly gets quite complex sometimes.

Also, we still don't have a default/abstract class for all plugins, part of Project Fluffy which has never properly got off the ground (https://dev.tiki.org/Project-Fluffy - very stale experimental branch here https://gitlab.com/jonnybradley/tiki/-/tree/project-fluffy-2) This would make handling of common parameters that all plugin share more manageable i think...

However, we can always interpret `! isset($param['searchable'])` as meaning 'n' when parsing/indexing the plugin so maybe we can aim to do this for 26.x and even maybe 25.1 or 2?

Any volunteers? :p

jonny




> On 12 Jan 2023, at 22:17, Benoit Grégoire <[email protected]> wrote:
> 
> On vendredi 6 janvier 2023 18 h 31 min 57 s EST Rick Sapir wrote:
>> > To provide additional flexibility, would it be useful to have this
>> > option on each plugin, that would override the global include/exclude list?
>> > 
>> > For example:
>> > 
>> > {DIV(searchable="y|n").....}
>> > 
>> > and the plugins noted by Volker could default to "y" (and the other
>> > plugins to "n").
>> > 
>> > And this would work as an override to the global include/exclude list.
>> > Just a thought....
> 
> Actually, that makes a LOT more sense to me than a global include/exclude list which I would think rarely makes sense globally except to exclude a buggy plugin that screws up indexing.
> 
> Volker's list illustrate the need for a default.  
> 
> And yes, as a first step indexing plugins that just modify output markup, and take plain text as a body makes a lot of sense.
> 
> But answering the question "do we want to index this by default" for a specific plugin type requires a bit more than that.
> 
> A) DO we want to index content from all instances of the plugin by default?
> 
> 1- Yes (ex:  Any pure markup plugin (ex: PluginDiv, PluginMarkdown), any plugin that potentially nests other plugins (ex: PluginTabs) 
> 2- No (ex:  Probably any plugin that retrieves content elsewhere in Tiki or over the Net)
> 3- Never, even if the user requests it (ex:  PluginGoogleAnalytics, PluginWYSIWYG (Plugin where neither the  data or output makes no sense to index), PluginRandominclude (Plugins where the data is never specific to the page).
> 
> The reason I didn't put a "Always" is there is that I believe the user would expect the behaviour of searchable/notsearchable to be recursive.  Erroring-out if the plugin is "Never", but recursively not index if one passes "notsearchable" to a parent plugin in the page. Disabling indexing on specific content is something the user could want to do for a number of non-technical reasons.
> 
> B) WHAT do we want to index?
> 
> 1- The body?  That the body of the plugin is expected to be raw text is a bit of an exception...  
> 2- The page output? Sometimes, but the output may depend on the user, or other context.  
> 3- Some different output? Likely to be the usual case (ex:  convert to plaintext, disable pagination, extract some summary data, etc., )
>  
> -- 
> 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