The AutoloadGenerator class is instantiated in the script
maintenance/generateLocalAutoload.php and its equivalents in
several extensions, none of which use MediaWiki's AutoLoader,
so you get a "Fatal error: Class 'ClassCollector' not found".
This reverts commit a379bebd03.
Change-Id: Ia6a7a1cb8a593ac86ecffdb690064e0b8ad68b47
AutoloadGenerator.php until now only updated autoload.php. As we shift
to extension registration, it would be cleaner if AutoloadGenerator.php
directly updates 'AutoloadClasses' in extension.json.
Bug: T88194
Change-Id: Idd601d7897634fae8c69f4d5338d9fc8f8b8f89b
The patch set from I5d502b5 re-introduced the use of realpath() within
AutoloadGenerator::readFile() as part of a set of changes to ensure that
path separators are normalized across Unix and Windows systems. As noted
previously in I4623b3d, the use of realpath() in this function will
cause fatal exceptions to be thrown when a file such as
LocalSettings.php is a symlink to a file outside to $IP.
This patch separates the path normalization functionality from
realpath() expansion and uses only the path normalization component
within AutoloadGenerator::readFile(). It also introduces a cautionary
comment in AutoloadGenerator::readFile() that will hopefully keep
realpath() from being reintroduced there.
Change-Id: I4923dfa8370a7bd6077f42ff4c437d7293fdad66
It was previously using the platform-specific directory separator, meaning
that we got backslashes on Windows and forward slashes on other OSs.
Bug: T77004
Change-Id: I5d502b54fddd55272e63d4a2a14b6d5de541263a
- Added/removed spaces around parenthesis
- Added newline in empty blocks
- Added space after switch/foreach/function
- Use tabs at begin of line
- Add newline at end of file
Change-Id: I244cdb2c333489e1020931bf4ac5266a87439f0d
The use of realpath() in AutoloadGenerator::readFile() causes the
LocalSettings.php symlink to be dereferenced. Since the target file
lives outside of $IP, AutoloadGenerator would fail with an exception.
Change-Id: I4623b3da9b984026999189d70349ffb4754812a5
When generating $wgAutoloadClasses for an extension the generator
currently outputs an assignment (=), but it is unlikely this is
the desired result. An extension wants to append to the existing
$wgAutoloadClasses. This bug is an unintended consequence of I75403ace
which changed the generator from assigning one key per line to using
an array literal.
This patch changes the output only when generating $wgAutoloadClasses
to the += operator which adds to the array any value that is not
already in the array.
Change-Id: I7d42ee5dc829991c6562878f0c90a06fadb1b6a6
Adds a comment to the top of the generated autoload.php directing
developers to the command to regenerate the file so they may just
copy and paste the command.
Change-Id: If098a1eb51ed732378677215c0e438c73d506697
Both zend and HHVM run through the autoload file faster when it
is a single array literal rather than individual key assignments.
The __DIR__ string concatenation remains because HHVM and Zend >= 5.5.0
optimize away constant string concatenation.
Change-Id: I75403ace264b09930d5cc545e62b8d7c3f1ad064
Currently all new classes in core need to be registered
with the autoloader. This is acceptable but inconvenient.
This patch adds a script to read the output of php's tokenizer
to determine the names of all the classes within mediawiki core.
Patches with new or removed classes will just need to rerun
the maint script rather than manually adjusting the arrays.
A full conversion to psr-0 + composer would solve this as well,
but this is a very non-intrusive patch that can get us some
portion of the benefit(reduced manual maintenance) today rather
than months down the line once we figure out all the intricacies
of mediawiki + composer.
Change-Id: I8b1bdb84a9699de79f8b9951fa61e5437d083c55
