OK, I have a question. I started the install and got to the install tables part and then it goes to the "Check your database config settings below and update them if necessary..." and then it tells me that I can not update until I :

$app_allow_dbase_reset = 0;

to

$app_allow_dbase_reset = 1;

First of all, why are we starting with that set to zero? This has always been a stick in my side concerning installation of Quam Plures (and that other unmentionable app). If I could easily change it at this stage, instead of having to ftp in, or shell in, and make the changes, then go back to the installation, it would be easier and less frustrating. This should be set to zero AFTER the installation so that it is not a stick in our sides trying to install Quam Plures.

OK, I think I found a bug with the installer; and I found this same bug in the old app and I had to yell at them to get them to finally agree it existed.

Seems if my database password contains $XY; where XY is either numerals or letters, it is removing the $ and the XY. For example, for password abcd$efg, it becomes abcdg; which is why the installer yelled ab me about checking the config.

Just noticed the first issue, which for me has never ever ever been an issue. I have never been hindered installing or upgrading with it set to 0, which is what it should be else you can wipe out your database. The only time you want that is when you are replacing an installation with a fresh one, which is not the same as installing right?

gonna test the db password now with the sample password you provided. I download a zip and am uploading it to my server space, and will then create a database for it using that reasonably clear password example. HOPEFULLY it goes into the main_config file incorrectly because that's us doing a preg_replace. If the file is good and it won't connect that's a php function being called so I dunno what we can do about that.

ruh roh. Using the password example above it stored it in the real file correctly and connected to the database for installation without issue or incident. Dunno what to say ... I mean, some of the simple stuff that comes to mind honestly doesn't sound like a path to a solution - more like reaching at straws. php version, anything you know of that might be "funny" or whatever on your server?

Hey I got the impression it stored the password wrong in the _main_config.php file - is that true? In other words you're seeing the problem in a file, not extracting it out from a server log or something? Assuming that's true the only place we can look with any confidence is the install/index file where it does the rather fancy preg_replace for the database info. Something about the regex going weird under a very specific set of circumstances?

dunno, but now that I got a "raw qp latest" on my server space I'm gonna keep it and do some bug hunting if I can. Unfortunately the few I found in my active installation were due mostly to having users with lesser permissions than admin has. Still, they're in there so they gotta get found and squashed eh?

OK, doing a fresh install on a fresh database.You get to the point where you enter your database info; You enter the info and then it continues to the next window where it asks you if you if you are setting up a new install and if you want it to create sample posts. I enter the settings I want and then press the button to continue. It was at this point that the install failed with the check config and that you have to reset in order to update the config. So I do that and go back and it reads in the config and I see the database password is incorrect, notice the missing $ and the next two characters as well. Tested with replacing the characters with numerals to see and same results.

Now this same bug appeared in that other app and at first I was told that no, the bug did not exists. It is possible we inherited this bug from that app and it just never appeared; I do regularly use symbols in passwords and use $ and ! most often over others. Yes, the main config file was being written incorrectly, so when it got to the point where it is suppose to connect to the database to create the tables, it can not because of the wrong password. Of course I can just edit the main config and all its good but we need to address this. I can test to see what combination of numerals and characters and symbols work or don't work. My guess when I saw it at that other app was that the $ was being seen as a variable declaration or that $XY was being seen as a variable. Perhaps the input scrubber against SQL injection is the culprit; seeing it as an attempt to enter some bad input.

I am reluctant to share the actual password as the user also accesses another database.

Here's the code from our file, then the same block from their latest "stable" release. There are diffs - even I can see that - but they're regex stuff and I've no clue how to do anything with regular expressions except break 'em. I'm thinking you can change from ours to theirs and see if the problem repeats? NOTE: I changed the order of the bits in their code to match ours because I recall we were scrambling up our stuff when we shuffled bits around so long ago. I seriously doubt it'll change anything, but full disclosure and all that eh? Anyway our code first ... a big-ass preg_replace thingie