Page MenuHomePhabricator

Page Forms: "values from query" no longer works with SMW 3.1.5
Open, Needs TriagePublic


This issue was orininally reported on GitHub for SMW.

Setup and configuration

  • SMW version: 3.1.5
  • MW version: 1.3.3
  • PHP version: 7.3.11-1~deb10u1 (apache2handler)
  • DB system (MySQL, Blazegraph, etc.) and version: 10.3.17-MariaDB-0+deb10u1


[fe42c27fc7e153154b6b1a45] [no req] Error from line 782 of /var/www/html/wikiname/extensions/PageForms/includes/PF_ValuesUtils.php: Call to undefined method SMWQueryProcessor::processFunctionParams()

When im using the "edit with form" option or i am trying to create an entity with a form im getting an error in the PF_ValuesUtils.php (PageForms). I was able to identify the error. I am using tokens for the input (which are replacing 'two listboxes') and localized the problems in the 'values' part:
{{{field|fieldName|input type=tokens|default=X|values from query={{#ask:[[Category:XCat]]}} }}}
When im removing the line it works well. After downgrading SMW from 3.1.5 to 3.0.2 the error is gone.

Stack trace

#0 /var/www/html/wikiname/extensions/PageForms/includes/PF_ValuesUtils.php(574): PFValuesUtils::getAllPagesForQuery(string, integer)
#1 /var/www/html/wikiname/extensions/PageForms/includes/PF_FormField.php(336): PFValuesUtils::getAutocompleteValues(string, string)
#2 /var/www/html/wikiname/extensions/PageForms/includes/PF_FormPrinter.php(1058): PFFormField::newFromFormFieldTag(array, PFTemplate, PFTemplateInForm, boolean)
#3 /var/www/html/wikiname/extensions/PageForms/includes/PF_AutoeditAPI.php(901): PFFormPrinter->formHTML(string, boolean, boolean, integer, string, string, NULL)
#4 /var/www/html/wikiname/extensions/PageForms/includes/PF_AutoeditAPI.php(115): PFAutoeditAPI->doAction()
#5 /var/www/html/wikiname/extensions/PageForms/specials/PF_FormEdit.php(104): PFAutoeditAPI->execute()
#6 /var/www/html/wikiname/extensions/PageForms/includes/PF_FormEditAction.php(310): PFFormEdit->printForm(string, string)
#7 /var/www/html/wikiname/extensions/PageForms/includes/PF_FormEditAction.php(32): PFFormEditAction::displayForm(PFFormEditAction, Article)
#8 /var/www/html/wikiname/includes/MediaWiki.php(511): PFFormEditAction->show()
#9 /var/www/html/wikiname/includes/MediaWiki.php(302): MediaWiki->performAction(Article, Title)
#10 /var/www/html/wikiname/includes/MediaWiki.php(900): MediaWiki->performRequest()
#11 /var/www/html/wikiname/includes/MediaWiki.php(527): MediaWiki->main()
#12 /var/www/html/wikiname/index.php(44): MediaWiki->run()
#13 {main}

Steps to reproduce

try to set values from query={{#ask:[[Category:XCat]]}} in input=tokens

Event Timeline

Kghbln created this task.Mar 6 2020, 8:31 AM
Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptMar 6 2020, 8:31 AM
Yaron_Koren renamed this task from Error from line 782 of "PF_ValuesUtils.php": Call to undefined method SMWQueryProcessor::processFunctionParams() to Page Forms: "values from query" no longer works with SMW 3.1.5.Mar 6 2020, 2:28 PM

About SMWQueryProcessor::processFunctionParams, see pull request #3402 (and issue #2737).

Thank you very much for forwarding. Are there any known workarounds to the problem other than removing the values statement?

Fortunately we have found a workaround:
just use

values from category=XCat


Fortunately we have found a workaround:

Ah, yes. I could probably have told you in the first place. I guess it was so focused on the query issue that I totally forgot to mention this. Anyway this bug is still valid though I do not expect it to be fixed any time soon.

Actually, looking at this now, I'm surprised that this worked before. I thought it was supposed to be just something like "values from query=[[Category:XCat]]", not "values from query={{#ask:[[Category:XCat]]}}". If you're actually calling #ask, you could just pass the results to "values=". @Circa138 - are you sure that's how you had it set up?

Yup, it's been doing what it's supposed to for the last five years on multiple forms. :)

@Circa138 - alright, it sounds like your specific issue is unrelated to the original bug. Rather, I guess in the code 8 years ago, "values from query" acted differently from the way it does now.

Actually, now I realize that you did post the original bug. So really, this was two separate issues: the syntax for "values from query" changed (I'm guessing a long time ago), and the current handling for "values from query" needs to be updated. Maybe the original bug report needs to be edited, although it probably doesn't really matter.

Hi Yaron, thanks for the answer. Meanwhile I had to realize that "values from category" is not a complete adequate replacement after all, because there is no depth parameter that outputs all subcategories, or am I wrong? I would use a tree if the number of entities was not already over 5000 ;)

No, "values from category" checks the subcategories as well - or at least, it's supposed to. Does that not work for you?

Circa138 added a comment.EditedApr 10 2020, 7:58 AM

Hello Yaron, sorry I was not precise enough in my statement. The focus of my statement is on "all subcategories". Up to depth 2 it seems to work for me, after that not anymore. I will build a minimal example on a clean version to confirm this for sure.