Will you be creating an importer for phpBB?

Paul B

XenForo moderator
Staff member
I know phpBB isn't widely regarded but my site started out on a free host and we still use phpBB for the forum.

I've been waiting for the right thing to come along before upgrading and I think I've found it.

A migration script would be absolutely essential though and is a show stopper.

I understand that your priority is to get the core functionality working and presumably you'll be targeting vB forum owners first but after that?
 
Soon like days, weeks, months, years?

I'll think about paying for a conversion though... .honestly at this point I'd just love to have someone who knows how to do it right.

That still has the password re-set issue though correct? i'd love to avoid that. Is there conformation that there will be an officiall phpBB port in the official release?

Floris did some work for me before and it went extremely well. I just do not have the time to mess with it myself and he was very reasonable.
 
See I agree with you there. But one thing I realized...

#1 25% of my users did NOT have updated emails. So they signed up 2,3,4 yrs ago and kept that old email, which no longer works. So unless I know them personally, or can match IP's it's hard for me to just give someone access to the account.

Hence why it's best to plan a migration, get the word out on the board for people to update their emails. If they aren't even going to do that, then are they really engaged users ?

#2 Some servers have limits on emails, so if you can only send 100-300 emails and have thousands of members. Right there it can take half a day almost or a full day to send out all the emails.

If you're running a decent sized community on a $10/month shared hosting ........ then yes you'll have limitations.
 
i agree most cpanel servers todays have limited number of emails sent per hour to avoid spam abuse.
so 10,000 members resetting their email password on the date of forum conversion will be an issue
to forum owners on a shared hosting.

surely theres a way to convert phpbb-->xenforo without having a password issue

Give it some time. They're focusing on getting a stable and effective forum software right now and nothing else. Hence, there's none of the blog, CMS, etc. stuff. The only reason there's a vBulletin 3 converter is pretty self-explanitory, coming from where they came from. That also explains why the current vBulletin 4 and SMF 2.0 converters are community-driven.

Mind you, the password conversion also shows the flaws of vBulletin, considering phpBB, IPB, MyBB, SMF (you need to login twice as a security measure, but it still counts), and just about everyone else supports password conversion at this time.
 
Hence why it's best to plan a migration, get the word out on the board for people to update their emails. If they aren't even going to do that, then are they really engaged users ?

I prepared members a couple of weeks beforehand, and repeated telling them about it as often as possible. I also sent two or three emails. And once the conversion was done, I put up a page node in XF that mentioned the conversion, and the password issue. Just about all the regulars were able to figure it out, so there really was no issue with it. (I moved from SMF --> vB --> XF.) I want to keep my XF installation as stock as possible, to make upgrades go that much easier. And a moment's inconvenience to members probably saved me several hours of trying to cobble something together that would work.

That is incorrect, the majority of people don't convert the password, they use the hash in it's stored state and either emulate the checking logic, or pass it off to a 3rd party piece of code.

One thing that might help some of the members viewing this thread: hashed strings (such as passwords) can never be converted. The encryption works one way. What happens is, a user enters a password at registration, and it is stored in an encrypted format. When they log in, the password they type during login is also encrypted using the same method, and then compared to the value stored in the database. If it's a match, the user can log in.

I occasionally had to tell this to members on our big board, who could not understand why we could not just pull their password out of the database, or why somebody couldn't decode it for them. (I didn't get into the whole "brute force" hacking angle with them.)
 
That is incorrect, the majority of people don't convert the password, they use the hash in it's stored state and either emulate the checking logic, or pass it off to a 3rd party piece of code.

What I refer to specifically is that converting to IPB, MyBB, etc. doesn't require sending out emails to reset the passwords and stuff. It isn't really practical, as swatme basically said.
 
My problem was also importing SMF's passwords to vBulletin. So I figured it was a lost cause anyway. Why spend hours messing with code on vB and XF to make old passwords compatible, when a few messages costing me a few minutes each, handle it much easier? Time is money, cut your losses, etc. ;)
 
My problem was also importing SMF's passwords to vBulletin. So I figured it was a lost cause anyway. Why spend hours messing with code on vB and XF to make old passwords compatible, when a few messages costing me a few minutes each, handle it much easier? Time is money, cut your losses, etc. ;)

One of the interesting things I found helping people with imports is they thought that having more users would take exponentially more time to deal with for a reset. Given that sending out emails is automated and clicking "send" is the same for 1 or 10,000 is the same ........ and then each user clicks 1 link and fills in a new password, that's it.
 
One of the interesting things I found helping people with imports is they thought that having more users would take exponentially more time to deal with for a reset. Given that sending out emails is automated and clicking "send" is the same for 1 or 10,000 is the same ........ and then each user clicks 1 link and fills in a new password, that's it.

Very true. The only issue I would worry about is that if you have a larger number of users, there will be a larger number of them who can't figure out the password resets on their own, and have to contact the staff. More of a staff support issue in other words. But when you have a forum that large, duties like this are usually split up among several staff members anyway and the work is tedious, but not time consuming or frustrating. And like Brogan did with his forum, it's a no-brainer to put up a small notice about resetting passwords.

Unless you are a developer who specializes in converting forums from one system to another, a forum conversion is such a small fraction of total time a typical forum admin will spend working on the forum as a whole, it's not worth worrying about.
 
And why is it not practical ? I have performed thousands of imports and have only ever heard this as an assumed issue before hand - opposed to experiencing the reality of it - ever.

How is vBulletin the only one who can't convert passwords after all these years (apart from laziness on their part)? I really want to know.
 
How is vBulletin the only one who can't convert passwords after all these years (apart from laziness on their part)? I really want to know.

If I had a dollar for every time I've explained that .............
biggrin.png
 
If I had a dollar for every time I've explained that ............. :D
Been there, done that, got the 7cc481e3eab24b4ef9ccc945c00f7784 (that's an MD5 hash for "t-shirt"). :D

Basically, passwords themselves can never be converted. Ever. No way, no how. Nope. Nada. Impossible. Ain't gonna happen. Does not compute. Hit the road, Jack. :D Hashing is one-way only. (Aside from brute-force hacking with millions of combinations, but that's not "standard usage" by any stretch of the imagination.)

You can modify or configure the target forum in the conversion to use the existing password hashes, but that is not converting passwords. Even vB could be altered for that.

I am guessing that when XF eventually offers more conversion options, there will be some kind of flag in there to let XF know that the user data for that record was imported, and from which system, so they can apply the appropriate encryption for login. I actually could have modded that into XF myself coming from SMF, but it was not worth the effort.

Whoever found this of value, please send $1 PayPal to Jerry... :D
 
Has anyone used a solution like giving everyone a new password based on their email address and username (or combo)....or some other info, and then letting them sign in and change it...as opposed to other resets from scratch?
I guess that brings up the question of what their password is in the time - now or never - before they do a reset?

On the other hand, a reset separates the men from the boys..so to speak. That is, members who never posted, spammers and those who have passed away, etc. etc......will never reset. At some point, it would then probably be a good idea to prune those who never made a post.
 
Has anyone used a solution like giving everyone a new password based on their email address and username (or combo)....or some other info, and then letting them sign in and change it...as opposed to other resets from scratch?

If you use a calculation based on a known piece of data it can be compromised. if my email is jerry@example.com and I'm told that my password is the reverse (for example), I can compromise any account of people that I know the email address off.

I guess that brings up the question of what their password is in the time - now or never - before they do a reset?

On the other hand, a reset separates the men from the boys..so to speak. That is, members who never posted, spammers and those who have passed away, etc. etc......will never reset. At some point, it would then probably be a good idea to prune those who never made a post.

100% - All they have to do is click on one link and enter their new password. If they aren't going to do that, are they really an engaged community member ?
 
Top Bottom