Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Suggestion: One database prefix configuration variable

edited August 2007 in Vanilla 1.0 Help
I'd love to see in a future version of vanilla: ONE variable in the config file for the database prefix.

If you have more than one installation of vanilla running in the same database it's nasty to change the db prefix in different files...

Actually I have to change it 1) for the LUM_User, 2) any other tables, 3) setup file, 4) mysql.php for creating the tables...

Comments

  • LUM_User is kept seperate intentionally and besides that there is only one variable for the prefix which the forum uses. I was under the impression that the setup script asked you what prefix you wanted to use but maybe it doesnt. In which case I suppose that aught to be added in future versions...
  • The setup progress does not ask... and also in the sql for creating the db tables it is hard coded...
    I look forward the next version :)
  • StashStash
    edited August 2007
    I'd support the prefix being user configurable, but defaulted to LUM_
  • yeah, just simple input field in setup with default value would be nice
  • MarkMark Vanilla Staff
    I've actually had a hard time with this recently. I'd love to hear any insight people have to integrating Vanilla with other applications, and what kind of adverse affects the vanilla setup had in this regard.
  • I had a major problem with integrating Vanilla and Drupal, as you can see in my Doc, I had to hack Vanilla's core to get the LUM_ prefix removed from a table that isn't the User table, it was very annoying... and will make upgrading that little bit more difficult on my forum.

    I was thinking, why not hardcode the prefix into the appg/database.php file's $DatabaseTables variable like you do with LUM_User, this way you can override the table names with whatever you like! Surely that is more advantageous than hardcoding it, it isn't confusing either.

    Adam.
This discussion has been closed.