We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
  • I don’t see how. You go from the page the form is on to the page where the results are shown; the POST values are passed along and the AjaxSearch on the results page gets the results for you. When you go to the linked page, then hit the back button to return to the results page, the POST values don’t exist any longer, since they weren’t carried from the results page to the linked page, so now AjaxSearch can’t generate any results for you.
      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
      • 12477
      • 5 Posts
      Or, If you don’t feel up to fluffing around trying to update lovely linux, and don’t use the ajaxsearch highlighting plugin - have a try disabling it. Might work for you wink Think it was spitting blood when it came into the ’+’ character through the _POST back.
        • 19132
        • 199 Posts
        How does on disable the highlighting plugin? And does that really work?

        I’m becoming more peeved with this non-functional snippet. AjaxSearch 181 on 963 works perfectly fine on our Plesk-based server with the so-called "buggy" library. Not a single issues. So how come Evo 1 / AS 183 doesn’t work?
          MySQL: 5.0.45
          PHP: 5.2.6
          Linux 2.6.9-023stab048.6-enterprise #1
          cURL enabled
          PDO enabled
          FFox Apple 3.6.8
          Firebug DIS-abled
          • 19132
          • 199 Posts
          AjaxSearch in 963 works.

          AjaxSearch in Evo 1.0.0 and 1.0.1 don’t work.

          Plain and simple. Convince me why I should pay a professional to update my pcre library that may or may not fix the issue when 963 works irrespective of the pcre libary?

          The error lies with modx, no?
          Error: preg_replace() [function.preg-replace]: Compilation failed: lookbehind assertion is not fixed length at offset 11
          Error type/ Nr.: Warning - 2
          File: ....manager/includes/document.parser.class.inc.php(746) : eval()’d code
          Line: 101

          All I know is this: it works in 963. It doesn’t work in 1.0.1 To blame CentOS’s default library shuts MODx out of a huge number of servers, no? Compounding the issue is that I have no guarantee that updating the pcre library - as suggested here in this thread - won’t break my server when Plesk updates the server.
            MySQL: 5.0.45
            PHP: 5.2.6
            Linux 2.6.9-023stab048.6-enterprise #1
            cURL enabled
            PDO enabled
            FFox Apple 3.6.8
            Firebug DIS-abled
            • 5811
            • 1,717 Posts
            it works in 963. It doesn’t work in 1.0.1
            Yes but you haven’t the same feature neither the same version of the searchHighlight plugin !

            ==== searchHighlight and advSearchHighlight plugins 1.4

            Removed useless urldecode calls;
            Added check for magic quotes - if set, remove slashes
            Highlights terms searched for when target is a HTML entity

            All issues execpt this one has been fixed. I haven’t enought time in this moment to investigate this last issue. And As it works for other operating systems, I prefer keep these changes.
            To solve it you could investigate to understand why the following lines doesn’t run with CentOS’s default PCRE library and/or suggest a work around
                $pcreModifier = ($pgCharset == 'UTF-8') ? 'iu' : 'i';
                $lookBehind = '/(?<!&|&[^;]|&[^;][^;]|&[^;][^;][^;]|&[^;][^;][^;][^;]|&[^;][^;][^;][^;][^;])'; // avoid a match with a html entity
                $lookAhead = '(?=[^>]*<)/'; // avoid a match with a html tag
                  $pattern = $lookBehind . preg_quote($word, '/') . $lookAhead . $pcreModifier;
                  $replacement = '<span class="' . $class . '">${0}</span>';
                  $body[1] = preg_replace($pattern, $replacement, $body[1]);
            Any suggestion is welcome.

            In any case the simplest workaround for you is to use the version of the plugin searchHighlight provided with MODx
              • 19132
              • 199 Posts
              Ah! The SearchHighlight was the issue. I disabled it and re-enabled 1.3

              I wouldn’t know where to begin with troubleshooting this issue on our server except where one of the first posts above said it was CentOS pcre libary 6.6. That’s exactly what we have at Media Temple and they refuse to upgrade pcre; it’s on Plesk Professional Services to do that. So until then, SearchHighlight 1.3 seems to resolve the issue.
                MySQL: 5.0.45
                PHP: 5.2.6
                Linux 2.6.9-023stab048.6-enterprise #1
                cURL enabled
                PDO enabled
                FFox Apple 3.6.8
                Firebug DIS-abled
                • 25061
                • 3 Posts
                The short answer... Replace this:
                $lookBehind = '/(?<!&|&[^;]|&[^;][^;]|&[^;][^;][^;]|&[^;][^;][^;][^;]|&[^;][^;][^;][^;][^;])';

                with this:
                $lookBehind = '/(?<!&|&[\w#]|&[\w#]\w|&[\w#]\w\w|&[\w#]\w\w\w|&[\w#]\w\w\w\w|&[\w#]\w\w\w\w\w)';

                The long answer...
                The root cause of the problem is due to a bug in the PCRE library (v6.6 and earlier). The changelog for PCRE version 6.7 explains this quite nicely in item # 5:
                5. A negated single-character class was not being recognized as fixed-length in lookbehind assertions such as (?<=[^f]), leading to an incorrect compile error "lookbehind assertion is not fixed length".
                The regex in question is using a negated single-character class so will always result in this regex compile error. So the solution is to 1.) use pcre v6.7 or higher, or 2.) change the regex so that is does not use a negated single-character class. Solution 2 sounds like the most universal fix since pcre 6.6 (and earlier) is still in general use.

                The regex in question is a negative lookbehind that attempts to ensure that the current position in the string is not part of an HTML entity. Well, in addition to the PCRE compile error, there are other problems with this regex! For starters, the sub expression that is causing all the problems: ’[^;]’, matches exactly one character that is anything other than a semi-colon. This does, in fact, correctly match characters that are part of an HTML entity (i.e. ’&copy’, ’&#123’, ’&x1FF’, etc), but it also erroneously matches many, many characters that are NOT valid within an HTML entity! e.g. This regex matches all of the following strings and considers each them to be valid HTML entities: ’&#$%^*’, ’&=][{}’, ’& A B’, etc. To put it mildly, this regex is doing a really crappy job of (negatively) matching an HTML entity!

                There are other problems that I have with the code posted above, but let me address just the immediate problem at hand. Lets fix the PCRE compile error problem and improve its false matching. So what is a valid HTML entity? Well there are three basic types but they are all sandwiched between an ampersand & and a semi-colon ;. The insides can be a word, a decimal number preceded with a # or a hexadecimal number preceded with a #x or a #X. (i.e. ’&copy;’, ’&#123;’, ’&x1FF;’, etc). Here is a replacement for the $lookbehind regex fragment which fixes the PCRE pre-v6.7 compile bug and improves the accuracy of the HTML entity matching: (same one as given above in the short answer)
                $lookBehind = '/(?<!&|&[\w#]|&[\w#]\w|&[\w#]\w\w|&[\w#]\w\w\w|&[\w#]\w\w\w\w|&[\w#]\w\w\w\w\w)';

                For each position after the opening & we match only characters that are actually valid within an HTML entity (instead of matching anything that is not a semi-colon, as the old regex erroneously did). Note that this regex is not perfect but is much better than the original. It still matches invalid sequences such as ’&_word’, ’&#12XY’ and ’&12345’. A more accurate version could be crafted (see below), but this one is a major improvement and should solve the PCRE compile error problem.

                If you are anal and want a more exact regex here’s a more correct (but slow!) solution:
                $lookBehind = '/(?<!&|&#|&#[0-9]|&#[0-9][0-9]|&#[0-9][0-9][0-9]|&#[0-9][0-9' .
                              '][0-9][0-9]|&#[0-9][0-9][0-9][0-9][0-9]|&#[0-9][0-9][0-9][0-' .
                              '9][0-9][0-9]|&#[xX]|&#[xX][0-9A-Fa-f]|&#[xX][0-9A-Fa-f][0-9A' .
                              '-Fa-f]|&#[xX][0-9A-Fa-f][0-9A-Fa-f][0-9A-Fa-f]|&#[xX][0-9A-F' .
                              'a-f][0-9A-Fa-f][0-9A-Fa-f][0-9A-Fa-f]|&[A-Za-z0-9]|&[A-Za-z0' .
                              '-9][A-Za-z0-9]|&[A-Za-z0-9][A-Za-z0-9][A-Za-z0-9]|&[A-Za-z0-' .
                              '9][A-Za-z0-9][A-Za-z0-9][A-Za-z0-9]|&[A-Za-z0-9][A-Za-z0-9][' .
                              'A-Za-z0-9][A-Za-z0-9][A-Za-z0-9]|&[A-Za-z0-9][A-Za-z0-9][A-Z' .

                Here is the same thing in a format that can be understood by us mere mortals...

                Hope this helps! smiley
                  • 5811
                  • 1,717 Posts
                  Waouh !!! Thanks a lot Ridgerunner for this solution. This is a very impressive post about regexp.

                  I will implement this fix in the next 1.9.0 release of ajaxSearch. For CentOS users, simply change the line #113 of the plugin SearchHighlight:
                  $lookBehind = '/(?<!&|&[^;]|&[^;][^;]|&[^;][^;][^;]|&[^;][^;][^;][^;]|&[^;][^;][^;][^;][^;])'; // avoid a match with a html entity
                  by this fix:
                  $lookBehind = '/(?<!&|&[\w#]|&[\w#]\w|&[\w#]\w\w|&[\w#]\w\w\w|&[\w#]\w\w\w\w|&[\w#]\w\w\w\w\w)';

                  Merci Jeff

                  [Issue (and fix) registered as AJAXSEARCH-57]
                    • 20413
                    • 2,877 Posts
                    @ridgerunner for PRESIDENT!! cool
                      @hawproductions | http://mrhaw.com/

                      Infograph: MODX Advanced Install in 7 steps:

                      Recap: Portland, OR (PDX) MODX CMS Meetup, Oct 6, 2015. US Bancorp Tower
                      • 6126
                      • 25 Posts
                      FYI, I think this error also affects sites hosted on the Rackspace Cloud Sites.