Page MenuHomePhabricator

Deprecate and remove $wgHashedUploadDirectory feature (always on)
Closed, DeclinedPublic

Description

DefaultSettings.php
/**
 * Set this to false if you do not want MediaWiki to divide your images
 * directory into many subdirectories, for improved performance.
 *
 * It's almost always good to leave this enabled. In previous versions of
 * MediaWiki, some users set this to false to allow images to be added to the
 * wiki by simply copying them into $wgUploadDirectory and then running
 * maintenance/rebuildImages.php to register them in the database. This is no
 * longer recommended, use maintenance/importImages.php instead.
 *
 * @note That this variable may be ignored if $wgLocalFileRepo is set.
 * @todo Deprecate the setting and ultimately remove it from Core.
 */
$wgHashedUploadDirectory = true;

Event Timeline

Krinkle created this task.Jul 14 2018, 1:14 AM
Restricted Application added projects: Commons, Multimedia. · View Herald TranscriptJul 14 2018, 1:14 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Tgr added a subscriber: Tgr.Aug 5 2018, 1:16 PM

$wgHashedUploadDirectory is just convenience for setting $wgLocalFileRepo (and the same goes for $wgHashedSharedUploadDirectory and $wgForeignFileRepos) so (as proposed) this wouldn't change the fact that a file repo can have an arbitrary level of hash directories (including zero).

What would be the migration path for wikis which currently set this to false?

Maintenance script as part of installer/updater. And yes, I meant removing the feature itself in FileRepo, not just the configuration short-cuts.

MaxSem added a subscriber: MaxSem.Jun 18 2019, 7:07 AM

The reason this was introduced is that some hashes contained ad which some adblocked blocked as... ads. Is this less of a concern these days?

Krinkle closed this task as Declined.Oct 12 2019, 10:41 PM
Krinkle moved this task from Untriaged to Not yet on the Technical-Debt (Deprecation process) board.

It's enabled on all WMF wikis and in MW core by default, so, I hope not?

Anyhow, declining this as there is very little to gain by removing the alias, and it's something that breaks badly for an affected wiki. We can move it out of Setup.php to the code that handles it to reduce init impact, though. But that can happen separately and isn't a priority for simple 1-1 mappings like this, which are cheap.