aboutsummaryrefslogtreecommitdiffstats
path: root/includes/parser/Parsoid/Config/PageConfigFactory.php
Commit message (Collapse)AuthorAgeFilesLines
* Set useParsoid flag in Parsoid's PageConfigC. Scott Ananian2025-01-161-0/+2
| | | | Change-Id: I5c0e7455ef914622e9bda0f3d52ea09c4f33c4a6
* Namespace all remaining classes in includes/parserJames D. Forrester2024-10-151-1/+1
| | | | | Bug: T353458 Change-Id: If02cc9b1ff78e26c1cf8c91ee4695845eb133829
* ParsoidParser: ensure magic variable expansion uses pageLanguageOverrideC. Scott Ananian2024-10-091-0/+1
| | | | | | | | | | | | | | | | This patch adds tests for the caching fix in Ie76020dc4fa3545f827e1674051530b479f01f31, but these tests also revealed that the recursive invocation of the legacy parser to expand magic variables like {{PAGELANGUAGE}} wasn't using the pageLanguageOverride, aka ParserOptions::getTargetLanguage(). The page language override is used when parsing new context which doesn't currently exist in the database and therefore doesn't have a page language set by its title (which doesn't yet exist). Bug: T376783 Follows-Up: Ie76020dc4fa3545f827e1674051530b479f01f31 Change-Id: If6fe7cf00be6e78ef46181b17f01138383e95e46
* Add namespace to IDBAccessObject and DBAccessObjectUtilsJames D. Forrester2024-09-271-1/+1
| | | | | Bug: T353458 Change-Id: I23cf7991f8792d4d000d1780463d8ce76dc0aee0
* Remove more indirect calls to IDBAccessObject::READ_* constantsAmir Sarabadani2024-01-231-1/+2
| | | | | | | | | | Found via (?<!IDBAccessObject)::READ_ We are planning to deprecate and remove implementing IDBAccessObject interface just to use the constants. Bug: T354194 Change-Id: I89d442fa493b8e5332ce118e5bf13f13b8dd3477
* includes/parser/Parsoid/*: Use typed class propertiesSubramanya Sastry2023-10-231-9/+3
| | | | | | | | | | | | | | | | * I had already used this on one property of one file here and noticed that Isabelle used this on a newly created class in output transform and that prompted me to switch over all these files. * I am about to start adding new files here for new hooks for DiscussionTools and updated everything in this namesspace to keep usage consistent. * This exposed initialization and bad typing issues in SiteConfig.php and LanguageVariantConverter.php Change-Id: I35f131a8f584ccc82a915dbfb1b50b3ef1ec6b06
* Remove all Parsoid debugApi references and usesSubramanya Sastry2023-09-141-26/+0
| | | | | | | | | | * Was used during the Parsoid JS -> PHP port and is no longer used. * This also eliminated the need to inject ParsoidSettings into some classes. * Once this merges and lands in core, I'll remove this from the Parsoid repo as well. Change-Id: I008d30ea81f5a3db26e512c87762b90e3ca3c4ff
* Catch RevisionAccessException in ParsoidOutputAccessArlo Breault2023-06-271-3/+23
| | | | | | | | | A shared get content assertion is added to PageConfigFactory::create Bug: T338925 Bug: T336501 Follows-Up: I647ed253691970bbf39321a3cd652ea14bc11278 Change-Id: Iaf3898e5c53f1673ade639f7990911e4595801a8
* Fix Phan suppressions related to Title::castFrom*() and friendsBartosz Dziewoński2023-04-221-2/+1
| | | | | | | | | | | | | | | | | | | | | There is no way to express that Title::castFromPageIdentity(), Title::castFromPageReference() and Title::castFromLinkTarget() can only return null when the parameter is null. We need to add Phan suppressions or explicit types almost everywhere that these methods are used with parameters that are known to not be null. Instead, introduce new methods Title::newFromPageIdentity() and Title::newFromPageReference() (Title::newFromLinkTarget() already exists), without the null-coalescing behavior, and use them when the parameter is not null. This lets static analysis tools, and humans, easily understand where nulls can't appear. Do the same with the corresponding TitleFactory methods. Change the obvious uses of castFrom*() to newFrom*() (if there is a Phan suppression, a type check, or a method call on the result). Change-Id: Ida4da75953cf3bca372a40dc88022443109ca0cb
* Parsoid PageConfigFactory: warn on any attempt to use deprecated argumentC. Scott Ananian2023-03-231-0/+4
| | | | | | | | | | The 4th argument to PageConfigFactory::create() used to be $textOverride. That argument now does nothing, but it may still entrap unwary users who try to pass a text override to the page config factory. It is hard to remove this argument entirely due to the dependencies between core and Parsoid, but we can at least wfDeprecated() anything which uses it. Change-Id: I1cc4d2075016e6bd479cef2e32cb768ff1ad51df
* Use Bcp47Code when interfacing with ParsoidC. Scott Ananian2023-03-131-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is very easy for developers and maintainers to mix up "internal MediaWiki language codes" and "BCP-47 language codes"; the latter are standards-compliant and used in web protocols like HTTP, HTML, and SVG; but much of WMF production is very dependent on historical codes used by MediaWiki which in some cases predate the IANA standardized name for the language in question. Phan and other static checking tools aren't much help distinguishing BCP-47 from internal codes when both are represented with the PHP string type, so the wikimedia/bcp-47-code package introduced a very lightweight wrapper type in order to uniquely identify BCP-47 codes. Language implements Bcp47Code, and LanguageFactory::getLanguage() is an easy way to convert (or downcast) between Bcp47Code and Language objects. This patch updates the Parsoid integration code and the associated REST handlers to use Bcp47Code in APIs so that the standalone Parsoid library does not need to know anything about MediaWiki-internal codes. The principle has been, first, to try to convert a string to a Bcp47Code as soon as possible and as close to the original input as possible, so it is easy to see *why* a given string is a BCP-47 code (usually, because it is coming from HTTP/HTML/etc) and we're not stuck deep inside some method trying to figure out where a string we're given is coming from and therefore what sort of string code it might be. Second, we've added explicit compatibility code to accept MediaWiki internal codes and convert them to Bcp47Code for backward compatibility with existing clients, using the @internal LanguageCode::normalizeNonstandardCodeAndWarn() method. The intention is to gradually remove these backward compatibility thunks and replace them with HTTP 400 errors or wfDeprecated messages in order to identify and repair callers who are incorrectly using non-standard-compliant language codes in web standards (HTTP/HTML/SVG/etc). Finally, maintaining a code as a Bcp47Code and not immediately converting to Language helps us delay or even avoid full loading of a Language object in some cases, which is another reason to occasionally push Bcp47Code (instead of Language) down the call stack. Bug: T327379 Depends-On: I830867d58f8962d6a57be16ce3735e8384f9ac1c Change-Id: I982e0df706a633b05dcc02b5220b737c19adc401
* Mark Parsoid configuration classes @internalC. Scott Ananian2023-03-071-0/+1
| | | | | | | | | | Clarify that the classes used to interface MediaWiki with Parsoid are not for external use and have no stability guarantees. External clients should use forthcoming support in Parser and ParserOutputAccess to access Parsoid content and not rely on these internal classes. Change-Id: I684fa3ef3e25317c114551de3e2f233c7e84ce6f
* Reorg: Namespace the Title classJames D. Forrester2023-03-021-1/+1
| | | | | | | | | | | | | | | | | | | This is moderately messy. Process was principally: * xargs rg --files-with-matches '^use Title;' | grep 'php$' | \ xargs -P 1 -n 1 sed -i -z 's/use Title;/use MediaWiki\\Title\\Title;/1' * rg --files-without-match 'MediaWiki\\Title\\Title;' . | grep 'php$' | \ xargs rg --files-with-matches 'Title\b' | \ xargs -P 1 -n 1 sed -i -z 's/\nuse /\nuse MediaWiki\\Title\\Title;\nuse /1' * composer fix Then manual fix-ups for a few files that don't have any use statements. Bug: T166010 Follows-Up: Ia5d8cb759dc3bc9e9bbe217d0fb109e2f8c4101a Change-Id: If8fc9d0d95fc1a114021e282a706fc3e7da3524b
* Stash original wikitext when rendering unsaved content.daniel2022-11-041-0/+12
| | | | | | | | | When visual editor switches from source mode to visual mode, we need to stash the wikitext. Otherwise, we later lack the proper context to convert the modified HTML back to wikitext. Bug: T321862 Change-Id: Id611e6e022bf8d9d774ca1a3a214220ada713285
* Remove $wikitextOverride argument to PageConfigFactory::create()C. Scott Ananian2022-07-261-48/+19
| | | | | | | | | | This reverts commit 368e955d739f295e14472fd6c047cd9fe9648e1f, which was a temporary workaround while old Parsoid code still passed $wikitextOverride. Now that the latest Parsoid has been deployed to production, we no longer need to support the $wikitextOverride argument. Change-Id: I0000e0129cfed6b3933c494418db94600720e8ce
* Various whitespace changesUmherirrender2022-07-121-4/+4
| | | | Change-Id: I31f316c66b3066461b9297c7b6f9845ade99f0df
* Followup to 5f5b4cbb: Unbreak Parsoid CISubramanya Sastry2022-06-171-19/+48
| | | | | | | | | | | Parsoid repo use of this method still relies on $wikitextOverride arg being handled properly, and the $pageId may be a LinkTarget not a PageIdentity. This patch contains some "unnecessary" renames just to make the diff with 5f5b4cbbb4a6214229a23062787c25acd4192ff7^ easier to read. Change-Id: I79a2773bf6d2366593b31555afd0b548b66d222a
* Have Parsoid\Config\PageConfigFactory take a rev instead of wikitextSubramanya Sastry2022-06-151-44/+36
| | | | | | | | | | | | | | | | | | | | * This let us pass mocked revisions in the parser test runner while running in Parsoid mode. * This leads to improvement in wt2html tests results where a revision id is queried. I've verified this in the Cite extension repo as also the main parserTests.text file but I cannot enable Parsoid integrated testing on the main parser tests file without doing a sweep over all parser tests and adding appropriate test sections * Currently, PageConfigFactory doesn't have unit tests. Will look into adding them separately in a followup. * Moved the setupParsoidTransform function to a more suitable place in the ParserTestRunner.php file. Bug: T270310 Change-Id: I94d68c8528bb2f7b367c68d80d14ebc1ab904a7f
* Code style improvements to code moved from ParsoidC. Scott Ananian2022-03-281-2/+5
| | | | | Followup-To: I0b388d93143a782c2c3b72e46407572e5c586e4a Change-Id: I3349dcd1c38ca7759fcff3104e990bb6171b610b
* [doc only] Update Parsoid's class documentation; add @since tagsC. Scott Ananian2022-03-281-0/+5
| | | | | Followup-To: I0b388d93143a782c2c3b72e46407572e5c586e4a Change-Id: Icbf172b51ffc90b51fd738f90d4425c4fc2aa5d7
* [doc only] Update copyright date for files moved from ParsoidC. Scott Ananian2022-03-281-1/+1
| | | | | Followup-To: I0b388d93143a782c2c3b72e46407572e5c586e4a Change-Id: I618237c4c91a054767516e1fae15a8a421e15371
* Copy over Parsoid's Config and ServiceWiring classesC. Scott Ananian2022-03-281-0/+182
* This is the first step of migrating Parsoid integration code into core and transitioning Parsoid from an extension to a pure library. * Parsoid already has conditional code to skip loading Parsoid's copy of its classes, but it relies on the existence of ParsoidServices. Technically ParsoidServices isn't needed once Parsoid is migrated to core -- users can just use MediaWikiServices instead -- but we need to temporarily add ParsoidServices as a marker class during the transition. This version of Parsoid's ServiceWiring comes from Parsoid commit 898c813fd832b3f2d7b5a37f60bd65e8368ce18f. Bug: T302118 Change-Id: I0b388d93143a782c2c3b72e46407572e5c586e4a
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-23 02:31:07 +0000