Since my webhoster relocated my scripts on a new server there are some configuration problems. The biggest is that user receives nginx timeouts if the query is too long or ends in an endless loop (see #20)

The reason for this new behavior is that as opposed to earlier the page content is not written directly to the browser but seems to be buffered.

Hello. When I try to use Wikiblame, I get a 403 "Forbidden" error. This happens with different browsers and different devices. Hope you can fix it soon.

When a search results in "was already present in the oldest revision searched dating from xx:xx, x xxxx xxxx." i am missing a button "start (new) search from here"

I'm currently getting matches to JS code inside HTML script tags on English Wikipedia, and it's because $start_token inside chop_content() is not working.

The article data now starts with <div class="mw-content-ltr mw-parser-output", but there's also <div class="mw-content-rtl mw-parser-output" on RTL scripts.

Search for "<u>", in a page that does contain this string.

Example:

You will notice the results are erroneously underlined.

Looks like it also makes the search somehow infinite… ?!

The use of WikiBlame is to find the diff showing where the searched changes happened.
However, currently that diff link isn't any more highlighted than the other links and is difficult to locate in day to day use. New users even don't find that link sometimes or it may take them some time (see here).

So it would very useful to add again that link after the end of the search with something like Link to diff (in bigger font).

Hi!
Could you update the tool so that the following translation is fixed?
https://translatewiki.net/w/i.php?title=Wikimedia%3AMessages%5Cx5b%27first_version_present%27%5Cx5d%2Fpt&type=revision&diff=6821236&oldid=6789559

see testcase at https://github.com/FlominatorTM/wikiblame/blob/master/test_cases.md

Thanks for this tool ❤️! I used it to find out who mistakenly added "Ringo" (Starr) to an article, and it does zero in on the first edit that added him on 2007-10-04. Unfortunately now that I've cleaned up the article, the search fails.

But, there was another, later edit on 2008-05-30 that also added "Ringo" to a different section. I couldn't figure out how to find that edit. I can't search linearly for it (the tool complains about too many revisions) and I can't add an ending date (or start date? it's very confusing) of the first edit to get the tool to search forward in time from that date. So I had to do my own binary search with View History's [Compare revisions] button.

Even if I set the start date to June 1 2008 and start oldest first, the tool doesn't find the addition, maybe because the first "Ringo" is always present. If the tool can only find an added string if it isn't already in the article, then something should mention that limitation. But shouldn't a linear search diff detect the second addition of the term? The diff should detect the new term. The more I fiddle with the settings, the less I understand the tool 😉.

http://wikipedia.ramselehof.de/wikiblame.php?project=wikipedia&article=AEG-Kleinow-Gestell&needle=18.047&lang=de&limit=50&offjahr=2015&offmon=11&offtag=2&offhour=23&offmin=55&searchmethod=lin&order=desc&force_wikitags=off&user_lang=de&ignorefirst=0&binary_search_inverse=false produces at least weird output.

Currently when user_lang is unspecified, it defaults to ab, even if lang is specified. Would it be better to default user_lang to lang?

Example URL: http://wikipedia.ramselehof.de/wikiblame.php?lang=en&article=Ruby_License

http://wikipedia.ramselehof.de/wikiblame.php?user_lang=en&lang=ru&project=wikipedia&article=Википедия%3AОформление+статей&needle=Обратите+внимание&skipversions=0&ignorefirst=0&limit=500&offtag=12&offmon=11&offjahr=2017&searchmethod=int&order=desc&binary_search_inverse=on&force_wikitags=on&user=

2 versions found
Comparing differences in 13:09, 20 October 2017 between 1 and 2 while coming from 2:OO 
Comparing differences in 14:54, 20 October 2017 between 0 and 1 while coming from 1:OO 
Deleting 1 earlier revisions, since removal must have been performed later

repeates indefinitely.

see https://de.wikipedia.org/wiki/Spezial:Diff/200224668/202383788?title=Benutzer_Diskussion:Flominator/WikiBlame

This is how it doesn't work:
http://wikipedia.ramselehof.de/wikiblame.php?lang=ja&project=wikipedia&article=%E6%9C%88&needle=%E3%83%8A%E3%83%88%E3%83%AA%E3%82%A6%E3%83%A0%E5%B0%BE&skipversions=0&ignorefirst=0&limit=500&offjahr=2020&offmon=7&offtag=31&searchmethod=int&order=desc&user=

"The unicode for "尾" U+5C3E contains 5C (backslash) and 3E (greater-than sign), so I guess this is causing some havoc"

It works without the character in question:
http://wikipedia.ramselehof.de/wikiblame.php?lang=ja&project=wikipedia&article=%E6%9C%88&needle=%E3%83%8A%E3%83%88%E3%83%AA%E3%82%A6%E3%83%A0&skipversions=0&ignorefirst=0&limit=500&offmon=7&offtag=31&offjahr=2020&searchmethod=int&order=desc&user=

I'd suggest changing "Start date" to "End date", since it's the end, chronologically speaking, of the period that will be searched, rather than the beginning. I confess the current nomenclature has always confused me. Maybe even "latest revision to check", to make it more explicit and less dependent on context.

Note: if/when #1 is implemented, then the date would instead be more accurately described as the "anchor date" (from it to the past, or from it to the future).

I don't know if something changed here or there. The blame tool is querying https://<language>.fandom.com/w/api.php Which is not the correct URL, it gets forwarded to /wiki/ and turned into an article lookup. The fandom API is at https://<language>.fandom.com/api.php

Wikipedia still works.

At first, it was an issue. But somehow i could solve it by myself. So now, i want to contribute an "installation guideline".

php-curl dependency is required, install it first :
sudo apt-get install php-curl
Then restart apache :
sudo service apache2 restart

1. Look for “nourrissons” in fr:Munster_(fromage)
2. Note WikiBlame considers that 21:12, 16 July 2022 revision has not the searched string, whereas it is the version which adds it.
3. The resulting diff is not the one which adds the searched string.

... it got lost during the transfer to translatewiki somehow.

I request commit access to this repo for translatewiki.net localisation updates. @siebrand already has a commit access for this, but I wish to increase redundancy.

It's common for MediaWiki wikis to have trouble configuring the Short URL setting, so the URLs are https://example.net/wiki/Foo instead of https://example.net/w/index.php/Page_title or https://example.net/w/index.php?title=Page_title.

WikiBlame should be able to handle wikis with the latter configurations, e.g. https://www.explainxkcd.com.

After merging #22, WikiBlame should work on HTTPS too. As nearly everything on Wikimedia uses HTTPS, it would be nice if this one wouldn’t be an exception. Probably moving to Toolforge is an option if the current server can’t switch to HTTPS.

WikiBlame performs its requests to the wiki in http, thus nowadays, on each request it gets a redirect to the https protocol. This causes a performance hit which should be noticeable.

Therefore, a "https mode" should be implemented, while keeping the possibility to perform http requests, if the WikiBlame application is used on some "out-of-wikimedia" wikis that don't support https.

tested with Google Chrome, this day, from France: KO

additional

https://www.ramselehof.de/ (personal website): OK

The Wikipedia page for this extension states that this application is under the GPL license, but no license text exists in the project.

I edit wiki in three language (sk,cs,en).
If I run WikiBlame from cs history page, it set default language to sk (may be for I have sk enviroment default set),
but this is not correct intuitive behavior because when I press search, I think so in that time I search cz page from I started run wikiblame, but it search in sk page with same name

Following support tickets were raised on Translatewiki.net support page -

1 - Support ticket : https://translatewiki.net/wiki/Thread:Support/About_Wikimedia:Messages%5Cx5b%27revision_date_format%27%5Cx5d/nl
Message: https://translatewiki.net/wiki/Wikimedia:Messages%5Cx5b%27revision_date_format%27%5Cx5d/nl
Comment: This needs qqq.

2 - Support ticket: https://translatewiki.net/wiki/Thread:Support/About_Wikimedia:Messages%5Cx5b%27paste_url%27%5Cx5d/en
Message: https://translatewiki.net/wiki/Wikimedia:Messages%5Cx5b%27paste_url%27%5Cx5d/en
Comment: URL needs to be capitalized in this message.

3 - Support ticket: https://translatewiki.net/wiki/Thread:Support/About_Wikimedia:Messages%5Cx5b%27no_valid_url%27%5Cx5d/en
Message: https://translatewiki.net/wiki/Wikimedia:Messages%5Cx5b%27no_valid_url%27%5Cx5d/en
Comment: URL needs to be capitalized in this message.

4 - Support ticket: https://translatewiki.net/wiki/Thread:Support/About_Wikimedia:Messages%5Cx5b%27inverse_stuck%27%5Cx5d/en
Message: https://translatewiki.net/wiki/Wikimedia:Messages%5Cx5b%27inverse_stuck%27%5Cx5d/en
Comment: This message needs support for PLURAL.

5 - Support ticket: https://translatewiki.net/wiki/Thread:Support/About_Wikimedia:Messages%5Cx5b%27from_url%27%5Cx5d/en
Message: https://translatewiki.net/wiki/Wikimedia:Messages%5Cx5b%27from_url%27%5Cx5d/en
Comment: URL should be capitalized in this message.

Observed behavior

I tried wikiblame on Main Page in 2016 and found problems with filtering revision history.

1. The variable $is_deleted_revision can be false for deleted revisions with username redacted. This causes the $versions array to contain revisions that won't return a valid $id in idfromurl().
   Here are the 20 revisions from Main Page used on the query. The class mw-userlink is normally on the username a element, like on the first and last revisions from this list. However, on the third revision, which has Username or IP removed instead of a username, the class is found on a span element. The wikiblame query from above shows 19 versions found, so the only exclusion is the last revision, which is the only redacted revision with a linked username.

2. The setting "Ignore minor changes" is not working, as line 475 on wikiblame.php looks for a string that does not exist. Running the same query from above but with this box checked still results in the same 19 versions found. The current element starting with <abbr class="minoredit" might be the one to target instead.

Possible solution

The API can simplify the code for filtering revisions, although the limit per request is 500 revisions. Here's how it could look:

"https://".$server."/w/api.php?action=query&prop=revisions&rvlimit=$limit&rvstart=$offset&titles=".$articleenc."&rvprop=ids|timestamp|flags|sha1&format=json&formatversion=2"

See Main Page revision using API.
The rvprop field has the flags value to include a minor boolean in the output, and the sha1 value to include a sha1hidden boolean in the output whenever the revision content was redacted.

First of all, thank you so much for this tool – it’s obviously very useful.

The usage section says “Versions that contain the searched string are marked with OOO, while versions lacking it show XXX”, but it seems that the current output uses OO, XX and XO according to whether the two versions compared contain the string.

Follow up of https://sourceforge.net/p/wikiblame/bug-reports/9/ and https://sourceforge.net/p/wikiblame/bug-reports/16/

Maybe some Javascript link next to article could open a prompt, ask for the url and insert it to the input fields ...

Just to point out this translatewiki thread.
I'm unsure what is the proper place to make the change, so let's notify both :)

It would be nice if we could have a checkbox to choose to go in the reverse direction (from the "start date" to the future, rather than from the start date to the past).

In fact, the term "start date" has always been quite confusing for me, since it refers to the start point of the algorithm's lookup, but also to the end of the time period covered by the range of edits being searched...

Possibly replacing the current Contact link in the footer.

It looks like the date separators are getting capitalized. For example, in Portuguese the separator is de (as seen here), but in the interface they show up as DE:

see https://de.wikipedia.org/wiki/Spezial:Diff/200224668/202383788?title=Benutzer_Diskussion:Flominator/WikiBlame

Can we please have this for MediaWiki other than those from Wikimedia Foundation, e.g. fandom.com / wikia.com?

I would imagine that instead of having a "Language" and a "Project" field, we would just have a single "Domain" field, in which we can provide "en.wikipedia.org" or "gta.fandom.com".

Correct me if I'm wrong, but if they are all powered by MediaWiki, I think most of the code would just work, right?

Some wikis do not have a subdomain, and even using "www" fails because they don't have the redirect set up — for example, https://translatewiki.net. Currently I can't use wikiblame on such wikis because the subdomain defaults to "en" if I leave it empty.

It would be nice if the lang parameter didn't automatically default to the user language if it's explicitly left empty:

Since it's already pre-filled when we open the tool page, I don't think removing the fallback behavior would be detrimental to the experience of people who would indeed want to use their UI language as the subdomain.

If there's no objection to this change, I'd be happy to submit a PR.