Item15172: RenderWikiApplicationWebHome does not list all topics

Priority: Normal
Current State: New
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: WikiWorkbenchContrib
Reported By: BramVanOosterhout
Waiting For:
Last Change By: BramVanOosterhout
-- BramVanOosterhout - 09 Jan 2023 Applications.RenderWikiApplicationWebHome is meant to list all topics relevant to an application if the ?q= parameter is not supplied. The current implementation does not list any topics. This caused by line 45:
  query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="topic='.*'"}%"

The topic parameter is not valid as part of a query in a DBCache context. I believe the correct query is:
  query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="TopicType=~'.*'"}%"

The following patch fixes the problem.
--- a/data/Applications/RenderWikiApplicationWebHome.txt
+++ b/data/Applications/RenderWikiApplicationWebHome.txt
@@ -1,4 +1,4 @@
-%META:TOPICINFO{author="ProjectContributor" comment="" date="1556788680" format="1.1" version="1"}%
+%META:TOPICINFO{author="BramVanOosterhout" comment="" date="1673256078" format="1.1" reprev="2" version="2"}%
@@ -42,7 +42,7 @@ See the [[CompleteDocumentation]].
   class="foswikiFlatTable foswikiStripes"
-  query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="topic='.*'"}%"
+  query="%IF{"'%URLPARAM{"q"}%'!=''" then="TopicType=~'%URLPARAM{"q"}%'" else="TopicType=~'.*'"}%"

That's not correct. We want to list all topics, not only those with a TopicType. The topic parameter is indeed very valid.

A better fix is to remove the else part all together.

-- MichaelDaum - 09 Jan 2023

Tried that

removing else="TopicType=~'.*'" gives strange results. Some topics are omitted from the list. This:
  class="foswikiFlatTable foswikiStripes"
  query="%IF{"'%<nop>URLPARAM{"q"}%'!=''" then="TopicType=~'%<nop>URLPARAM{"q"}%'"}%"
produces 8 pages of results. Page 1 shows results 1..8, Page 2 15..19, Page 3 22 .. 30, etc... It appears some results get lost altogether.

Two rhetorical questions: 1. if topic is a valid query parameter, why does it not work? 2. why such weird results if the else is deleted?

Could the problem be in JQDataTablesPlugin? Let me investigate. .

-- BramVanOosterhout - 10 Jan 2023

I did some investigation and the conclusion is:


The problem is between the seat and the keyboard frown, sad smile

Question: Can I add connector="dbcache" to the RenderWikiApplicationWebHome DATATABLE parameters. The WikiWorkbench requires DBCachePlugin anyway.

Re: the missing entries in the displayed list: that is a feature. Topics without a FORM are skipped, but the index is incremented regardless.

Long answer

the connector

Analysis: The wiki workbench is shipped with the DATATABLES query:
query="%IF{"'%<nop>URLPARAM{"q"}%'!=''" then="TopicType=~'%<nop>URLPARAM{"q"}%'" else="topic=~'.*'"}%"

The query is connector specific (dbcache) in the topic=~'.*'" part. The JQDataTablesPlugin installation sets the default connector to search (Well I did).

And topic=~'.*'" returns no result with the search connector.

So no bug.

The fix for me is to add the connector="dbcache" to the DATATABLE in RenderWikiApplicationWebHome, since I have used the DATATABLE default connector in many other places, with the associated query SEARCH.

Adding the connector to the RenderWikiApplicationWebHome DATATABLE parameter list in the distribution would avoid the confusion for other users. Here is the patch:
diff --git a/data/Applications/RenderWikiApplicationWebHome.txt b/data/Applications/RenderWikiApplicationWebHome.txt
index a5f2b3c..7051521 100644
--- a/data/Applications/RenderWikiApplicationWebHome.txt
+++ b/data/Applications/RenderWikiApplicationWebHome.txt
@@ -1,4 +1,4 @@
-%META:TOPICINFO{author="ProjectContributor" comment="" date="1556788680" format="1.1" version="1"}%
+%META:TOPICINFO{author="BramVanOosterhout" comment="" date="1673657914" format="1.1" version="4"}%
@@ -43,6 +43,7 @@ See the [[CompleteDocumentation]].
   class="foswikiFlatTable foswikiStripes"
   query="%IF{"'%<nop>URLPARAM{"q"}%'!=''" then="TopicType=~'%<nop>URLPARAM{"q"}%'" else="topic='.*'"}%"
+  connector="dbcache"
Alternative: Add a note in the description that says: The query used in the DATATABLE requires the dbcache connector. If this is not your default connector (set in config JQDataTables), you need to make it explicit here with connector="dbcache"

The missing entries in the listed topics

Analysis: The missing entries are related to topics in the web that do not have a FORM associated with them. Specifically:
No formdef: Topic=WebAtom
No formdef: Topic=WebChanges
No formdef: Topic=WebLeftBar
No formdef: Topic=WebLexiconTemplate
No formdef: Topic=WebLinks
No formdef: Topic=WebNotify
No formdef: Topic=WebPreferences
No formdef: Topic=WebRss
No formdef: Topic=WebSearch
No formdef: Topic=WebSearchAdvanced
No formdef: Topic=WebTopicEditTemplate
No formdef: Topic=WebTopicList
That makes sense, because there are no fields other than Changed to display.But it is weird that the numbering is not adjusted.

Investigation: Topics without a form definition are skipped in - convertResult (line 188).

For a freshly created app DBCacheConnector search returns (line 408)
  • Total 26
  • Total filtered 26
  • Entry count in @data 17
The display from RenderWikiApplicationWebHome contains 17 entries numbered 1 .. 26. Nine entries( 13, 14, 15, 17, 18, 20, 21, 23,24) are missing.

The rowNumber is set in - convertResult (line 223) as $params{index}.

$params{index} is set to $index in a loop over all matched topics. $index is incremented for each topic. (DBCacheConnector line 389)

And so each $row goes up one number. However...

... since convertResults skips topics without FORM and therefor does not increment $count, convertResult will return undef for these topics (line 388). In turn these non-rows are not pushed to @data (DBCacheConnector line 402). But the index is still incremented.

Question convertResults deliberately removes topics without a FORM. Should it?

If so, the index needs to be adjusted.

If not, the non-FORM topics should not be skipped.

Which way should it be?

-- BramVanOosterhout - 14 Jan 2023
Topic revision: r4 - 14 Jan 2023, BramVanOosterhout
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy