• An addendum to Rule 3 regarding fan-translated works of things such as Web Novels has been made. Please see here for details.
  • We've issued a clarification on our policy on AI-generated work.
  • Our mod selection process has completed. Please welcome our new moderators.
  • Due to issues with external spam filters, QQ is currently unable to send any mail to Microsoft E-mail addresses. This includes any account at live.com, hotmail.com or msn.com. Signing up to the forum with one of these addresses will result in your verification E-mail never arriving. For best results, please use a different E-mail provider for your QQ address.
  • For prospective new members, a word of warning: don't use common names like Dennis, Simon, or Kenny if you decide to create an account. Spammers have used them all before you and gotten those names flagged in the anti-spam databases. Your account registration will be rejected because of it.
  • Since it has happened MULTIPLE times now, I want to be very clear about this. You do not get to abandon an account and create a new one. You do not get to pass an account to someone else and create a new one. If you do so anyway, you will be banned for creating sockpuppets.
  • Due to the actions of particularly persistent spammers and trolls, we will be banning disposable email addresses from today onward.
  • The rules regarding NSFW links have been updated. See here for details.

XF Move To-Do List

Vanathor said:
Does anyone have any idea of how endemic the corruption of data is? Is it an issue effecting more then a handful of posts?

Because if not, a simple solution would be to host the old SMF board of QQ on a free hosting level, keep it shut down for new posting, but let users retrieve their old posts at their leisure if said post is corrupted.
Click to expand...
Click to shrink...
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.


Problem with the new rich-text editor: it's using server calls for operations that should be entirely local, like the insert-link dialogue, or the insert-spoiler dialogue. If you're on a slow connection, or the server's being laggy, this can be quite painful. I know this is fixable; it's been fixed on SB.
 
macdjord said:
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.
Click to expand...
Click to shrink...
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.

Problem with the new rich-text editor: it's using server calls for operations that should be entirely local, like the insert-link dialogue, or the insert-spoiler dialogue. If you're on a slow connection, or the server's being laggy, this can be quite painful. I know this is fixable; it's been fixed on SB.
Click to expand...
Click to shrink...
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'.
 
macdjord said:
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.
Click to expand...
Click to shrink...
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.

Regarding the rich-text editor...it goes on the pile. I'll poke at that once I get a moment.
 
Vanathor said:
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.
Click to expand...
Click to shrink...
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'~


alethiophile said:
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.
Click to expand...
Click to shrink...
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.


Another request: can we get a better plaintext BBcode editor? Or, well, any plaintext BBcode editor? Because what we have right now isn't really an editor at all; it's just a HTML text box. No formatting buttons, no colour selector - I get the distinct impression that whoever designed the XF editor only thew it in as a pro-forma alternative to the rich-text editor, without ever expecting anyone would actually use it.
 
Hey question I was just flipping through Alexander's Exalted/DxD quest when I noticed. All his smut isn't in the NSFW forum. It and a few other works seemingly didn't get transferred are they now lost?
 
Hm, how easy is it to upgrade this server again (hopefully without IP change^^)? And how well would that be covered by the subscriptions?
 
Walkir said:
Hm, how easy is it to upgrade this server again (hopefully without IP change^^)? And how well would that be covered by the subscriptions?
Click to expand...
Click to shrink...

There's one level left of upgrade that wouldn't require another ip change, and it'd run us another $30 a month. Our current level of subscriptions wouldn't cover that.
 
macdjord said:
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.


Another request: can we get a better plaintext BBcode editor? Or, well, any plaintext BBcode editor? Because what we have right now isn't really an editor at all; it's just a HTML text box. No formatting buttons, no colour selector - I get the distinct impression that whoever designed the XF editor only thew it in as a pro-forma alternative to the rich-text editor, without ever expecting anyone would actually use it.
Click to expand...
Click to shrink...
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.

Should it transpire that there isn't a way to fix this other than manually, I'm entirely on board with switching back to SMF. None of the benefits of XF are worth unreadable archives. I could wish that my money in switching hadn't been wasted, but the money is a means to the end of the forum.

I'm unsure what you mean by a "plaintext editor". You mean just a textarea which also has buttons above to insert BBcode tags?
 
Ampersandwich said:
there should be several "
" tags which are not present.
Click to expand...
Click to shrink...

Xenforo doesn't have a horizontal rule BBcode, and looking for one in custom BBcode resources have failed too.

There is a work around, if you want to use it: use center alignment to create your own.

[ center]---------------[/center]

Which will produce:

---------------​

Not ideal, I know, but better than nothing, imo.
 
alethiophile said:
I'm unsure what you mean by a "plaintext editor". You mean just a textarea which also has buttons above to insert BBcode tags?
Click to expand...
Click to shrink...
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.


tehelgee said:
Xenforo doesn't have a horizontal rule BBcode, and looking for one in custom BBcode resources have failed too.

There is a work around, if you want to use it: use center alignment to create your own.

[ center]---------------[/center]

Which will produce:

---------------​

Not ideal, I know, but better than nothing, imo.
Click to expand...
Click to shrink...
Can we do a global find/replace on the archives to fix all past instances of [hr]?
 
Unfortunately, the importer simply strips out
tags since they don't exist in XF BB. This is kind of silly, since it doesn't seem to want to help correct every other BBcode error, but that data was lost in the import. It's still present in the old DB, but getting at it would be fraught.
 
alethiophile said:
Unfortunately, the importer simply strips out
tags since they don't exist in XF BB. This is kind of silly, since it doesn't seem to want to help correct every other BBcode error, but that data was lost in the import. It's still present in the old DB, but getting at it would be fraught.
Click to expand...
Click to shrink...

Run the find/replace on the old DB, then reimport?
 
tehelgee said:
You'd end up duplicating everything in the old database.
Click to expand...
Click to shrink...
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.
 
macdjord said:
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.
Click to expand...
Click to shrink...

Uh, you want to wipe all the posts and such made since the import, just for the sake of a single type of bbcode tag that didn't see much use?
 
If I were to do this, it would take the same form as fixing the corrupted user data this last time took: set up a test install and DB, run the import (luckily this seems to be a deterministic process, so user IDs remain the same), do whatever transforms are needed on the test DB, merge the tables. It would require some forum downtime during the merge, but hopefully not more than an hour's worth. What would be lost would be edits to old posts made since the XF switch.

It would also be contingent on getting a way to closely manage the import process; it seems that the transforms run over the input data aren't really discretionary in the usual case. I'm classing this as a low-priority fix, since the damage it does is not to the point of illegibility and the fix would entail much effort and some data losses.
 
alethiophile said:
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.
Click to expand...
Click to shrink...

No, it's not that. Or at least it's not just that. Those masses of extra added "[/color]" tags are corruption, as well; they weren't present in the original at all. (Never mind the "[color=#A4A77F]", etc, following that, or the mass of irrelevant closing tags at the trailing end of the post.) Additionally, SMF's [code] and [tt] tags appear to have been merged, which is very wrong: the latter should have been changed to [font="Courier New"] tags or somesuch.

And, as you noted later, the [hr] tags have been lost. It should be almost trivial to add [hr] support with a plugin; at the very least unknown tags should be left in place, untouched, rather than stripped entirely. (As was done for the [nobbc] tag, which XF could sorely use an equivalent to.)

alethiophile said:
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.
Click to expand...
Click to shrink...

No, that's not right at all. Nesting a [color] tag does make sense, if (say) you want a single bit of red text in the middle of some cyan, and I'm pretty sure SMF and XF will handle those cases identically: basically like this, open open close close. What I remember doing on SMF wasn't just to nest and close color tags, though; there was another tag (explicit default size, maybe? I've forgotten) that I used to surround the whole shebang, implicitly closing all the "color" tags when I closed that outer tag. That's what SMF did that XF doesn't do: in XF, unclosed interior tags leak out of the enclosing tag.

SMF's code needs to be properly parsed and restructured in order to translate it to legal XF code, and the importer simply did not do this.

alethiophile said:
It would also be contingent on getting a way to closely manage the import process; it seems that the transforms run over the input data aren't really discretionary in the usual case. I'm classing this as a low-priority fix, since the damage it does is not to the point of illegibility and the fix would entail much effort and some data losses.
Click to expand...
Click to shrink...

It totally is to the point of illegibility. See the first link I provided, and scroll down. Highlight. That text shouldn't be transparent.

I don't see why you think the fix would entail loss of data. It should be possible to import only unchanged posts.
 
Ampersandwich said:
It totally is to the point of illegibility. See the first link I provided, and scroll down. Highlight. That text shouldn't be transparent.
Click to expand...
Click to shrink...
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).

The mass of closing tags in your post are not in the database either, so technically speaking they are not created by import corruption. They appear to be a product of XF's renderer, which I would guess based on this failure operates as follows: 1. parse the BBcode to a data structure, 2. attempt to render the data structure, 3. run into the limit on tag nesting depth and give up on rendering, 4. for some idiotic reason, having given up on rendering, dump all the remaining tags implied by your structure directly into the output stream, regardless of the fact that they aren't in the input. Again, the code is the same in the SMF database and in XF's, so a reimport will not immediately fix this situation.

That being said, if we did have a correct SMF -> XF converter, it would quite probably be best to run it during the import, due to that information which is lost. Unfortunately, from what I can tell, the import process is not customizable in the slightest, which means any such endeavor would have to modify XF's code on-the-fly.
 
You must log in or register to reply here.

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top