Problem mit Navigation wenn auf der Referenz-Seite eingebunden

[Spooky]

Angenommen man hat folgende Struktur:

- OnePageWebsite <-- reference, regular structure module, navigation module
    - Page 1
    - Page 2
    - Page 3

Man legt also die OnePageWebsite Page als Referenzseite fest und möchte dort auch die Ausgabe der Subpages für die OnePageWebsite machen. In so fern hat man auch das Navigationsmodul dort, bzw. im Seiten-Layout eingebunden.

Jetzt bereitet aber folgender Code ein Problem: system/modules/onepagewebsite/OnePageWebsite/Frontend/ModuleOnePageWebsiteNavigation.php, Zeile #173 ff.

// href
if($objJumpTo->id != $objPage->id && $objJumpTo->id > 0)
{
    $href = $this->generateFrontendUrl($objJumpTo->row()) . '#page' .$objSubpages->id;
}
else
{
    $href = '#page' .$objSubpages->id;
} 

Die Condition verursacht, dass, wenn die Referenz-Seite und die aktuelle Seite gleich sind, der href zB nur "#page1" wird, anstatt bspw. "onepagewebsite.html#page1".

Dies mag zwar auf den ersten Blick sinnvoll erscheinen, allerdings funktionieren anchor links nicht, wenn ein <base href="..."> existiert! Solche Links, also wie zB href="#page1" führen dann immer zu der im base href angegeben URL, also zB http://www.domain.com/#page1.


Beispiel, unabhängig von Contao und OPW: angenommen man hat eine foo.html auf domain.com. In dieser foo.html befindet sich bspw.

<a href="#target">...</a>

...

<h2 id="target">...</h2> 

Ohne base href funktioniert dies wunderbar, der Browser möchte dann zu http://www.domain.com/foo.html#target springen, wenn man den Link betätigt. Hat man allerdings folgendes:

<base href="http://www.domain.com/">

...

<a href="#target">...</a>

...

<h2 id="target">...</h2> 

funktioniert dies nicht mehr. Der Browser wandelt href="#target" zu http://www.domain.com/#target um anstatt http://www.domain.com/foo.html#target



Beispiel online: http://www.inspiredminds.at/files/mi...ehref/foo.html


Insofern ist es wahrscheinlich sinnvoll sowieso immer

$href = $this->generateFrontendUrl($objJumpTo->row()) . '#page' .$objSubpages->id; 

zu verwenden (und ggf. den $objJumpTo->id > 0 check zu Zeile #165 hinzu zu fügen), da Contao den base href tag ja immer ausgibt, sofern man das nicht selbst ändert.


Unter Umständen ist dieser Fehler bis jetzt noch niemanden aufgefallen, weil die empfohlene Struktur ja so aussieht:

- Foo <-- regular structure, navigation module
    - Referenz <-- reference
        - Page 1
        - Page 2
        - Page 3

Da tritt der Fehler ja nicht auf, weil

$objJumpTo->id != $objPage->id 

immer true ist.

[folkfreund]

Beispiel, unabhängig von Contao und OPW: angenommen man hat eine foo.html auf domain.com. In dieser foo.html befindet sich bspw.

<a href="#target">...</a>

...

<h2 id="target">...</h2> 

Ohne base href funktioniert dies wunderbar, der Browser möchte dann zu http://www.domain.com/foo.html#target springen, wenn man den Link betätigt. Hat man allerdings folgendes:

<base href="http://www.domain.com/">

...

<a href="#target">...</a>

...

<h2 id="target">...</h2> 

funktioniert dies nicht mehr. Der Browser wandelt href="#target" zu http://www.domain.com/#target um anstatt http://www.domain.com/foo.html#target

Verständnisproblem:
wieso hast du auf einer OnePageWebsite eine foo.html?
Es dürfte dort doch eigentlich nur eine Seite geben, und alle Anker wären in dieser Seite.

folkfreund

[Spooky]

Verständnisproblem:
wieso hast du auf einer OnePageWebsite eine foo.html?
Es dürfte dort doch eigentlich nur eine Seite geben, und alle Anker wären in dieser Seite.

folkfreund

Also erstens gilt das nur als Beispiel und hat auch nichts direkt damit zu tun, ob du eine OnePageWebsite hast oder nicht. Wenn du nur eine index.html auf deiner Domain hast, dann funktioniert es - aber eben nur zufällig.

Und zweitens gibt es natürlich kein "dürfen" bei einer OnePageWebsite. Die Extension erlaubt dir den Inhalt mehrere Unterseiten auf einer einzelnen Seite darzustellen, im Stile einer "One-Page-Website". Du könntest innerhalb einer Website aber auch mehrere solche Bereiche haben. Oder du könntest ein Portal haben und erst woanders deinen OnePageInhalt. Oder auf deiner Website existiert generell ein separter Bereich, den du aber im OnePageWebsite-Stil darstellen und verwalten willst. Spielt keine Rolle, letztendlich zählt was du brauchst, bzw. haben willst, bzw. wie das Ergebnis für dich aussehen soll.


// hm, aber ich glaube deiner Frage nach, hast du das eigentliche Problem evt. nicht verstanden:

Es dürfte dort doch eigentlich nur eine Seite geben, und alle Anker wären in dieser Seite.

Es gibt auch nur eine Seite und alle Anker sind in dieser Seite. Das Problem ist, dass der Browser die Anker-Links ohne Page-Link anders interpretiert, sobald der <base href="..." /> Tag vorhanden ist. Dann zeigt href="#target" immer auf die URL, die im <base href="..." /> steht und nicht auf die Seite, auf der man gerade ist. Wenn man nur eine index.html hat, diese vom Webserver automatisch ausgegeben wird, wenn man die URL des base hrefs aufruft, dann funktionieren diese Anker-Links natürlich trotzdem, was aber praktisch nur rein zufällig ist.


Contao macht aus dem selben Grund den Top-Link daher auch so:

<div class="ce_toplink block">
    <a title="..." href="page.html#top">...</a>
</div> 

und nicht einfach nur so:

<div class="ce_toplink block">
    <a title="..." href="#top">...</a>
</div> 

Letzeres würde in Contao nicht funktionieren.

[MacKP]

Dafür gibts doch dann den request Inserttag?
Den kann man überall in Contao nutzen.

{{env::request}}

Viele Grüße

[Spooky]

Dafür gibts doch dann den request Inserttag?
Den kann man überall in Contao nutzen.

{{env::request}}

Viele Grüße

Sorry, ich glaube du hast den Thread nicht gelesen . Hier geht es um ein spezifisches Problem in der OnePageWebsite Extension .

Das Problem nochmal kurz zusammengefasst:

• Die Extension gibt als href für die jump links nur "#pageX" aus, wenn sich das Navigations-Modul auf der Referenz-Seite befindet.
• Dies führt zu dem oben beschriebenen Problem in Contao, da dies im Zusammenhang mit dem base href nicht funktioniert. (funktioniert nur dann zufällig, wenn die entsprechende Seite die index.html ist)
• Die Lösung ist, immer die Page im href ausgeben zu lassen und nie nur das Anker-Ziel

[MacKP]

Ja, und genau dafür ist dieser Inserttag. Den benutzt man in Contao IMMER, wenn man Anker links benutzt (ist eben kein spezifisches Problem!). Sonst springt man eben immer zurück auf die Domain mit dem Anker, wegen dem base-Tag.

Viele Grüße

[Spooky]

Ja, und genau dafür ist dieser Inserttag. Den benutzt man in Contao IMMER, wenn man Anker links benutzt (ist eben kein spezifisches Problem!). Sonst springt man eben immer zurück auf die Domain mit dem Anker, wegen dem base-Tag.

Viele Grüße

Schon klar, aber hier geht es ja um die Ausgabe des Moduls. Das Modul an sich generiert ja schon den korrekten href und braucht auch nicht extra den Insert-Tag dazu (wäre ja auch sinnlos):

$href = $this->generateFrontendUrl($objJumpTo->row()) . '#page' .$objSubpages->id; 

Das Modul gibt aber nur

$href = '#page' .$objSubpages->id; 

aus, wenn sich das Navigations-Modul auf der Referenz-Seite befindet.

Die Existenz des {{page::request}} insert tags spielt ja keine Rolle dabei. Natürlich könnte ich jetzt ein neues nav_default Template erstellen und dort

<a href="{{page::request}}<?php echo $item['href']; ?>" ...>

hineinschreiben. Aber das wäre ja nur ein Workaround und das Template könnte auch nicht generell benutzt werden, da sonst im anderen Fall

<a href="http://www.domain.com/foo.htmlfoo.html#page1" ...> 

herauskommt.

[Tim G]

Nein ein Inserttag sollte man nicht brauchen und auch das Standard-Template soll genügen. Dank Dir MacKP, ist generell der richtige Weg, man erwartet aber vom Modul, das es die url generiert.

Ich schau mir den Aufbau nach dem genannten Muster an. In der Tat nutze ich immer eine eigene Referenzseite als Startpunkt für die OPW, so wurde es auch dokumentiert.
Aus meiner Sicht hatte diese Aufbau den Vorteil, dass man das Seitenlayout für die Seiten innerhalb der OPW auf die versteckte Referenzseite anwendet und dieses damit vererbt wird.
Hat man einen obengenannten Aufbau und das ist auch gleich die erste Seite (Startseite), wird das eigentliche Standard-Layout der Webseite überschrieben bzw. man muss jeder einzelnen Seite in der OPW manuell das abgespeckte Layout geben. Klar, kann man machen, ist ja nicht verkehrt.

Die Referenzseite ist wichtig für den Backlink mit Anker von Seiten ausserhalb der OPW (z.B. eine autarke Impressums-Seite. Hier muss die Navi auf die Referenzseite leiten mit Anker).

Wenn Referenz = Startpunkt OPW und die URL über generateFrontendUrl laufen soll, wäre hier das global $objPage objekt richtig. Wir befinden uns ja auf der gleichen Seite.
$objJumpTo wird ja azcg nur erstellt, wenn der User auch wirklich eine Referenzseite gewählt hat, was er nicht muss. Das wäre hier zu unsicher, oder man müsste ein Pflichtfeld daraus machen.

global $objPage
$href = $this->generateFrontendUrl($objPage->row()) . '#page' .$objSubpages->id;

Ich glaube aber dann muss die Abfrage wieder rein, für den Fall die aktuelle Seite ist die erste Seite der Website. (1. Seite nach Startpunkt einer Webseite)

Für diesen Fall, darf die URL in der Tat nur mit
$href = '#page' .$objSubpages->id;

gebildet werden. Sonst hängt Contao den Pfad an und der erste Klick wäre ein wirklicher Seitenwechsel.

[Spooky]

Ich glaube aber dann muss die Abfrage wieder rein, für den Fall die aktuelle Seite ist die erste Seite der Website. (1. Seite nach Startpunkt einer Webseite)

Für diesen Fall, darf die URL in der Tat nur mit
$href = '#page' .$objSubpages->id;

gebildet werden. Sonst hängt Contao den Pfad an und der erste Klick wäre ein wirklicher Seitenwechsel.

Hm, nein denke nicht. Wenn die Startseite index heißt, erzeugt generateFrontendUrl auch einen link der nur die Domain beinhaltet (Zeile #2165 in system/modules/core/library/Contao/Controller.php). Somit sollte nie ein Seitenwechsel passieren, wenn man sich eh schon auf der Target-Page befindet.

Wie sieht es eigentlich aus, wenn man die Sprache in der URL drin hat? Da ist die base href ja weiterhin domain.com und ein link mit href="#target" würde auch in so einem Fall wieder auf domain.com/#target gehen, anstatt domain.com/de/#target (oder domain.com/de/foo.html#target).

Ich denke der korrekte Weg müsste weiterhin sein immer

$href = $this->generateFrontendUrl($objJumpTo->row()) . '#page' .$objSubpages->id; 

zu verwenden.


Wenn der User keine Target-Page angibt, gibt es halt dieses Fehlverhalten, falls die Seite auf der die OnePageWebsite ausgegeben wird, nicht die index Seite ist.

[Tim G]

Was machste, wenn der User keine Referenzseite gewählt hat? Lässte in nen PHP Fehler laufen?
Wir reden hier vom Navi Modul, nicht das Struktur Modul.

[Spooky]

Was machste, wenn der User keine Referenzseite gewählt hat? Lässte in nen PHP Fehler laufen?

Hatte es gerade hinzugefügt . Wenn der User keine Zielseite angibt, kommt es halt zu dem Fehlverhalten, falls er die OPW Ausgabe nicht auf der index Seite macht.

Und das wäre auch in der aktuellen Implementation so -> du fragst ja schon folgendes ab:

$objJumpTo->id > 0 

In so einem Fall ist der href output dann

$href = '#page' .$objSubpages->id; 

und führt zu dem oben beschriebenen Fehler, wenn sich die OPW Ausgabe nicht auf der index Seite befindet.


Das heißt also, dass du sowieso keine Funktionalität verlieren würdest, wenn du einfach folgende Änderung implementierst:

// href
if($objJumpTo->id > 0)
{
    $href = $this->generateFrontendUrl($objJumpTo->row()) . '#page' .$objSubpages->id;
}
else
{
    $href = '#page' .$objSubpages->id;
} 

(also $objJumpTo->id != $objPage->id && rausnehmen).

• Dies sollte zu keinem Fehlverhalten bestehender OPW Implementationen führen.
• Das von mir beschriebene Problem wird behoben.
• Im Fall, wo der User keine Referenz-Seite angibt und die OPW Ausgabe nicht auf der index Seite erfolgt, gibt es weiterhin das beschriebene Problem. Aber dieses Problem existiert ohnehin auch jetzt schon ohne diese Änderung.

// addendum

Aus meiner Sicht hatte diese Aufbau den Vorteil, dass man das Seitenlayout für die Seiten innerhalb der OPW auf die versteckte Referenzseite anwendet und dieses damit vererbt wird.
Hat man einen obengenannten Aufbau und das ist auch gleich die erste Seite (Startseite), wird das eigentliche Standard-Layout der Webseite überschrieben bzw. man muss jeder einzelnen Seite in der OPW manuell das abgespeckte Layout geben. Klar, kann man machen, ist ja nicht verkehrt.

Jap, stimmt natürlich. Mir ist dieses Verhalten halt jetzt aufgefallen, weil ich etwas ganz simples aufbauen wollte zum testen und es kam mir "sauberer" vor es so zu machen. Dann in einem "echten" Einsatz werde ich wohl wieder die zusätzliche Zwischen-Page einfügen, eben wegen der Layout-Vererbung.

[Tim G]

naja, schön ist es nicht, aber damit entsteht kein Fehler.

$objJumpTo->id ist maximal null bzw. undefined. Da knallt erstmal nichts.

[Tim G]

Da muss ich dich korrigieren.

$objJumpTo->id != $objPage->id

Das ist recht wichtig, weil die Navi auf Seiten ausserhalb der OPW reagieren muss. (habe ich oben am impressums beispiel beschrieben)

Wenn Du eine Reguläre autarke Seite betrittst und mit hilfe der Navi zurück auf einen Anker innerhalb der OPW Seite gehen willst, brauchst du diese Abfrage. Sie prüft ob die Zielseite der Navi eben nicht die aktuelle Seite ist.

[Spooky]

naja, schön ist es nicht, aber damit entsteht kein Fehler.

Naja warum ist es nicht schön? Wenn ein base href Tag vorhanden ist, dann muss der href eben immer mit page.html#target lauten (einzige Ausnahme: index-Page, wenn man keine Language URL verwendet). Alles andere wäre nicht schön . Mit "$objJumpTo->id != $objPage->id &&" beschränkst du den Einsatz dieser Struktur künstlich auf die index-Page und dafür gibt es ja keinen Grund.

[Spooky]

Da muss ich dich korrigieren.

$objJumpTo->id != $objPage->id

Das ist recht wichtig, weil die Navi auf Seiten ausserhalb der OPW reagieren muss. (habe ich oben am impressums beispiel beschrieben)

Wenn Du eine Reguläre autarke Seite betrittst und mit hilfe der Navi zurück auf einen Anker innerhalb der OPW Seite gehen willst, brauchst du diese Abfrage. Sie prüft ob die Zielseite der Navi eben nicht die aktuelle Seite ist.

Nein, die Abfrage brauchst du ja nicht. Wenn du dies Entfernst ist die Ausgabe des hrefs immer page.html#target, sofern eine Zielseite definiert wurde. Wenn du auf der impressum.html bist, führt dich der link dann eben auf page.html#target. Wenn du auf der page.html bist, führt dich der link auchauf page.html#target, ohne einen Seitenwechsel.

Wenn sich die OPW auf der index-Page befindet, zeigt der link auf #target (ohne Language URL). Selbst wenn du dann auf impressum.html bist, führt dich #target zurück auf domain.com/#target. Und innerhalb der index page führt dich #target dann auch zu #target, ohne dass die Seite neu geladen wird.

[Tim G]

Hm, nein denke nicht. Wenn die Startseite index heißt, erzeugt generateFrontendUrl auch einen link der nur die Domain beinhaltet (Zeile #2165 in system/modules/core/library/Contao/Controller.php). Somit sollte nie ein Seitenwechsel passieren, wenn man sich eh schon auf der Target-Page befindet.

Der Fall, dass die erste Seite wirklich index als Alias hat, ist schwindend gering und das olle generateFrontendUrl gibt, wie es seine Aufgabe ist, die ganze URL wieder, was bei einer Startseite, wo die URL maximal das LanguageTag hat, falsch.

[Spooky]

Der Fall, dass die erste Seite wirklich index als Alias hat, ist schwindend gering und das olle generateFrontendUrl gibt, wie es seine Aufgabe ist, die ganze URL wieder, was bei einer Startseite, wo die URL maximal das LanguageTag hat, falsch.

Wenn die Startseite in Contao nicht den "alias" index hat, dann leitet Contao auch auf http://www.domain.com/startseite.html weiter, wenn man http:/www.domain.com/ aufruft. Und dann passt es auch wieder, wenn der href startseite.html#target ist

// ah, sorry, da hatte ich mich geirrt. Naja, aber das ist dann halt ein spezielle Fall, den du abfangen musst, und nicht umgekehrt. Ansonsten schränkst du die Extension ja künstlich ein.

[Tim G]

Bitte bau dir das mal richtig nach und setz deine Abfrage ein.
Du hast sofort in der Url den alias der Seite. Das ist falsch auf Startseiten.
Du kannst mit generateFrontendUrl eigentlich nichts anfangen, ausser man ist nicht auf der Seite, auf der die OPW Struktur ausgegeben ist. Das ist ne nötige Brücke hier.

Der wirklich richtige Weg wäre, wie MacKP es vorgeschlagen hat, Environment request zu nutzen. Das werde ich machen. Hat zusätzlich den riesen Vorteil, das auch GET Parameter erhalten bleiben.

[Spooky]

Du hast sofort in der Url den alias der Seite. Das ist falsch auf Startseiten.

Nur, wenn die Startseite nicht index heißt und falsch ist es auch nur dann, wenn der Request auf die domain war, nicht auf die page direkt.

Du kannst mit generateFrontendUrl eigentlich nichts anfangen, ausser man ist nicht auf der Seite, auf der die OPW Struktur ausgegeben ist. Das ist ne nötige Brücke hier.

Warum? Du kannst nur in einem "Spezialfall" nichts damit anfangen: auf der Startseite, wenn das alias der Seite nicht index ist. Ansonsten ist es immer nötig auch den alias bzw. die eigentlich page URL im href drinnen zu haben - da dich ein href ohne URL immer auf Startseite der Domain leitet.

Der wirklich richtige Weg wäre, wie MacKP es vorgeschlagen hat, Environment request zu nutzen. Das werde ich machen. Hat zusätzlich den riesen Vorteil, das auch GET Parameter erhalten bleiben.

Auch gut, wobei in einem Menü ja nicht unbedingt Get Parameter erhalten bleiben sollen? Naja

[Tim G]

Warum? Du kannst nur in einem "Spezialfall" nichts damit anfangen: auf der Startseite, wenn das aliax der Seite nicht index ist. Ansonsten ist es immer nötig auch den alias im href drinnen zu haben - da dich ein href ohne page immer auf Startseite der Domain zurückleitet.

Generell richtig. Aber jetzt kommt mod_rewirte und radiert dir den alias der Startseite raus

Das ist der Grund warum generateFrontendUrl nur auf entfernten Seiten zum Einsatz kommt und warum wir überhaupt eine Weiterleitungsseite im Navi Modul brauchen.

[Spooky]

Generell richtig. Aber jetzt kommt mod_rewirte und radiert dir den alias der Startseite raus

By default wird ja nur index rausradiert. Und in so einem Fall wäre dann auch kein page reload, da generateFrontendUrl für die Startseite kein index.html ausgibt, wenn der alias index ist. Wenn der Alias der Startseite "startseite" heißt würde generateFrontendUrl startseite.html ausgeben. Allerdings kommt es eben dann zu dem page reload, den du verhindern willst, wenn man zum ersten mal auf einen Menüpunkt klickt.

[Tim G]

By default wird ja nur index rausradiert. Und in so einem Fall wäre dann auch kein page reload, da generateFrontendUrl für die Startseite kein index.html ausgibt, wenn der alias index ist. Wenn der Alias der Startseite "startseite" heißt würde generateFrontendUrl startseite.html ausgeben. Allerdings kommt es eben dann zu dem page reload, den du verhindern willst, wenn man zum ersten mal auf einen Menüpunkt klickt.

ganz genau