756900 - amp syntax (duplicate)

Status: VERIFIED FIXED

(SeaMonkey :: Website, defect)

Description

[ricardo.itaa]

When I view the source it says "&" instead of "&".
Take a look at http://www.seamonkey-project.org/start/ and see the list on the left.

I couldn't access or edit the source of start/index_en.html so I decided to report the bug.

I paste part of the source here:

	<li><a href="../">Home</a></li>
	<li><a href="../news">News</a></li>
	<li><a href="../releases/">Download &amp;amp; Releases</a></li>
	<li><a href="../start/">Start Page</a></li>
	<li><a href="../community">Community &amp;amp; Support</a></li>
	<li><a href="../doc/">Documentation &amp;amp; Help</a></li>

Comment 1

[Andrew Poth]

The error appears on most pages on the site, as if it is part of a server-side include in the page format.

Comment 2

[TrondBK]

Tested the SeaMonkey homepage in multiple browsers, both 32bit and 64bit, but they all show the double & because the HTML code is like the poster indicates with the unneeded "amp;" in the menu code. Are there any other OSes or environments where this issue does not occur? I use Windows 7 Enterprise 64bit and have tested the pages in IE9, Chrome 19, Firefox 12, Nightly 15.0a1 and SeaMonkey 2.9.1 (release).

(Cut & Paste from http://www.seamonkey-project.org/)

    Home
    News
    Download & Releases
    Community & Support
    Documentation & Help
    Add-Ons
    SeaMonkey Shop
    Donate
    Development
    Legal Resources
    About

I guess this coding issue has a very low priority, but it is pretty obvious on the home page, it should be easy to fix. Would the removal of the double "amp;" affect any users negatively? Thanks in advance for any replies. :-)

Comment 3

[Tony Mechelynck [:tonymec]]

I confirm this, browsing with SeaMonkey (Linux 64 trunk version), and Jeff Lee saw it too (and reported it by email using 32-bit Thunderbird on 64-bit Windows).

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

The reason for this mess lies in the website building server migration that happened few weeks ago. Before that, the website builder server behaved like my local website build environment, but after the migration it started to show this issue.

The problem is related to how the website building works. It's mostly based on Perl Template Toolkit. The affected sidebar entries mentioned in the comments above are located inside an XML file (sitemap.xml). Obviously, in an XML file, characters like the ampersand need to be escaped using entities like &. That file is included into the sidebar template (sidebar.tmpl) through the XML::Simple Perl plugin, which is used to add certain parts of the XML file to the HTML output. In HTML, again characters like the ampersand need to be escaped.

In order to have the desired result of & in the output HTML, we have & in the XML file. This is also what you can see in the HTML source of the production website, but that doesn't necessarily mean that no processing was applied to that string. I suspect that XML::Simple decodes the & entity, but then, in production unlike locally in my test environment, either XML::Simple or Template Toolkit re-encode the ampersand into the & entity. So the problem is either with Template Toolkit itself, XML::Simple, or something else in the chain.

XML::Simple has a configuration option called NoEscape [1] which we could try to pass in sidebar.tmpl (since everything works as expected locally we can only use production to test this, but I at least checked that introducing that option does not make it worse locally).

[1]: http://search.cpan.org/~grantm/XML-Simple-2.18/lib/XML/Simple.pm#NoEscape_=%3E_1_#_out_-_seldom_used

I'll try to get someone on #it to test this out for us when I have some time (AFAIK the website is still not back to updating automatically, see bug 752691). FTR, this is what I was thinking about (fixing the nit while we're there is just typically me; you can ignore that):

diff -u -r1.6 sidebar.tmpl
--- sidebar.tmpl        28 Jun 2010 15:45:31 -0000      1.6
+++ sidebar.tmpl        2 Jun 2012 13:52:38 -0000
@@ -1,7 +1,8 @@
 [% USE site = XML::Simple( 
        'sitemap.xml'
        ForceArray = ['page']
-       KeyAttr = ['' ]
+       KeyAttr = ['']
+       NoEscape = 1
    )
 %]

Callek, if you get to this before me, feel free to go ahead. :-)

Comment 6

[Jens Hatlak (:InvisibleSmiley)]

Bah, unfortunately I missed during my investigation that NoEscape is an XMLout option rather than an XMLin one, so it cannot be used in our setup where only XMLin is used:

http://cpansearch.perl.org/src/ABW/Template-XML-2.17/lib/Template/Plugin/XML/Simple.pm

The only other Perl module I could recognize as being part of the process is XML::XPath. Might be interesting to know which version of that is installed at our server. Locally I have the latest version, 1.13. That module is pretty old (2001), though, so I guess our server has the latest version, too.

XML::XPath::Node contains a function called DecodeDefaultEntity, called by function XMLescape, which translates e.g. "&" to "&amp;". The strings that cause our issues here are inside an XML attribute (named "title"), so XML::XPath::Node::Attribute is responsible for that. That module's toString function calls XMLescape and tells it to translate characters "&>< so title="&" becomes title="&amp;". So if the toString function is called at all (didn't check), that would suggests what our server does is correct, but not why our old server and my local environment behave differently. :-/

Now we're basically back at the beginning. As much as I dislike it, I guess it'll be easier to replace the four "&amp;amp;" occurrences by something like "and", "+" or "/" than continue the investigation of what caused the regression and how to fix it. 

Callek, Tony, KaiRo, what are your preferences?

Comment 7

[Jens Hatlak (:InvisibleSmiley)]

Replace "&" by "and" for now

Checking in lib/sitemap.xml;
/www/seamonkeyproject-org/lib/sitemap.xml,v  <--  sitemap.xml
new revision: 1.118; previous revision: 1.117
done

[Will go live with SM 2.10 website update within the next few hours.]

Comment 8

[Tony Mechelynck [:tonymec]]

The problem has been worked around by writing "and" in full 3 times in the left sidebar of the page. => VERIFIED.