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