Redirect script beïnvloed admin

timdebuurman · **Posted:** Mon Feb 04, 2019 10:05 pm

Hoi,

Ik heb in de sjabloon een re-direct script gemaakt, met een UDT die redirect (zelfde als de standaard redirect_to tag, maar dan met een 301 re-direct), welke getriggert wordt zodra de huidige url niet overeenkomt met de canonical url.
Dit ter voorkoming van meerdere url's met dezelfde inhoud.

Werkte prima, echter zodra je de sjabloon op wilt slaan, wil de admin ook gelijk alles uitvoeren en daar gaat het mis.

In eerste instantie opgelost door in de UDT de re-direct zelf weg te 'commenten' , dan de sjabloon op te slaan en daarna de UDT weer actief maken.
Gaat goed, echter zodra iemand dan een pagina die gebruik maakt van die sjabloon wil aanpassen in de backend, geeft hij een wit scherm, omdat hij die UDT weer gaat inladen.

Hopelijk leg ik het probleem goed uit zo.
Heeft iemand een idee over hoe dit op te lossen?

gr Tim

arnoud · **Joined:** Sun Apr 19, 2009 9:33 am **Posts:** 1381

timdebuurman \timdebuurman:

Ik heb in de sjabloon een re-direct script gemaakt, met een UDT die redirect (zelfde als de standaard redirect_to tag, maar dan met een 301 re-direct), welke getriggert wordt zodra de huidige url niet overeenkomt met de canonical url.
Dit ter voorkoming van meerdere url's met dezelfde inhoud.

Het idee van canonical url's is dat er maar 1 unieke url geindexeerd wordt binnen zoekmachines. Url's die fout geindexeerd zijn worden na verloop van tijd correct geindexeerd als de canonical url eenmaal goed staat.

In cmsms zijn url's altijd op verschillende manieren op te vragen. Zowel "met" als "zonder" pretty url's kan dit op heel veel verschillende manieren. Neem als voorbeeld een pagina met als alias "contact".

Deze kan opgevraagd worden als:
yourwebsite.nl/contact (met pretty urls)
yourwebsite.nl/contact?foo=bar (met pretty urls)
yourwebsite.nl/index.php?page=contact (met en zonder pretty urls)
yourwebsite.nl/index.php?page=contact&foo=bar (met en zonder pretty urls)
.... etc

Om voor iedere variant een redirect te introduceren lijkt me ondoenlijk.

Probeer je een probleem op te lossen of heb je zelf een probleem gecreëerd voor iets wat geen probleem is?

Een '301' redirect is wel nuttig voor een pagina die hernoemt is of niet meer op te vragen is op de 'oorspronkelijk geindexeerde' url.

Meestal is je .htaccess bestand de beste plek om een redirect 301 te plaatsen.

Bijvoorbeeld:

\$1:

RewriteRule ^contact /route/ [R=301,L]
RewriteRule ^blog/([0-9]+)/([0-9])+/(.+)/$ nieuws/$1/$2/$3/ [R=301,QSA,L]

timdebuurman \timdebuurman:

Werkte prima, echter zodra je de sjabloon op wilt slaan, wil de admin ook gelijk alles uitvoeren en daar gaat het mis.

In eerste instantie opgelost door in de UDT de re-direct zelf weg te 'commenten' , dan de sjabloon op te slaan en daarna de UDT weer actief maken.
Gaat goed, echter zodra iemand dan een pagina die gebruik maakt van die sjabloon wil aanpassen in de backend, geeft hij een wit scherm, omdat hij die UDT weer gaat inladen.

Hopelijk leg ik het probleem goed uit zo.
Heeft iemand een idee over hoe dit op te lossen?

gr Tim

Pagina's die via de /admin [Preview]-tab bekeken hebben laten in je Apache Access log ongeveer het volgende zien:

\$1:

192.xx.xx.xx - - [05/Feb/2019:19:55:06 +0100] "GET /index.php?page=-15&junk=43949988944 HTTP/1.1" 200 4257 "http://yourwebsite.nl/" "user-agent"

Je kunt in je UDT via de _REQUEST['uri'] en preg_match checken of de junk parameter in de url voorkomt, zodoende weet je dat deze opgevraagd is via /admin [Preview].

http://php.net/manual/en/reserved.variables.request.php
http://php.net/manual/en/function.preg-match.php

timdebuurman · **Posted:** Thu Feb 07, 2019 9:00 am

Hoi Arnoud,

Bedankt voor je uitgebreide antwoord.

Je hebt helemaal gelijk voor wat betreft de canonical hoor.
Dat was dan ook mijn eerste reactie naar mijn opdrachtgever hierover.

Ook heb ik duidelijk gemaakt dat andere url's in hun metingen (o.a. via Google) alleen kunnen komen doordat er verkeerde links bestaan naar die pagina's.

Toch bleven er 'verkeerde' url's verschijnen in de bezoekersmetingen en was hun duidelijke wens om het zo te maken dat er ten ale tijde zou worden doorgestuurd naar de juiste url.

Vandaar dus mijn scriptje, die een canonical opbouwd aan de hand van de gehanteerde url-opbouw.
De canonical in modules zoals LISE en News worden dan in de sjablonen daarvan opgebouwd en de pagina's zelf weer anders.

Dit resulteerd nu in zoiets als dit in de slabloon (2-talig, vandaar de 'nl en 'en'):

\$1:

{if $newscanonical}
    {$canonical = $newscanonical}
{elseif $portcanonical}
    {$canonical = $portcanonical}
{else}
    {capture assign="canonical"}https://{$smarty.server.HTTP_HOST}{if $parent && $parent != 'nl' && $parent != 'en' && $parent != 'topmenu-nl' && $parent != 'topmenu-en'}/{$parent|lower}{/if}/{if $page_alias != 'welkom' && $page_alias != 'home'}{$page_alias}{/if}{/capture}
{/if}
{capture assign="currenturl"}https://{$smarty.server.HTTP_HOST}{$smarty.server.REQUEST_URI}{/capture}
{assign var="currenturl" value="?"|explode:$currenturl} 
{if ($currenturl[0] != $canonical) && $page_alias != 'nieuws'}{redirect_301 to=$canonical}{/if}

Zoals je kunt zien heb ik hiermee wel de parameters ondervangen.

De varianten zonder de pretty url's niet, maar die komen ook in het geheel niet voor in de metingen. Hier komen dus blijkbaar niet per ongeluk links van ergens terecht.

Ik begrijp dus goed dat er in de basis niet echt een probleem is en dat een beetje is gecreëerd door mijn opdrachtgever.

Echter lijkt deze oplossing nu wel goed te functioneren, afgezien mijn probleempje dat zodra ik de sjabloon wilde opslaan (dus niet eens een preview probeerde) hij blijkbaar tijdens het opslaan alle php gaat uitvoeren.
Hierdoor ging het mis met het redirect script.

Dit heb ik nu op weten te lossen door in de UDT enkele ip-adressen uit te sluiten van de re-direct.
Aangezien ik voor de veiligheid ook de admin-toegang alleen open zet voor ingevoerde ip-adressen, werkt deze oplossing wel.

gr Tim

arnoud · **Joined:** Sun Apr 19, 2009 9:33 am **Posts:** 1381

Als dan niet een redirect uitvoeren op basis van een ipadres is mooi gevonden.

Zelf had ik het volgende in gedachte, goed te doen in een udt/php, wat lastiger in Smarty:

\$1:

$needle = 'junk';
preg_match("/(^.*)(\?|\&)($needle)(.*$)/", $_SERVER['REQUEST_URI'], $matches);

if ($matches[3] == $needle) {
  print "no redirect \n";
} else {
  print "redirect\n";
}

Het nadeel van News/CGBlog is dat de (pretty)url standaard gebasseerd is op het geen er in de titel staat. Wijzigd de titel nadat deze anders geindexeerd is door zoekmachines dan is het artikel nog wel op te vragen alleen onder een andere URL. Herstel (middels aangepaste canonical ) duurt lang.

Je kunt je opdrachtgever wijzen op de "Slug URL" of meegeven wat de invloed is van teveel aanpassingen in titel/slug.

Op basis van LISE heb ik in het verleden een blog site gebouwd (de opdrachtgever had de wens artikelen in een zelf bepaalde volgorde te plaatsen, iets wat met News/CGBlog alleen op basis van datum, titel etc kan).

Omdat teksten continue herschreven werden en titels/aliasen ook veel aangepast werden stonden bepaalde artikelen wel in de zoekmachines maar hadden ze na wijziging vaak een andere URL.

Een lastige kwestie, mijn leermoment zorg er altijd voor dat er een "primary-key, artikel id" in de url staat dan is er nog wat te herschrijven.. redirecten in Smarty, PHP of .htaccess.

Qua zoekmachine indexering moet je geduld hebben en niet panisch worden als er hier en daar iets uit de pas loopt.

timdebuurman · **Posted:** Thu Feb 07, 2019 9:57 am

Hey,

Ik heb dit in mijn nieuwssjabloon:

\$1:

{assign var="conurl" value="/"|explode:$entry->canonical}
{assign var="last" value=$conurl|@end} 
{capture assign="newscanonical"}https://{$smarty.server.HTTP_HOST}/news/{$entry->id}/{if $entry->category == 'nl'}132{elseif $entry->category == 'en'}100{/if}/{$last}{/capture}
{$newscanonical = $newscanonical scope=global}

Gaat wel goed volgens mij, ook bij wijzigen van een titel...

Rolf · **Posted:** Thu Feb 07, 2019 10:02 am

Met https://cmscanbesimple.org/blog/base-cms-made-simple-page-template-with-automated-metatags kun je een goede/correcte canonical URL maken.

In de Page Template zou je met Smarty, een vergelijk kunnen maken tussen de daadwerkelijk URL in de browser (https://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI])
en de Canonical URL. Als deze niet overeenkomt kun je (met een meta redirect commando) een redirect uitvoeren naar de canonical URL.
Of is dit te simpel gedacht?

grt. Rolf

arnoud · **Joined:** Sun Apr 19, 2009 9:33 am **Posts:** 1381

Dat is een mooi "eenvoudig" begin echter zijn er nog wel een aantal aanpassingen nodig:

1) Een meta-redirect heeft geen http status code 301 (301: Definitief verplaatst), maar een http status code 200. (Voor 100% zekerheid controleren in browser debug tools).

De redirect tags van cmsms (redirect_page, redirect_url), zijn niet bruikbaar want deze hebben geen parameter om de gewenste status code mee te geven.

In deze tags wordt er gewerkt met een meta-refresh als php al een header heeft geprint. Een php header() functie zonder status code (standaard http code 200) als er nog geen header geprint is.

http://php.net/manual/en/function.header.php

2) Geen redirect vanuit de /admin

Checken op de parameter junk is bedoeld om een redirect te voorkomen als de editor de "preview"-tab bekijkt tijdens het bewerken van een pagina in /admin. @timdebuurman gebruikt hier een ipadres check voor.

\$1:

$needle = 'junk';
$uri = $_SERVER['REQUEST_URI'];
preg_match("/(^.*)(\?|\&)($needle)(.*$)/", $_SERVER['REQUEST_URI'], $matches);

Ik maak me niet zo druk om verschil tussen door zoekmachine geindexeerde en opgevraagde url.

Maar mocht ik zo'n redirect functie nodig hebben. Dan zou ik voor een "generieke" UDT oplossing gaan. Een die ook buiten News te gebruiken is. In minder dan 10 regels php code te doen.

In Smarty wordt de logica snel te complex en zoals aangegeven hebben de standaard redirect_page, redirect_url beperkingen wat betreft http codes, dit zou een mooie feature zijn

Opvragen/vergelijken van canonical en werken met:

\$1:

$_SERVER[HTTP_HOST]
$_SERVER[REQUEST_URI]

is perfecte basis, genoeg inspiratie te vinden in gespecialiseerde CMSMS blogs

timdebuurman · **Posted:** Thu Feb 07, 2019 11:53 am

Hier dan nog even mijn gebruikte UDT, inderdaad omdat de standaard redirect-tags gen 301 redirect doen:

\$1:

require(dirname(dirname(dirname(__FILE__))) .'/cache.php');

$redirectto = $params['to'];

if(!$disablecache) {

header("Location: ".$redirectto,TRUE,301);
exit(0);

}

In dit geval bevat cache.php een script om cachebestanden weg te schrijven, maar daarin zitten ook uit te sluiten ip-adressen.
Indien het zo'n ip-adres bevat, wordt de variabele 'disablecache' op true gezet.
Vandaar hierin de check op die variabele.

arnoud · **Joined:** Sun Apr 19, 2009 9:33 am **Posts:** 1381

Vanuit /admin ["preview"] hoeft de cache niet leeg gemaakt te worden want de "cache-buster" zit al in de junk parameter, die na iedere pagina wijziging veranderd.

\$1:

http://yourwebsite.nl/page?junk=XXXXX

Zorgen dat editors (waarvan het ipadres bekend is) altijd een niet gecachde pagina te zien krijgen, kan weinig kwaad.

Ik heb vernomen dat CMSMS 2.3 op gebied van Smarty/Template caching "standaard" minder gaat doen en meer aan de developer over gaat laten waar wel en niet te cachen.

Heb zelf weinig problemen met Smarty/Template caching, maar doe dan ook weinig met redirecting.

Tijdens het ontwikkelen liep ik in het verleden wel eens tegen caching problemen in .css en .js bestanden (oude versie na doorvoeren wijzigingen). Dit heb ik met assetfingerprints / hashes opgelost in mijn build tool.

Een editor zal hier niet veel last van hebben want templates, css, js zijn over het algemeen erg stabiel als een site in productie genomen is.

Rolf · **Posted:** Thu Feb 07, 2019 5:29 pm

UDT RedirectCanonical

\$1:

$canonical_url = isset($params['canonical_url']) ? $params['canonical_url'] : '';

if ( $canonical_url != '' ) 
{
  $stripped_url = preg_replace('(^https?://)', '', $canonical_url);
  $browser_url = htmlspecialchars ( $_SERVER[HTTP_HOST] . $_SERVER[REQUEST_URI] );

  if ( $stripped_url != $browser_url )
  {
    header('Location: ' . $canonical_url , TRUE, 301);
    exit();
  }
}

Correcte canonical URLs via:
https://cmscanbesimple.org/blog/base-cm ... d-metatags

In de Page Template onder de canonical regel van mijn blog roep je de UDT aan.

\$1:

{$canonical_url = $canonical_url|default:"{$content_obj->GetURL()|lower|default:''}" scope=global}
{RedirectCanonical canonical_url=$canonical_url}

Dit voorkomt dubbele URLs bij normale pagina's, bijvoorbeeld:
https://pneumatic.tube/blah/blah/suppliers
https://pneumatic.tube/index.php?page=suppliers

Foutieve News, CGBlog, etc. zal normaal een 404 geven.

Hoe lijkt dit?

Ps. UDT code verbeterd tov eerste plaatsing!

timdebuurman · **Posted:** Fri Feb 08, 2019 7:50 am

Hoi Rolf,

Ziet er goed uit.
Lijkt op wat ik gedaan heb, met als verschil dat jij alles in de UDT hebt gedaan.

Je Blog zitten ook nog wel enkele dingen. in die ik nog niet toepaste, daar kan ik ook nog wel wat mee verbeteren..bedankt

arnoud · **Joined:** Sun Apr 19, 2009 9:33 am **Posts:** 1381

Ziet er op het eerste gezicht goed uit.

Er zijn nog wel wat edge cases, bijvoorbeeld wanneer je deze udt ook op een pagina plaatst met news/summary en pager (de canonical url kan uit de pas lopen met de unpretty url's waarin het pagerid staat).

Voor CgBlog/News detail pagina's en normale content pagina's prima toe te passen en een mooie functionaliteit.

Om er voor te zorgen dat er in de "/admin -> Content Manager [edit] -> [preview] tab" geen redirect plaats vindt zou ik alleen nog een check op de "junk" parameter inbouwen.

Als je dit niet doet zijn bewerkingen die je op een pagina doet pas zichtbaar nadat de "submit || apply" button is aangeklikt. In de /admin area is een redirect niet wenselijk. (Tellen van bezoekers-statistieken [evil Google Analytiscs and such] ook niet).

Voorbeeld:

\$1:

$canonical_url = isset($params['canonical_url']) ? $params['canonical_url'] : '';

if ( $canonical_url != '' )
{
  $stripped_url = preg_replace('(^https?://)', '', $canonical_url);
  $browser_url = htmlspecialchars ( $_SERVER[HTTP_HOST] . $_SERVER[REQUEST_URI] );

  $needle = 'junk';
  preg_match("/(^.*)(\?|\&)($needle)(.*$)/", $_SERVER['REQUEST_URI'], $matches);

  if ($matches[3] == $needle)
  {
    return;
  }

  if ( $stripped_url != $browser_url )
  {
    header('Location: ' . $canonical_url , TRUE, 301);
    exit();
  }
}

timdebuurman · **Posted:** Fri Feb 08, 2019 8:32 am

Hoi Arnaud,

Je refereert steeds aan de Preview mogelijkheid, maar ik heb dus gemerkt dat het gewon opslaan van een sjabloon ook al resulteert in het uitvoeren van de scripts die in de sjabloon staan.

Ik kon daardoor zonder die ip-check de sjabloon met die UDT er in niet eens opslaan.

gr Tim

arnoud · **Joined:** Sun Apr 19, 2009 9:33 am **Posts:** 1381

timdebuurman \timdebuurman:

Hoi Arnaud,

Je refereert steeds aan de Preview mogelijkheid, maar ik heb dus gemerkt dat het gewon opslaan van een sjabloon ook al resulteert in het uitvoeren van de scripts die in de sjabloon staan.

Ik kon daardoor zonder die ip-check de sjabloon met die UDT er in niet eens opslaan.

gr Tim

Ik sla al mijn templates in bestanden op en hang zo min mogelijk in de /admin area rond tijdens het ontwikkelen.

Heb voor de zekerheid met de Design Manager -> Layout -> Create + "[Create New Template]" 2 templates aangemaakt: (1 x Core:Generic + 1 x Core:Page). Ik zie nergens een redirect uitgevoerd worden.

Als extra test heb ik aan de bovenkant van mijn UDT een: exit() gezet het opslaan van templates gaat zonder problemen.

Ik zie een redirect/RedirectCanonical alleen in de de preview-tab en wanneer het vergroot glas (preview page) in de rechterbovenhoek van de /admin area aangeklikt wordt.

Nu weet ik niet wat jouw Smarty logica met:

\$1:

{redirect_301 to=$canonical} ...

teweeg brengt maar goed dat je dit nog even aanstipt.

De voorkant van de website zonder ip-check controleren lijkt me trouwens niet ontverstandig. Redirecting kan wat problemen oplossen maar ook problemen veroorzaken: circular redirects en edge cases (zie mijn vorige post), die je niet altijd kunt overzien.

Rolf · **Posted:** Fri Feb 08, 2019 1:27 pm

Ik heb (nog) geen problemen ondervonden met de preview en opslaan van pagina's... maar kan nog komen.

Waar ik met het script wel tegen aanloop is bijzondere tekens in de URLs. Dat gaat niet altijd goed...
Ik heb voor nu het script op mijn website even uit gezet!

Toevallig heb ik net in de mail een soortgelijk script gekregen van een andere CMSMS gebruiker. Dit weekend ook eens testen!

Redirect script beïnvloed admin

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Share On:

Who is online