We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 33372
    • 1,611 Posts
    Has the issue reported here been investigated/addressed?
    http://modxcms.com/forums/index.php?topic=9877.new;topicseen#new
      "Things are not what they appear to be; nor are they otherwise." - Buddha

      "Well, gee, Buddha - that wasn't very helpful..." - ZAP

      Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options
      • 22303 MODX Staff
      • 10,725 Posts
      Quote from: ZAP at May 23, 2007, 05:38 PM

      Has the issue reported here been investigated/addressed?
      http://modxcms.com/forums/index.php?topic=9877.new;topicseen#new
      I can’t find a bug report for it...I’ll do another STRICT_MODE test and fix it if you’ll enter a proper bug report. wink
        • 33372
        • 1,611 Posts
        This actually isn’t a bug that I have seen personally or can confirm (I’m not running PHP in STRICT_MODE). Should I enter it into FlySpray anyway? I assume that the person reporting it isn’t lying to us, so it probably shoudl be checked out.
          "Things are not what they appear to be; nor are they otherwise." - Buddha

          "Well, gee, Buddha - that wasn't very helpful..." - ZAP

          Useful MODx links: documentation | wiki | forum guidelines | bugs & requests | info you should include with your post | commercial support options
          • 23491 ☆ A M B ☆
          • 1,056 Posts
          I thought I’d also share general success stories with the latest SVN:

          Today I have been actively developing on the new build (fresh install, all extras/no content) with no hiccups whatsoever.

          I’ve been playing heavily with Security--primarily Web Permissions/Web Users and Document Groups. Also manager users, internal "email" messaging, caching, and much more...not to mention 3rd party plugins and snippets all with complete success.

          I also worked with the same build in a completely separate environment last night leveraging Site Import, Move Document, Previews, etc...At first, I noticed things were loading extremely slow and very out of the ordinary compared to my typical MODx manager experience...turns out FireBug was Enabled and causing the extra load, especially with all of the documents in the DocTree. Turning it off instantly solved the problem.

          Unfortunately, I haven’t dealt with STRICT_MODE myself, but do let me know if I can be of any assistance.

          In summary, great work everyone! You should be proud. I feel more confident with this build the more I use it and will definitely relay any concerns should they arise.

          Update: I recall reading a post in the forum where somebody’s shared host had somehow disabled the PHP
          glob()
          function, something new to the 096 cache clearing method sirlancelot implemented. Should this be taken into account (somehow checking if glob is enabled, else fall back on the prior logic?)
            Mike Reid - www.pixelchutes.com
            MODx Ambassador / Contributor
            [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
            ________________________________
            Where every pixel matters.
            • 27376
            • 576 Posts
            Quote from: pixelchutes at May 23, 2007, 06:16 PM

            Update: I recall reading a post in the forum where somebody’s shared host had somehow disabled the PHP
            glob()
            function, something new to the 096 cache clearing method sirlancelot implemented. Should this be taken into account (somehow checking if glob is enabled, else fall back on the prior logic?)
            Right now, it simply uses [tt]version_compare()[/tt] logic to make sure PHP is of the right version for [tt]glob()[/tt], I’m sure it could be changed to a [tt]function_exists()[/tt] check.
              • 22303 MODX Staff
              • 10,725 Posts
              Quote from: sirlancelot at May 23, 2007, 08:31 PM

              Quote from: pixelchutes at May 23, 2007, 06:16 PM

              Update: I recall reading a post in the forum where somebody’s shared host had somehow disabled the PHP
              glob()
              function, something new to the 096 cache clearing method sirlancelot implemented. Should this be taken into account (somehow checking if glob is enabled, else fall back on the prior logic?)
              Right now, it simply uses [tt]version_compare()[/tt] logic to make sure PHP is of the right version for [tt]glob()[/tt], I’m sure it could be changed to a [tt]function_exists()[/tt] check.

              http://modxcms.com/bugs/task/873 -- fix committed in branches/0.9.6 as revision 2757
                • 22303 MODX Staff
                • 10,725 Posts
                Quote from: ZAP at May 23, 2007, 05:56 PM

                This actually isn’t a bug that I have seen personally or can confirm (I’m not running PHP in STRICT_MODE). Should I enter it into FlySpray anyway? I assume that the person reporting it isn’t lying to us, so it probably shoudl be checked out.
                Revision 2756 in branches/0.9.6 covers the instances where strict mode is killing manager and web user data entry in the manager. Will be merged for final -- http://modxcms.com/bugs/task/756
                  • 30223
                  • 1,010 Posts
                  Upgrade to 0.9.6 rev2754
                  Linux - Apache/1.3.37 - PHP Version 5.1.6 (CGI)

                  Upgrade went smoothly but when saving a newly created document I get this error:
                  Warning: strtr() [function.strtr]: The second argument is not an array. in home/.../public_html/manager/processors/save_content.processor.php on line 858
                  The document is saved without an alias. This also happens when editing an existing document...

                  The cause as far as I can see was that I forgot to set the Character encoding to utf8 (It was set to Windows-1252). However this should not break things the way it does. In fact looking at the code again,.. the real cause is on line 573 in save_content.processor.php

                  //<?php
                   function stripAlias($alias) {
                  	global $modx;
                  
                  	if (strtoupper($modx->config['modx_charset']) == 'UTF-8'){
                          //$alias = utf8_decode($alias);
                          //$alias = strtr($alias, array (chr(196) => 'Ae', chr(214) => 'Oe', chr(220) => 'Ue', chr(228) => 'ae', chr(246) => 'oe', chr(252) => 'ue', chr(223) => 'ss'));
                  
                          // Convert accented characters to their non-accented counterparts. Idea originally from Brett Florio (thanks!) ... expanded list from Textpattern (double-thanks!)
                          $replace_array = array(
                                  //REMOVED FOR BREVITY'S SAKE
                          );
                          $alias = strtr($alias, $replace_array);
                    }
                  
                          $alias = strip_tags($alias);
                          $alias = preg_replace('/&.+?;/', '', $alias); // kill entities
                          $alias = preg_replace('/[^\.%A-Za-z0-9 _-]/', '', $alias);
                          //$alias = preg_replace('/\s+/', '-', $alias);
                          $alias = preg_replace('|-+|', '-', $alias);
                          $alias = trim($alias, '-');
                          return $alias;
                  }
                  //?>
                  


                  The test for the character set is missing the { } brackets and as the $replace_array is the next statement it is not executed, any further lines however will be and hence the strtr($alias,$replace_array); causes a php warning;

                  The correct code I’m assuming would be:
                  //<?php
                  function stripAlias($alias) {
                  	global $modx;
                  
                  	if (strtoupper($modx->config['modx_charset']) == 'UTF-8'){ //added bracket
                          //$alias = utf8_decode($alias);
                          //$alias = strtr($alias, array (chr(196) => 'Ae', chr(214) => 'Oe', chr(220) => 'Ue', chr(228) => 'ae', chr(246) => 'oe', chr(252) => 'ue', chr(223) => 'ss'));
                  
                          // Convert accented characters to their non-accented counterparts. Idea originally from Brett Florio (thanks!) ... expanded list from Textpattern (double-thanks!)
                          $replace_array = array(
                  		//REMOVED FOR BREVITY'S SAKE
                          );
                          $alias = strtr($alias, $replace_array);
                    } //added bracket
                  
                     $alias = strip_tags($alias);
                     $alias = preg_replace('/&.+?;/', '', $alias); // kill entities
                     $alias = preg_replace('/[^\.%A-Za-z0-9 _-]/', '', $alias);
                     //$alias = preg_replace('/\s+/', '-', $alias);
                     $alias = preg_replace('|-+|', '-', $alias);
                     $alias = trim($alias, '-');
                     return $alias;
                  }
                  
                  //?>
                  


                  EDIT: committed in branches/0.9.6/ @ 2758
                  Added in bugtracker: #874
                    • 23491 ☆ A M B ☆
                    • 1,056 Posts
                    Quote from: sirlancelot at May 23, 2007, 08:31 PM

                    Right now, it simply uses [tt]version_compare()[/tt] logic to make sure PHP is of the right version for [tt]glob()[/tt], I’m sure it could be changed to a [tt]function_exists()[/tt] check.

                    I think you’re doing it the right way today. I wonder if function_exists or some form of error handling/fall back action should be considered additionally. I would consider this case minor/rare, but possible--It’s only a matter of how to handle the possibility.

                    @Jason, thank you for opening the ticket! How did you end up handling this one?

                    Also, what is the fully qualified URL for the branches/0.9.6 SVN URL?
                      Mike Reid - www.pixelchutes.com
                      MODx Ambassador / Contributor
                      [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
                      ________________________________
                      Where every pixel matters.
                      • 22303 MODX Staff
                      • 10,725 Posts
                      Quote from: pixelchutes at May 24, 2007, 12:18 AM

                      @Jason, thank you for opening the ticket! How did you end up handling this one?
                      Just changed it to if (function_exists(’glob’)) {

                      Quote from: pixelchutes at May 24, 2007, 12:18 AM

                      Also, what is the fully qualified URL for the branches/0.9.6 SVN URL?
                      http://svn1.cvsdude.com/rethrash/tattoo/tattoo/ is the root of our repository. That would make it http://svn1.cvsdude.com/rethrash/tattoo/tattoo/branches/0.9.6/ as a fully-qualified URL.