Announcement

**cdicken** · 08-May-2003, 01:51 PM

Thanks Norman

I'm not sure whether that is a record or not, but I'm sure it will count as as a personal best.

I've passed on your findings to the team.

**zmagyar** · 08-May-2003, 02:12 PM

Thanks Norman,

As Chris reported your finding I have checked this issue. I think the script is working correctly for most of the cases. However it looks like you have managed to find a case when it doesn't. :-) Actually the highlight is done for everything what is not enclosed by < and >. See

$$rsHTML =~ s'\>(.*?)\<'
my $t = $1;
$t =~ s/($sPattern)/$sStart$1$sEnd/gsi;
">$t<";
'gesi;

As far as I can see this can be broken if single < or > characters in the page source. Can you check if it is the case please?

**NormanRouxel** · 08-May-2003, 02:19 PM

Zoltan,

You might need to repost that fragment inside [ CODE ] and [ / CODE ] tags as the forum is messing it up.

I think that excluding anything between <script and </script may need to be done before the above first.

Norman

**NormanRouxel** · 08-May-2003, 08:56 PM

Zoltan,

That's a bitchy bit of Perl. I've done this to keep my site working safely.

In ACTINIC.pm routine HighlightWords I changed the entire loop starting
"foreach $sPattern (@Patterns)" to:-

Code:

   foreach $sPattern (@Patterns)
      {
      my $sTemp = $$rsHTML;
      my $sFixed = '';
      while ( $sTemp =~ m/(.*?)\<script (.*?)\<\/script\>(.*)/is )	# first look for <script...>    </script> tags
  		{
                my $sT1 = $1;
		my $sT2 = $2;
                my $sT3 = $3;

		$sT1 =~ s'\>(.*?)\<'			 # Highlight the bit before the <script...>
	           #
	           # see WARNING above...this is the start of code generation
	           # the indentation is correct - single quote is a delimiter like "{"
        	   #
	           # Extract the text between adjacent markup tags into $1.
	           # Many end up ($1 eq "") or ($1 =~ /\s/), but Perl should
        	   # quickly search-mismatch on those anyway via length checking.
      	   	   # Since this is a global replace, it will essentially reread
	           # the HTML for each pattern - ok for $#Patterns of 1 or 2, if
	           # we allow many more than that, the loop should be reconsidered.
	           # For highlighting, more than 3 or 4 may be unworkable anyway.
	           # But an advanced search with one match out of a much larger
	           # group of patterns could occur.
	           #
	           my $t = $1;
	           $t =~ s/($sPattern)/$sStart$1$sEnd/gsi;
	           #
	           # Re-insert the text, now surrounded by highlight on/off, between
			# the original markup tags with markup delimiters since the original
			# used them to search
	           #
        	   ">$t<";
	           #
	           # see WARNING above...next line is the finish
	        'gesi;                                    # ' # This single quote eliminates formatting problems with emacs

		$sFixed .= $sT1 . '<script ' . $sT2 . '</script>';
		$sTemp = $sT3;				 # the bit after the </script>
        	}

	$sTemp =~ s'\>(.*?)\<'				 # Highlight the final bit of the page (see WARNING above).
          my $t = $1;
          $t =~ s/($sPattern)/$sStart$1$sEnd/gsi;
          ">$t<";
        'gesi;                                    	 # ' # This single quote eliminates formatting problems with emacs

      $$rsHTML = $sFixed . $sTemp;		         # now save all we've done		
      }

However I'm sure there are better ways to do this especially if they reduce the amount of processing that is going on.

The existing way calls that inner replace for every HTML tag in the page times every keyword to highlight.

Norman

**zmagyar** · 08-May-2003, 08:56 PM

Originally posted by NormanRouxel
Zoltan,

You might need to repost that fragment inside [ CODE ] and [ / CODE ] tags as the forum is messing it up.

Sorry, but that's the code.

But I agree it looks like a mess. I can recall when I saw Actinic scripts first time I thought Richard (who was working on the scripts before me) allowed his cats to play with the keyboard.

Anyway I think it helps if I put it here with full comments. See below.

Code:

      $$rsHTML =~ s'\>(.*?)\<'
         #
         # see WARNING above...this is the start of code generation
         # the indentation is correct - single quote is a delimiter like "{"
         #
         # Extract the text between adjacent markup tags into $1.
         # Many end up ($1 eq "") or ($1 =~ /\s/), but Perl should
         # quickly search-mismatch on those anyway via length checking.
         # Since this is a global replace, it will essentially reread
         # the HTML for each pattern - ok for $#Patterns of 1 or 2, if
         # we allow many more than that, the loop should be reconsidered.
         # For highlighting, more than 3 or 4 may be unworkable anyway.
         # But an advanced search with one match out of a much larger
         # group of patterns could occur.
         #
         my $t = $1;
         $t =~ s/($sPattern)/$sStart$1$sEnd/gsi;
         #
         # Re-insert the text, now surrounded by highlight on/off, between
	 # the original markup tags with markup delimiters since the original
	 # used them to search
         #
         ">$t<";
         #
         # see WARNING above...next line is the finish
      'gesi;

I think that excluding anything between <script and </script may need to be done before the above first.

Probably that would help a bit but it may significantly increase the complexity of the highlighting code which is complex enough without such a change (especially if further exclusions are requested later due to special problems). I think enclosing the javascript code by  tags resolves most of the cases. The only case when it doesn't work properly if < and > operators are used in the script. That case I would suggest to move the script to an external js file so it won't be parsed.

Regards

**NormanRouxel** · 08-May-2003, 09:10 PM

Zoltan,

I had included !<-- and // --> tags in my javaScript (the Actinic routines don't bother by the way) and they still broke. The problem there is that "<" and ">" may be necessary in the JavaScript (especially if it's writing HTML tags).

I've posted just above your message my initial fix. This doesn't add too much to the complexity but isn't a general purpose solution.
There's an extra loop that excluded <script..> </script> tags and that won't be too much of an overhead as there will only be a handful of <script..> tags compared with the hundreds or thousands of HTML ones.

Remember that this fails on Actinic's own routines. Anyone searching for OPTION for example (I just found 19 such results on my own site) will break the standard code Actinic puts in Act_Primary.

Norman

**zmagyar** · 08-May-2003, 10:32 PM

Originally posted by NormanRouxel
I had included !<-- and // --> tags in my javaScript (the Actinic routines don't bother by the way) and they still broke. The problem there is that "<" and ">" may be necessary in the JavaScript (especially if it's writing HTML tags).

Correct. However your example didn't contain those chars so I can't see how could it fail in your case. I have tested it with the original templates and it seems to be working fine. I would be interested in your template as it can affect the final resolution. Can you post it to me please?

I've posted just above your message my initial fix. This doesn't add too much to the complexity but isn't a general purpose solution.
There's an extra loop that excluded <script..> </script> tags and that won't be too much of an overhead as there will only be a handful of <script..> tags compared with the hundreds or thousands of HTML ones.

I agree that it doesn't seem to be a performance hit. However the server side performance is a top priority ATM and I can imagine a few cases when this can be a problem. Due to our large customer base we should be really careful doing such changes.

Remember that this fails on Actinic's own routines. Anyone searching for OPTION for example (I just found 19 such results on my own site) will break the standard code Actinic puts in Act_Primary.

I have posted a bug report for this. Thanks.

Regards,

**NormanRouxel** · 08-May-2003, 11:29 PM

Hi Zoltan,

Glad to hear the bit about server side performance being so important. I wholeheartedly agree.

My templates had thing in them like:-

document.write('<br>');

which was confusing the highlight code.

Re the bug report.

The easiest way to demonstrate this is to use the out of the box Demo Site. Go to any product or section page and search for "select". You'll get a few hits. Now choose the top item "Desktop PC" and - kaboom - lots of JavaScript errors. It's the ACT_DropListBox function that gets corrupted. This is typical of the problems I'm getting as well.

Norman

**zmagyar** · 12-May-2003, 09:26 AM

Hi Norman,

Some kind of good news. After some investigation and discussion it has been decided to be fixed in the next maintenance release.

Regards,

**zmagyar** · 14-May-2003, 09:51 AM

Norman,

In case of you are interested in the official solution:

Code:

   my $nFragmentCount = 0;

   $$rsHTML =~ s'\<title\>.+?\<\/title\>|\<script.+?\<\/script\>'
   	#
   	# Save old content for XML parsing
   	#
   	$nFragmentCount++;
   	$ACTINIC::B2B->SetXML("ProtectFragment_$nFragmentCount", $&);
   	#
   	# Now replace the fragment to the protective XML tag
   	#
   	"<Actinic:ProtectFragment_$nFragmentCount/>";
   	'gesi;

The above code fragment is inserted to replace the lines saving the <title> tag (the lines restoring the <title> tag can also be removed).
As you can see instead of doing a two phase highlight the HTML code is preprocessed and all fragments where highlight shouldn't be done is replaced to an XML tag. The original content will be restored during the final XML parsing of the page.

Regards,

Announcement

Bug. Highlighted Search result modifies JavaScript code

Bug. Highlighted Search result modifies JavaScript code

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment