Mon, Jan 6
Dec 18 2019
I configured my local wiki to allow:
GroupPermissions['administrators']['suppressrevision'] = true; and added 'suppressor' for revisions to my administrators http://localhost:8080/index.php?title=Special%3AUserRights account. I then used local user account to edit a page and then used my admin account to edit it again. I captured the other users edit oldid and used the admin account to access the page history and used 'Change visibility of selected revisions' button on right to suppress the ability to read that old revision. This reproduced the bug and I found that Api/PageConfig makeRequest( ... ) was not returned the [pages] as designed, but our code was accessing that associative key anyway without protection causing a crash.
I believe this is a duplicate of T238845 and is triggered by an editor electing to 'suppress' an edit revision which then causes the Api/PageConfig.php code call to makeRequest( ... ) to return associative array missing the ['pages'] elements appropriately, but the code then went and attempted to access ['pages'] anyway without protection causing a crash.
The fix for T238845 seems to fix this case as well.
Dec 17 2019
Dec 16 2019
Dec 10 2019
Dec 9 2019
Nov 19 2019
Nov 12 2019
Nov 7 2019
Fix for crash completed and fixes that produce desired behavior and correct wikitext and VE edit updates all implemented and tests written.
Nov 6 2019
Nov 5 2019
Oct 31 2019
Should be resolved by:
Oct 24 2019
Debugged both parsoid JS and PHP and without, and with --useBatchAPI enabled on parsoidJS, the class="new" does appear, but the redlinks code will not get called without that command line flag enabled. The parsoid PHP calls the redlink code without any command line flags required.
Unable to reproduce the error that occurred in the server environment, possibly missing --useBatchAPI?
Oct 18 2019
The JS Poem extension was also failing to properly handle the following (enhanced slightly WT below) and the PHP Poem was dramatically failing to produce viable HTML from:
Oct 16 2019
Researched and attempted to reproduce using command line parse.php and in that mode, does not fail to match ParsoidJS in command line mode. The core parser also produces the seek correctly, but when ParsoidPHP is used in production mode, fails with local installation of mediawiki or on server installations.
I need to get my local mediawiki install back in running state after upgrading OSX to Catalina to continue.
Oct 15 2019
Replaced empty() and isset() where safe.
Oct 9 2019
After reviewing Parsoid/PHP on Oct, 9, it appears that all performance improvements possible were addressed by:
Sep 18 2019
Aug 1 2019
Jul 30 2019
Jul 26 2019
Jul 17 2019
Jul 16 2019
Jul 15 2019
Jul 10 2019
Nov 27 2018
First phase of generating dom pre and post pass test files completed:
Nov 8 2018
Aug 16 2018
Jul 17 2018
So on my development Parsoid (some configuration info is not the same as production), I cannot reproduce this bug:
Jun 11 2018
May 22 2018
Apr 19 2018
The normalization code now checks for matching href and textContent, and also avoid normalizing WikiLinks that have color, style and class attributes.
Apr 4 2018
Adding a second patch to handle multiple paragraphs being collapsed in a figcaption.
Mar 19 2018
The first submission of the patch just fixes the single case.
Ed, Subbu and I have discussed that for multiple p tags in the caption, we will be replacing the new lines with a single space, merging the captions together. The hope is that the captions would be sentences and that joining them with a space will be a reasonable way to "fix" this situation.
Feb 1 2018
Re-opened until merged and deployed, my bad.
So for class = "external free", "external text" and "external autonumber", parsoid now generates the proper class attributes and matches the PHP parser output.
Dec 18 2017
I retried James example the current Parsoid and it seems to work properly. Is there another failing case I can look at?
Oct 5 2017
Hi, thanks, I linked the accounts (I think).
THanks I linked the accounts.