We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 15001
    • 697 Posts
    I’m using WebloginPE in manager mode to generate a drop list of 117 members (all users).

    id and internalKey are numbered from 1 to 117 with id = internalKey

    Five users are not returned: those with id/internalKey = 15,53,60,100,1.
    The output shows that the records are returned, but that placeholders are replaced by nothing for those only 5 records.

    I checked the following tables: web_users, web_user_attributes and some custom "extended attributes" table. I cannot see any problem with the aforementioned records.

    There is no filtering on groups or other criteria and I cleared the cache.

    Because I supected some parsing limit, I tried to place only one placeholder in the template, but the problem remains. I’m not using PHx.

    Maybe is some limit elsewhere, but I cannot find. Any idea?

    Here’s my WebLoginPE snippet call.
    [!WebLoginPE? &type=`manager` &tableCheck=`0` &customTable=`musiciens` &customFields=`nom` &usersList=`Membres:default:default:nom:ASC:` &manageOuterTpl=`assets/snippets/webloginpe/liste_membres_simple_manager.tpl` &manageTpl=`assets/snippets/webloginpe/option_vers_profil_membre.tpl` &manageProfileTpl=`assets/snippets/webloginpe/gestion_profil_muet.tpl` !]

    • Sounds more like some reason why it doesn’t like those particular records. Can you get those specific records to display?
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
        • 15001
        • 697 Posts
        They don’t display. But the chunk corresponding to them is printed. The placeholders are replaced by nothing.

        Edit: I that some users got a wrong id. Maybe this comes from the algorithm that imported the data from sql and csv files. They generally split the query into several requests.
          • 15001
          • 697 Posts

          Found the culprit: small typos in usernames which were different from one table to another.

          I expected the snippet to work mostly using id and internalKey.
          But it appears that usernames are very important to link the miscellaneous tables.

          From my experience, I would recommend the following in such situation:

          1) Check very carefully the usernames that do not display if you entered them manually into your csv files; especially usernames with non-evident orthographes. Names with double letters like "aa", with silent letters like "h" are prone to this type of errors.

          2) If usernames are derived from names, make sure for women that usernames were not generated from the maiden name in one table and from the married name in another table.

          @Susan: Thanks, you pointed me the right direction.