1.3 to 1.4 Upgrade testing

Franz · 2010-01-05 15:19:31

As you guys can probably see, only one ticket is keeping us from releasing the first release candidate now. After a quick test, the process of upgrading seems to go pretty well. However, I only tested it with a fresh install, because I do not have access to a production-style database right now.

That's where you come into play. For those of you who are planning to upgrade to 1.4 once it's released anyway: could you test if the upgrade script works with your forum (obviously on a backup), please? It would help us finding any bugs or issues left with the updating script and it would allow you to

A quick reminder on upgrading steps:

Replace all old files with the files from the 1.4 package.
Rename the constant FORUM to PUN in config.php.
Visit your forum. If all goes well, it should tell you to run the update script (providing a link there).
Run the upgrade script.

You won't be able to login anymore. This is, however, the only problem left in my eyes.

Thanks for your help in advance.

ehtime · 2010-01-05 15:33:35

If you do not mind my English...

http://iiich.com/bbs/
Thanks!

fluxbb@iiich.com

Franz · 2010-01-05 15:54:08

@ehtime: What about that site?

ehtime · 2010-01-05 16:08:47

lie2815 wrote:

@ehtime: What about that site?

It's about a Chinese input method. It can be used to input Chinese characters.
I just worry about I can't expression some specialized problems in English after I upgrade. Not these:)

Sorry!.....These are useful information

* 操作系统: Linux
* PHP: 5.2.4
* 加速器: N/A

* MySQL Standard 5.0.22
* lines: 6,579
* size: 795.16 KB

Last edited by ehtime (2010-01-05 16:21:50)

ehtime · 2010-01-05 16:13:51

Now, everything has been backed up, svn 1220 is downloaded... Aha!:)

Reines · 2010-01-05 16:24:52

As a quick note we can miss out step 2 by defining PUN in common.php if we notice FORUM is defined (1.3 did the same but in reverse). I can commit this when I get home.

Franz · 2010-01-05 17:10:47

I have a similar plan, which goes along with "downgrading" the password hash. Instead of checking for PUN to be defined we check for PUN or FORUM to be defined (or we just use your way) when "verifying" that config.php has been included.

Then, in login.php, having FORUM defined tells us to fetch the salt, too, and downgrade the hash if it hasn't been done yet.

Reines · 2010-01-05 17:45:34

Using PUN and FORUM to check which version isn't really reliable, some coming from 1.3 may have FORUM defined (fresh install) and some may have PUN defined (upgraded from 1.2). Though just the presence of the salt field in the users table should be enough to tell us if we need to handle it or not?

jojaba · 2010-01-05 17:45:36

I'm happy to see that FluxBB is going to be ready for a RC version ! Congratulation to the developper team, thanks for your hard work
Just a little question, nothing critical, just a phylosophie question : why do you name a constant PUN ? We are here talking about FluxBB (and not punBB) isn't it ? It shouldn't be too difficult to rename that constant by using a good text editor (if it appears in several files)...

Reines · 2010-01-05 17:47:07

We still have quite a few things named after pun for backwards compatibility with PunBB-1.2.x.

Franz · 2010-01-05 17:51:08

Reines wrote:

Using PUN and FORUM to check which version isn't really reliable, some coming from 1.3 may have FORUM defined (fresh install) and some may have PUN defined (upgraded from 1.2).

Huh? If FORUM is defined, it's 1.3. It's as easy as that. And it's the only time that it could be necessary to downgrade the password hash.

Reines wrote:

Though just the presence of the salt field in the users table should be enough to tell us if we need to handle it or not?

I wanted to avoid that. Wouldn't that mean that we need another query? Or is there an easy (database-cross-compatible) way to determine it inside the SELECT query?

Reines · 2010-01-05 17:53:56

lie2815 wrote:

Huh? If FORUM is defined, it's 1.3. It's as easy as that. And it's the only time that it could be necessary to downgrade the password hash.

Yes, but if PUN is defined it can be either 1.2 or 1.3, so assuming FORUM being defined means it's 1.3 wont work in all cases.

lie2815 wrote:

Wouldn't that mean that we need another query?

I don't think so, since we already pull * from the users table we can just check if $pun_user['salt'] is set or not.
Edit: Actually in login we don't pull *, I guess we could do it by pulling * though...

Franz · 2010-01-05 17:56:45

Oh... now I get it. You're talking about FORUM being named PUN in PunBB 1.3!?

EDIT:

Reines wrote:

Edit: Actually in login we don't pull *, I guess we could do it by pulling * though...

Makes sense. Good idea.

Last edited by Franz (2010-01-05 17:57:32)

Reines · 2010-01-05 17:58:40

No... If a user had a FluxBB 1.2.x forum it was defined as PUN. If they then upgraded to 1.3, the password was converted to a salted password, but the definition in the config file is left as PUN; so it is possible 1.3 forums can still have PUN defined in the config file and not FORUM.

Franz · 2010-01-05 18:00:30

Why is life always so easy?

Reines · 2010-01-05 18:53:30

I have created a patch that will check for the salt field and convert a password if required. Will download a copy of this forums database later and give it (and the upgrade script) some testing and see what happens...

Reines · 2010-01-05 23:00:57

I've commit the patch in r1224. I've tested updating a fresh install of 1.2.22, 1.3-legacy and 1.4-beta2 and they all seem to have worked fine. I also tested upgrading this forum and it seems to have worked fine.

Can someone maybe have a look over the changeset (since it would be a kinda bad start if people could log in without a valid password!), then we can hopefully finally get RC1 out

It seems the db_update script isn't currently handling UTF-8 properly when updating from 1.3 so I'll have a look at that now...

Last edited by Reines (2010-01-05 23:01:51)

Reines · 2010-01-05 23:46:18

r1226 should fix the charset being incorrectly converted when upgrading from 1.3, though I'm not sure if the call to set_names is in the right place in the finish stage, shouldn't it be done before we start preparsing the posts etc?

Franz · 2010-01-05 23:50:01

Isn't it done right at the beginning?

jojaba · 2010-01-06 07:16:28

I see your working hard to have the RC soon running (I hope you are sleeping while I'm writing that ). Great work ! Go ahead !
Below something you can forget or not read, just here to slow you down in your work (I'm jocking )

Reines wrote:

We still have quite a few things named after pun for backwards compatibility with PunBB-1.2.x.

Sorry for that newbie question but if you update 1.2 version to 1.4 version don't you replace (override) all the files (except the config file of course) ? Perhaps something to do with the Data Base...
I scanned the "upload folder" for "pun" and "PUN" strings using Prgrep (i'm on Windows OS) here's the statistics :

Number of "pun" and "PUN" strings in this folder : 5436
Number of files containing this strings (pun and PUN) : 126

Reines · 2010-01-06 07:42:34

lie2815 wrote:

Isn't it done right at the beginning?

Yes, though the script first calls set_names there (latin1 or UTF-8 depending on 1.2 or 1.3), then converts the data to UTF-8 if required, then converts the tables themselves to UTF-8 if required, then preparses the posts and sigs etc. What I'm wondering is if we should be recalling set_names(UTF-8) before we start preparsing the posts, since by that time we should be working with purely UTF-8 data. I'm not sure who decided to put it in the finish section instead (or why), maybe Smartys can advise?

jojaba wrote:

Sorry for that newbie question but if you update 1.2 version to 1.4 version don't you replace (override) all the files (except the config file of course) ? Perhaps something to do with the Data Base...

Yeah if we are talking fresh installs then that would work great, though the aim with 1.4 is to try not break too much for people who have modified or integrated their forums. Renaming $pun_user or $pun_config for example would break pretty much every single modification there is. Once we start work on 2.0 we will forget all the pun_ rubbish

jojaba · 2010-01-06 07:50:10

jojaba wrote:

... (I hope you are sleeping while I'm writing that ...

You aren't !!!
Thanks for your reply !

Reines · 2010-01-06 07:57:22

Just up, got work in 5mins

Edit: Seems I was right, set_names needs called for preparsing otherwise conversion from 1.2 doesn't work right.
Edit2: Actually I just checked and 1.3 already does this, maybe I should have just looked there first...

The only problem I am now aware of is db_update seems to think my 1.2 database is already UTF-8 encoded (based on the db_seems_utf8() function), since the only data in it is english and chinese (which is html entity encoded, so doesn't get flagged as UTF-8). It can be sorted by forcing the conversion, but might be nice if it could detect that itself.

Last edited by Reines (2010-01-06 08:11:34)

qie · 2010-01-06 08:15:47

jojaba wrote:

I see your working hard to have the RC soon running (I hope you are sleeping while I'm writing that ). Great work ! Go ahead !
Below something you can forget or not read, just here to slow you down in your work (I'm jocking )
Reines wrote:
We still have quite a few things named after pun for backwards compatibility with PunBB-1.2.x.
Sorry for that newbie question but if you update 1.2 version to 1.4 version don't you replace (override) all the files (except the config file of course) ? Perhaps something to do with the Data Base...
I scanned the "upload folder" for "pun" and "PUN" strings using Prgrep (i'm on Windows OS) here's the statistics :
Number of "pun" and "PUN" strings in this folder : 5436
Number of files containing this strings (pun and PUN) : 126

hey guy do you hate PUN?
I don't;
don't forget what it is based and the original author

Last edited by qie (2010-01-06 08:27:21)

qie · 2010-01-06 08:41:10

Reines wrote:

lie2815 wrote:
Isn't it done right at the beginning?
Yes, though the script first calls set_names there (latin1 or UTF-8 depending on 1.2 or 1.3), then converts the data to UTF-8 if required, then converts the tables themselves to UTF-8 if required, then preparses the posts and sigs etc. What I'm wondering is if we should be recalling set_names(UTF-8) before we start preparsing the posts, since by that time we should be working with purely UTF-8 data. I'm not sure who decided to put it in the finish section instead (or why), maybe Smartys can advise?
jojaba wrote:
Sorry for that newbie question but if you update 1.2 version to 1.4 version don't you replace (override) all the files (except the config file of course) ? Perhaps something to do with the Data Base...
Yeah if we are talking fresh installs then that would work great, though the aim with 1.4 is to try not break too much for people who have modified or integrated their forums. Renaming $pun_user or $pun_config for example would break pretty much every single modification there is. Once we start work on 2.0 we will forget all the pun_ rubbish

@Reines says:

since this Reines says, which pun_rubbish, means that something in the resource that pre with"pun" is rubbish, If I can say that which you intend to start work is something "2.0", it is pre with "flux_rubbish" ?

Okay, I don't think the one who is talking a project based which is formerly worked is a "rubbish", then why his project is a not

they'r just projects,not the a tool for attacking others

Last edited by qie (2010-01-06 08:45:02)

Forums

#1 2010-01-05 15:19:31

1.3 to 1.4 Upgrade testing

#2 2010-01-05 15:33:35

Re: 1.3 to 1.4 Upgrade testing

#3 2010-01-05 15:54:08

Re: 1.3 to 1.4 Upgrade testing

#4 2010-01-05 16:08:47

Re: 1.3 to 1.4 Upgrade testing

#5 2010-01-05 16:13:51

Re: 1.3 to 1.4 Upgrade testing

#6 2010-01-05 16:24:52

Re: 1.3 to 1.4 Upgrade testing

#7 2010-01-05 17:10:47

Re: 1.3 to 1.4 Upgrade testing

#8 2010-01-05 17:45:34

Re: 1.3 to 1.4 Upgrade testing

#9 2010-01-05 17:45:36

Re: 1.3 to 1.4 Upgrade testing

#10 2010-01-05 17:47:07

Re: 1.3 to 1.4 Upgrade testing

#11 2010-01-05 17:51:08

Re: 1.3 to 1.4 Upgrade testing

#12 2010-01-05 17:53:56

Re: 1.3 to 1.4 Upgrade testing

#13 2010-01-05 17:56:45

Re: 1.3 to 1.4 Upgrade testing

#14 2010-01-05 17:58:40

Re: 1.3 to 1.4 Upgrade testing

#15 2010-01-05 18:00:30

Re: 1.3 to 1.4 Upgrade testing

#16 2010-01-05 18:53:30

Re: 1.3 to 1.4 Upgrade testing

#17 2010-01-05 23:00:57

Re: 1.3 to 1.4 Upgrade testing

#18 2010-01-05 23:46:18

Re: 1.3 to 1.4 Upgrade testing

#19 2010-01-05 23:50:01

Re: 1.3 to 1.4 Upgrade testing

#20 2010-01-06 07:16:28

Re: 1.3 to 1.4 Upgrade testing

#21 2010-01-06 07:42:34

Re: 1.3 to 1.4 Upgrade testing

#22 2010-01-06 07:50:10

Re: 1.3 to 1.4 Upgrade testing

#23 2010-01-06 07:57:22

Re: 1.3 to 1.4 Upgrade testing

#24 2010-01-06 08:15:47

Re: 1.3 to 1.4 Upgrade testing

#25 2010-01-06 08:41:10

Re: 1.3 to 1.4 Upgrade testing

Board footer