A project for the RottenLinks extension being developed to easily make the detection and management of dead links easier.
Fri, Feb 5
Jan 10 2021
Jan 1 2021
Done (using P365).
Dec 22 2020
Oct 24 2020
I was deploying the ALTERs to the wikis while RottenLinks was disabled (the ALTERs cannot be done live using pt-osc, unfortunately), but I forgot to re-enable RottenLinks. For now, I have enabled RottenLinks. The extension only needs to be disabled again (and the update scripts killed) if you are deploying the schema changes on databases.
Oct 13 2020
@John it doesn't look like larger VARCHARs are possible. Even if you don't use the rl_id field, it does seem to be working fine at first glance, without fundamentally changing the schema (the current, old fields can stay). What do you think?
Oct 10 2020
02:56:34 <+SPF|Cloud> JohnLewis: db7 doesn't seem to accept a varchar(8192) for rl_externallink 02:56:38 <+SPF|Cloud> ERROR 1071 (42000): Specified key was too long; max key length is 3072 bytes 03:01:39 <+SPF|Cloud> looking at https://mariadb.com/kb/en/innodb-system-variables/#innodb_large_prefix and https://mariadb.com/kb/en/innodb-large_prefix-deprecated-resulting-key-length/, relying on such huge varchars for index keys seems deprecated 03:09:42 <+SPF|Cloud> I don't think having the varchars as primary key is a good idea, given the deprecation comments. What do you think?
Oct 9 2020
While the change was committed, the change has not been applied to existing tables.
Sep 8 2020
Jun 30 2020
Jun 18 2020
Jun 17 2020
Jun 16 2020
Jun 7 2020
WikiLirik sözcüleri eleştirisel pozitif-negatif düşünce karşılaştırma
PyschoLyricWiki Attack Groups
Ben ötesi psikoloji
Jun 6 2020
Mar 23 2020
Thank you for the contribution and spotting issues that escaped testing for this particular extension!
The third point is linked to T5295.
Mar 22 2020
RottenLinks is more of a maintenance-based tools. The current section therefore is appropriate.
Mar 2 2020
Sorry for the bad classification.
Feb 16 2020
The name “RottenLinks” is a noun and as such would not have another translatable alternatives.
Feb 4 2020
Jan 8 2020
The extension is built on standard MediaWiki code - the support for —wiki is through standard MediaWiki (as proven above).
I fully understand what you explain about the PHP magic constant __DIR__ - but shouldn't your script then at least support the given --wiki database name and use it? In all my tests, it does not.
Thank you for documenting your approach. Here is mine - using the unpatched script updateExternalLinks.php:
root@mw1:~# cd /srv/mediawiki/w/extensions/RottenLinks/maintenance/ root@mw1:/srv/mediawiki/w/extensions/RottenLinks/maintenance# php updateExternalLinks.php The wiki database '' was not found.
Can you please tell me HOW you tested it? As I already explained, my installations are like this:
Jan 7 2020
$ w3m -dump https://abj.miraheze.org/wiki/Special:RottenLinks?stats=1
Status of external links
Jan 6 2020
wfGetDB( DB_MASTER ) opens a database connection from the wiki where the script is being ran (namely the --wiki option, or whatever the value of $wgDBname is).
as I wrote in my initial message, the original PHP script does not recognize when run from e.g. /MYPATH/wiki/en/extensions/ - it then also checks all URLs in the IntactiWiki pool's database named intactiwiki, but not in the English Intactiwiki database, which is named intactiwiki_en. My patch fixes this for me.
This is found under statistics.
The script is fairly bandwidth intensive. It’s not reasonable to allow any user on a wiki to run it on demand - it would be a decision of the system administrators running the extension when to run it.
I am not saying "please update it for my wiki".
I am saying "please give users a way to update it without needing a Steward's help."