Not acceptable by any means. That would leave huge swaths of content which would never get fixed because the authors either don't care or aren't even around anymore. I'd rather move back to the old software if we can't fix it.
Fair enough: Though again that is determined by how endemic it is. I have not seen much in the way of this issue prior to @Ampersandwich mentioning it. If its only a few occurrences with regards to the massive fuck-ups then it should not be an issue. 'Huge Swathes' is a problem. Small occurances here and there is not exactly a major emergency, though one worthy of a fix. And I believe that alethiophile stated that the line-break issues should be able to fix via scripts, which is the big one I noticed.
Will talk to someone who may know how to fix this then. If its been done, then its possible and thus a simple matter of figuring out the 'how'.
It wouldn't actually even work, anyway. The corruption isn't in the import process, it's in XF's renderer being broken. All the relevant information is already in the current database.
Fine, but I propose we define the boundary between 'small occurrences' and 'huge swaths' as 'exactly as many instances as Vanathor is willing to go through and fix manually so the authors don't have to'~
Is it likely to be fixed any time soon? Because I stand by what I said before: if we can't fix this, better to roll back to the old software than to have parts of the archive unreadable. And if we do roll back, the sooner the better.
I'm pretty sure all of it did get transfered.
Nope even tried Searching for it by hand and through Alexander's name in Search neither shows up.
I am currently arguing with the XF devs about the render issue. Apparently, in the specific case of your post, the problem is that it treats [color=something]this[color=somethingelse]that[/color] as two nested tags without a proper closing of one, rather than implicitly closing each tag at the beginning of the next one (as it should, since nesting a [color] tag doesn't even make sense). This means that a big train of this runs into their recursion limit. No info on a resolution as of yet, but working on it.
It's there. Go to page three of the nsfw board and it's right there.
Yes, like the one we had in SMF, basically. Right now, you can either use the WYSIWYG rich-text editor, or use the plain-text 'editor' and type every single BBCode by hand.
Can we do a global find/replace on the archives to fix all past instances of [hr]?
If I had to guess it'd probably be something about the older threads not being indexed. I can find my new thread via the above method just fine.
I meant import-replace. If that's not possible, wipe everything in the current database older than the changeover, then reimport. Any edits made to posts older than that would have to be redone, but better working through a few days of edits than an untold number of errors.
No, just wipe out the stuff older than the move. Leave anything created since then intact.
It has one: [plain]
That would have been helpful to know when writing that post. Well, add to the complaints list that [nobbc] isn't properly converted to [plain], then.
This is another case in which the issue isn't corruption during the import process, but differences between the renderers. Here, if your explanation about the closing of tags is correct, the [color=transparent] is inside an [i], which is closed and so (under SMF) implicitly closes the [color]. This is the same in both databases. What's needed isn't another import, but a conversion which correctly turns SMF's BBcode into XF's (which, if we had it, could in this case be run just as effectively on the version already in XF's database).
