No longer strip <sha1> tags

[yzqzss]

It's 2023, and wikia isn't wikia anymore.
Missing sha1 makes it impossible to import wikidump revisions dedupely.

[nemobis]

So are you saying we never enter this "else" any more?

[makoshark]

The problem was that Wikia was adding <sha1/> tags under with pages, not revisions, in the XML.

Whether Wikia is Wikia and fact that the code was added a long time ago is not really relevant. The question is whether (a) the code's presence is causing problems and/or (b) whether this ever happens (at Fandom/Wikia or elsewhere). If Fandom/Wikia is no longer exporting these invalid SHA1's, I don't really object to removing it so I haven't seen it anywhere else.

My impression is that I don't really see what the harm is. If we ever see a SHA1 outside of a <revision>, we really do want to strip it!

[yzqzss]

• Removing the sha1 tag in its entirety just to deal with the misalignment is not appropriate, IMO.
• At least I haven't encountered any sha1 tag mismatches on fandom so far [2022,2023).
• Although <text> contains a sha1 attr, it does not have the same meaning as a separate sha1 tag. (cf. MediaWiki MCR and export 0.11)
• The MediaWiki import tool relies on sha1 de-duplication, which means that if the import fails on the way in, the imported revision will be skipped when re-importing (this is very very very helpful for importing large wikis, most of which have all sorts of complex extensions, special configurations, and so on, which cause the import to fail mid-import. Not being able to de-import is a disaster!)
• The import tool currently ignores <text> attr's (including sha1 attr, deleted attr, etc.), it only recognizes individual sha1 tags.

---

• If a misplaced sha1 tag does occur, it should be handled by the xml consumer themselves, and removing "<sha1>*</sha1>" from the pipe is simple.

[yzqzss]

:(