Brauche hook in PageRegular::createStyleSheets().

Hi,
Ich weiss nun nicht, ob ich hier mit der Anfrage richtig bin da ja nun das Forum umgestellt wurde, trac abgeloest wird durch redmine und ich nicht mehr genau weiss wo nun was hin sollte.

Ich baue gerade mit scare an der Catalog Extension einiges um/aus.

Gerade bin ich dabei den RSS feed zu implementieren, was bislang auch ohne Probleme geklappt hat.
RSS Feeds werden erzeugt, im tl_layout habe ich das neue Feld eingetragen, die Kataloge werden auch in der Datenbank abgelegt, soweit klapp alles perfekt.

Dennoch geht es nun nicht weiter, denn in PageRegular werden die RSS fuer News und Kalender ja hardcodiert eingelesen, da kann ich mich leider nicht mit reinhaengen.

Dass ich mich per $GLOBALS['TL_HEAD'] einklinke scheidet leider auch aus, da ich ja layoutabhaengig meine Feeds in der DB hinterlegt habe und somit "Database_Result $objLayout" auswerten muss.

Ich braeuchte also in PageRegular::createStyleSheets() einen Hook welcher dann eigene RSS feeds zurueckgeben kann.
ggf. koennte man das ja sogar als generelle, layoutabhaengige, Zeilen im <head> erweitern.

Falls jemand eine andere Idee hat, wie ich meine, vom jeweils gewaehlten layout abhaengige, head-Zeile reinbekomme bin ich ueber jede Information dankbar.

Gruss
Chris

Hallo Chris,

über die "global $objPage" könntest du bestimmt irgendwie das Layout herausfinden und dann mit $GLOBALS['TL_HEAD'] einbinden.
Allerdings klappt das nicht zwingend immer...

Es wäre auch möglich mit dem outputFrontendTemplate Hook zu arbeiten und direkt HTML zu schreibe - auch etwas unschön.

Ich denke ein Hook wäre das richtige, allerdings kommt mir der Name der Funktion etwas komisch vor...? Auf jeden Fall müsste der Hook als Ticket bei Leo gewünscht werden.

Nachdem wir uns gestern ja im IRC unterhalten hatten, hier nochmal mein Lösungsansatz

1.) HOOK parseFrontendTemplate registrieren
$GLOBALS['TL_HOOKS']['parseFrontendTemplate'][] = array('Klasse', 'parseFrontendTemplate');
2.) In der HOOK-Funktion würde ich folgendes implementiern

PHP-Code:

public function parseFrontendTemplate($strContent, $strTemplate){ if(!isset($GLOBALS['TL_HEAD']['meinRssLink'])) { // Logik um den RSS zu erstellen global $objPage; .... $GLOBALS['TL_HEAD']['meinRssLink'] = "<link ...">; } }

Grüße

Ich habe mich direkt nachdem wir es im IRC besprochen hatten implementiert komme jedoch jetzt erst dazu hier zu posten.
Ich bin mit der Loesung allerdings nicht ganz gluecklich.

Ich poste einfach mal meinen Code:

PHP-Code:

/** * Get a page layout and return it as database result object. * This is a copy from PageRegular, see comments in parseFrontendTemplate() below for the reason why this is here. * @param integer * @return object */ protected function getPageLayout($intId) { $objLayout = $this->Database->prepare("SELECT * FROM tl_layout WHERE id=?") ->limit(1) ->execute($intId); // Fallback layout if ($objLayout->numRows < 1) { $objLayout = $this->Database->prepare("SELECT * FROM tl_layout WHERE fallback=?") ->limit(1) ->execute(1); } // Die if there is no layout at all if ($objLayout->numRows < 1) { $this->log('Could not find layout ID "' . $intId . '"', 'PageRegular getPageLayout()', TL_ERROR); header('HTTP/1.1 501 Not Implemented'); die('No layout specified'); } return $objLayout; } /** * get called by hook to inject all RSS feeds for the current layout into the template */ public function parseFrontendTemplate($strBuffer, $strTemplate) { if(!isset($GLOBALS['TL_HEAD']['CATALOGFEED'])) { global $objPage; // here we are getting dirty, we have to import the page layout as we have no other way to get the layout from it. // I know it does exist already as we are being called from it but hey, we got no Hook in PageRegular::createStyleSheets // and therefore have to suffer the hard way... :( $objLayout=$this->getPageLayout($objPage->layout); $catalogfeeds = deserialize($objLayout->catalogfeeds); // Add catalogfeeds if (is_array($catalogfeeds) && count($catalogfeeds) > 0) { $objFeeds = $this->Database->execute("SELECT * FROM tl_catalog_types WHERE id IN(" . implode(',', $catalogfeeds) . ")"); while($objFeeds->next()) { $base = strlen($objFeeds->feedBase) ? $objFeeds->feedBase : $this->Environment->base; $GLOBALS['TL_HEAD']['CATALOGFEED']= '<link rel="alternate" href="' . $base . $objFeeds->alias . '.xml" type="application/' . $objFeeds->feedFormat . '+xml" title="' . $objFeeds->description . ' ' . $strTemplate . '" />' . "\n"; } } } // Return buffer no matter if we added something to the global array or not. // We simply to not want to tamper with it. return $strBuffer; }

Auf diese Art und Weise funktioniert es zwar, jedoch durchlaufe ich hierbei fuer jedes Template meine Funktion (habe es per debugging mal getraced, aktuell 16 Aufrufe die unnoetig sind), welche zwar sofort abbricht da mein Eintrag ja schon gesetzt ist aber dennoch aeusserst unschoen.
Was mich hierbei am Meisten stoert ist die Tatsache, dass ich die Routine getPageLayout() in meine Klasse reinkopieren musste und somit abhaengig von der jeweiligen konkreten Implementierung der aktuellen TL Version bin. Zugegeben, daran wird sich vermutlich nicht viel aendern in zukuenftigen Versionen aber dennoch gehoert es meiner Meinung einfach nicht doppelt in den Code sondern nur einmal und dann logischerweise dort wo es hingehoert, in PageRegular.

Meine Loesung wuerde sich durch einen einzelnen Hook in PageRegular::createStyleSheets() massiv vereinfachen lassen, wenn dieser nur mit dem aktuellen layout aufgerufen wuerde.
Wir wuerden dadurch das mehrfache durchlaufen der Routine einsparen und das Duplikat der Routine getPageLayout.

Das Problem steigert sich obendrein noch, sobald man dasselbe Verhalten in einer anderen Erweiterung benoetig, welche ggf. auch noch einen RSS bereitstellen will. Also muss man dorthin ebenfalls wieder die getPageLayout kopieren und die jeweilige Routine wird dann ebenfalls wieder fuer jedes Template durchlaufen obwohl dies nur ein einziges Mal passieren muesste.

Mein Fazit ist also: Es funktioniert, ist jedoch meiner Meinung nach ein Hack und sollte geaendert werden. Auf welchem Bugtracker muss ich aktuell nun einen Request fuer den Hook machen oder ist das sowieso von vornherein zum scheitern verurteilt?

Gruss
Chris

Also die Sache mit den 16 Aufrufen lasse ich so nicht gelten, lass mal nen Profiler mitlaufen, die Zeit wird verschwindend sein.

Die Sache mit dem LayoutID-herausfinden find ich hier brisanter, da man dieses doch öfters benötigt. Hier fände ich es klever, $objPage einfach mit der in PageRegular::generate() gefundenen LayoutID zu erweitern. Die Datenbankspalte hierfür ist ohnehin schon vorhanden und nur ggf. leer (falls das Layout der übergeordneten Seite verwendet werden soll). Logischerweise wäre es also kein Fehler die ID selbst im Objekt zu vererben.

Zitat:

Zitat von Psi

Also die Sache mit den 16 Aufrufen lasse ich so nicht gelten, lass mal nen Profiler mitlaufen, die Zeit wird verschwindend sein.

Die Zeit mag verschwindend sein, dennoch ist es schlichtweg unnoetig und vermeidbar. Darum ging es mir. :)

Zitat:

Zitat von Psi

Die Sache mit dem LayoutID-herausfinden find ich hier brisanter, da man dieses doch öfters benötigt. Hier fände ich es klever, $objPage einfach mit der in PageRegular::generate() gefundenen LayoutID zu erweitern. Die Datenbankspalte hierfür ist ohnehin schon vorhanden und nur ggf. leer (falls das Layout der übergeordneten Seite verwendet werden soll). Logischerweise wäre es also kein Fehler die ID selbst im Objekt zu vererben.

Du meinst sicherlich das Objekt vom PageLayout, welches vererbt werden sollte, denn die ID ist ja vorhanden bzw. 0 und dann laeuft der fallback.
Wenn man nun das layout im objPage haette, dann waere das schon wieder einiges einfacher.
Die Frage hierbei ist nun, ob man das Layout ohne weiteres in objPage reinpressen kann, oder ob das Layout nicht vor objPage erzeugt/ausgewertet wird, so genau habe ich den Source noch nicht analysiert.

Aber ich nehme an, du teilst meine Meinung, dass dies definitiv eleganter zu loesen waere?

Gruss
Chris

ich würde in PageRegular.php in Zeile 52 volgendes einfügen

PHP-Code:

$objPage->layout = $objLayout->id;

Also einfach die gefundene layoutID ins aktuelle objPage-Objekt schreiben. Mir fällt gerade keine Situatio ein, wo das logisch nicht korrekt wäre.

Zitat:

Zitat von Psi

Also einfach die gefundene layoutID ins aktuelle objPage-Objekt schreiben. Mir fällt gerade keine Situatio ein, wo das logisch nicht korrekt wäre.

Hiermit bin ich jedoch dann wieder gezwungen das Layout aus der Datenbank zu querien, da ich ja nicht die ID sondern die Nutzdaten fuer dieses Layout benoetige.
Im Konkreten Fall "$objLayout->catalogfeeds"

Was spricht gegen:

Code:

$objPage->layout = $objLayout;

Auf diese Weise haette man das komplette Layout immer zur Hand wenn man es benoetigt und nicht nur die ID. Meiner Meinung nach sollte auch dies keine Probleme mit sich bringen.

Gruss
Chris

Das wäre logisch inkorrekt! $objPage ist das Database_Result Objekt der Anfrage, also ein Abbild der entsprechenden Datenbankzeile.

Da DU die Tabelle tl_layout erweiterst und damit catalogfeeds einfügst, würde ich sagen, dass du es auch wieder auslesen musst. Darauf verlassen, dass Leo im Core immer SELECT * FROM verwendet würde ich mich nicht. Die extra Datenbankabfrage ... seis drum. Wir schreiben hier ja kein Echtzeitsystem.

Ich habe einen entsprechenden Feature-Request gestellt. http://https://contao.org/ticket/894

Ich habe Chris Lösung an meine Bedürfnisse angepasst und die Ausgabe im Frontend funktioniert auch. Wenn ich allerdings im Backend einen Artikel bearbeiten will, wird auch die Funktion aufgerufen und getPageLayout bricht an der Stelle "Die if there is no layout at all" ab.

Ist das bei Euch auch so und woran könnte es liegen?

Nachtrag:
Habe es jetzt mit zusätzlicher Abfrage in der if-Abfrage gelöst, aber naja...

PHP-Code:

public function parseFrontendTemplate($strBuffer, $strTemplate) { global $objPage; if(!isset($GLOBALS['TL_HEAD']['SUMMARIZE_FEEDS']) AND $objPage->layout) {