Slash Boxes

Slash Open Source Project

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login
Loading... please wait.
  • by thelink (3383) on Monday September 02 2002, @08:25PM (#5279) Homepage
    logically it should go in the users_comments table, but I don't see fields for those variables there. Looking at the code, it simply passes it to setUser() which doesn't do anything special with those variables. Does Slash just ignore variables it's told to set when the corresponding fields are in the database? Do these features work at all?
    • They go in users_param.

      You can't grep a dead tree.
    • "logically it should go in the users_comments table, but I don't see fields for those variables there"

      Logic doesn't always have anything to do with it... the code is evolving. :) We used to have a good reason to have all our users_* tables split conceptually but now it doesn't matter that much anymore, so don't expect 100% rationality for what fields go where.

      If you call setUser() for a field that doesn't exist as a column in one of the users_* tables, it creates an entry in users_param. And getUser() reads from that table too. In general, commonly used fields, and those which have been around since the beginning of Slash, are in the main users_* tables, and less-commonly edited fields which are fairly new are just dumped in users_param.

      (By users_* tables, I mean: users, users_comments, users_hits, users_ index, users_ info, users_messages, users_prefs.)

      If you grep the codebase on "sigdash," for instance, you see it being read from $user->{sigdash}, and passed into setUser(), but it's not in the schema. So it's just in users_param. To read it youself, do a SELECT value FROM users_param WHERE uid=123 AND name='sigdash'; or a perl -MSlash::Test=slash,123 -le 'print $user->{sigdash}'

      As for how to find the other options you mention, the best way is to grep the codebase for the text that's displayed for them. Once you find the template that is used to edit them, you can grep on the template's name (probably in to find the code that edits the options.