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

Volker Wysk <post-hhF2Jplw28UoZk/[email protected]> Fri, 13 Jan 2023 17:40:39 +0100
Newsgroups	gmane.comp.cms.tiki.devel
Message-ID	<[email protected]>
Hi Jonny!

Am Freitag, dem 13.01.2023 um 12:33 +0000 schrieb Jonny Bradley via
TikiWiki-devel:
> Hi Benoit, Volker and all
> 
> That's some pretty impressive feature creep, 

I don't think this is feature creep at all. I feels like it will be more
elegant, more intuitive and easier to use than the way it is now. For both
the users and the developers of plugins.

If we had an exhaustive default for the list of plugins which should be
searchable, it would be less usable. We'd have long, unclear lists of plugin
names in the search configuration. It would be very hard to see where those
lists divert from the default.

When a new plugin is introduced, its searchability couldn't be easily
recorded in the search configuration. We would have to modify the lists. 

> i was going to just add that list:
> 
> > On 6 Jan 2023, at 11:57, Volker Wysk <post-hhF2Jplw28UoZk/[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.

Remember that this list isn't complete yet. It's the result of a short run-
through of the plugins.


> 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.

Hmmm...  A specific plugin knows what kind of text it has in its body, and
what happens to it when the page is rendered. Text that's translated to
visible text in the HTML page, should be searchable. Text that isn't should
be non-searchable.

The body of a non-searchable plugin shouldn't be searched, even when there
are searchable plugins inside of it - because the enclosing plugin knows
that the (entire) contents of its body aren't to be searched (because of
what this plugin does with it).

The body of a searchable plugin should be searched, except for non-
searchable plugins within.


> 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

I'm still volunteering for the task to add searchability-by-default info to
all the plugins.

Volker


> 
> 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

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
signature.asc (application/pgp-signature, 833 B)