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

> > I tried and obviously failed repeatedly to explain it clearly enough in
> > prose.   I think it's clearer in the code:
> > https://gitlab.com/tikiwiki/tiki/-/blob/master/lib/core/WikiParser/Parsabl
> > e.php#L168
> I don't get it.
> 
> I'm NOT saying that it is symmetric the way it is now. I'm saying that it
> could (and should) be made symmetric easily.
> 
> I would do it like this: Each plugin gets an "searchable_by_default"
> parameter, which is set in the plugin's info function. This should probably
> default to "no". Two settings are added, "include_in_search" and
> "exclude_from_search". They contain a list of plugin names and override the
> "searchable_by_default" parameters. An optional "searchable" parameter to
> all plugins, as specified in the wiki pages, is added. It overrides both
> "searchable_by_default" and "include_in_search"/"exclude_from_search".
> 
> That's all that is needed. I find it easy to comprehend.

No, it is not all that is needed!  

This is getting ridiculously time consuming.  Trying one last time.

First, let's say we are in a hypothetical situation where we:
1 - Rename every preference to a coherent name (style doesn't matter, as long as it's 
coherent so we can talk about the same thing)
2 - Someone writes a migration for every piece of data that we need to keep, so we don't 
care about past preferences
3 - We add every possible setting or preferences, good idea or not

We end up with:

* unified_exclude_all_plugins (a pref):  Don't try to index any plugin at all. Status: we now 
removed this.

* searchable_by_default (a static code parameter for each plugin): 
Status: we now implemented this.

* unified_force_disable_plugins (a pref):  
Status: was already implemented as unified_excluded_plugins, we didn't change the 
name or behaviour.

* unified_force_enable_plugins (a pref):
Status: we now removed this.  No one provided a case for it, and it's dangerous.  Former 
behaviour of unified_included_plugins

* unified_additional_default_enable_plugins (a pref):
Status: we now implemented this.  Implemented as the new behaviour of  
unified_included_plugins, because we needed to keep the data on user's server (if it 
contained data, it's the plugins they wanted indexed, as that was the only way to do so 
before), and didn't have time to write a complex migration.

* unified_additional_default_disable_plugins  (a pref):
Status:  Not implemented.  No one (including you) provided a likely case for it now that we 
have searchable_by_default.

* searchable (a plugin syntax parameter):
Status:  Not implemented yet, but we plan to, probably as part of the plugin syntax 
rework for relationships.  Conceptually very simple to implement, we'd accept and refine a 
patch for it if it arrives before.


Now, in your email above you want a exclude_from_search, whose behaviour matches 
unified_additional_default_disable_plugins the symetric of the implemented 
unified_additional_default_enable_plugins.  I don't see much of a need for it, but 
presumably you have one.  If someone submits a patch I wouldn't try to veto it.

On the other hand I say keeping unified_excluded_plugins, whose behaviour matches 
unified_force_disable_plugins is essential.  But nobody asked or provided a case for the 
unimplemented symetric unified_force_enable_plugins.  unified_force_disable_plugins is 
crucial to the integrity of production systems in case of buggy plugins, especially now 
that we don't have unified_exclude_all_plugins.  Keeping unified_exclude_all_plugins was 
not realistic, as now that there are plugins indexed by default by searchable_by_default, 
enabling unified_exclude_all_plugins would materially break people's search in hard to 
predict and impossible to control ways. 

So what do we do?

I like symmetry as much as the next guy, but to get it we'd have to double the number of 
list type preferences for this feature (from 2 to 4), 2 of which nobody provided real use 
cases for.  I don't think that's what you want.

We do have pretty bad naming because:
 - no one has time to write a complex migration, that's time better spent implementing 
"searchable"
 - we didn't really agree on a naming, and yes, the lack of symmetry makes it more 
difficult to have short names. 

Aside from that, the feature was implemented EXACTLY as you described in your email, 
except that
 - Your exclude_from_search (unified_additional_default_disable_plugins) was not added
 - We kept unified_excluded_plugins (unified_force_disable_plugins)

_______________________________________________
TikiWiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel