Thank Jeffrey, that's a good eye, but unfortunately, the problem persists. Indeed, update.php had not completed *successfully*. There appears to be a mistake in the documentation (or a shorthand in which it is assumed the admin understands the syntax is not literal). The INSTALL page says to run: I had ran this command verbatim. Initially, composer would not complete due to another unrelated module which specified unit-tests in its require/manifest, but the module was not deployed with its test directory. Having fixed that problem in multiple places, the composer command ran successfully. Unfortunately the tilde seems to have been the cause of the failure for running update:      phpoffice/phpexcel: 1.8.2 installed, ~1.8 required.      Error: your composer.lock file is not up to date. Run "composer update --no-dev" to install newer dependencies This is really quite strange. I looked at the composer documentation, and there is definitely some confusion there. In one section, it says that the version attribute must match a regular expression, which does not include the ~. Another section (https://getcomposer.org/doc/articles/versions.md <https://getcomposer.org/doc/articles/versions.md>) indicates this is perfectly acceptable, and that "~1.8" should mean ">=1.8.0".  However, none of the following combinations in composer.json worked:           - "1.8*"           - "1.8.*"           - "1.8.0"           - ">=1.8.0" In the end, I had to change composer.json with the exact version number composer had previously installed. Then I could run update. I also updated the language cache. On Thu, Jun 24, 2021 at 2:11 PM Jeffrey Walton &lt;noloader(a)gmail.com <mailto:noloader@gmail.com>> wrote: On Thu, Jun 24, 2021 at 4:39 AM otheus uibk &lt;otheus.uibk(a)gmail.com <mailto:otheus.uibk@gmail.com>> wrote: Extension via Git. I installed it on a 1.31 MW system per the INSTALL file. I went to the Spezial:XMLview page as instructed. I selected one of the  categories and the main namespace and hit 'view XML'. After a few seconds (< 10) I got a 500 page. I see the 500 error in the PHP logs (so this isn't a web timeout). The PHP debug logs show only the following: $IP/local/extensions/DataTransfer/includes/DT_PageStructure.php on line 139 I believe you need to run maintenance/update.php after you install an extension. Can you confirm you have run it? (I find it is best to run maintenance/update.php after any maintenance, including a Mediawiki upgrade, extension installation, extension removal, etc). Jeff -- Otheus otheus.uibk(a)gmail.com <mailto:otheus.uibk@gmail.com> otheus.shelling(a)uibk.ac.at <mailto:otheus.shelling@uibk.ac.at> _______________________________________________ MediaWiki-l mailing list -- mediawiki-l(a)lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

On Thu, Jun 24, 2021 at 9:40 AM otheus uibk &lt;otheus.uibk(a)gmail.com&gt; wrote: persists. a mistake in the documentation (or a shorthand in which it is assumed the admin understands the syntax is not literal). The INSTALL page says to run: due to another unrelated module which specified unit-tests in its require/manifest, but the module was not deployed with its test directory. Having fixed that problem in multiple places, the composer command ran successfully. Unfortunately the tilde seems to have been the cause of the failure for running update: update --no-dev" to install newer dependencies and there is definitely some confusion there. In one section, it says that the version attribute must match a regular expression, which does not include the ~. Another section ( https://getcomposer.org/doc/articles/versions.md) indicates this is perfectly acceptable, and that "~1.8" should mean ">=1.8.0". However, none of the following combinations in composer.json worked: composer had previously installed. Then I could run update. I also updated the language cache. Don't get me started on the dev tools on a production server... Here's what I do for composer: $ sudo apt-get install -y composer $ sudo su - # cd /var/www/html/w # rm -rf /var/www/html/w/vendor # php -d extension=phar.so composer.phar update --no-dev # exit $ sudo apt-get remove -y composer Then, fix ownership and permissions on the files. We use root:www-data, 0750 and friends. Root owns everything and gets read/write. The webserver is the group owner and only gets read. (The webserver gets read/write on the upload/ and sessions/ directories). Jeff _______________________________________________ MediaWiki-l mailing list -- mediawiki-l(a)lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/mediawiki-l.lists.wikimedia.org/

OK, so you get error stack-traces in a *debug* log, and in the error log you get warning notices? *facepalm* I have a stack-trace which may be relevant. [error] [YNT6JB0y@yYaYYse7zE8PgAAAIc] /neulatein/index.php?title=Spezial:XML_anzeigen&categories%5BLBI-Authors%5D=on&namespaces%5B0%5D=on ErrorException from line 139 of /sites/wiki.uibk.ac.at/app/bluespice-20191215/local/extensions/DataTransfer/includes/DT_PageStructure.php: PHP Notice: Undefined index: 0505261 #0 $IP/local/extensions/DataTransfer/includes/DT_PageStructure.php(139): MWExceptionHandler::handleError(integer, string, string, integer, array) #1 $IP/local/extensions/DataTransfer/includes/DT_PageStructure.php(26): DTPageStructure->parsePageContents(string) #2 $IP/local/extensions/DataTransfer/includes/specials/DT_ViewXML.php(138): DTPageStructure::newFromTitle(Title) #3 $IP/local/extensions/DataTransfer/includes/specials/DT_ViewXML.php(230): DTViewXML->getXMLForPage(Title, NULL) #4 $IP/local/extensions/DataTransfer/includes/specials/DT_ViewXML.php(22): DTViewXML->doSpecialViewXML(NULL) #5 $IP/includes/specialpage/SpecialPage.php(565): DTViewXML->execute(NULL) #6 $IP/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(NULL) #7 $IP/includes/MediaWiki.php(288): SpecialPageFactory::executePath(Title, RequestContext) #8 $IPincludes/MediaWiki.php(861): MediaWiki->performRequest() #9 $IP/includes/MediaWiki.php(524): MediaWiki->main() #10 $IP/index.php(42): MediaWiki->run() #11 {main} That index is very suspicious. Perhaps the page content is so big that it triggers some kind of numeric overflow?