MediaWiki REL1_33
|
Functions | |
$article | view () |
Variables | |
$oldArticle = $wgArticle | |
versus | $oldTitle = $wgTitle |
$wgArticle = new Article | |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration which are documented in DefaultSettings php There is no comprehensive documentation for the remaining however some of the most important ones are listed below They are typically initialised either in index php or in Setup php $wgTitle Title object created from the request URL $wgOut OutputPage object for HTTP response $wgUser User object for the user associated with the current request $wgLang Language object selected by user preferences $wgContLang Language object associated with the wiki being viewed $wgParser Parser object Parser extensions register their hooks here $wgRequest WebRequest to get request data | $wgMemc |
$wgTitle = Title::newFromText( $t ) | |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an | efficient |
globals will be eliminated from MediaWiki | entirely |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration which are documented in DefaultSettings php There is no comprehensive documentation for the remaining | globals |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration which are documented in DefaultSettings php There is no comprehensive documentation for the remaining however some of the most important ones are listed below They are typically initialised either in index php or in Setup php $wgTitle Title object created from the request URL $wgOut OutputPage object for HTTP response $wgUser User object for the user associated with the current request $wgLang Language object selected by user preferences $wgContLang Language object associated with the wiki being viewed $wgParser Parser object Parser extensions register their hooks here $wgRequest WebRequest | object |
globals txt Globals are evil The original MediaWiki code relied on globals for processing context far too often MediaWiki development since then has been a story of slowly moving context out of global variables and into objects Storing processing context in object member variables allows those objects to be reused in a much more flexible way Consider the elegance | of |
database rows | |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be | seen |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration | settings |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being | though |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of | writing |
$wgArticle view | ( | ) |
$oldArticle = $wgArticle |
Definition at line 17 of file globals.txt.
versus $oldTitle = $wgTitle |
Definition at line 16 of file globals.txt.
Referenced by RenameUserCleanup::checkRenameLog(), ApiEditPage::execute(), SpecialNewpages::formatRow(), ApiMove::moveSubpages(), TitleBlacklistHooks::onMovePageCheckPermissions(), RenameuserSQL::rename(), MovePageTest::testMoveAbortedByTitleMoveHook(), and MovePageTest::testTitleMoveCompleteIntegrationTest().
$wgArticle = new Article |
Definition at line 21 of file globals.txt.
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration which are documented in DefaultSettings php There is no comprehensive documentation for the remaining however some of the most important ones are listed below They are typically initialised either in index php or in Setup php $wgTitle Title object created from the request URL $wgOut OutputPage object for HTTP response $wgUser User object for the user associated with the current request $wgLang Language object selected by user preferences $wgContLang Language object associated with the wiki being viewed $wgParser Parser object Parser extensions register their hooks here $wgRequest WebRequest to get request data $wgMemc |
Definition at line 64 of file globals.txt.
Referenced by Installer::__construct(), ClearInterwikiCache::execute(), ApiCategoryTree::getHTML(), ForkController::initChild(), FancyCaptcha::pickImageDir(), FancyCaptcha::pickImageFromDir(), FancyCaptcha::pickImageFromList(), ForkController::prepareEnvironment(), and UploadFromUrlTestSuite::setUp().
$wgTitle = Title::newFromText( $t ) |
Definition at line 20 of file globals.txt.
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an efficient |
Definition at line 31 of file globals.txt.
Definition at line 29 of file globals.txt.
Referenced by CleanupInvalidDbKeys::__construct().
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration which are documented in DefaultSettings php There is no comprehensive documentation for the remaining globals |
Definition at line 39 of file globals.txt.
Referenced by MockExtensionProcessor::__construct(), ExtensionProcessor::addConfigGlobal(), ExtensionProcessor::extractCredits(), ExtensionProcessor::extractExtensionMessagesFiles(), ExtensionProcessor::extractHooks(), ExtensionProcessor::extractInfo(), ExtensionProcessor::extractMessagesDirs(), ExtensionProcessor::extractNamespaces(), ExtensionProcessor::extractPathBasedGlobal(), ExtensionProcessor::extractResourceLoaderModules(), and ExtensionProcessor::getExtractedInfo().
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration which are documented in DefaultSettings php There is no comprehensive documentation for the remaining however some of the most important ones are listed below They are typically initialised either in index php or in Setup php $wgTitle Title object created from the request URL $wgOut OutputPage object for HTTP response $wgUser User object for the user associated with the current request $wgLang Language object selected by user preferences $wgContLang Language object associated with the wiki being viewed $wgParser Parser object Parser extensions register their hooks here $wgRequest WebRequest object |
Definition at line 62 of file globals.txt.
Referenced by ApiResult::applyTransformations(), PathRouter::doAdd(), BlockListPagerTest::formatValueDefaultProvider(), BatchRowUpdateTest::genSelectResult(), MediaWiki\Tests\Maintenance\CategoriesRdfTest::getCategoryIterator(), MediaWiki\Tests\Maintenance\CategoriesRdfTest::getCategoryLinksIterator(), CategoryChangesAsRdfTest::getCategoryLinksIterator(), CommentStore::getCommentInternal(), ResourceLoaderStartUpModule::getConfigSettings(), ImagePage::imageLinks(), DatabaseLogEntry::newFromRow(), BotPassword::newUnsaved(), DatabaseTestHelper::open(), PopulateContentTables::populateTable(), CategoryChangesAsRdfTest::provideCategoryData(), MediaWiki\Tests\Revision\RevisionArchiveRecordTest::provideConstructor(), MediaWiki\Tests\Revision\RevisionStoreRecordTest::provideConstructor(), MediaWiki\Tests\Revision\RevisionArchiveRecordTest::provideConstructorFailure(), MediaWiki\Tests\Revision\RevisionStoreRecordTest::provideConstructorFailure(), JsonContentTest::provideDataAndParserText(), ApiFormatNoneTest::provideGeneralEncoding(), ApiFormatXmlTest::provideGeneralEncoding(), OutputPageTest::provideGetCategories(), RevisionTest::provideGetRevisionText(), RevisionTest::provideGetRevisionTextWithGzipAndLegacyEncoding(), RevisionTest::provideGetRevisionTextWithLegacyEncoding(), RevisionTest::provideGetRevisionTextWithZlibExtension(), RevisionTest::provideGetRevisionTextWithZlibExtension_badData(), RevisionMcrWriteBothDbTest::provideGetTextId(), RevisionNoContentModelDbTest::provideGetTextId(), RevisionPreMcrDbTest::provideGetTextId(), MediaWiki\Tests\Revision\SlotRecordTest::provideInvalidConstruction(), ResourcesTest::provideMediaStylesheets(), MediaWiki\Tests\Revision\RevisionStoreDbTestBase::provideNonHistoryRevision(), ResourceLoaderFileModuleTest::providerGetScriptPackageFiles(), MediaWiki\Session\SessionTest::provideSecretsRoundTripping(), WANObjectCacheTest::provideSetAndGet(), RevisionTest::provideTestGetRevisionText_returnsDecompressedTextFieldWhenNotExternal(), ApiResultTest::provideTransformations(), JsonContentTest::provideValidConstruction(), MediaWiki\Tests\Maintenance\DeleteAutoPatrolLogsTest::runProvider(), JobQueueRedis::serialize(), MediaWiki\Auth\AbstractPasswordPrimaryAuthenticationProvider::setPasswordResetFlag(), ApiStashEdit::storeStashValue(), ApiResult::stripMetadata(), ApiResult::stripMetadataNonRecursive(), ApiResultTest::testAddMetadataToResultVars(), RevisionTest::testConstructFromRow(), ChangeTagsTest::testDeleteTags(), BlockListPagerTest::testFormatValueRestrictions(), PageArchivePreMcrTest::testGetTextFromRow(), MediaWiki\Tests\Revision\McrWriteBothRevisionStoreDbTest::testInsertRevisionFromArchiveRow_unmigratedArchiveRow(), ChangeTagsTest::testListExplicitlyDefinedTags(), RevisionTest::testLoadFromTitle(), DatabaseLogEntryTest::testNewFromId(), MediaWiki\Tests\Revision\RevisionStoreDbTestBase::testNewRevisionFromArchiveRow_no_user(), MediaWiki\Tests\Revision\RevisionStoreDbTestBase::testNewRevisionFromRow_no_user(), BlockListPagerTest::testPreprocessResults(), MultiWriteBagOStuffTest::testSetDelayed(), BagOStuffTest::testSetDeleteMulti(), ChangeTagsTest::testUpdateTags(), ChangeTagsTest::testUpdateTagsDoNothingOnRepeatedCall(), ChangeTagsTest::testUpdateTagsSkipDuplicates(), ApiResultTest::testUtilityFunctions(), FormatJsonTest::toObject(), and MediaWiki\Auth\ResetPasswordSecondaryAuthenticationProvider::tryReset().
BatchRowIterator $reader Iterator that returns an array BatchRowUpdate::of |
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be seen |
Definition at line 31 of file globals.txt.
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of globals were initialised on startup by MediaWiki of these were configuration settings |
Definition at line 37 of file globals.txt.
Referenced by Installer::__construct(), HashConfig::__construct(), WebInstallerOptions::execute(), WebInstaller::execute(), SiteConfiguration::extractAllGlobals(), HashConfig::get(), SiteConfiguration::getAll(), SiteConfiguration::getSetting(), Installer::getVar(), HashConfig::has(), CheckLanguageCLI::help(), CheckExtensionsCLI::help(), WebInstaller::reset(), HashConfig::set(), and Installer::setVar().
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being though |
Definition at line 35 of file globals.txt.
globals will be eliminated from MediaWiki replaced by an application object which would be passed to constructors Whether that would be an convenient solution remains to be but certainly PHP makes such object oriented programming models easier than they were in previous versions For the time being MediaWiki programmers will have to work in an environment with some global context At the time of writing |
Definition at line 36 of file globals.txt.