Extension talk:RottenLinks

The documentation tells me: If you would like to use RottenLinks with MediaWiki 1.39, you have to use the REL1_39 branch.

The link goes to https://github.com/miraheze/RottenLinks/tree/REL1_39

Then, the result is:

PHP Fatal error:  Uncaught ExtensionDependencyError: RottenLinks is not compatible with the current MediaWiki core (version 1.39.6), it requires: >= 1.40.0.
 in /var/www/test/mediawiki/includes/registration/ExtensionRegistry.php:432
Stack trace:
#0 /var/www/test/mediawiki/includes/registration/ExtensionRegistry.php(276): ExtensionRegistry->readFromQueue()
#1 /var/www/test/mediawiki/includes/Setup.php(278): ExtensionRegistry->loadFromQueue()
#2 /var/www/test/mediawiki/maintenance/doMaintenance.php(83): require_once('/var/www/test/m...')
#3 /var/www/test/mediawiki/maintenance/rebuildLocalisationCache.php(286): require_once('/var/www/test/m...')
#4 {main}
  thrown in /var/www/test/mediawiki/includes/registration/ExtensionRegistry.php on line 432

Now what?

Are you sure you're on the REL1_39 branch?

The latest version on REL1_39 is "1.0.20 (56e4017)". Do you see this Rotten Links version on Special:Version?

I just re-checked on my 1.39 install and it works fine.

;-) When adding the extension to LocalSettings, Mediawiki urges me to rebuild the Localisation cache. Therefore, no GUI, no SpecialVersion. The crash report that you see above is the result of calling "php rebuildLocalisationCache.php"

Having a second look, I found out the problem was my fault. Git usage is a little bit crappy. The green "Code" button suggests using the URL https://github.com/miraheze/RottenLinks.git

which unfortunately always is the latest version. Even if i choose the REL1_39 branch on the left-handside.

Downloading the zip file offered at the bottom of the same "Code" menu solved the problem.

Lessen learned ... the problem is always sitting in front of the screen.

Good to hear that you solved it :)

That would allow the extension to not require the regular launch of the script

I second this request! It would make the list always up-to-date and useful!

And how to configure it? I can see that to install this extension I will obviously need one, or some sites will block me almost immeadiately, but a proxy server is a security risk, so I would very much like some recommendations, please :-)

How is one supposed to set the value? I have tried setting it to one of these:

• "_blank"
• _blank
• true

in LocalSettings.php, but it doesn't seem to have any effect. External links still open on the same tab as the MW site.

Thank you for an otherwise excellent extension.

Not reproducable.

We have updated to MW 1.35.4 recently, additionally we switched to PHP 7.4.24.

When running with PHP 7.4, the script begins checking external links and after some thousand or more it crashes:

InvalidArgumentException from line 152 of /var/www/test/mediawiki/vendor/guzzlehttp/psr7/src/Response.php: Status code must be an integer value between 1xx and 5xx.

#0 /var/www/test/mediawiki/vendor/guzzlehttp/psr7/src/Response.php(99): GuzzleHttp\Psr7\Response->assertStatusCodeRange()

#1 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/Handler/StreamHandler.php(115): GuzzleHttp\Psr7\Response->__construct()

#2 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/Handler/StreamHandler.php(50): GuzzleHttp\Handler\StreamHandler->createResponse()

#3 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/Middleware.php(233): GuzzleHttp\Handler\StreamHandler->__invoke()

#4 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php(37): GuzzleHttp\Middleware::GuzzleHttp\{closure}()

#5 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php(54): GuzzleHttp\PrepareBodyMiddleware->__invoke()

#6 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/Middleware.php(57): GuzzleHttp\RedirectMiddleware->__invoke()

#7 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/HandlerStack.php(71): GuzzleHttp\Middleware::GuzzleHttp\{closure}()

#8 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/Client.php(351): GuzzleHttp\HandlerStack->__invoke()

#9 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/Client.php(112): GuzzleHttp\Client->transfer()

#10 /var/www/test/mediawiki/vendor/guzzlehttp/guzzle/src/Client.php(129): GuzzleHttp\Client->sendAsync()

#11 /var/www/test/mediawiki/includes/http/GuzzleHttpRequest.php(204): GuzzleHttp\Client->send()

#12 /var/www/test/mediawiki/includes/libs/http/MultiHttpClient.php(500): GuzzleHttpRequest->execute()

#13 /var/www/test/mediawiki/includes/libs/http/MultiHttpClient.php(191): MultiHttpClient->runMultiHttp()

#14 /var/www/test/mediawiki/includes/libs/http/MultiHttpClient.php(145): MultiHttpClient->runMulti()

#15 /var/www/test/mediawiki/extensions/RottenLinks/includes/RottenLinks.php(25): MultiHttpClient->run()

#16 /var/www/test/mediawiki/extensions/RottenLinks/maintenance/updateExternalLinks.php(57): RottenLinks::getResponse()

#17 /var/www/test/mediawiki/maintenance/doMaintenance.php(107): UpdateExternalLinks->execute()

#18 /var/www/test/mediawiki/extensions/RottenLinks/maintenance/updateExternalLinks.php(83): require_once('/var/www/test/m...')

#19 {main}

Not reproducable. Don't know why but now the script completes without error.

Using the same setup I run into the same error:

InvalidArgumentException from line 152 of /html/secret-wiki-neu/mediawiki/vendor/guzzlehttp/psr7/src/Response.php: Status code must be an integer value between 1xx and 5xx. 

#0 /html/secret-wiki-neu/mediawiki/vendor/guzzlehttp/psr7/src/Response.php(99): GuzzleHttp\Psr7\Response->assertStatusCodeRange(999)

I tried to fix the Guzzle thing with this fix, but no luck...

Using RottenLinks version 925f40d.

I wanted to use a version supporting 1.35, but as there are not branches or tags in git, this is not possible. I was able to find a fork that had a working version, but I'd appreciate if you would use versioning so we can use the correct versions for MW releases.

I second Krabina. Since my sites rely heavily on SemanticMediaWiki, which does not run with MW 1.36 so far, I have to stick to MW 1.35. It would be great if you moved your code to gerrit and introduce branches.

@Krabina: Where can I find this fork for 1.35?

Thanks for your work on RottenLinks!

Update: I found commit 925f40d (version 1.0.14) is the newest that is still working with MW 1.35.

I think I used one of the forks: https://github.com/miraheze/RottenLinks/network/members I guess it was the WikiTeq fork...

Fixed with version 1.0.16

Just updated 2 wikis from MW1.34 to 1.35, same problem on both. When I run update.php at the end, I get the following error. If I disable rottenlinks update.php finishes and the wiki seems to work normally. If I then re-enable RottenLinks, wiki continues to work and RottenLinks "Status of external links" page seems to work as well. However, update.php now fails again if I run it.

Here is the error:

...rottenlinks table already exists.
...rl_externallink in table rottenlinks already modified by patch /home/xxx/xxx.xxx..ca/extensions/RottenLinks/includes/../sql/patches/patch-primary-key.sql.
Adding rl_id field to table rottenlinks ...Wikimedia\Rdbms\DBQueryError from line 1699 of /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/Database.php: Error 1068: Multiple primary key defined (ccmdbpriv-db.ccmdb.kuality.ca)
Function: Wikimedia\Rdbms\Database::sourceFile( /home/xxx/xxx.xxx..ca/extensions/RottenLinks/includes/../sql/patches/patch-add-rl_id.sql )
Query: ALTER TABLE `mw_rottenlinks`
 ADD COLUMN rl_id INT AUTO_INCREMENT PRIMARY KEY


#0 /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/Database.php(1683): Wikimedia\Rdbms\Database->getQueryException('Multiple primar...', 1068, 'ALTER TABLE `mw...', 'Wikimedia\\Rdbms...')
#1 /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/Database.php(1658): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('Multiple primar...', 1068, 'ALTER TABLE `mw...', 'Wikimedia\\Rdbms...')
#2 /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/Database.php(1227): Wikimedia\Rdbms\Database->reportQueryError('Multiple primar...', 1068, 'ALTER TABLE `mw...', 'Wikimedia\\Rdbms...', false)
#3 /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/Database.php(5075): Wikimedia\Rdbms\Database->query('ALTER TABLE `mw...', 'Wikimedia\\Rdbms...')
#4 /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/Database.php(5010): Wikimedia\Rdbms\Database->sourceStream(Resource id #956, NULL, NULL, 'Wikimedia\\Rdbms...', NULL)
#5 /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->sourceFile('/home/ccmdb/ccm...')
#6 /home/xxx/xxx.xxx..ca/includes/libs/rdbms/database/MaintainableDBConnRef.php(35): Wikimedia\Rdbms\DBConnRef->__call('sourceFile', Array)
#7 /home/xxx/xxx.xxx..ca/includes/installer/DatabaseUpdater.php(727): Wikimedia\Rdbms\MaintainableDBConnRef->sourceFile('/home/ccmdb/ccm...')
#8 /home/xxx/xxx.xxx..ca/includes/installer/DatabaseUpdater.php(801): DatabaseUpdater->applyPatch('/home/ccmdb/ccm...', true, 'Adding rl_id fi...')
#9 /home/xxx/xxx.xxx..ca/includes/installer/DatabaseUpdater.php(512): DatabaseUpdater->addField('rottenlinks', 'rl_id', '/home/ccmdb/ccm...', true)
#10 /home/xxx/xxx.xxx..ca/includes/installer/DatabaseUpdater.php(480): DatabaseUpdater->runUpdates(Array, true)
#11 /home/xxx/xxx.xxx..ca/maintenance/update.php(181): DatabaseUpdater->doUpdates(Array)
#12 /home/xxx/xxx.xxx..ca/maintenance/doMaintenance.php(107): UpdateMediaWiki->execute()
#13 /home/xxx/xxx.xxx..ca/maintenance/update.php(253): require_once('/home/ccmdb/ccm...')
#14 {main}

Still getting this error in the newest version I just downloaded

can confirm, MW REL1_35, php 7.3 and 7.4.3, mariadb 10.3.25

WikiTeq is working on a fix for this issue. It should be ready within a week.

I fixed the error and created a pull request https://github.com/miraheze/RottenLinks/pull/26 and it was merged to the master branch

tried with version 1.0.11 (#4e7e675) and 1.0.12 (#1f4b396) but still getting this when trying to run update.php:

Adding rl_id field to table rottenlinks ...Wikimedia\Rdbms\DBQueryError from line 1699 of /path/to/wiki/includes/libs/rdbms/database/Database.php: Error 1068: Multiple primary key defined (localhost)
Function: Wikimedia\Rdbms\Database::sourceFile( /path/to/wiki/extensions/RottenLinks/includes/../sql/patches/patch-add-rl_id.sql )
Query: ALTER TABLE `mw_rottenlinks`
 ADD COLUMN `rl_id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST


#0 /path/to/wiki/includes/libs/rdbms/database/Database.php(1683): Wikimedia\Rdbms\Database->getQueryException()
#1 /path/to/wiki/includes/libs/rdbms/database/Database.php(1658): Wikimedia\Rdbms\Database->getQueryExceptionAndLog()
#2 /path/to/wiki/includes/libs/rdbms/database/Database.php(1227): Wikimedia\Rdbms\Database->reportQueryError()
#3 /path/to/wiki/includes/libs/rdbms/database/Database.php(5073): Wikimedia\Rdbms\Database->query()
#4 /path/to/wiki/includes/libs/rdbms/database/Database.php(5008): Wikimedia\Rdbms\Database->sourceStream()
#5 /path/to/wiki/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->sourceFile()
#6 /path/to/wiki/includes/libs/rdbms/database/MaintainableDBConnRef.php(35): Wikimedia\Rdbms\DBConnRef->__call()
#7 /path/to/wiki/includes/installer/DatabaseUpdater.php(769): Wikimedia\Rdbms\MaintainableDBConnRef->sourceFile()
#8 /path/to/wiki/includes/installer/DatabaseUpdater.php(843): DatabaseUpdater->applyPatch()
#9 /path/to/wiki/includes/installer/DatabaseUpdater.php(554): DatabaseUpdater->addField()
#10 /path/to/wiki/includes/installer/DatabaseUpdater.php(522): DatabaseUpdater->runUpdates()
#11 /path/to/wiki/maintenance/update.php(181): DatabaseUpdater->doUpdates()
#12 /path/to/wiki/maintenance/doMaintenance.php(107): UpdateMediaWiki->execute()
#13 /path/to/wiki/maintenance/update.php(253): require_once('/var/www/html/w...')
#14 {main}

installation is still on MW REL1_35, php 7.4, SMW 3.2.2, and mariadb 10.3.25

Still a problem in 1.0.12 (7ce92c7) 2021-01-12T15:37:52 as cloned 2021-03-10.

Was a previous version once installed? Or is it a new installation of the extension?

Indeed, the system was upgraded from 1.31 to 1.35. Rottenlinks was working as expected in the previous system. After upgrading Mediawiki and updating Rottenlinks, the reportet error occurred.

Same as Oetterer, I have been running the extension for a long time and it's only acting up during the update.php since the time I raised this issue. I was just upgrading from the most recent version at the time, though, not a large step upgrade. I don't know what version of Rottenlinks I had before this started acting up, it's been a while. If I comment out the extension while running update.php, and then enable it again, it seems to be working fine. I haven't tried to force it to run an update of the list to see if that gives errors.

Got it. My guess is that after our patch the extension will do fine in a new installation, but won't work with an existing installation. Let me see if we can fix it. We're a bit overloaded right now, but please feel free to ping me again.

Is there a specific table/file/other content that stores this that I could just blow away so the install is "as new"? Then I would just need to run the update to re-populate it. Mind you, if it was that easy you could probably put it into the update itself. Just hoping I guess :-)

You can try dropping the rottenlinks table.

Please let me know if this works.

Thanks Tosfos, I tried that. I ran drop table mw_rottenlinks at the SQL console and deleted the table. Update.php finishes without error after that. Was able to manually run updateExternalLinks.php after and this re-created the content. That allows me to fix the problem so it doesn't show up at every update.php, but it would be even better if RottenLinks just caused that to happen automagically when update.php runs.

Got it. Just making sure this fix worked. We'll incorporate this functionality into the extension update itself. We'll submit a patch soon.

Just noting that our patch was submitted and is awaiting merge. It is here.

Merged! If you're experiencing these issue, update your extension to version 1.0.16.

I've tried $wgRottenLinksExcludeWebsites = [ "http://www.example.com" ]; but it still checks web pages on that site. Thanks.

Just checked the code and the answer is to use $wgRottenLinksExcludeWebsites = [ "www.example.com" ];

I'll edit the wiki page accordingly. Thanks.

I'd like to use this extension, but I'm not sure how to install it. Other extensions have a Download Extension link to a tarball for each version or a suggested addition to a composer file.

Any particular reason why this is different to the other extensions?

Thanks!

The installation procedure, as well as the download link is included in Extension:RottenLinks#Installation. Do you encounter any problems?

Link just takes me to the Github repository. README has no instructions. Not sure what to do. Other extensions take me to a download link with a tar command to copy.

Just put all the files in extensions/RottenLinks folder. You can use git clone or download and extract the zip file of the repo.

OK, can see the Zip download link in Github - thanks. Still, I wonder if this extension would get more use if it could be installed in the "normal" way? Up to you, of course.

User that are on shared hosters usually have no shell access. Since they have no means of runnung php extensions/RottenLinks/maintenance/updateExternalLinks.php manually they can't use this extension.

Is there any way, that extensions/RottenLinks/maintenance/updateExternalLinks.php can be triggered as part of running the webupdater (mw-config) so this extension can be used as well? The only workaround currently is to import a recent dump of the mediawiki DB into XAMPP und running extensions/RottenLinks/maintenance/updateExternalLinks.php in the shell from there and then looking up and changing each link manually on the live version.

There's a lot you can't do without shell access on Mediawiki. I'll see what can be done but maybe consider a host with more control.

There used to be the MaintenanceShell extension that would allow you to run individual script. Since the "updateExternalLinks.php" script can potentially run for many hours it is not advisable to do this via the webupdater anyways. Indeed I'd also suggest to switch to adequate hosting.