VasilievVV wrote:
includes/ directory directory contains about 200 files. It looks like a dump, where it's hard to find something. I propose to move some files to subdirectories (if it won't break something):
I've been thinking about such a change for a while, but please...
- includes/specialpages/ (SpecialPage.php and all special pages)
make it "special". The "pages" bit doesn't add anything. Then we can rename all the files to remove the "Special" from the start. That's one of the reasons the "sort by name" system Thomas Dalton promotes is not ideal, you get long prefixed filenames.
- includes/output. (or other name; all functions obviously related to
output: HttpFunctions.php, OutputHandler.php, OutputPage.php, WebRequest.php, WebResponse.php, etc.)
That's not a category I would have picked out. WebRequest is not really output, HttpFunctions certainly isn't.
- includes/database (or db; not sure if there's too many files related)
For API folder (now about 50 files; will be more after merging apiedit):
- includes/api/formats (for ApiFormat*)
- includes/api/edit (for write API)
- includes/api/query/{list,prop,meta} (includes/api/query for
ApiQueryBase, subdirectories for API queries)
Some extra suggestions:
includes/updates: LinksUpdate, HTMLCacheUpdate.php, SearchUpdate.php, SiteStatsUpdate.php (split from SiteStats.php), SquidUpdate.php
includes/objectcache: BagOStuff.php (will be split in the future), memcached-client.php, ObjectCache.php
includes/parser: CoreParserFunctions.php, MagicWord.php, Parser.php, ParserCache.php, ParserOptions.php, ParserOutput.php, Sanitizer.php, StringUtils.php
That one demonstrates another one of the problems of sorting by name: prefixing is not used ubiquitously. You'd have to know the parser pretty well to know that all those files are very closely related to it.
Sure, search and profiler too, as per Roan's suggestion. But search should only be the search subclasses, SearchUpdate.php should be in updates.
Presumably other categories would become clear once those are removed. Perhaps a "coreui" directory, for EditPage, CategoryPage, etc. Maybe a directory for functions (global and static collections), such as HttpFunctions.php and Xml.php.
David A. Desrosiers wrote:
I personally run ~54 separate Mediawiki instances from the same source tree, all talking to a single mediawiki database with table prefixes.
Are you sure your planned changes will still continue to work with this model?
Are you talking about using require_once and include() directives to point to the new locations? Or referencing the files with an absolute path from the baseroot of the tree?
It will work just fine, the same way as it works already for files in subdirectories. Paths for most files relative to $IP are listed in AutoLoader.php. Setup.php loads files relative $IP, and the startup sequence loads files relative to the current directory.
-- Tim Starling