The problems are a lot of used tags in old posts from the old vbulletin.
People who used there size 2 for a readable size have now texts in a too small way.
I have not thought about, that it would be easier to change all [size=2 in [size=4, maybe i will do this now.
Before i tried to get rid of all [size=2 ... [/size
My tried regex only takes the first [size=2 and the last [/size; then i have to find [/size [size=2 many times between start and end.
So if I understand correctly you already ran that expression you wrote and executed the changes on a site that you had imported from VB and you also did not back up your DB before you started running regex against the post and must fix this manually now?
If so that should be fixed before changing any other posts but without knowing exactly what you did I still can't advise you on what to do as I don't want to take responsibility for fixing an unknown erroneous regex replacement against a column in table while someone else uses my processes remotely on what I assume to be a live site... it's a scary thought.
Ultimately the best course of action is to not have the 'save changes' box checked until you know for sure it will work, I get that the broken result might not have showed itself for thousands of lines down the page so it is completely understandable.
Since I assume you are at this point already I would ask if you took a backup of your db before you started making replacements to it?
This is only an issue because unless every single closing /size was the last entry in each post that you replaced on you would have no way of knowing where to reinsert the [/size] closing tag nor can I say without seeing your regex if it would have caught strings starting with a size=2 wrapping but ending with a let's say size=5 wrapping and I am confident enough to say I don't think every post you changed ended in [/size] and I would guess that you don't want to just remove all size=ANYSIZE instances if that is the case.
I do hope for your sake that you backed up your DB before getting started or that your import to xf is not live yet.
(also you should put this around [plain] [size=2 , or [quote], [/ANYBBCODE] [/plain] , etc when you don't want it to parse in a post but want to show how it looks on your site this way someone like me can see what you actually intended to show me and so you can paste the actual text of the post you are making an example of)
I know that there is a way in perl to find one or more or all needles, but i dont know to say it in xenforo/php regex style.
I work with komodo, but the code i try there is not the same i need here.
This addon uses PCRE (Perl Compatible Regular Expressions) which literally uses the same syntax and semantics as Perl 5. I am not certain what you mean when you say komodo (there are many products with the name komodo/comodo) but the top hit for me on google was "Komodo Rx Toolkit" used for creating regex for you within the "Komodo IDE" point and click interface and that itself looks like it supports at least 6 flavors of regex each with small or great differences in semantics and syntax from the others.
The second problem is that we have a lot of urls without the t (for thread) and only with p (for posts), in vb it was enough to adress a post-id. Here in XF i dont know how to adress a thread/post only with the post id.
You can address a post id in xf like I posted above
Right click that link and open it in a new tab.
So the question is how i can come from showthreads.php?p=12345 to the right threadid here?
Maybe i have to write a small php-script looking for ?p=xxxx, get the thread and add a &t=yyyy?
From this i can do a regex again (or manage it directly in my script)
Well when you imported... if all your thread IDs and post ids stayed the same, then you can use regex alone usually to rewrite the links.
If a post on your VB site or a thread on your VB site does not match up with the post/thread of the same ID on your XF site then yes that would be import/post-import cleanup work most likely involving a script using regex for matching internal link references, extracting 'source id->destination id' , constructing the list of replacements for destination and applying the replacements which is outside of the scope of this addon.
But maybe XF can manage this also?
As far as the builtin XF importers managing this, it is highly unlikely though possible if they run out of things to do. There are a lot of other platforms one could be importing from thus there could be a lot of different format/syntax/url changes to account for and I would say at this point with the devs working on XF2 that it is probably not happening in the immediate if ever.
The scope of this is more the responsibility of the person doing the import though often times I find this stuff can take longer than the actual import itself.
Sleep time.
