We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 9207 ☆ A M B ☆
    • 2,475 Posts
    I did do as you suggested and placed the [*comment-RT*] in it’s own form without a WebLoginPE call on the page and it was NOT binding to the database. So... not sure what to try next here. I think maybe some food and a break might be in order before taxing my brain again:-)

    If the [*comment-RT*] isn’t working OUTSIDE of a WebLoginPE chunk, there’s no way it’ll work inside a WebLoginPE chunk. I’m trying to get you to isolate the problem. I think you need to try using different widgets in your Template Variable definition. The rich text widget has nothing to do with WebLoginPE.

    Once you get the text to show up on your page in [*comment-RT*], then you can worry about displaying it via WebLoginPE. Make sense?
      • 15003
      • 85 Posts
      You were right, my understanding of the template variables was skewed.

      ... Ultimately I don’t need to have the comment field as rich text since the user won’t see it or update it anyways. I just need it to not replace some of my code with html entities. That way my client can enter document links, lists and messages to his clients through the Web Users panel, and using css to display:none I can prevent his clients from being able to edit the field in the update-profile page. Using a webloginPE call I can place this comment within each service package he offers so a customized message will be seen by each client. See post http://modxcms.com/forums/index.php/topic,39334.msg238419.html#msg238419

      I feel like a dog chasing it’s tail:-)
        • 9207 ☆ A M B ☆
        • 2,475 Posts
        Again, I think this gets back to your Template Variate definition. You’ve defined it as:
        Input Type: RichText

        So it will replace html entities and perform tweaks on your input. If you want just raw text, choose a different input type.

          • 15003
          • 85 Posts
          The only reason I needed a Template Variable was to force the field to be RichText which would in turn leave the code as is that I entered into the Create/edit web user in the admin panel. I thought I could use the Template variable to access a particular field in a table, not necessarily add another field the php web page template. I think my logic was flawed.

          If I add the following to the user comment field in the admin panel:
          <a href="assets/templates/steinberg/xls/SteinbergConsulting_client-massage-tracking.xls">client massage tracking</a>
              <ul>
                  <li>one</li>
                <li>two </li>
                <li>three</li>
              </ul>
          <p>Praesent libero. Sed cursus ante dapibus diam.</p>
          <p>Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi.</p>


          It is parsed correctly and looks as it should on the profile page.

          Once it’s parsed by the <textarea> field in the update-profile page my code looks like:
          <a href="assets/templates/steinberg/xls/SteinbergConsulting_client-massage-tracking.xls">client massage tracking</a>
              <ul>
                  <li>one</li>
                <li>two </li>
                <li>three</li>
              </ul>
          <p>Praesent libero. Sed cursus ante dapibus diam.</p>
          <p>Integer nec odio. Praesent libero. Sed cursus ante dapibus diam. Sed nisi.</p>


          I am questioning whether or not using a Template Variable as a solution is the right way to go.

          What do you think?

          ~Jules
            • 9207 ☆ A M B ☆
            • 2,475 Posts
            If you are merely associating an extra field to a user profile, then you don’t need a Template Variable (TV). TV’s are for associating extra fields with pages (via their templates).

            WebLoginPE has a way to allow additional user parameters, i.e. custom fields... have a look here:
            http://wiki.modxcms.com/index.php/WebLoginPE_Custom_Fields

            If you are wanting to control how the web users edit information in that field, then it’s just a question of changing the HTML/Javascript of that particular form (defined in one of the WebLoginPE’s chunks).
              • 27330
              • 884 Posts
              also fix the editing with permissions and not CSS.
              think about it, someone with Firebug could start changing your details kinda easily.

              and if you need it to be like control panel where the admin (your client) can make edits to web users and web users (his clients) can only view the info
              you might like better to customize the manager interface and let the admin work from there. that’s already built for you.
                • 15003
                • 85 Posts
                I wasn’t really needing an extra field since MODx already has "comment" field. If I set up a custom field in WebLoginPE then I will also have to find a way to set up an additional field in the Create/edit web user in the admin panel for my client to post links and messages to his users/clients. Is that even possible? I just thought it would be simpler to "recycle" a field that was already there. If I place code in the "comment" field in the Create/edit web user in the admin panel the html links and lists render correctly in a browser. It’s when the <textarea> in the WebLoginPE form parses that same information that the code is replaced with the html entities. If I remove the "comment" textarea field from the update-profile form then the content of that field is removed from the database. So I have to include it, but if I do it parses html entities.

                If you are wanting to control how the web users edit information in that field, then it’s just a question of changing the HTML/Javascript of that particular form (defined in one of the WebLoginPE’s chunks).
                Not sure what you mean when you say "question of changing the HTML/Javascript of that particular form"
                  • 9207 ☆ A M B ☆
                  • 2,475 Posts
                  If you are wanting to control how the web users edit information in that field, then it’s just a question of changing the HTML/Javascript of that particular form (defined in one of the WebLoginPE’s chunks).

                  I’m just stressing best-practices in semantic web development e.g. don’t try to do back-end stuff on the front-end... if it’s just a matter of making things look good or making things easier for your users on the front-end, then usually this is best handled on the front end. Look at this form for an example: there are a bunch of formatting controls to make text bold, etc, but this is simply eye-candy. The back end process that takes this data and inserts a row into the database doesn’t care where the content came from. After looking at this more, I think WebLoginPE is messing up your HTML code... I suspect that WebLoginPE is running all input through the htmlentities() function, and that is thwarting your attempts to display this info... it’s probably doing this to close a security hole: if a user could upload and display arbitrary html/javascript tags, he could execute cross-site scripting attacks on your site. Anyhow... moving this into its own table with its own set of interactions would ensure that WebLoginPE is not monkeying with your code.

                  Is the core of this problem that you need a way for the manager/admin to update the comments field of each web user, but not allow the web users to edit that information themselves? If that’s what you’re trying to do, I might just create another table keyed off the web user id and have a column in that table for comments. Then you could use a simple @SELECT binding to select the additional info and display it to the logged in user. phpMyEdit would offer a simple way of editing those comments for the manager... the web users themselves would have no way of editing that information because it would live in a table outside of WebLoginPE’s influence. You can get the user id of the currently logged in web user by doing through the data stored in the $_SESSION array... do a print_r($_SESSION); as a Snippet, and put that on a page to watch the output.... I think the web user id is stored in $_SESSION[’webInternalKey’] -- read that value and use it to drive your @SELECT statement.

                  Did that make sense? Or am I completely misunderstanding the problem? Maybe a more detailed wire-frame type of description of the final result would help me understand exactly what you’re trying to do...
                    • 15003
                    • 85 Posts
                    sinbad --
                    also fix the editing with permissions and not CSS. think about it, someone with Firebug could start changing your details kinda easily.
                    You make a great point, but I have to admit I don’t know how to do that. Also, and I guess it’s probably kinda lazy of me, but since only users can have access to the update-profile page I wasn’t really worried about a user using Firebug or something else to edit the field. The chances of my client’s users having that kind of technical know how is more than slim, and all the field is going to contain is links and a message to that user from my client.
                    It would be good information for me to know and understand though.

                    and if you need it to be like control panel where the admin (your client) can make edits to web users and web users (his clients) can only view the info you might like better to customize the manager interface and let the admin work from there. that’s already built for you.
                    I didn’t know there was a way to add a field to the manager interface of MODx. I looked into using the ManagerManager plugin but says it can rename, hide, and move fields and tabs, not add fields. Do you know of a plugin that can add a field to MODx’s manager interface?

                    Really appreciate you input
                    ~Jules
                      • 15003
                      • 85 Posts
                      Everett--
                      Is the core of this problem that you need a way for the manager/admin to update the comments field of each web user, but not allow the web users to edit that information themselves?
                      You got it, that’s exactly what I am trying to do. I’m with you on the add additional table keyed off the web user id, but I’m concerned about making it too complicated for my client to add his messages to each of his clients. I wasn’t familiar with phpMyEdit and am checking it out. I really don’t want to give my client two interfaces to learn and work out of . ...So how hard/bad is it to hack the core? I found the manager interface comment <textarea> fields below, but I don’t know/understand the cascading effects it could have if I added code to include a RichText field. Do you? Or is this so far above my head that I shouldn’t attempt it?

                      //line 418 in /manager/actions/mutate_user.dynamic.php
                      <textarea type="text" name="comment" class="inputBox"  rows="5" style="width:300px" onchange='documentDirty=true;'><?php echo htmlspecialchars($userdata['comment']); ?></textarea>
                      
                      //line 379 in /manager/actions/mutate_web_user.dynamic.php
                      <textarea type="text" name="comment" class="inputBox"  rows="5" style="width:300px" onchange='documentDirty=true;'><?php echo htmlspecialchars(isset($_POST['comment']) ? $_POST['comment'] : $userdata['comment']); ?></textarea>