442691 - Template stylesheets aren't absolute links, break on localized kb

Status: VERIFIED FIXED

(support.mozilla.org :: Knowledge Base Software, task)

Description

[David Tenser [:djst]]

Attachment: Broken layout because of long links

This looks like a regression because I didn't see this a couple of days before. Could it be because of the length of the popular article titles?

Also where did the Thunderbird background image go?

Comment 1

[David Tenser [:djst]]

Setting 0.6 milestone. A possible workaround is to truncate the length of the links.

Comment 2

[David Tenser [:djst]]

Seems to have been a temporary thing. Lucy saw it too, but then it went away.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

/me still sees it!

Comment 4

[Brian Krausz]

Tikiwiki bug, refiling.

When you go to /en-US/kb, you see the following code:

<link type="text/css" href="css/freetags.css" rel="stylesheet"></link>
<link type="text/css" href="styles/mozms.css" rel="stylesheet"></link>

This tries to go to /en-US/styles/mozms.css, which gives a 404.  We need to use the following instead:

<link type="text/css" href="/css/freetags.css" rel="stylesheet"></link>
<link type="text/css" href="/styles/mozms.css" rel="stylesheet"></link>

Does anyone know where this code is?  The template makes the following call: {if $headerlib}{$headerlib->output_headers()}{/if}

This is also a problem with IE-specific CSS, fixed in r16465.

Comment 5

[Nelson Ko [:nkoth]]

The code is in lib/headerlib.php



(In reply to comment #4)
> Tikiwiki bug, refiling.
> 
> When you go to /en-US/kb, you see the following code:
> 
> <link type="text/css" href="css/freetags.css" rel="stylesheet"></link>
> <link type="text/css" href="styles/mozms.css" rel="stylesheet"></link>
> 
> This tries to go to /en-US/styles/mozms.css, which gives a 404.  We need to use
> the following instead:
> 
> <link type="text/css" href="/css/freetags.css" rel="stylesheet"></link>
> <link type="text/css" href="/styles/mozms.css" rel="stylesheet"></link>
> 
> Does anyone know where this code is?  The template makes the following call:
> {if $headerlib}{$headerlib->output_headers()}{/if}
> 
> This is also a problem with IE-specific CSS, fixed in r16465.
> 

Comment 6

[Nelson Ko [:nkoth]]

The catch is that "/en-US/kb/" is ok , but "/en-US/kb" is not. Canonicalizing with the trailing slash using a redirect is always a good idea, since it may not just be the css that is affected - not sure what else requires it. 

My opinion is that since /en-US/kb is a sort of "virtual directory", it should have a trailing slash. However, a redirect is one extra request. Any good ideas? 

Making lib/headerlib.php use /.... to force it has 2 disadvantages. In principle - tikiwiki is designed to work in sub-directories [multiple tikis on one server for e.g.] (although we've pretty much broken that with our fancy URL handling), and there may be other undiscovered dependencies on /en-US/kb/ being canonicalized as a directory.

The other possibility of rewriting /???/{anything} and /??-??/{anything} and /??/{anything} and so on to the webroot could also be too liberal and catch stuff that aren't locales.

Comment 7

[Nelson Ko [:nkoth]]

Attachment: redirect <locale>/kb and so on to <locale>/kb/ with trailing slash

Comment 8

[Nelson Ko [:nkoth]]

in r16605 (trunk) and r16606 (production)

Comment 9

[Laura Thomson :laura]

Comment on attachment 327718 [details] [diff] [review]
redirect <locale>/kb and so on to <locale>/kb/ with trailing slash

Do we need 0-9 in there as well?

Comment 10

[Nelson Ko [:nkoth]]

no. locales don't have 0-9. Only operating systems.

Comment 11

[David Tenser [:djst]]

Do we need to do admin work before this is pushed or should this bug be resolved?

Comment 12

[Laura Thomson :laura]

Bulk moving open bugs to 0.6.1 

Comment 13

[Brian Krausz]

Seems to have been fixed, just never closed.

Comment 14

[Stephen Donner [:stephend] Not actively reading bugmail]

Even when I change my preferred language to be Friulian (fur), when I load http://support-stage.mozilla.org/fur/kb it doesn't redirect to http://support-stage.mozilla.org/fur/kb/.

Do .htaccess changes not show up until we push live?

Comment 15

[Laura Thomson :laura]

.htaccess changes need to be activated by running htaccess.sh in production.  This was requested in the push bug - Aravind?

Comment 16

[Aravind Gottipati [:aravind]]

@Laura: Not sure what the Q. here is.  There was an explicit request in the last sumo production push bug asking me to run a htaccess script, which I did.  I am not sure how other environments are set up.

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

Laura: was I testing wrong?  http://support.mozilla.com/fur/kb does redirect to http://support.mozilla.com/fur/kb/.

I assumed that I was supposed to test on support-stage first, but if the script is production-only, then this can be verified FIXED...

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

This landed in trunk according to the SVN rev # in comment 8, so waiting until I can verify in both places.

Comment 19

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED; htaccess.sh was just run on staging, and so I've verified both staging and production redirect me properly; thanks to bkrausz for poking IT :-)