In T165612#3405964, @Samwilson wrote:

Do we want to set up some monitoring of 404s so that we can track if there are popular broken incoming links? I guess it wouldn't be hard to add to the meta collecting?

Might be a very good idea.

Also, we should verify that the parameters still work between the old xtools and new xtools. I'd like to set up just a 301 redirect to get people to the new xtools eventually.

I assume we'll have the redirect functionality done via some code we add to the old XTools, and not by lighttpd settings or whatever (which may not even be possible). If this is the case we can still collect usage tracking that will effectively tell us which popular links are broken.

Looking at the list at T163283, I wanted to point out a few things that I'm not sure we've discussed:

• ./rangecontribs/index.php should not redirect to the new XTools or throw a 404. The old tool should remain functional until T163562 is resolved.
• ./autoblock/index.php should check which wiki they are querying for and redirect them to that wiki's Special:AutoblockList
• ./Export.php We haven't added exporting functionality yet, and even if we do we may not add a dedicated endpoint for it. Instead we might use the same /tool/wiki/whatever route but allow a parameter like ?export=csv to programmatically download the data. In the meantime I think we should keep the legacy Export.php functional.
• ./echo/index.php redirect to Special:Notifications
• ./api.php We have a /api route but it doesn't offer what the old API did. We can get to that later. It was used only for a gadget that has been broken for a very long time.
• ./agent/config.php This is for the aforementioned gadget and XEcho settings. We can just kill it or maybe redirect to Special:Notifications.
• ./editsummary/index.php We haven't yet rebuilt this very basic tool. Personally I think it should be part of the Edit Counter, as another sub-tool. Let's keep the old tool running for now.
• ./isAdmin/index.php, ./ipcalc/index.php, ./pcount/index.php, and ./pcount/index2.php all redirect to other working tools, so we shouldn't need to do anything extra (there might be a double redirect but no biggie)
• ./rfa/index.php, ./rfbp2/index.php and ./rfap/index.php should be kept as-is until they are implemented in the rewrite.

The smart redirecting for ./autoblock/index.php and ./echo/index.php sounds like overkill (and potentially confusing to the user). How about just a page that tells the user that the tool has been deprecated and they should check the replacement special pages instead.

The old routes are listed in T163283, and I've checked that we've got everything in that list covered at the moment.

So is this task done or do we need to address the things mentioned in T165612#3408385 before we can launch the new version?

I've created T170098 to track the export feature. The other big feature here seems to be supporting the gadget; I thought I'd seen a ticket for that, but can't find it now.

I think that as we're not going to do a full redirect of the old site, we don't need to worry about catching every URL before we launch the new version.

There will be more tasks required before the old XTools can be fully redirected and turned off though (as @MusikAnimal says).

As for the query string parameter names, I've read through things and as far as I can find we've covered everything (e.g. we're accepting user and username for all inputs, and project stays the same, and the various other ones I think are as they were in old Xtools).