Hi, this works for me, what version of Page Forms are you using? I think this is related to this bug: https://phabricator.wikimedia.org/T239023, which should be already fixed in the last version of Page Forms.
Wed, Mar 24
Feb 26 2020
Nov 24 2019
I tested the code on MediaWiki 1.33.1 (wikieditor 0.5.2) and MediaWiki 1.31.5 (wikieditor 0.5.1) and worked fine.
Nov 13 2019
Nov 10 2019
I have also had problems due to having some long strings not being truncated, but in my case the SQL insertion queries failed and no data was added to the database for the pages with those long strings. I am using MySQL 5.7. To fix this I just changed the type of the affected columns to text in my database, but I agree with HertzDevil that the strings should be truncated before being added to the database. Also, currently there is no easy way of knowing if something went wrong, if a string is truncated or if an insertion/update query fails there is no warning or error message anywhere.
Oct 7 2019
I have made a patch to solve the issue.
Oct 3 2019
Jul 23 2019
Thanks for accepting this change!
Jun 30 2019
Jun 28 2019
Thank you!, yes, now the code works as expected, so I am marking this bug as resolved.
Jun 26 2019
I have found the problematic line of code. The bug is in the function getSQLConditionForAutocompleteInColumn (In PF_ValuesUtils.php), which is called when autocompleting by category or namespace.
Jun 25 2019
May 24 2019
Hi, thanks a lot for the questions and comments:
May 20 2019
Hi Yaron, I think that you are right, I think that there is no important use case for a display format, and that the export format is enough. So I have uploaded a new patch to leave only a bibtex format (which now will be the exporting format).
May 19 2019
I'm closing this since the fix has been merged. Now everything works fine. Although one of the patch reviewers said that there is a ->equals() method in the Title class and that maybe we should use it.
May 18 2019
Thanks for the fix Yaron!, certainly your code is better than mine, I do not have experience with MediaWiki coding. However, you forgot to check $wgTitle for null and now the mainteinance scripts fail (at least cargoRecreateData), yikes! I am uploading a patch to fix it.
May 15 2019
You are welcome ｡^‿^｡, you can use my explanations as you wish.
May 14 2019
I tried to make the query in cargo (without the instr function), just for curiosity, and as I said before it can be done with a 2 join query. For the example of books it would be like this:
The HOLDS command only works fine for one author. If you use the HOLDS query as you say with an OR, and a book is authored both by 'Leo Tolstoy' and 'Dostoevsky', then that book will appear twice in the query resutls.
May 12 2019
I have uploaded a second patch. In the first patch that I uploaded I disabled the output in the constructor of the CargoExport class, but that made the MediaWiki SpecialPages page to be blank, I have no idea why, it is very strange, everything else seems to work fine. I uploaded a second patch where I just replaced the line "$this->getOutput()->setArticleBodyOnly( true );" with "$this->getOutput()->disable();", that seems to work fine.
All the warnings are "Cannot modify header information". I am getting 6 of them, the given locations of the warnings in OutputPage.php are: 2665, 2667, 2681, 2531, 2575, and 2576, which are the lines that set the headers.
I was checking again this problem and I realized that I had several options set to debug errors on LocalSetting.php. Disabling this options solves the problem since no warnings are appended at the output, so this bug only occurs when using the debug options. I updated the bug description with this information.
I marking this as resolved since the patch is merged. Thank you!