• The site has now migrated to Xenforo 2. If you see any issues with the forum operation, please post them in the feedback thread.
  • 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

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.
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.
 
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.

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.
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'.
 
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.
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.
 
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.
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'~


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.
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?
 
Could you do something about the forum loading slowly?
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?
I'm pretty sure all of it did get transfered.
 
Hm, how easy is it to upgrade this server again (hopefully without IP change^^)? And how well would that be covered by the subscriptions?
 
Hm, how easy is it to upgrade this server again (hopefully without IP change^^)? And how well would that be covered by the subscriptions?

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.
 
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.
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?
 
there should be several "
" tags which are not present.


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.
 
I'm unsure what you mean by a "plaintext editor". You mean just a textarea which also has buttons above to insert BBcode tags?
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.


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.
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.
 
Find all threads by * in the information tab on the profile pages don't work.
 
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.


Run the find/replace on the old DB, then reimport?
 
You'd end up duplicating everything in the old database.
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.
 
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.

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.
 
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.

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.)

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.

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.

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.

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.
 
It totally is to the point of illegibility. See the first link I provided, and scroll down. Highlight. That text shouldn't be transparent.
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.
 

Users who are viewing this thread

Back
Top