Thanks for the patch, can you submit it to Gerrit?

this is an older issue, but it's still in the software. Is there any news about this?

Can you provide a link where we can test and see the source?

Yeah exactly. The example I set up renders the form fine; see: https://discoursedb.org/wiki/Special:FormEdit/ForTemplateNested/ForTemplateNestedTest.

Isn't this a nice feature to have?

A little bit later then two weeks, but here you go :-)

Is there any way you could re-submit your fixes? Presumably the patch required would be smaller than before, given that some parts of it, like the getLabelsFromDisplayTitle() function, have already been added to the code.

Holidays are now over, so I'll try submit a new patch within two weeks.

The original bug is reintroduced, and it seems my fixes are not working in any way I fixed them before. Thus to sum it up (its all about the tokens field):

• It should do remote autocompletion whenever the possible values exceeds the maximum allowed value;
• It should display values like "DisplayTitle (real page title)" - it just displays the real page title now. This was partly done in the 'ext.pf.select2.tokens.js' file
  • And the 'reverse lookup' mechanism, where the actual post values would be translated to just save the 'real page titles'.

The patch was functioning correctly in previous versions, but with the recent update to PageForms, it appears that similar code has been partially integrated. However, this integration seems incomplete, as certain components are missing. Consequently, the solution I originally implemented is no longer effective.

Thanks, you've pointed me to https://github.com/wikimedia/mediawiki-extensions-PageForms/commit/77bbf48769c37a13ef217e7a4bb32b268fccd4bc. This issue can be closed!

We've tried that and the same problem exists, but that was expected - since nothing has been changed regarding ordering and tokens field between those versions.

So, I made the same test case on discoursedb.org as I did on the SMW sandbox. You can check it on: https://discoursedb.org/wiki/Special:FormEdit/Test_order/Test_order. The order issue did not occur that; thus I think its SMW related.

In T351489#9367029, @Yaron_Koren wrote:

Okay, that's good to know. Yes, since you offered - could you replicate this problem on https://discoursedb.org?

It's not a problem of old code. We're running 5.6 (and up) and the same problem occurs there. Do you have a sandbox wiki where I can demonstrate it? I'm pretty sure it's in every version of PF.

I fixed this before; the merge request was not merged; but the current version of PF somewhat includes my code, but not all... What's happened?

I know this is a rather old issue; but we've encountered the same issue.

In T329928#8644142, @YOUR1 wrote:

So, after extensively testing with this fix I don't have this issue anymore on my branch. We did encounter a other issue, which is similar to T283161 and T132128.

Our scenario is that we have one category that has a lot of pages in it (around 10.000). Each page in that category has its own display title. Whenever we edit that for, the 'possible' values are limited to whatever $wgPageFormsMaxAutocompleteValues is set to. This is problematic, because whenever we search (through the autocomplete) on a value that's further away then the 1000 prefilled values in the form, it doesn't get resolved correctly.

I've already written a fix for this, but its written on the same change (https://gerrit.wikimedia.org/r/890002) above. Do you want me to submit another patch, or fix this issue in the same change?

So, after extensively testing with this fix I don't have this issue anymore on my branch. We did encounter a other issue, which is similar to T283161 and T132128.

I will have a patch ready today.

To bad nobody did anything with the patches I wrote above.. This seems like a useful solution..

I think you set $wgPageFormsMaxAutocompleteValues to 25 or something to reproduce it.

I tested it with pageforms 4.9.5; field definition:

This change doesn't work as expected. You introduce a new bug by changing item.id = item.displaytitle, while it 'looks' okay; it's really not, because once you save the form, the selected value will be the displaytitle, and not the pagetitle (id) of the page.

I've written some patches for 1.31 which enables you to use symlinks, but we're also using the same strategy for 1.27 and so on.

In T231297#5447341, @Kghbln wrote:

This extension is tagged meaning that it does not follow WMF branches. You need to do a git checkout 1.3.0 instead following the branch. Leaving this to Yaron to confirm.

In T227801#5410045, @Yaron_Koren wrote:

@Rcdeboer - what's the status of the patch? Are you still working on it?

There are still issues with the patch, which we couldn't solve:

@Yaron_Koren are you planning to update ApprovedRevs? As of now its kinda broken..

Btw; https://github.com/wikimedia/mediawiki-extensions-PageForms/blob/master/libs/PageForms.js#L340 the function is not always a function, sometimes a string

Fix available on: https://github.com/wikimedia/mediawiki-extensions-PageForms/pull/3

I've fixed the problem. I will push it upstream.

In T195281#4249695, @Yaron_Koren wrote:

Alright. Well, I'm tempted to mark this as "Declined", since I don't know if there's anything that can be done about this problem within the Page Forms code, unless anyone has any ideas...

In T58269#2012910, @Rcdeboer wrote:

Can anyone verify whether disabling these lines in OutpuPage.php solves the issue for them too? Does anyone understand how these particular lines could trigger Uncommitted DB writes?