User not found in IM preferences table

In some Prillian installations, you or your users may encounter an error message such as this:

Quote:

This topic is devoted to this error message, the cause, and what you can do to make it go away. The error message you see may be slightly different. The number following "user_id=," a 2 above, is usually something that changes for each user viewing the page. Let's call this number the user_id from here on.

First, let's look at a special, but mostly obsolete case. If the user_id is a zero, you are likely seeing this error after clicking on a "Find A Username" button somewhere in phpBB. This special case was fixed in Prillian 0.7.1, so upgrading to that version, or a later version, is advised.

Most of the time, the user_id is some number other than zero and is a different number for every user that views a page with this error. In these cases, the cause of this error is that some information Prillian needs for the user viewing the page is not available in the database. Prillian expects the information to be present for each and every user. When a user is encountered for which the data is missing, the error message above is displayed. These information entries are supposed to be created automatically, but this process sometimes fails.

Prillian comes with a custom installer script that attempts to create the entries for each existing user. On very large forums, or forums with a very short time limit for running PHP scripts, this process may not be completed. The installer should advise of this and give you a list of SQL queries you can execute yourself to finish the process. If the installer doesn't provide the list of queries, you can create your own. The queries will be explained later in this document.

Once Prillian is installed on your forum, the hack's additions to phpBB's usercp_register.php should create the same type of data entries for each new user during the registration process. This sometimes fails to happen for currently unknown reasons. The failure here seems to be a transparent process; there are no reports of error messages during the registration as of yet. The best current solution here is essentially the same as that for the installation process: create a list of queries and run them yourself.

Each query will fix the error for a specific user. For this reason, you need to run one query for each affected user. Often, this means you will be executing multiple queries - the number may go into the hundreds. These queries will be of the format:

Quote:

There are two important numbers in each query, marked in blue and red here. You may need to change the blue number, depending on the setup of your forum. It represents the themes_id number of a template installed on your forum. The original template, subSilver, is assigned an themes_id number of 1 when the forum is installed. If you deleted this template and installed another, you will need to change this digit to the themes_id number of an existing template. To find these numbers, you need to browse the phpbb_themes table in your database. They are labeled as themes_id there.

The red numbers above are the user_id numbers for each user. You'll need to execute a query with a different user_id number for each affected user. If you are dealing with an installer failure situation, the user_id numbers typically start at 2, for the first user created when phpBB 2 is installed, and increase by one for each user. Registration failures tend to deal with user_id numbers that will be much higher. In those cases, the user_id numbers you need to start with can be found by comparing the phpbb_users and phpbb_im_prefs database tables.

If you do not know how to run SQL queries, there is a tutorial related to this at phpBBHacks.com.



Preemptive Maintenance
If you find that you're having the registration variant of this problem, you may wish to run several extra queries to prevent some future users from encountering this problem. In these queries you would use the user_id numbers of future users. The user_ids are automatically generated, so using a series of ever increasing numbers, such as 501, 502, 503, 504, and so forth would be the idea here.



Alternate Solution
Here is an alternative solution designed to solve the problem without running extra queries, courtesy of cryptoknight. I have not tested this and cannot say how well it does or does not work. It may have some bugs, so use this at your own risk.

Code: