Except for the one "$side = ddcountry" which you missed converting...
On Mon, Sep 15, 2014 at 12:03 PM, Yehuda Katz <yeh...@ymkatz.net> wrote: > EasyApache is the cPanel program that builds the Apache (and PHP) binaries > and config files, so if you use cPanel, you use EasyApache. > > I looked on my cPanel server and found this directive: > <IfModule mod_include.c> > <Directory "/home/SITENAME/public_html"> > SSILegacyExprParser On > </Directory> > </IfModule> > > You should be able to put SSILegacyExprParser Off in your .htaccess. > > I downloaded both of your files and (again, after changing the matched > URLs) they appeared to work perfectly for me. > > - Y > > On Mon, Sep 15, 2014 at 11:23 AM, Simen Mangseth <s...@live.no> wrote: > >> To take the good news first, I changed it to the echo element, and the >> encoding now works. Thanks. >> >> However, the expressions still refuses to work. I’m thinking maybe I >> already have the legacy filter on, because I read here that cPanel puts on >> that setting if you’re using EasyApache. I don’t know if I’m using >> EasyApache, but here’s >> <http://docs.cpanel.net/twiki/bin/view/EasyApache/Apache/Apache24Issues#Server-Side%20Include%20(SSI)%20Expres> >> the >> link anyways. >> >> Is there a way to check if the setting is on or off? If the legacy filter >> is on, are the new expressions still valid, too? >> >> I’ll just include the files anyways, if it’s my fault. It won’t work. I’m >> thinking, the old code worked if only one expression and not “||” (the >> or-sign), the new code doesn’t work on anything. >> >> the 404.shtml a small file defining some variables and including the >> error template 1HTTP.shtml. >> >> / Simen >> >> *Fra:* Yehuda Katz <yeh...@ymkatz.net> >> *Sendt:* søndag, 14. september 2014 19:54 >> *Til:* users@httpd.apache.org >> >> On Sun, Sep 14, 2014 at 4:03 AM, Simen Mangseth <s...@live.no> wrote: >> >>> Thanks for your reply, Yehuda. However, I can’t get any of your >>> suggestions to work. You can get the whole file if you want, but for the >>> time being, I’ll just send the pieces of code that doesn’t work. >>> >>> Here’s the new if-code: >>> <!--#if expr="%{SERVER_NAME} =~ /dans.no/ || %{SERVER_NAME} =~ >>> /dans.dansas/" --> >>> <!--#set var="side" value="dans" --> >>> <!--#elif expr="%{SERVER_NAME} =~ /dedanseglade/ || %{SERVER_NAME} =~ / >>> dd.no/" --> >>> <!--#set var="side" value="dd" --> >>> <!--#elif expr="%{SERVER_NAME} =~ /gullskoen/" --> >>> <!--#set var="side" value="gullskoen" --> >>> <!--#elif expr="%{SERVER_NAME} =~ /ddcountry/" --> >>> <!--#set var="side" value="ddcountry" --> >>> <!--#endif --> >>> >> >> I took this exact code and changed the URLs to match several that point >> to my server and it worked fine. What URLs are you expecting to hit? >> I can add them to my hosts file and see if they match. >> >> >>> Now nothing works, not even the two last ones with no “||”-expression >>> that worked before. >>> >>> I still use this to reference to this, though: >>> <!--#if expr="side = dd" -->DeDanseglade >>> <!--#elif expr="$side = ddcountry" -->DDCountry >>> <!--#elif expr="$side = gullskoen" -->Gullskoen >>> <!--#elif expr="$side = dans" -->Dans >>> <!--#else -->DansAS >>> <!--#endif --> >>> >>> Should I change it to percentage, brackets and the tilde, too? I’ll try >>> now. >>> >> >> This is what I used: >> >> <!--#if expr='v("side") = "dd"' -->DeDanseglade >> <!--#elif expr='v("side") = "ddcountry"' -->DDCountry >> <!--#elif expr='v("side") = "gullskoen"' -->Gullskoen >> <!--#elif expr='v("side") = "dans"' -->Dans >> <!--#else -->DansAS >> <!--#endif --> >> >> >>> I don’t want the legacy setting on, as I don’t like using old >>> legacy stuff. If something changes, I should learn it and adapt to it >>> rather than complaining and “wanting the old back” as so many does. >>> However, I do think this new syntax is complicated… >>> >>> Your second suggestion (encoding=”none”) doesn’t have any effect. This >>> is the full code, even though I don’t think it would be full of surprises: >>> <!--#set encoding="none" var="errormelding" value="<p><strong>Vi >>> beklager, men siden du har kommet til eksisterer ikke eller har blitt >>> flyttet.</strong><br>Sørg for at du har den riktige adressen.</p>" --> >>> >> The output is “<p><strong> etc..” made out of > and < html >>> characters in the code. >>> >> >> You need to set it on the <!--#echo, not on the <~--#set. >> >> >> - Y >> >> I’ve found out I’m running the latest version, 2.4.10, if that matters. I >>> have cPanel, LiteSpeed, CloudLinux, PHP and a bunch of other stuff running >>> over this. >>> >>> If you want, you can get the full code. Don’t worry, it’s not that long. >>> >>> Simen >>> >>> *Fra:* Yehuda Katz <yeh...@ymkatz.net> >>> *Sendt:* søndag, 14. september 2014 06:01 >>> *Til:* users@httpd.apache.org >>> >>> On Sat, Sep 13, 2014 at 9:53 AM, Simen Mangseth <s...@live.no> wrote: >>> >>>> I have two questions regarding SSI and .shtml files. >>>> >>>> 1: I’m using Apache 2.4, and now I can’t write like this anymore: >>>> >>> The simplest option might be to enable the Legacy Expression PArser: >>> >>> SSILegacyExprParser on >>> http://httpd.apache.org/docs/2.4/mod/mod_include.html#ssilegacyexprparser >>> >>> >>>> <!--#if expr="$SERVER_NAME = /dans.no/ || $SERVER_NAME = /dd.no/" --> >>>> I’ve read that there’s a new syntax, but on the website I don’t >>>> understand it, even after reading It many times. So the question is: How do >>>> I transform this simple expression into the new syntax? >>>> >>> >>> <!--#if expr="%{SERVER_NAME} =~ /dans.no/ || %{SERVER_NAME} =~ /dd.no/" >>> --> >>> >>> >>> 2: When I’m creating a variable with #set like this: >>>> <!--#set var="errormelding" value="<p><strong>Text…</strong></p>" --> >>>> The HTML code appears in the output. I don’t get a paragraph, or bold >>>> text, as I want. How do I do this? >>>> >>> >>> This might be a bug, since the documentation says default encoding is >>> none, but I was able to reproduce it. >>> You can get around it by adding encoding="none" to your echo. For your >>> example: >>> <!--#echo encoding="none" var="errormelding" --> >>> >>> >>> I’m sorry, but I’ve just started learning this, so I don’t know much yet. >>>> >>> No need to apologize, it is really why the list is here. >>> >>> - Y >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> > >
