Fehlende Insert Tags

[samkuem]

Aus meiner Sicht (und aus der praktischen Erfahrung in der Arbeit mit Contao) fehlen bei den möglichen Insert-Tags einige ganz wichtige, die dringend in einer der nächsten Versionen nachgerüstet werden sollten, weil man sie doch recht oft braucht:

Und zwar: {{env::newsTitle}} – Ausgabe des Titels der aktuellen Newsmeldung {{env::newsAlias}} – Ausgabe des Alias der aktuellen Newsmeldung {{env::newsURL}} – Ausgabe der URL der aktuellen Newsmeldung

Wenn ich das Newssystem etwas umfassender einsetzen will und auch eigene Module dazu machen will, hätte ich in der Vergangenheit nun schon mehrfach diese Insert Tags gebrauchen können.

Ich würde also darum bitten, dass diese im nächsten Contao Release implementiert werden. Danke!

[Samson1964]

+1 für newsAlias Aber nur weil der Request-Parameter items bei Cache-Verwendung nicht mehr weitergegeben wird.

[samkuem]

Man könnte die Insert Tags auch so umsetzen, denke ich:

{{news::Title}} {{news::Alias}} {{news::URL}} {{news::ID}}

Ich finde diese vier Tags werden sehr häufig gebraucht.

[samkuem]

Ehrlich gesagt, bräuchte ich diese Tags so schnell wie möglich. Wo finde ich jemanden, der mir das programmieren kann? Bis zum nächsten Contao Release kann ich eigentlich nicht warten... ich brauch die Möglichkeit bei AKTUELLEN Projekten...

[aschempp]

Schau dir die Contao Entwicklungspartner an.

[Samson1964]

@samkuem: Schick mir mal eine Email - webmaster@schachbund.de

[samkuem]

Wo genau finde ich die Contao Entwicklungspartner? Und wie erreiche ich, dass meine Issue ins nächste Contao Release „offiziell“ übernommen wird? Prüft die jemand? (Bin neu hier... ;-)

[Toflar]

Partner findest du hier: https://contao.org/de/partners.html. Sie entwickeln dir bei Bedarf eine Extension die deine Bedürfnisse abdecken. Offiziell übernommen wird es aber dann noch lange nicht. Das ist ein Entscheid, den du nicht beeinflussen kannst :) Ich persönlich z.B. finde die InsertTags gehören absolut nicht in den Core :)

[samkuem]

Schön, dass du das persönlich findest. Bitte Argumente – ansonsten ist so eine „Meinung“ irgendwie überflüssig.

Diese Tags fehlen, sollten eigentlich selbstverständlich sein und ich finde sie für jeden Webentwickler sehr wichtig. Wenn man den Newsbereich von Contao auch nur halbwegs umfassend einsetzen will, sind diese InsertTags unabdingbar. Titel, Alias, URL und ID von Newseinträgen braucht man ständig – sei es zur automatischen Titelübername an bestimmten Stellen, zur Erzeugung von URLs oder für die Erstellung von individuellen Menüs.

Und wieso kann ich als Contao Nutzer den Entscheid nicht beeinflussen? Wer entscheidet das? Und aus welchen Gründen? Fragen über Fragen...

[samkuem]

Ich dachte, es geht bei den Issues darum, Contao mit Hilfe der Nutzer besser zu machen... und nicht um persönlichen Meinungsaustausch.

[Toflar]

Schön, dass du das persönlich findest. Bitte Argumente – ansonsten ist so eine „Meinung“ irgendwie überflüssig.

Kein Problem. Der Core von Contao heisst "Core" weil er die wesentlichen Dinge mitliefern soll. Er soll flexibel erweiterbar sein, aber an sich möglichst schlank bleiben.

Diese Tags fehlen, sollten eigentlich selbstverständlich sein und ich finde sie für jeden Webentwickler sehr wichtig.

Ich arbeite seit 5 Jahren jeden Tag mit Contao und habe keinen einzigen deiner vorgeschlagenen InsertTags je benötigt. Ich sehe also keinen Grund, warum die fix in den Core gehören müssten :-)

Und wieso kann ich als Contao Nutzer den Entscheid nicht beeinflussen? Naja, beeinflussen kannst du das natürlich indem du Argumente dafür lieferst, dass die Änderungen zwingend erforderlich sind.

Wer entscheidet das?

Die Arbeitsgruppe "Core-Entwicklung" aka @leofeyer, @aschempp, @psi-4ward und @backbone87 :-)

Und aus welchen Gründen?

Man diskutiert über Vor- und Nachteile und entscheidet dann.

Ich dachte, es geht bei den Issues darum, Contao mit Hilfe der Nutzer besser zu machen... und nicht um persönlichen Meinungsaustausch.

Du persönlich entscheidest ja nicht, was "besser machen" bedeutet. Das geschieht durch Diskussionen und deshalb sehr wohl durch persönlichen Meinungsaustausch. Deine Meinung ist, du brauchst das. Meine Meinung ist, ich will das nicht im Core - wir haben wichtigere Baustellen. Jetzt stossen weitere Leute zur Diskussion hinzu, präsentieren weitere Argumente dafür oder dagegen und schlussendlich entscheidet die Arbeitsgruppe Core-Entwicklung über Ja oder Nein :-) Eigentlich ganz einfach :-)

[samkuem]

Ok, kurz und knapp: Insert Tags sind wesentlich und machen den Core nicht weniger schlank. Ich programmiere lange genug um zu wissen, dass das Auslesen von ein paar Tabellensätzen keine riesige Erweiterung für den Core darstellt. Leider reichen meine Fähigkeiten nicht, um das selbst zu programmieren – HTML5+CSS3 sind meine Stärken.

Keine Ahnung wie du es 5 Jahre ohne diese Tags ausgehalten hast – wenn ich jetzt frech wäre, würde ich sagen, du hast Contao noch nie ausgereizt... da ich aber dich nicht kenne, unterlasse ich diese Behauptung.

Die Argumente habe ich oben genannt – diese Tags stellen keine wesentliche Beeinträchtigung für den Core oder das System sonst dar, sind kleine Verbesserungen, können von vielen Webentwicklern für vielfältige Zwecke gebraucht werden. Ansonsten ist eine Änderung nie zwingend – aber ich halte das für eine deutliche Verbesserung. Mir würden noch deutlich mehr Tags einfallen, die aber aus meiner Sicht nur in einzelnen Ausnahmefällen gebraucht werden... aber die von mir vorgeschlagenen sind essentiell für das Newssystem.

(Wie kann man die Arbeitsgruppe bestechen?)

Nachteile gibt es aus meiner Sicht keine. Die würde ich gerne genannt bekommen, bevor solch ein konstruktiver Vorschlag für Contao mit einem nicht schlüssigen „Das bläst den Core auf und es gibt andere Baustellen“ vom Tisch gewischt wird.

Ich bin gespannt auf die Meinung der Arbeitsgruppenmitglieder ...

[tristanlins]

Keine Ahnung wie du es 5 Jahre ohne diese Tags ausgehalten hast...

Ganz einfach, man kommt ohne Insert Tag an diese Information. :-D Genauer betrachtet ist das ganze technisch gar nicht so einfach zu lösen. Deshalb interessiert mich "wo" du diese Insert Tags verwenden willst?!

[samkuem]

Aha... und wie?

Ich will damit z.B. eine Navigation innerhalb einer Newsmeldung erstellen erstellen, mit welcher man durch Klicken an eine bestimmte Stelle der Seite kommt.

Schema

{{news::URL}}#Position1 {{news::URL}}#Position2

Alternativ würde vielleicht auch

{{env::path}}/{{news:Alias}}#Position1 gehen...

Wenn ich als Link nur #Position1 angebe, springt er automatisch auf den Root.

In ähnlicher Weise habe ich noch 2-3 andere Anwendungsplätze für diese Tags in anderen Projekten.

Worin besteht die technische Schwierigkeit? Soweit meine Datenbank, SQL und PHP Kenntnisse reichen, müsste das doch im Core irgendwo einfach auslesbar sein...

[Samson1964]

Ich arbeite seit Jahren exzessiv mit Nachrichten, nicht erst seit ein paar Monaten mit Contao. Aber irgendwelche ID's oder ähnliches habe ich bisher nie gebraucht, schon gar nicht für eine Sprungmarke. href="#Sprungmarke" sollte völlig ausreichen. Ich habe bisher damt noch nie Probleme gehabt.

[tristanlins]

{{news::URL}}#Position1

Anstelle von {{news::URL}}#Position1 versuch doch mal {{env::request}}#Position1. {{env::request}} kannst du universell einsetzen :)

Worin besteht die technische Schwierigkeit?

Insert Tags werden an einem Zeitpunkt ausgewertet, wo die Information um welche News es geht nicht mehr existiert, nämlich ganz am Ende der Generierung, kurz vor dem Senden zum Browser. Deshalb ist es technisch schwierig, das "mal eben so" umzusetzen.

[samkuem]

@Samson1964 Das funktioniert nicht. Habe ich hinlänglich getestet.

@tristanlins Ich habe es mit allen Tags probiert... es funktioniert mit keinem. Das mit der Generierung wusste ich natürlich nicht.

[tristanlins]

@samkuem doch, {{env::request}}#Position1 funktioniert, habe ich gerade schnell mal getestet. http://demo.contao.org/en/news/james-wilson-returns.html (aber schnell, wird in 30 Minuten resettet)

[backbone87]

Diese Modifikation benötigt einen Extra-Pass von replaceInsertTags, der bei der News-Generierung selbst ausführt wird. Es müsste sich mit den parseArticles und replaceInsertTags Hooks in einer eigenenständigen Erweiterung umsetzen lassen. Generell: Die Sprungmarken-Sache hat Tristan schon erläutert und ich sehe auch kein Problem daran, warum es nicht funktionieren sollte.

Meine Gedanken zu den anderen Insert-Tags {{news::Title}} {{news::Alias}} {{news::ID}}: Diese Informationen liegen vollständig beim "pflegen" des Newseintrags vor, sodass ich keinen Grund sehe, da innerhalb eines Eintrags nochmal zu referenzieren.

Generell ist die Verwendung von Insert-Tags nicht ganz so "einfach" wie hier dargestellt wird. Einige Sachen sind kein Problem (wie {{env::request}}), aber andere Sachen haben uns schon einige Schwierigkeiten eingehandelt, die sich fast nicht lösen lassen ohne einen BC-Break (z.B. {{insert_article|module|content::*}})

[backbone87]

Nachtrag: Zu der Sache mir der "persönlichen Meinung":

Schön, dass du das persönlich findest. Bitte Argumente – ansonsten ist so eine „Meinung“ irgendwie überflüssig.

Es geht hier um ein etabliertes Paradigma in der Softwareentwicklung: KISS Solange es sich ohne eine Modikation des Cores umsetzen lässt (als eigene Erweiterung), gibt keinen Grund für zusätzliche Komplexitäten innerhalb der Cores bzw. der Core-Distribution. Das dem Paradigma gefolgt werden sollte, ist seine persönliche Meinung, geprägt durch seine Erfahrungen. Und ich für meinen Teil und ich denke auch ein Großteil der Contao Community legt wert auf Toflars Meinung und Erfahrungen.

Zu der Sache mit dem "Ich brauchs sofort": Man kann nicht erwarten, das eine Software womit hunderte Leute arbeiten und ihr Geld verdienen, von heut auf morgen geändert wird, weil es einem selbst grad etwas Arbeit abnimmt. Bei Sicherheitskritischen Sachen oder groben Fehlern, welche die Verwendung von Contao stark einschränken, ist ein Hotfix innerhalb weniger Tage kein Problem. Bei allen anderem sollte man sich am vorgegebenen Release-Zyklus orientieren. Ein guter Weg um etwas schnellstmöglichst zu bekommen:

• Ticket eröffnen und zu einer Entscheidung kommen, ob es denn aufgenommen wird oder nicht.
• konformen Pull Request erstellen (lassen) basierend auf dem development-Branch
• Im IRC (#contao.dev) 2-3 Leute ansprechen, ob sie denn ein gutes Wort für den PR einlegen
• Den PR in seinem eigenen Projekt schon verwenden
• Auf den Merge & nächsten Release-Zyklus warten

[jankout]

Ich würde es auch willkommenheißen. :-)

Grundsätzlich sollte es aber möglich sein, im Backend standardmäßig über TinyMCE die News und Events zu verlinken und nicht wie das jetzt ist, wo man die IDs erst finden muss und dann wieder zu dem Artikel zurückkommen muss, wo man die Verlinkung zu News oder Event haben möchte. Das ist ein großes Manko von Contao, obwohl es sonst sehr benutzerfreundlich ist.

[weipah]

Es gibt eine Erweiterung namens "moretags", die das m.M. nach ermöglicht. Leider ist dieses im Entwicklungsstand von 2009. Wenn man eine neue autoload.php in den Config Ordner packt, um die Klasse zu registrieren funktioniert es bis Contao 3.5.6 aktuell.

"morelinks" zum Verlinken, gibt es auch noch.

Es gibt auch einen Wiki-Beitrag, sowie einen Eintrag im Cookbook, wie man eigene InsertTags schreibt.

[madmaharaja]

Ich wollte eben ein Ticket genau zu diesem Thema eröffnen und bin dann doch noch hier darauf gestoßen, dass ich wohl nicht der einzige bin, der sich solche Inserttags wünschen würde.

Der vorangegangenen Diskussion nach scheint die Umsetzung solcher Inserttags wohl nicht ganz Ohne zu sein. Falls sich hierfür aber eine praktikable Lösung finden würde, würde ich mich auch sehr freuen, wenn es solche Inserttags nicht nur für News, sondern auch gleich für Events und sogar Artikel geben würde!

Ich hätte mir jedenfalls in der Vergangenheit schon mehrfach für verschiedene Anwendungsfälle gewünscht, im Frontend Felder von News, Events und Artikeln per Inserttag ausgeben zu können. Für Personen, die nicht über großartige Programmierkenntnisse verfügen (ich denke da z.B. an mich), sind Inserttags geniale Hilfsmittel, um kreativ diverse Anwendungsfälle selber umsetzen zu können! Von daher ein +1 von mir für den Vorschlag von @samkuem

[Samson1964]

Geht es dabei um den ursprünglichen Vorschlag von @samkuem ?

{{env::newsTitle}} – Ausgabe des Titels der aktuellen Newsmeldung {{env::newsAlias}} – Ausgabe des Alias der aktuellen Newsmeldung {{env::newsURL}} – Ausgabe der URL der aktuellen Newsmeldung

Das sollte ja einfach in einer Erweiterung umsetzbar sein, in dem einfach der aktuellste Beitrag aus der tl_news-Tabelle herausgesucht wird. Um die URL herauszubekommen, muß man aber noch ein paar Sachen mehr machen: den Newsleser finden und auf welcher Rootpage (wegen der Domain) der eingebunden ist.

EDIT: Oder war das mit "aktuelle Newsmeldung" anders gemeint? Geht es um die gerade angezeigte News und darin soll zusätzlich der Inserttag möglich sein?! Dann würde env nicht passen, weil es ja global gelten soll.

[madmaharaja]

Mit "aktuell" meinte ich (und ich vermute auch @samkuem ), die gerade im Frontend angezeigte News -- also nicht die zuletzt veröffentlichte. Analog zur Systematik, wie sie ja schon für Seiten existiert (z.B. {{page::title}} -- gibt den Namen der "aktuellen" Seite aus), würde ich den zweiten Vorschlag von @samkuem befürworten:

{{news::title}} {{news::alias}} {{news::ID}}

({{news::URL}} wäre meiner Meinung nach nicht erforderlich, da die aktuelle URL ja bereits über {{env::request}} ausgegeben werden kann)

Und der Vollständigkeit halber auch:

• {{news::subtitle}}
• {{news::teaser}}
• {{news::date}}
• {{news::image}} (sodass z.B. auch {{news::image?width=200&height=150}} o.Ä. umsetzbar wäre)
• {{news::enclosureLink}}
• {{news::parentTitle}} (Name des Nachrichenarchivs)

Und analog dazu das gleiche für Events und Artikel -- und warum nicht auch für FAQ ...

[Samson1964]

Was Du da alles willst, würde ich über ein eigenes Newstemplate festlegen. Dort stehen ja alle Variablen zur Verfügung. Wozu sollte ich z.B. mit {{news::date}} das Nachrichtendatum noch einmal anzeigen. Es steht doch eh' schon da. Und auch den Namen des Nachrichten-Archivs gebe ich mit im Template aus: <?php echo $this->archive->title; ?>

[madmaharaja]

Wie gesagt, zum einen ist nicht jeder vom Kenntnisstand her in der Lage, Templates anzulegen. Zum anderen verstehe ich Templates so, dass man die anlegt, wenn man nach einem immergleichen Muster eine bestimmte Anzeigeform mehrfach erreichen möchte (z.B. ich möchte, dass alle News in einem Reader immer den gleichen Aufbau haben).

Mit Inserttags ist man (zumindest als jemand ohne programmiererische Kenntnisse) sehr viel flexibler und kann schnell etwas "punktuell" umsetzen oder kann (weil man ja nicht in der Lage ist, Templates zu coden) sich Module anlegen, in die man Inserttags einfügt, die quasi eine Template-Funktion übernehmen.

Ein Anwendungsbeispiel, wofür ich mir Inserttags, wie die oben genannten wünschen würde: Ich habe mir im Formulargenerator ein Anmeldeformular gebastelt. Dieses habe ich im Seitenlayout auf der Seite eingebaut, auf der sich auch mein Eventleser befindet. Im Formular würde ich dann z.B. eine Checkbox einbauen, wo die Bezeichnung wie folgt aussieht:

Hiermit melde ich mich Verbindlich für die Veranstaltung "{{event::title}}" an.

So würde in Abhängigkeit vom aktuell angezeigten Event ein und dasselbe Formular immer einen anderen Veranstaltungstitel dort anzeigen.

Ein weiteres Beispiel: Ich könnte bei einem zweispaltigen Seitenlayout in der linken Spalte einen Newsreader einbauen, der mir dort den Text der News anzeigt. Durch Inserttags könnte ich im Seitenlayout in der rechten Spalte z.B. eine "Box" einbauen, in der immer der zu einer News dazugehörige Anhang angezeigt wird.

Ich könnte in der Seite mit dem Event- oder Newsleser mit Inserttags das Datum der betreffenden News oder des Events dem Seitentitel oder der Seitenbeschreibung hinzufügen.

Vielleicht möchte jemand manchmal bei manchen News auf der Newsdetailseite/dem Newsleser vorneweg den Teaser anzeigen, bei anderen Nachrichten aber nicht. Mit einem Template kann ich es nur so einstellen, dass er immer oder nie angezeigt wird -- mit einem Inserttag kann ich das flexibel handhaben.

Zugegeben, für manche der genannten Inserttags fällt mir spontan kein sinnvoller Anwendungsfall ein -- aber aus eigener Erfahrung weiß ich, es gibt immer irgendjemanden, der mitten in der Nacht an der Umsetzung einer kniffligen Aufgabe sitzt und sich mega freut, dass er selber in der Lage ist, das mittels bereits existierender Inserttags zu lösen, ohne vorher ein Ticket eröffnen zu müssen und sich in einer Diskussion für seinen Anwendungsfall rechtfertigen zu müssen. :-)

Wie gesagt, das ist alles aus der Sicht von Anwendern/Webmastern geschrieben, die keine Programmierkenntnisse haben bzw. sich nicht zutrauen, in Templates rumzupfuschen. Für solche Personen bieten Inserttags unzählige Möglichkeiten, kreativ zu einem gewünschten Ergebnis zu kommen, wofür sie sonst einen Entwickler beauftragen müssten.

[fritzmg]

@Samson1964 mit Insert Tags könntest du verschiedene Eigenschaften einer News an verschiedenen Layout stellen ausgeben, ohne extra für jede Stelle ein Newsreader + Newstemplate anlegen zu müssen.

[Samson1964]

Vielleicht möchte jemand manchmal bei manchen News auf der Newsdetailseite/dem Newsleser vorneweg den Teaser anzeigen, bei anderen Nachrichten aber nicht. Mit einem Template kann ich es nur so einstellen, dass er immer oder nie angezeigt wird -- mit einem Inserttag kann ich das flexibel handhaben.

Das läuft dann darauf hinaus, das Dein Newsleser-Template bis auf den Wrapper praktisch leer ist, weil Du mit den Inserttags jede Nachricht unterschiedlich gestaltest. Okay, wenn man es in verschiedenen Layoutspalten benötigt, vielleicht sinnvoll.

[asaage]

Ich frag mich, wo du diese Insert-Tags platzieren willst. Wenn du das auf der NewsReader-Seite machst sehen doch wieder alle News gleich aus vom Aufbau. Wenn du dafür zusätzliche Artikel Anlegst fehlt die die Referenz zum entprechenden Beitrag.

Den Titel von News/Events solltest du auf der Reader-Seite eigentlich mit {{page::pageTitle}} ausgeben können.

[madmaharaja]

Nach einigen Jahren lande ich erneut bei diesem Thread, weil ich aufgrund eines aktuellen Projekts wieder mal danach gegoogelt habe, ob es nicht irgendeine Möglichkeit gibt, per Inserttags die Informationen der aktuell aufgerufenen News auszugeben. Und nun erinnere mich: ach ja, es geht leider nicht.

Da dieses Ticket noch offen ist, wollte ich nur mal nachfragen, ob inzwischen mal im Core-Entwickler-Team besprochen wurde, ob eine Übernahme dieser Inserttags in den Core denkbar wäre?

Ich möchte an dieser Stelle auch nochmal ein grundsätzliches Plädoyer dafür halten, dass man eine solche Entscheidung nicht nur davon abhängig macht, ob man selber im Laufe seiner jahrelangen Arbeit mit Contao zufällig schonmal ein bestimmtes Feature benötigt hat oder nicht. Zum einen sind die Anforderungen an Features so unterschiedlich wie die Zwecke und Betreiber von Websites (da liegt es auf der Hand, dass man noch nie in die Verlegenheit gekommen ist, ein bestimmtes Feature zu benötigen). Zum anderen sind Core-Entwickler ja Menschen, die jede eigene Contao-Anforderung jederzeit selber durch die Programmierung einer Erweiterung oder eines Templates realtiv schnell für sich lösen können. Die Zahl der Contao-Anwender und Administratoren, die eben nicht über solche Fähigkeiten verfügen, wird wohl eine weitaus größere Anzahl an Personen darstellen. Und gerade für diese Personengruppe (die ja auch tagtäglich mit Contao arbeitet), sind Features wie die Core-Inserttags eine Mega-Hilfestellung. Ich vermute mal, dass man als fähiger Entwickler fast alle Anforderungen lösen könnte, selbst wenn die bisherigen Core-Inserttags nicht existieren würden. Der Logik nach müsste man sich dann fragen, ob Core-Inserttags überhaupt gerechtfertigt sind. Ich wage mal zu behaupten, dass Core-Features nicht nur "must have", sondern auch "very nice to have" sein dürfen und sollen, um das System weiterhin attraktiv für den ordinären Anwender und Websitebetreiber zu halten.

Von daher von mir nochmal ein Votum pro Aufnahme der News-Inserttags in den Core. :-)