We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 23383
    • 138 Posts
    Just a question for you ram : Are you sure your custom table is in utf8 ? Because I had this problem : My all modx site was in utf8 and my custom table in iso-8859-1, so my custom entries were wrong. Maybe because the default database’s encoding is iso-8859-1, but it still seems strange for me.
      • 24414
      • 45 Posts
      I was wondering about the table encoding myself, but it was actually the same as the rest of my DB.

      Adding the UTF-8 encoding flag to htmlentities stopped the errors I was having with incorrectly encoded UTF-8 characters.
        • 23383
        • 138 Posts
        ok thanks for the advice smiley
          • 36571
          • 145 Posts
          There seems to be a bug which limits textarea inputs to 255 characters in length. Anything longer than 255 characters just gets cut off.

          I assume that this is due to the limit set in the modx core, but does anyone have an idea for a solution/workaround?
            • 36571
            • 145 Posts
            ...answered my own question.

            Just had to go into phpmyadmin and set the column type in the web_user_attributes_extenden table to "text", instead of the default varchar(255).
              • 27617
              • 11 Posts
              Quote from: Dr. at Nov 28, 2007, 05:31 PM


              There is an updated ieButtonFix.js file attached to this post. give that a try.


              This file doesn’t appear any different than the one I got when I downloaded WebLoginPE. Has this file been incorporated into the main distribution? If so, I am still having problems of a similar nature in Firefox 2.0.0.11 - namely, the ieButtonFix patch breaks the forms in Firefox. After examining the HTTP headers, it appears that the submit button is being transmitted twice - once with the value of the selected button, and again with an empty string. This results in a failure to submit the selected button to WebLoginPE. If I disable the ieButtonFix code, then the form works marvelously in Firefox, but no longer in IE. Any suggestions?
                • 28033
                • 925 Posts
                It hasn’t, since Scotty hasn’t had time yet to do a "bugfix" release between 1.3.0 and 1.4.0.

                Have you tried doing an IE conditional statement so only IE loads up the .js file?
                  My Snippets
                  -> PopUpChunk v1.0
                  • 26178
                  • 32 Posts
                  Hey guys! Have got a problem with custom fields. I’m using utf8 encoding throughout my database and everything works just fine. Except of custom fields for webloginpe. When displayed on the site, the output is broken (I’m using special characters). Any ideas how to fix it? Thank you in advance.
                    • 26178
                    • 32 Posts
                    Ok. I found the problem. It seems to be this line:

                    $extendedFieldValues[] = " `".$field."` = '".$modx->db->escape(stripslashes(htmlentities(trim($_POST[$field]), ENT_QUOTES)))."'";


                    Specifically, the htmlentities function. It didn’t work even with the third "charset" parameter (I set it to "UTF-8"), so I just dropped it:

                    $extendedFieldValues[] = " `".$field."` = '".$modx->db->escape(stripslashes(trim($_POST[$field])))."'";    


                    It works ok, now.
                      • 8642
                      • 28 Posts
                      The character encoding stuff seems a bit silly.

                      Everything gets encoded into html entities, which really shouldn’t be necessary since we use UTF-8 by default, and the database should be built to handle that in the first place. But then again, it might be prudent as some browsers can’t handle character sets correctly.

                      What isn’t prudent though, is to convert back from html entities when it becomes time to show the data. The browser does that prefectly ok, that’s what HTML-browsers are for, to parse HTML-data!

                      So, comment out (or delete) these lines:
                      line 1222:
                      //							$value = html_entity_decode($value);


                      line 1326:
                      //			$setting = html_entity_decode($setting);


                      and line 1758:
                      //					$value = html_entity_decode($value);


                      Doing that will get rid of most problems with the encodings. You might also want to use the correct encoding when you save the data to the database, which means you need to find the places where data is saved. Do a search for "htmlentities" and change everyone of them along this pattern:
                      Original:
                      				$generalElementsUpdate[] = " `".$field."` = '".$modx->db->escape(stripslashes(htmlentities(trim($_POST[$field]), ENT_QUOTES)))."'";


                      Corrected version:
                      				$charset='"'.$modx->config['modx_charset'].'"';
                      				$generalElementsUpdate[] = " `".$field."` = '".$modx->db->escape(stripslashes(htmlentities(trim($_POST[$field]), ENT_QUOTES,$charset)))."'";


                      That should do the trick.