We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 10487 MODX Staff
    • 1,535 Posts
    Does anyone want me to continue?
    Most definitely, Paul! Please do continue ... this is looking great so far grin
      Garry Nutting
      Senior Developer
      MODX, LLC

      Email: [email protected]
      Twitter: @garryn
      Web: modx.com
      • 6726
      • 7,075 Posts
      Waow, this is incredibly fast, yes keep going on... that’s the MODx phenomenon happening again grin
      Idea -> Discussion -> extension ! I have seen it happen so often... the "MODx effect" !

      @Silent: Yes I could ask Yves smiley Hmmm... I will !
        .: COO - Commerce Guys - Community Driven Innovation :.


        MODx est l'outil id
        • 25762
        • 67 Posts
        I bend low in gratitude for the ’hour’ you are spending. Now, the problem for me will be to return to a standing position ...
          • 22815
          • 1,097 Posts
          Unfortunately guys, I have had to stop and rethink - Vanilla keeps not quite being as friendly as it might be. However, the issues all stem from the "using 2 tables for users" situation that MODx is currently in.

          I found that I could simplify the prefix issue by redefining the prefix as ’’ and redefining all the tables with LUM_ at the beginning.

          I need to change Vanilla so that it registers users in two tables. I can see how I can change the functions in People.Class.UserManager.php - but there is no easy way of swapping out one for another like there is with Authentication. The original Vanilla > WordPress integration post uses an extension, but I have no real idea how Vanilla extensions can replace functions. And frankly I’ve already delved into Vanilla more than I expected to.

          So. Backtrack 3 and a bit hours. If I add all of Vanilla’s fields to modx_users instead, life becomes so much easier. As it turns out the only field that is in _attributes that I was reusing was "email". (I could possibly have used "photo" also.) This will be an issue back in MODx, as email is a required field, but at least that’s familiar territory to me.

          So I’m going that way.
            No, I don't know what OpenGeek's saying half the time either.
            MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
            Forum: Where to post threads about add-ons | Forum Rules
            Like MODx? donate (and/or share your resources)
            Like me? See my Amazon wishlist
            MODx "Most Promising CMS" - so appropriate!
            • 25762
            • 67 Posts
            Assuming I’m following you, it is a small deal (at least for me) to reach Vanilla through MODx user management - MODx as Vanilla’s front-end. If the future yields a more elegant two-way authentication and registration model, fine. If that future is next week because another MODx guru finds a hack for the block, cool. If it comes with/after the mythical 1.0, cool.

            The main thing is that MODx users won’t have to register-or-login separately to Vanilla to be found by Vanilla authentication ... and that I can launch a Vanilla discussion thread from a MODx document while styling a complete Vanilla forum to look like it’s part of a single (MODx) application. The latter styling can be done in Vanilla itself, of course.
              • 22815
              • 1,097 Posts
              Well, this is quick and this is dirty. This is possibly the loosest integration in the world - all that is shared really is the username and password.

              Having ditched a lot of workarounds, here’s a very quick complete solution. At the end I will list some issues I hope others can solve.

              1) Install Vanilla, tell it your MODx db details.
              2) Edit /conf/database.php - add this in after your password:

              // We're using MODx table for the user.
              $DatabaseTables['User'] = 'modx_web_users';
              // Next, an extra table, because MODx 0.9.x mostly uses another tables for web user attributes.
              $DatabaseTables['UserExtra'] = 'modx_web_user_attributes';
              // If you are using a different prefix, you must change this here.
              
              // All Vanilla table references are redefined with LUM_ here so that we can use MODx tables for any table.
              $DatabaseTables['Category'] = 'LUM_Category';
              $DatabaseTables['CategoryBlock'] = 'LUM_CategoryBlock';
              $DatabaseTables['CategoryRoleBlock'] = 'LUM_CategoryRoleBlock';
              $DatabaseTables['Comment'] = 'LUM_Comment';
              $DatabaseTables['Discussion'] = 'LUM_Discussion';
              $DatabaseTables['DiscussionUserWhisperFrom'] = 'LUM_DiscussionUserWhisperFrom';
              $DatabaseTables['DiscussionUserWhisperTo'] = 'LUM_DiscussionUserWhisperTo';
              $DatabaseTables['IpHistory'] = 'LUM_IpHistory';
              $DatabaseTables['Role'] = 'LUM_Role';
              $DatabaseTables['Style'] = 'LUM_Style';
              $DatabaseTables['UserBookmark'] = 'LUM_UserBookmark';
              $DatabaseTables['UserDiscussionWatch'] = 'LUM_UserDiscussionWatch';
              $DatabaseTables['UserRoleHistory'] = 'LUM_UserRoleHistory';
              
              $DatabaseColumns['UserExtra']['UserID'] = 'internalKey'; 
              $DatabaseColumns['UserExtra']['Email'] = 'email'; 
              // We may, in time add the others.
              
              // Reused fields:
              $DatabaseColumns['User']['UserID'] = 'id'; 
              
              // New fields:
              $DatabaseColumns['User']['Password'] = 'password';
              $DatabaseColumns['User']['Email'] = 'vanilla_email';
              $DatabaseColumns['User']['Name'] = 'username';
              $DatabaseColumns['User']['RoleID'] = 'vanilla_RoleID'; 
              $DatabaseColumns['User']['StyleID'] = 'vanilla_StyleID';
              $DatabaseColumns['User']['CustomStyle'] = 'vanilla_CustomStyle';
              $DatabaseColumns['User']['FirstName'] = 'vanilla_FirstName';
              $DatabaseColumns['User']['LastName'] = 'vanilla_LastName';
              $DatabaseColumns['User']['VerificationKey'] = 'vanilla_VerificationKey';
              $DatabaseColumns['User']['EmailVerificationKey'] = 'vanilla_EmailVerificationKey';
              $DatabaseColumns['User']['UtilizeEmail'] = 'vanilla_UtilizeEmail';
              $DatabaseColumns['User']['ShowName'] = 'vanilla_ShowName';
              $DatabaseColumns['User']['Icon'] = 'vanilla_Icon';
              $DatabaseColumns['User']['Picture'] = 'vanilla_Picture';
              $DatabaseColumns['User']['Attributes'] = 'vanilla_Attributes';
              $DatabaseColumns['User']['CountVisit'] = 'vanilla_CountVisit';
              $DatabaseColumns['User']['CountDiscussions'] = 'vanilla_CountDiscussions';
              $DatabaseColumns['User']['CountComments'] = 'vanilla_CountComments';
              $DatabaseColumns['User']['DateFirstVisit'] = 'vanilla_DateFirstVisit';
              $DatabaseColumns['User']['DateLastActive'] = 'vanilla_DateLastActive';
              $DatabaseColumns['User']['RemoteIp'] = 'vanilla_RemoteIp';
              $DatabaseColumns['User']['LastDiscussionPost'] = 'vanilla_LastDiscussionPost';
              $DatabaseColumns['User']['DiscussionSpamCheck'] = 'vanilla_DiscussionSpamCheck';
              $DatabaseColumns['User']['LastCommentPost'] = 'vanilla_LastCommentPost';
              $DatabaseColumns['User']['CommentSpamCheck'] = 'vanilla_CommentSpamCheck';
              $DatabaseColumns['User']['UserBlocksCategories'] = 'vanilla_UserBlocksCategories';
              $DatabaseColumns['User']['DefaultFormatType'] = 'vanilla_DefaultFormatType';
              $DatabaseColumns['User']['Discovery'] = 'vanilla_Discovery';
              $DatabaseColumns['User']['Preferences'] = 'vanilla_Preferences';
              $DatabaseColumns['User']['SendNewApplicantNotifications'] = 'vanilla_SendNewApplicantNotifications';
              


              3) Edit /conf/settings.php - add in
              // MODx integration settings
              $Configuration['DATABASE_TABLE_PREFIX'] = ''; // LUM_  is now added elsewhere.
              // $Configuration['AUTHENTICATION_MODULE'] = 'People/People.Class.MODxAuthenticator.php';
              
              // This should work with the WebLogin snippet, change it if you use a different session ID:
              $Configuration['SESSION_USER_IDENTIFIER'] = 'webInternalKey';
              
              // WebLogin actually uses the username in the cookie, so you'll have to just double-cookie.
              $Configuration['COOKIE_USER_KEY'] = 'lussumocookieone';
              $Configuration['COOKIE_VERIFICATION_KEY'] = 'lussumocookietwo';
              // Change COOKIE_PATH if you change the cookie.
              


              4) Use phpMyAdmin to add to your web_users table by executing this SQL:
              ALTER TABLE modx_web_users
                ADD `vanilla_RoleID` int(2) NOT NULL DEFAULT '3',
                ADD `vanilla_StyleID` int(3) NOT NULL DEFAULT '1',
                ADD `vanilla_CustomStyle` varchar(255) DEFAULT NULL,
                ADD `vanilla_FirstName` varchar(50) NOT NULL DEFAULT '',
                ADD `vanilla_LastName` varchar(50) NOT NULL DEFAULT '',
                ADD `vanilla_VerificationKey` varchar(50) NOT NULL DEFAULT '',
                ADD `vanilla_EmailVerificationKey` varchar(50) DEFAULT NULL,
                ADD `vanilla_Email` varchar(200) NOT NULL DEFAULT '',
                ADD `vanilla_UtilizeEmail` enum('1','0') NOT NULL DEFAULT '0',
                ADD `vanilla_ShowName` enum('1','0') NOT NULL DEFAULT '1',
                ADD `vanilla_Icon` varchar(255) DEFAULT NULL,
                ADD `vanilla_Picture` varchar(255) DEFAULT NULL,
                ADD `vanilla_Attributes` text NULL,
                ADD `vanilla_CountVisit` int(8) NOT NULL DEFAULT '0',
                ADD `vanilla_CountDiscussions` int(8) NOT NULL DEFAULT '0',
                ADD `vanilla_CountComments` int(8) NOT NULL DEFAULT '0',
                ADD `vanilla_DateFirstVisit` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
                ADD `vanilla_DateLastActive` datetime NOT NULL DEFAULT '2006-06-06 00:00:00',
                ADD `vanilla_RemoteIp` varchar(100) NOT NULL DEFAULT '',
                ADD `vanilla_LastDiscussionPost` datetime DEFAULT NULL,
                ADD `vanilla_DiscussionSpamCheck` int(11) NOT NULL DEFAULT '0',
                ADD `vanilla_LastCommentPost` datetime DEFAULT NULL,
                ADD `vanilla_CommentSpamCheck` int(11) NOT NULL DEFAULT '0',
                ADD `vanilla_UserBlocksCategories` enum('1','0') NOT NULL DEFAULT '0',
                ADD `vanilla_DefaultFormatType` varchar(20) DEFAULT NULL,
                ADD `vanilla_Discovery` text,
                ADD `vanilla_Preferences` text,
                ADD `vanilla_SendNewApplicantNotifications` enum('1','0') NOT NULL DEFAULT '0';
              


              5) For an appropriate Web User, change vanilla_RoleID to 4 - granting access to the Vanilla admin stuff.

              6) That’s it.

              --

              Big Thing Left To Do:
              Add to web_user_attributes upon registration.

              The impact of A means that presently (under MODx 0.9.2.1), users added in MODx can be used in Vanilla, but users added in Vanilla won’t show up in the list - presumably because there is no corresponding userid in _attributes.

              I’ve made the _attributes table available to Vanilla, I called it UserExtra. It is presently not used, but I have successfully used it in investigations thus far. You can use something like

              $s->SetMainTable(’UserExtra’, ’ue’);
              to use it. There are 2 fields available through the definitions - UserID (actually the internalKey field) and Email.

              What needs to happen on registration is: Do registration. Get UserID. Save a new row in UserExtra with UserID and Email set. I just don’t know how exactly to go about doing this bit. I can see that it needs to be in a file called extensions/MODxIntegration/default.php and that it needs to be like the code at the bottom of http://lussumo.com/docs/doku.php?id=vanilla:integration:wordpress but I don’t fully understand his API, and frankly it’s late here.

              I’m not going to get chance to do anything more on this - I hope it’s helped.

              Now, of course, all that’s happened here is we’ve bolted on a bunch of Vanilla fields to a user system that is in dire need of attention, and told Vanilla where to look for stuff (including session ID). It is quite, quite far from the integration one might dream about. It is however a start.

              A suite of Vanilla-friendly snippets would be useful - a version of WebLogin that used the same cookie/session methodology would be a big help. It should also be fairly trivial to whip up a TV with binding to Vanilla threads so that the relevant page to link to could be set easily.
                No, I don't know what OpenGeek's saying half the time either.
                MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
                Forum: Where to post threads about add-ons | Forum Rules
                Like MODx? donate (and/or share your resources)
                Like me? See my Amazon wishlist
                MODx "Most Promising CMS" - so appropriate!
                • 27226
                • 186 Posts
                Great stuff from Paul "The Wizard"! laugh
                I’ll try this out as soon as possible.
                The impact of A means that presently (under MODx 0.9.2.1), users added in MODx can be used in Vanilla, but users added in Vanilla won’t show up in the list -
                Is this so important? I might have missed one of the various points here, but "hacking", redirecting, overwriting or even disabling Vanilla’s registration-feature in the user-interface would be sufficient here. For me, making a MODx-web-user a Vanilla user would be enough, I don’t have, nor do I want that a (new) Vanilla user becomes a MODx-web-user.

                Anyway: great job!
                And being able to follow your steps almost "live" was an exciting and extremely entertaining experience! laugh
                  • 4673
                  • 577 Posts
                  I hate to ask this but is Vanilla that different from SMF?
                  It seems to me that it is a slimer version of a BBS but .... I don’t see what all the fuss is about?

                  Would somebody mind educating me?

                  Thanks smiley
                    Tangent-Warrior smiley
                    • 27226
                    • 186 Posts
                    Carsten:
                    Just look at the first posts of this thread. Vanilla-User-integration was not intended because it is better than SMF, but just because some people use it. And then PaulGregory jumped in and made a very sporty and interesting attempt to do it as quick as it has been done with WordPress. Was more a "proof of concept" (from Vanilla’s and MODx’ side) concerning integration.
                    This was fun, education and useful (for Vanilla users) at the same time! I see absolutely no "fuss" here.
                    Is there anything more to tell? laugh
                      • 25762
                      • 67 Posts
                      Carsten - fair question which I think Silent answered. Granted, I’m a fan of Vanilla but SMF is a robust, powerful and interesting solution. I would say that, between them, Vanilla and SMF solutions that are MODx-aware will cover > 90% of the desirable space for nearly all MODx apps requiring a forum ... that is, until Paul Gregory renders every forum on earth redundant with his native MODx forum grin

                      Vanilla does offer a fresh take on both the ’classic’ forum-style interface and discussion-thread structure within a clean, elegant, extensible architecture. Hmm, that sounds familiar if ’CMS’ is substituted for ’forum above and MODx for Vanilla.

                      (Nothing is ideal. Vanilla is already bumping up against the configuration tradeoffs that come with synchronizing a ruthlessly pruned core with a growing set of extensions of varying quality, currency and ease of integration. One person’s extension ’should’ be another person’s core. Food fights are beginning.)

                      Speaking only for myself, I favor a somewhat minimalist approach to web-and-community applications. Each feature added should be able to make a defense against my skepticism that it will support, rather than impede, user participation and satisfaction. The tool should stay in the background so far as possible. The MODx architecture allows and even encourages that. So does Vanilla.

                      (I can blend Vanilla almost totally into a MODx application without anyone ’knowing’ they are using a separate application. It’s just ’the site’. I don’t feel I can do that easily, maybe at all, with SMF, given its feature set and learning curve.)

                      For blog applications and small communities (under 2,500 registered users), I would prefer Vanilla as the conversational commenting/forum app. It can support bigger stuff but begins to lose its edge as the administrative and management requirements grow. For scads of quite large (though not huge) corporations), this will always meet the internal requirement. For scads of serious non-profit (and personal) applications, likewise. For everything - no.