Frage zu RT ARTICLE_TITLE
Frage zu RT ARTICLE_TITLE
Ich habe mal den Code aus dem Wiki betreffend Anzeige von ARTICLE_TITLE etc. integriert, um den Artikel Titel spezifisch anzeigen zu lassen.
( Entspr. Link: http://www.phpwcms-howto.de/wiki/doku.p ... _assembled )
Auf einer Bsp.-Seite mit integriertem CP Teaser wird nun aber der Artikel Titel des zuletzt aufgerufenen Teaser-Artikels angezeigt und nicht der Titel der Seite in welcher der CP Teaser erscheint. Ist das so gewollt?
BSP.
Aufgerufener Artikel: sample0
Darin durch CP Teaser integrierte Artikel-Teaser: sample1, sample2, sample3
der {ARTICLE_TITLE} - konkret $row['article_alias']- zeigt nun den Titel des Artikels sample3 an statt des Artikels sample0
( Entspr. Link: http://www.phpwcms-howto.de/wiki/doku.p ... _assembled )
Auf einer Bsp.-Seite mit integriertem CP Teaser wird nun aber der Artikel Titel des zuletzt aufgerufenen Teaser-Artikels angezeigt und nicht der Titel der Seite in welcher der CP Teaser erscheint. Ist das so gewollt?
BSP.
Aufgerufener Artikel: sample0
Darin durch CP Teaser integrierte Artikel-Teaser: sample1, sample2, sample3
der {ARTICLE_TITLE} - konkret $row['article_alias']- zeigt nun den Titel des Artikels sample3 an statt des Artikels sample0
Re: Frage zu RT ARTICLE_TITLE
Hmm, ich kann das Verhalten im Moment noch nicht nachvollziehen.
Alle Tags arbeiten, zumindest bei mir (r380), einwandfrei
{ARTICLE_TITLE} -> $row['article_title']
{ARTICLE_ALIAS} -> $row['article_alias']
{ARTICLE_ID} -> $row['article_id']
und zeigen die Werte der aufgerufenen aktuellen Seite.
Die ensprechenden Teaser-Tags (im Teaser-Template)
Article-ID: {ARTICLEID}
Category-ID:{CATEGORYID}
zeigen richtigerweise jeweils die IDs des zu rufenden Artikels.
Knut
Alle Tags arbeiten, zumindest bei mir (r380), einwandfrei
{ARTICLE_TITLE} -> $row['article_title']
{ARTICLE_ALIAS} -> $row['article_alias']
{ARTICLE_ID} -> $row['article_id']
und zeigen die Werte der aufgerufenen aktuellen Seite.
Die ensprechenden Teaser-Tags (im Teaser-Template)
Article-ID: {ARTICLEID}
Category-ID:{CATEGORYID}
zeigen richtigerweise jeweils die IDs des zu rufenden Artikels.
Knut
>> HowTo | DOCU | FAQ | TEMPLATES/DOCS << ( SITE )
Re: Frage zu RT ARTICLE_TITLE
Hier ist die Bsp. Seite http://www.winet.ch/wcms/
Oben stehen die Testwerte für $row['article_title'] und $row['article_id'] welche hier den Angaben aus dem 3. Teaser-Artikel entsprechen. Sie müssten aber so lauten wie im Headerbild integriert. Diese habe ich nun einfach in die Strukturebene eingegeben als ("Seitentitel" und "Beschreibung der Seitenebene"), d.h.
$content["struct"][$content["cat_id"]]["acat_pagetitle"] und
$content["struct"][$content["cat_id"]]["acat_info"]
Oben stehen die Testwerte für $row['article_title'] und $row['article_id'] welche hier den Angaben aus dem 3. Teaser-Artikel entsprechen. Sie müssten aber so lauten wie im Headerbild integriert. Diese habe ich nun einfach in die Strukturebene eingegeben als ("Seitentitel" und "Beschreibung der Seitenebene"), d.h.
$content["struct"][$content["cat_id"]]["acat_pagetitle"] und
$content["struct"][$content["cat_id"]]["acat_info"]
Re: Frage zu RT ARTICLE_TITLE
Oh oh,
$row ist das falsche Array in diesem Fall, hier wird immer der aktuelle Artikel vorgehalten und das ist bei einem direkt integrierten Teaser eben der letzte aus seiner Liste. (Mit einem Teaser per SHOW_CONTENT sieht das anders aus).
richtig ist:
Im wiki korrigiert
Knut
$row ist das falsche Array in diesem Fall, hier wird immer der aktuelle Artikel vorgehalten und das ist bei einem direkt integrierten Teaser eben der letzte aus seiner Liste. (Mit einem Teaser per SHOW_CONTENT sieht das anders aus).
richtig ist:
Code: Select all
echo 'Artikel-Title:'. $content['article_title'] .'<br>';
// seit V1.4.2 r316 (24.06.09) ersetzt durch den eingebauten Tag {CURRENT_ARTICLEID}
echo 'Artikel-ID:'. $content['article_id'] .'<br>';
echo 'Artikel-Alias:'. $content['articles'][$content['article_id']]['article_alias'].'<br>';
Knut
>> HowTo | DOCU | FAQ | TEMPLATES/DOCS << ( SITE )
Re: Frage zu RT ARTICLE_TITLE
Danke für die prompte Antwort. Immerhin sind ja die RT's flexibel genug, dass man sich die Infos trotzdem irgendwie anzeigen lassen kann.
In meinen Websites ist es eh meist so, dass ich nur 1 Artikel pro Naviitem habe, so kann ich die Daten gut in der Struktur versorgen.
Nochmals Danke.
PS: Mir ist grad durch den Kopf, dass es vielleicht noch cool wäre, die RT's über das Admin verwalten zu können, d.h. RT-Tag, Description, Code, enabled, disabled und das ganze in der DB oder alternativ in nur einer Datei speichern. Ist so was machbar und würde es Sinn machen?
In meinen Websites ist es eh meist so, dass ich nur 1 Artikel pro Naviitem habe, so kann ich die Daten gut in der Struktur versorgen.
Nochmals Danke.
PS: Mir ist grad durch den Kopf, dass es vielleicht noch cool wäre, die RT's über das Admin verwalten zu können, d.h. RT-Tag, Description, Code, enabled, disabled und das ganze in der DB oder alternativ in nur einer Datei speichern. Ist so was machbar und würde es Sinn machen?
Re: Frage zu RT ARTICLE_TITLE
Diese Idee trage ich schon länger mit mir herum, das ist sicher machbar.S: Mir ist grad durch den Kopf, dass es vielleicht noch cool wäre, die RT's über das Admin verwalten zu können, d.h. RT-Tag, Description, Code, enabled, disabled und das ganze in der DB oder alternativ in nur einer Datei speichern. Ist so was machbar und würde es Sinn machen?
Alle RTs müssten normiert bzw. so eine Art einheitliche Schnittstelle gebildet werden.
Um so etwas vernünftig hinzubringen gehen schon einige Tage ins Land. - Jetzt fehlt nur noch der Verrückte der das sauber durchplant bis in die letzte Ecke und dann umsetzt .......
(Ich werde das vorerst nicht sein, denn bei der riesigen Anzahl von Fremdartikeln bzw. Spenden für das wiki die auf mich einprasseln habe ich keine Zeit mehr mich darum auch noch zu kümmern ..... )
Knut
>> HowTo | DOCU | FAQ | TEMPLATES/DOCS << ( SITE )
Re: Frage zu RT ARTICLE_TITLE
schon klar. war auch nicht als Aufforderung gedacht. Ich werd es mir über Weihnachten mal ansehen - auch wenn ich in Sachen "planen und bis ins Eck durchdenken" wohl der falsche bin.
Re: Frage zu RT ARTICLE_TITLE
"Das Planen" ist in diesem Fall eine der wesentlichen Aufgaben, um nicht nach einem halben Jahr mit besseren Ideen alles wieder umschmeißen zu müssen. Alles andere hat längerfristig keinen Bestand.
Sonst kommen dann irgendwelche Konverter an den Start, deren Entwicklung auch gut Zeit frisst.
(Bestes Beispiel ist gerade das BE User-Modul, hier geht es ohne Konverter nicht, wenn neue Module hinzukommen.
Die Funktion um den Rechteschlüssel zu berechnen musste umgeschrieben werden da der jetzige Schlüssel zu kurz ist - alle User bekommen einen neuen Schlüssel und das natürlich mehr oder weniger automatisch).
Knut
Sonst kommen dann irgendwelche Konverter an den Start, deren Entwicklung auch gut Zeit frisst.
(Bestes Beispiel ist gerade das BE User-Modul, hier geht es ohne Konverter nicht, wenn neue Module hinzukommen.
Die Funktion um den Rechteschlüssel zu berechnen musste umgeschrieben werden da der jetzige Schlüssel zu kurz ist - alle User bekommen einen neuen Schlüssel und das natürlich mehr oder weniger automatisch).
Knut
>> HowTo | DOCU | FAQ | TEMPLATES/DOCS << ( SITE )
Re: Frage zu RT ARTICLE_TITLE
Vielleicht könnte OG dazu mal ein kurzes Statement fallen lassen, wie so etwas am besten angegangen wird.
- Was die einzelnen RTs sinnvollerweise an Infos zur Verfügung stellen sollten
- Wie die Parameterübergabe (wenn notwendig) einheitlich gemacht werden kann
- Was die einzelnen RTs sinnvollerweise an Infos zur Verfügung stellen sollten
- Wie die Parameterübergabe (wenn notwendig) einheitlich gemacht werden kann
>> HowTo | DOCU | FAQ | TEMPLATES/DOCS << ( SITE )
Re: Frage zu RT ARTICLE_TITLE
nur mal so angedacht:
- Web Repository in welchem die veröffentlichten RT's verwaltet sind
- Das CMS Backend bietet eine Möglichkeit, RT's aus dem Repository zu installieren, oder eigene (private) RT's im lokalen CMS hinzuzufügen
- Alle (nicht-Core) RT's lassen sich aktivieren bzw. deaktivieren
- Das Backend prüft nach verfügbaren Updates im Repository
Jedes RT bietet Standardfelder für Tag, Beschreibung, Erläuterung allfälliger Parameter, Abhängigkeiten, etc
- Web Repository in welchem die veröffentlichten RT's verwaltet sind
- Das CMS Backend bietet eine Möglichkeit, RT's aus dem Repository zu installieren, oder eigene (private) RT's im lokalen CMS hinzuzufügen
- Alle (nicht-Core) RT's lassen sich aktivieren bzw. deaktivieren
- Das Backend prüft nach verfügbaren Updates im Repository
Jedes RT bietet Standardfelder für Tag, Beschreibung, Erläuterung allfälliger Parameter, Abhängigkeiten, etc