Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Email Confirmation link throws a fatal error

The_TimThe_Tim Everett, WA New

I'm running a new Vanilla 2.2 setup. I installed fresh and imported data from my old phpBB forum.

In the registration settings I've set the method to "Basic" and checked the box for "Require users to confirm their email addresses (recommended)"

However, when a new user tries to click on the confirmation link that is emailed to them, they get sent to the "Something has gone wrong." page.

I turned on debug, and got the error "Fatal Error in PHP.trigger_error();"

I can't figure out what's going on. Can anyone help me out?



  • Options
    x00x00 MVP
    edited July 2015

    There is no error message so that is a bug in itself. it is assuming it is a PDO error it mightn't be

    I've added a bug report.

    grep is your friend.

  • Options
    The_TimThe_Tim Everett, WA New

    Thanks... Any idea for a workaround other than disabling email verification (which I would prefer not to do of course)?

  • Options

    The issue is not your error by errors in general in that context not showing up.

    You could


    If (!$message) {
        trigger_error($ex->getMessage(), E_USER_ERROR);


    list($state, $code, $message) = $PDO->errorInfo();

    around line 414 in library/database/class.database.php

    That will give you the actual error.

    grep is your friend.

  • Options
    The_TimThe_Tim Everett, WA New

    That is definitely helpful. After adding that I get a real error:

    Fatal Error in Gdn_Database.Query();

    Duplicate entry '1839-8' for key 'PRIMARY'
    insert GDN_UserRole
    (UserID, RoleID)
    values (:UserID, :RoleID)

  • Options

    I suspect you have duplicate rows in GDN_UserRole

    delete duplicates where the UserID and RoleID are the same, leaving just one of each.

    grep is your friend.

  • Options
    The_TimThe_Tim Everett, WA New
    edited July 2015

    I just checked and I don't have any duplicates in the GDN_UserRole table. There is definitely something odd going on though, because the GDN_Role table does not even have a Role with RoleID 8, but for some reason a new row in GDN_UserRole with RoleID 8 is being created for new users.

    Here are all my roles:

    Here's what the GDN_Role table looks like:

    I open an incognito window and register a new test account called TestAccount12, then I run this query:

      U.Name AS User_Name,
      R.Name AS Role_Name
    FROM GDN_UserRole UR
      LEFT JOIN GDN_Role R ON R.RoleID = UR.RoleID
      LEFT JOIN GDN_User U ON U.UserID = UR.UserID

    This is what I see:

    As you can see above, there is no role with RoleID 8. So why was that inserted into the table? And why is it apparently attempting to insert it again when the user confirms their email?

    Also, why are brand new users who haven't confirmed their email yet being given the role "Members" and not "Unverified Members" or "Applicants"?

  • Options
    peregrineperegrine MVP
    edited July 2015

    Also, why are brand new users who haven't confirmed their email yet being given the role "Members" and not "Unverified Members" or "Applicants"?

    in 2.1 if you have the config settings correct they should be given the unconfirmed role. Upon confirmation they should be given member role.

    Applicants is only for applicant approval.

    Member Role is standard 8.

    people who have ported from other databases have had roles and permissions munged up and have different numbers.

    this may help.
    you can set the default roles here...

    if it were me and I had the time I would migrate all members to role id 8

    change the member role to role id 8 in the role table and

    set all roles with roleid 11 to 8 in user role table.

    all done carefully of course.

    Personally I would use applicant approval and forget about email confirmation totally.
    thats just my opinion

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

  • Options
    The_TimThe_Tim Everett, WA New

    Okay, per your suggestion I manually edited the RoleID for each of the standard roles to match the defaults (as found in the definition of $RoleModel in /applications/dashboard/settings/structure.php then I manually reset all the permissions per Q19 in the FAQ link you provided.

    After doing all that, things seem to be working as expected. So it definitely looks like there are some bugs that pop up if you modify the default roles in 2.2. Anyway, things seem to be working as desired now.


Sign In or Register to comment.