GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Edit Task
  • Edit Related Tasks...
  • Create Subtask
  • Edit Parent Tasks
  • Edit Subtasks
  • Merge Duplicates In
  • Close As Duplicate
  • Edit Commits
  • Edit Mocks
  • Mute Notifications
  • Protect as security issue
  • MediaWiki-Parser
  • (Backlog)
  • Parsoid

This view

  • Original page
  • New address

GeezerVison is showing phabricator.wikimedia.org — T299528 Deprecate and remove `ParserFirstCallInit` hook (move hook/tag registration out of Parser constructor)

Page MenuHomePhabricator
Log In
Create Task
Maniphest T299528

Deprecate and remove `ParserFirstCallInit` hook (move hook/tag registration out of Parser constructor)
Open, Needs TriagePublic
Actions

  • Edit Task
  • Edit Related Tasks...
  • Create Subtask
  • Edit Parent Tasks
  • Edit Subtasks
  • Merge Duplicates In
  • Close As Duplicate
  • Edit Related Objects...
  • Edit Commits
  • Edit Mocks
  • Mute Notifications
  • Protect as security issue
Assigned To
None
Authored By
cscott
Jan 19 2022, 3:08 PM2022-01-19 15:08:50 (UTC+0)
Project Tags
  • MediaWiki-Parser (Backlog)
  • Parsoid (Tech Debt / Big changes)
  • MediaWiki-extensions-Variables (On the radar)
Referenced Files
None
Subscribers
Aklapper
alex-mashin
Alex44019
cscott
DannyS712
Dereckson
dmehus
View All 25 Subscribers

Description

We would like to make Parser construction as speedy as possible. Calling the ParserFirstCallInit hook to register every single parser function and extension tag on every single parser object instantiation (as is now done) is a waste: 99.9% percent of extension and parser functions are available in every constructed parser, so we keep building the same maps and tables of tags and functions again and again.

Instead, extension and parser function registration should be via the standard ExtensionRegistry, and the hook/tag extension API should give extensions/parser functions the ability to 'nope out' of expansion if the tag/function is supposed to be disabled in that parser context. (This latter functionality will rarely be the right thing to do, since it's going to end up splatting the tag/function text literally on the page, but it might be necessary for, say, security or access control reasons.)

Note that this doesn't directly give you the ability to, say, have multiple extensions implement the <foo> tag, with one or the other registered during parser construction time. That's fine: just create a single shared <foo> implementation which calls a hook to dispatch to one or the other implementation dynamically. (Or just Don't Do That.) We might optionally change the extension mechanism to allow multi-maps from extension/tag name to implementation to allow fallback, but this seems like unnecessary complexity at this time.

See also T250444: Deprecate and remove Parser::firstCallInit(), which is about removing the Parser::firstCallInit method. This is about removing the hook.

Related Objects
Search...

  • Task Graph
  • Mentions
StatusSubtypeAssignedTask
OpenNoneT261329 Prepare Parsoid for MW
OpenNoneT236809 Refactor Parser.php to allow alternate parser (Parsoid)
OpenNoneT299528 Deprecate and remove `ParserFirstCallInit` hook (move hook/tag registration out of Parser constructor)
Mentioned In
T263772: Make RelatedArticles extension compatible with Parsoid
T268144: Add setFunctionHook equivalent support to Parsoid Extension API
Mentioned Here
T250444: Deprecate and remove Parser::firstCallInit()

Event Timeline

cscott created this task.Jan 19 2022, 3:08 PM2022-01-19 15:08:50 (UTC+0)
Restricted Application removed a project: Patch-For-Review. · View Herald TranscriptJan 19 2022, 3:08 PM2022-01-19 15:08:50 (UTC+0)
cscott updated the task description. (Show Details)Jan 19 2022, 3:09 PM2022-01-19 15:09:33 (UTC+0)
cscott renamed this task from Make Parsoid hook/tag registration global, instead of in Parser constructor to Deprecate and remove `ParserFirstCallInit` hook (move hook/tag registration out of Parser constructor).Jan 19 2022, 3:13 PM2022-01-19 15:13:43 (UTC+0)
cscott updated the task description. (Show Details)
RobinHood70 unsubscribed.Jan 19 2022, 3:29 PM2022-01-19 15:29:04 (UTC+0)
JJMC89 removed projects: MW-1.36-notes (1.36.0-wmf.8; 2020-09-08), MW-1.35-notes (1.35.0-wmf.36; 2020-06-09).Jan 19 2022, 4:24 PM2022-01-19 16:24:06 (UTC+0)
MSantos subscribed.Jan 19 2022, 8:08 PM2022-01-19 20:08:16 (UTC+0)
ihurbain subscribed.Jan 31 2022, 10:53 AM2022-01-31 10:53:32 (UTC+0)
Arlolra moved this task from Needs Triage to Tech Debt / Big changes on the Parsoid board.Feb 2 2022, 6:17 PM2022-02-02 18:17:51 (UTC+0)
cscott mentioned this in T268144: Add setFunctionHook equivalent support to Parsoid Extension API.Feb 11 2022, 4:32 PM2022-02-11 16:32:54 (UTC+0)
cscott added a comment.Edited · May 23 2022, 3:50 PM2022-05-23 15:50:16 (UTC+0)
Comment Actions

Because there are some legacy extensions that may deliberately register a parser function or extension tag *only* in a specific context, our "expand this extension tag/parser function" API should explicitly have a "skip this registration and look for another" return value. That way those legacy extensions can (in the new system) *always* register the extension tag/parser function, but return the "skip this registration" value in all cases except those of the specific context in which it wants to be active.

Luckily, this pattern does not appear to be widespread, but it's still probably worth accommodating in the API to ease migration.

TheresNoTime removed a subscriber: RhinosF1.Dec 15 2022, 11:35 PM2022-12-15 23:35:46 (UTC+0) ·
RobinHood70 subscribed.May 1 2023, 3:49 AM2023-05-01 03:49:35 (UTC+0)
MGChecker moved this task from Backlog to On the radar on the MediaWiki-extensions-Variables board.Sep 8 2023, 5:41 PM2023-09-08 17:41:44 (UTC+0)
cscott mentioned this in T263772: Make RelatedArticles extension compatible with Parsoid .Dec 4 2023, 3:26 PM2023-12-04 15:26:35 (UTC+0)
alex-mashin subscribed.Jan 14 2024, 6:54 AM2024-01-14 06:54:35 (UTC+0)
Alex44019 subscribed.Nov 4 2024, 7:15 PM2024-11-04 19:15:10 (UTC+0)
Aklapper removed a project: Parsing-Active-Work.Apr 8 2025, 11:55 AM2025-04-08 11:55:58 (UTC+0) ·
Michael subscribed.Sep 5 2025, 10:20 AM2025-09-05 10:20:50 (UTC+0)
Dereckson subscribed.Oct 23 2025, 9:18 PM2025-10-23 21:18:01 (UTC+0)
Comment Actions

Do we currently have any migration guide if we take this path?

KockaAdmiralac subscribed.Apr 14 2026, 6:09 PM2026-04-14 18:09:09 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.