Dateien im Fließtext verlinken

[soletan]

Ist es gewollt oder ein Bug, dass in 3.1 im RTE für ein Text-Inhaltselement keine Dateien aus der Dateiverwaltung mehr über das "typolinks"-Plugin des TinyMCE gewählt werden können? Irgendwie konnte ich bisher weder hier im Forum noch per Google eine ausreichend klare Aussage dazu ermitteln und bin schon mehrfach darüber gestolpert, dass diese Option in 3.1 fehlt (insgesamt hat man den Eindruck, dass 3.0 und 3.1 derzeit eher RC-Status haben) ...

[Samson1964]

Ist mir auch schon aufgefallen und wird von mir schmerzlich vermißt. Vielleicht war die Dateiliste einfach zu lang. In meiner tl_files sind inzwischen über 21.000 Datensätze.

Wahrscheinlich ist die Funktion beim Umbau der ganzen TinyMCE-Auswahl versehentlich entsorgt worden. Dabei wäre es doch sicher einfach, hier noch einen dritten Button einzufügen und eine Datei per Inserttag einfügen zu können. Der Inserttag file ist ja leider dafür schon belegt. Bis Version 3.0.6 wurde der Pfad hier eingefügt. Besser fände ich {{file::18544}} oder sowas Ähnliches. Das ist man dann auch vor Verschiebungen oder Umbenennugen der Datei gefeit.

[soletan]

Inserttags sind sicher eine Alternative, aber mitunter beim Kunden nicht vermittelbar. Spontan hatte ich danach zuletzt auch gesucht, bin wie du beim {{file}} fündig geworden und dachte nur, ach nee, der war für was anderes ....

Bei kleineren Sites war die bisherige Lösung doch auch okay. Im Template des TinyMCE-Plugins ist der Code in jedem Fall richtig raus.

[swinde]

Hallo!

Ich würde, im Zweifelsfall, mal eine Fehlermeldung bei Github einstellen! Mehr wie eine Ablehnung kann nicht kommen.

Steffen Winde

[soweit_ok]

Leider kann ich hier nicht zur Erhellung beitragen, weil ich noch kein Update auf Contao 3 machen kann und es mir bei einer produktiven Seite auch noch als zu riskant erschiene. Aber ich hab mir den Thread mal gebookmarkt und bin gespannt, was dabei herauskommt. Weiß nicht, ob die 3er-Releases eigentlich eher noch rc sein sollten, wie manche sagen. Jedoch weiß ich, dass man mit Postings bzgl. wohl weithin als nebensächlich angesehenen Dingen wie z. B. TinyMCE-FE-Belange oder FE-Dateiupload bei Problemen nicht selten keine einzige Antwort erhält. Nehme ich nicht krumm, doch registriere ich eben.

Denn derlei betrachte ich absolut nicht als unwichtigen Kram, sondern im Gegenteil ist meine Erfahrung, dass die Summe aller "Kleinigkeiten" unterm Strich verdammt viel Arbeitszeit verschlingen kann. 21.000 Datensätze oder Dateien sind in einer größeren Installation garnix. Da darf ein System noch lange nicht einknicken. So groß kann der Unterschied unmöglich sein im Hinblick darauf, dass z. B. eine Java/Oracle DB betriebene Webseite sogar auch bei mit bis zu 20 Parametern aut. generierten rekursiven Queries auf Millionen Datensätze nicht schlappmacht und noch halbwegs passable Antwortzeiten ermöglicht, wenn es sauber programmiert ist. Fürs Dateisystem gilt nicht dasselbe, doch dann brauchts dafür Lösungen. Ist die Ordnerstruktur von tl_files bzw. files bei Contao 3 in der Datenbank indexiert? Keine Ahnung, aber es klang so im betreffenden Vorposting.

PS: Ja ich weiß, bei diesem Problem gehts ums BE. Doch das macht m. E. keinen wesentlichen Unterschied, denn eine moderne Webseite sollte unbedingt den RTE im BE wie FE gleich gut unterstützen. Wohl noch immer ein schwächelnder Bereich, den ich bereits im 2er-Releas nur mit aufwändigen Nacharbeiten befriedigend auf die Reihe brachte.

[soweit_ok]

... Im Template des TinyMCE-Plugins ist der Code in jedem Fall richtig raus.

Ohne Alternative ist das makaber, weil unverzichtbar. Und Inserttags sind definitiv keine Alternative. Ich denke ebenfalls, Kundenredakteuren nicht oder nur schwer vermittelbar.

[soletan]

Github wäre natürlich mein nächster Schritt, doch bevor ein Ticket ins Issue-Tracking geht, ist ja ein Forum die vorherige Station.

Zu der Rechnerei mit der Performance: das ist sicher nicht das Problem. Nur 20.000 Files in einer Auswahlliste zu verpacken kann diese in puncto Nutzbarkeit ad absurdum führen und außerdem ist - egal ob statisch im HTML oder per AJAX/JSON - die Transfermenge beachtlich. Da ist es juck, ob dahinter Oracle, DB2 oder "nur" MySQL werkeln, wenn am anderen Ende ein 1MBit-Nutzer hängt. Auch die Serverlast, ein 20.000-Einträge-Array aufzubauen und zu managen, ist in jeder Sprache - egal ob Java oder PHP ein RAM-Fresser, den nicht jeder Hoster gestattet.

Daher kann ich das verstehen, die Option zu entfernen. Sie aber ersatzlos oder ohne Wahlmöglichkeit zu streichen ...

[soletan]

Kleiner Nachtrag: ich versuche seit Monaten, 3er-Contaos für Produktiveinsätze vorzubereiten, doch irgendwie kann ich das derzeit nur bei funktional eher schlichten Sites ohne bedenken machen. Die Kinderkrankheiten sind zahlreich, ja. Das OS nicht ohne Mithilfe wird, ist mir auch klar, aber warum dann 3.1? 3.0 scheint noch nicht mal etabliert, da kommt schon 3.1 hinterher. Das kann ich schwer nachvollziehen, denn es scheint, als wären hier Major-Releases vorschnell ausgegeben worden. Und solche Summen an Kinderkrankheiten kosten vor allem Image und Zuspruch ...

Die Funktionen in 3.1 sind wirklich cool. Aber die Community baut lieber weiter an 2.11 ... versteh ich nicht wirklich.

[soletan]

Ticket: https://github.com/contao/core/issues/5995

[soweit_ok]

Github wäre natürlich mein nächster Schritt, doch bevor ein Ticket ins Issue-Tracking geht, ist ja ein Forum die vorherige Station.

Zu der Rechnerei mit der Performance: das ist sicher nicht das Problem. Nur 20.000 Files in einer Auswahlliste zu verpacken kann diese in puncto Nutzbarkeit ad absurdum führen und außerdem ist - egal ob statisch im HTML oder per AJAX/JSON - die Transfermenge beachtlich. Da ist es juck, ob dahinter Oracle, DB2 oder "nur" MySQL werkeln, wenn am anderen Ende ein 1MBit-Nutzer hängt. Auch die Serverlast, ein 20.000-Einträge-Array aufzubauen und zu managen, ist in jeder Sprache - egal ob Java oder PHP ein RAM-Fresser, den nicht jeder Hoster gestattet.

Daher kann ich das verstehen, die Option zu entfernen. Sie aber ersatzlos oder ohne Wahlmöglichkeit zu streichen ...

Wobei bei großen Sites natürlich die Server-Hardware entsprechend skaliert wird und da kein Hoster mitzureden hat. Ansonsten völlig richtig und ich kann es ebenfalls verstehen. Aber nicht alternativlos, das ist doch keine Lösung! Außerdem frage ich mich, wieso eigentlich müssen all diese mitunter auf tausende anwachsenden Dateien unbedingt unter einem einzigen Mountpoint versammelt werden? Gibts keine flexiblere Strukturierungsmöglichkeit? Selbst wenn sich da noch garnicht soviel tummelt, nerven mich die dortigen Ladezeiten im BE manchmal auch so schon genug, wenn ich mal keine schnelle Internetverbindung habe. Und mit einer solchen können nunmal nicht alle Kundenredakteure prahlen.

[soweit_ok]

Die Funktionen in 3.1 sind wirklich cool. Aber die Community baut lieber weiter an 2.11 ... versteh ich nicht wirklich.

Na ja, aufgrund diverser tiefgreifender Änderungen musste es wohl zwangsläufig ein Major-Release werden. Alles andere wäre letztlich reine Augenwischerei gewesen.

Na sicher baut die Community lieber vorerst noch weiter an der stabilen ausgereiften 2.11. Dies war auch an den umfassenden Diskussionen im Vorfeld absehbar, doch der Innovationsdruck/-wille war offensichtlich stärker. Dass die projektbezogenen Interessen einzelner User bei solchen Entscheidungen eine wesentliche Rolle spielen, ist auch nicht zu erwarten.* Hast Du denn eine bessere Idee? Anders kann man das doch bei größeren produktiven Sites bisher garnicht ernstlich verantworten. Es sei denn, man zählt bereits zu den absolut verschärften Contao-Cracks und wird deshalb mit nahezu jedwedem Problem notfalls auch alleine fertig. Eine andere Sache sind daneben womöglich verwendete noch inkompatible Extensions. Verzicht geht nicht immer und erst recht nicht bei drangestrickten Interaktionen zwischen Extensions.

*PS: Das belegt auch der eingeführte LTS. Was ich nun wieder sehr gut finde. Nur die Supportphase in Relation zu den bei den neueren Releases noch bestehenden Mängeln vielleicht etwas kurz.

[soletan]

Na ja, aufgrund diverser tiefgreifender Änderungen musste es wohl zwangsläufig ein Major-Releas werden. Alles andere wäre letztlich reine Augenwischerei gewesen.

2.11 nach 3.0 bin ich dabei ... aber 3.0 auf 3.1 ist auch kein Pappenstiel und signalisiert mehr als Bugfixing ... ohne Stütze durch die Community bei den Extensions bleiben aber vielerorts Mehrnutzen auf der Strecke. Die Innovationen sind toll, aber vermutlich ist es eine alte IT-Story, dass durch einen Bruch mit der "Vergangenheit" Wechsel erschwert werden und man im Henne-Ei-Problem endet, weil die neue Version ohne Community nur bedingt taugt und die Community nur mit direktem Nutzen auf die neue Version zu wechseln bereit ist. Woher sollte dieser Initialfunke kommen?

Na sicher baut die Community lieber vorerst noch weiter an der stabilen ausgereiften 2.11. Dies war auch an den umfassenden Diskussionen im Vorfeld absehbar, doch der Innovationsdruck/-wille war offensichtlich stärker. Dass die projektbezogenen Interessen einzelner User bei solchen Entscheidungen eine wesentliche Rolle spielen, ist auch nicht zu erwarten. Hast Du denn eine bessere Idee? Anders kann man das doch bei größeren produktiven Sites bisher garnicht ernstlich verantworten. Es sei denn, man zählt bereits absolut verschärften Contao-Cracks und wird deshalb mit nahezu jedwedem Problem notfalls auch alleine fertig. Eine andere Sache sind daneben womöglich verwendete noch inkompatible Extensions. Verzicht geht nicht immer und erst recht nicht bei drangestrickten Interaktionen zwischen Extensions.

Auch das ist kein neues Problem. Doch solange die Extension nicht auf 3.0 gezogen werden, wechselt keiner, egal ob dank Live-Update das leicht geht. Solange keiner wechselt, muss keiner seine Extensions auf die 3.0 ziehen. Als Extension-Entwickler stehe ich da ja auch in der Pflicht, ich weiß ... aber wie gesagt: mein Unverständnis galt vor allem der Signalwirkung, die vom Umstand ausgeht, dass bereits 3.1 stable/aktuell sein soll, nur keiner sie so nutzen kann wie bspw. die 2.11 ... die immerhin zwei "Major" davor liegt. Spürbare und Inkompatibilitäten verursachende Innovationsschübe gab es auch schon zw. 2.9 und 2.10 oder 2.10 und 2.11 und manche meiner Sites liegt heute deshalb noch auf 2.9 ...

Auch PS: Wir entfernen uns vom Thema

[soweit_ok]

2.11 nach 3.0 bin ich dabei ... aber 3.0 auf 3.1 ist auch kein Pappenstiel und signalisiert mehr als Bugfixing ... ohne Stütze durch die Community bei den Extensions bleiben aber vielerorts Mehrnutzen auf der Strecke. Die Innovationen sind toll, aber vermutlich ist es eine alte IT-Story, dass durch einen Bruch mit der "Vergangenheit" Wechsel erschwert werden und man im Henne-Ei-Problem endet, weil die neue Version ohne Community nur bedingt taugt und die Community nur mit direktem Nutzen auf die neue Version zu wechseln bereit ist. Woher sollte dieser Initialfunke kommen?



Auch das ist kein neues Problem. Doch solange die Extension nicht auf 3.0 gezogen werden, wechselt keiner, egal ob dank Live-Update das leicht geht. Solange keiner wechselt, muss keiner seine Extensions auf die 3.0 ziehen. Als Extension-Entwickler stehe ich da ja auch in der Pflicht, ich weiß ... aber wie gesagt: mein Unverständnis galt vor allem der Signalwirkung, die vom Umstand ausgeht, dass bereits 3.1 stable/aktuell sein soll, nur keiner sie so nutzen kann wie bspw. die 2.11 ... die immerhin zwei "Major" davor liegt. Spürbare und Inkompatibilitäten verursachende Innovationsschübe gab es auch schon zw. 2.9 und 2.10 oder 2.10 und 2.11 und manche meiner Sites liegt heute deshalb noch auf 2.9 ...

Auch PS: Wir entfernen uns vom Thema

Hmmh, wird offtopic ... beenden wir diesen Aspekt also am besten bis auf weiteres. Bevor uns Lucina den Hahn abdreht. *gg* Vielleicht noch dies: Genau so. Deshalb hör ich mir mitunter auch im Forum an "Du wieder mit Deiner Uraltversion". Doch was soll man machen. Außenstehende können die Komplexität einer Installation garnicht beurteilen und welcher Updateaufwand jeweils damit verbunden ist. Jede Installation ist anders.

[Mike1410]

Es gibt doch eine einfache Lösung, in dem man mehrgleisig fährt. Damit meine ich, kleine Webseiten mit wenig Features, sind optimal mit Contao 2 oder 3 (nicht 3.1 zu viele Fehler) umsetzbar. Für mittlere und große gibt es doch sehr gute Alternativen wie Joomla oder gar Typo 3.

[soweit_ok]

Es gibt doch eine einfache Lösung, in dem man mehrgleisig fährt. Damit meine ich, kleine Webseiten mit wenig Features, sind optimal mit Contao 2 oder 3 (nicht 3.1 zu viele Fehler) umsetzbar. Für mittlere und große gibt es doch sehr gute Alternativen wie Joomla oder gar Typo 3.

Nette Theorie, nur sorry, nach meiner persönlichen Einschätzung und realer Erfahrung zumindest bei großen Projekten so nicht ganz zutreffend. Ohne auf die Produktmerkmale der genannten Alternativen näher einzugehen - damit besteht die Updateproblematik genauso. Außerdem ist es bei der Planung großer und daneben komplexer Webseiten ja nicht so, das zu den Anforderungen augenscheinlich am besten passende Entwicklungswerkzeug zu wählen, und damit wäre längerfristig alles gut. Vielmehr lässt sich selbst bei sehr guter Kapitaldecke nicht alles mittels Manpower parallelisieren und die Realisierung erstreckt sich häufig über mehrere Framework-Releases. Dieser allgegenwärtige Fakt ist unplanbar und zählt zum unvermeidlichen Risiko. Sogar bei extrem teuren kommerziellen Produkten (in meinem Fall Progress) erlebte ich das schon, Projekt fertig - Basis veraltet und nur mit bedeutendem Aufwand hochzuziehen. Insoweit ist es egal, was man wählt und kann sich stets nur an der Passung zu den Anforderungen beim Kick Off orientieren.

[soletan]

Es gibt doch eine einfache Lösung, in dem man mehrgleisig fährt. Damit meine ich, kleine Webseiten mit wenig Features, sind optimal mit Contao 2 oder 3 (nicht 3.1 zu viele Fehler) umsetzbar. Für mittlere und große gibt es doch sehr gute Alternativen wie Joomla oder gar Typo 3.

Nicht dein ernst. Joomla? Typo3? Sorry, wenn ich den Code dieser CMS sehe, dann gibt's besser gleich Anonymous-FTP mit Schreibrechten. Der Code bspw. von Typo3 ist - zumindest meinem Kenntnisstand 2011 folgend - so dermaßen veraltet und schlecht organisiert, echt jetzt. Nee! Nur weil jeder sagt, dass die gut für's Enterprise sind, heißt das nicht, dass das stimmt. Mit Contao schaffe ich mehr als mit den beiden und habe am Ende eine kundenfreundlichere UI, die auch Leute ohne 1500 EUR/Tag-Seminar verstehen können. Da schüttelt es sich mir ... beide kommen mir auf keinen meiner Server. Der Vorschlag ist aus meiner Sicht als SW-Entwickler mehr als unangebracht, sorry.

[Mike1410]

Nicht dein ernst. Joomla? Typo3? Sorry, wenn ich den Code dieser CMS sehe, dann gibt's besser gleich Anonymous-FTP mit Schreibrechten. Der Code bspw. von Typo3 ist - zumindest meinem Kenntnisstand 2011 folgend - so dermaßen veraltet und schlecht organisiert, echt jetzt. Nee! Nur weil jeder sagt, dass die gut für's Enterprise sind, heißt das nicht, dass das stimmt. Mit Contao schaffe ich mehr als mit den beiden und habe am Ende eine kundenfreundlichere UI, die auch Leute ohne 1500 EUR/Tag-Seminar verstehen können. Da schüttelt es sich mir ... beide kommen mir auf keinen meiner Server. Der Vorschlag ist aus meiner Sicht als SW-Entwickler mehr als unangebracht, sorry.

So hat jeder seine Meinung, und das ist auch gut so. Ist ein Lösungsansatz

[soletan]

So hat jeder seine Meinung, und das ist auch gut so. Ist ein Lösungsansatz

Gewiss ist es ein Ansatz. In Contao selbst die fehlende Funktion für eine Site individuell zu ergänzen ein anderer.

Die Staffelung bei mir ist nur eher, dass Contao die Enterprise-Klasse bedient und dazu sich viele Male bewährt hat. In einem Contao-Forum hätte ich von einem Contao-Fan in dieser Sache ausreichend erkennbares Zutrauen in dieses CMS und dessen extrem vielseitige Fähigkeiten erwartet, anstatt dem CMS seine Fähigkeit abzusprechen und stattdessen seine Zweckmäßigkeit auf kleinere Websites zu begrenzen, um dann lieber jene monolithischen Monster zu empfehlen, deretwegen Contao überhaupt erst entstand.

[Mike1410]

Ich bin und bleibe Contao Fan, allerdings bin ich von der 3er Version ein wenig enttäuscht. Viele kleine Fehler und Bugs und halb durchdachte neue Features. Daher nutze ich lieber die 2er, nur die wird nicht ewig weiterentwickelt. Ebenso die Entwicklungspolitik ist mir nicht ganz verständlich.

[soletan]

Ich bin und bleibe Contao Fan, allerdings bin ich von der 3er Version ein wenig enttäuscht. Viele kleine Fehler und Bugs und halb durchdachte neue Features. Daher nutze ich lieber die 2er, nur die wird nicht ewig weiterentwickelt.

Okay, darin sind wir uns hier ja offenbar alle einig. Und du lieferst quasi den Beleg für meine obige Kritik, dass die 3er Version dem Image und Zuspruch von Contao schaden dürfte.

Aber nun mal zurück zum Thema ...

[Mike1410]

Absolut!

[Bennie]

Um nochmal auf die Ausgangsfrage zu kommen. Ich kann es bei mir nicht nachvollziehen
In Contao 3.1.1 gehe ich im Text- Inhaltselement an eine bestimmte Textstelle, markiere diese, gehe auf das Linksymbol und kann sowohl Seiten wie auch Dateiverwaltung aufrufen um diese zu verlinken. War diese Vorgehensweise gemeint? Wenn ja dann funktioniert es bei mir einwandfrei.

LG
Bennie

[soletan]

In Contao 3.1.1 gehe ich im Text- Inhaltselement an eine bestimmte Textstelle, markiere diese, gehe auf das Linksymbol und kann sowohl Seiten wie auch Dateiverwaltung aufrufen um diese zu verlinken. War diese Vorgehensweise gemeint? Wenn ja dann funktioniert es bei mir einwandfrei.

Damn it, das war gemeint. Ich habe es eben auch nochmal geprüft und bisher offenbar im Link-Popup die Icons neben dem Feld ignoriert. Ich drehe mal eine Retourkutsche ...

[Samson1964]

Das Bild-Symbol hat mich irritiert. Vielleicht bin ich auch verwirrt, weil in meinem Popup die Icons fehlen. Es handelt sich um ein Update von 3.0.6 auf 3.1.1. Möglicherweise stören ja noch veraltete Dateien, die die Anzeige verhindern.
In meiner frischen 3.1.1 ist alles okay.

[Bennie]

Fehlen evtl noch andere Icons in deiner Installation, z.B. von Erweiterungen?
Ich habe auch ein (manuelles) Update durchgeführt (localhost - xampp)und keine nennenswerten Probleme außer fehlenden Icons und defekten Erweiterungen was aber an den htacess Änderungen lag bzw. dass die neueste Apache Version unter Xampp läuft, aber das dürfte ja mittlerweile bekannt sein.

[amarin]

Wahrscheinlich ist die Funktion beim Umbau der ganzen TinyMCE-Auswahl versehentlich entsorgt worden. Dabei wäre es doch sicher einfach, hier noch einen dritten Button einzufügen und eine Datei per Inserttag einfügen zu können. Der Inserttag file ist ja leider dafür schon belegt. Bis Version 3.0.6 wurde der Pfad hier eingefügt. Besser fände ich {{file::18544}} oder sowas Ähnliches. Das ist man dann auch vor Verschiebungen oder Umbenennugen der Datei gefeit.

Ich habe gerade eine Extension für genau so einen Insert-Tag erstellt, weil ich es selbst gebraucht habe:

{{x_db_file::*}}

https://contao.org/de/extension-list...inserttag.html

Der Tag lässt sich in den Einstellungen umbenennen, damit falls er in den core aufgenommen wird, er so benannt werden kann, wie der zukünftige Core Tag. Dann muss man nicht die ganze Seite anpassen, sollte der Tag in den core aufgenommen werden.

Holger

[Mike1410]

Hallo,

ich bin jetzt auch ein wenig verwirrt um welche Icon es geht. Nur nochmal zur Bestätigung, meinst du die im Screenshot (von Contao 3.1.0). Denn die fehlten bei mir auch mal, das war ein Problem mit Erweiterungen die ich installiert hatte.

screenshot_v310.png

[Samson1964]

Hallo,

ich bin jetzt auch ein wenig verwirrt um welche Icon es geht. Nur nochmal zur Bestätigung, meinst du die im Screenshot (von Contao 3.1.0). Denn die fehlten bei mir auch mal, das war ein Problem mit Erweiterungen die ich installiert hatte.

screenshot_v310.png

In meinem Screenshot habe ich genau denselben Dialog wie Du. Und die beiden Icons sind wohl absichtlich durch Contao ausgeblendet, sonst würde das Input-Feld ja nicht so breit sein.

Fehlen evtl noch andere Icons in deiner Installation, z.B. von Erweiterungen?
Ich habe auch ein (manuelles) Update durchgeführt (localhost - xampp)und keine nennenswerten Probleme außer fehlenden Icons und defekten Erweiterungen was aber an den htacess Änderungen lag bzw. dass die neueste Apache Version unter Xampp läuft, aber das dürfte ja mittlerweile bekannt sein.

Unter localhost fehlen links im Backend-Menü einige Icons, was aber an den jeweiligen .htaccess liegen könnte. Online ist alles bestens bis auf die Icons im TinyMCE-Popup.

[Mike1410]

Bei mir kam das dadurch das ich die Erweiterung: TinyMCE_Customizer installiert hatte, und dann upgedatet habe. Dann fehlten die entsprechenden Icons. Dann hatte ich diese Erweiterung deinstalliert und sie fehlten immer noch.

Erst als ich in der alten, also vorherigen, Version, die Erweiterung deinstalliert habe und dann upgedatet habe, waren sie da.

[Samson1964]

Bei mir kam das dadurch das ich die Erweiterung: TinyMCE_Customizer installiert hatte, und dann upgedatet habe. Dann fehlten die entsprechenden Icons. Dann hatte ich diese Erweiterung deinstalliert und sie fehlten immer noch.

Erst als ich in der alten, also vorherigen, Version, die Erweiterung deinstalliert habe und dann upgedatet habe, waren sie da.

Danke das Du mich auf die richtige Fährte gebracht hast. Ich habe unter 3.0.6 eine system/config/tinyCustom.php installiert und in system/config/dcaconfig.php aktiviert. Fortan wurde bei normalen Inhaltselementen meine tinyCustom.php abgearbeitet. Bei Teasern wird sie aber offensichtlich ignoriert. Da hatte ich meine Icons immer. Deshalb war ich wohl auch eingangs mit meinem ersten Posting auf den falschen Zug aufgesprungen. Die nur gelegentlich vorhandenen Icons und zudem das verwirrende Bild-Icon (für eine Dateiauswahl) lockten mich aufs Abstellgleis.

Mein Versuch davor das smart_backend_theme rauszuwerfen, führte zu nichts - außer das ich weiter ein smart_backend habe, obwohl ich die Erweiterung deinstalliert habe. Das ist zwar wunderschön, macht mir aber auch ein wenig Angst...

[Mike1410]

Danke das Du mich auf die richtige Fährte gebracht hast. Ich habe unter 3.0.6 eine system/config/tinyCustom.php installiert und in system/config/dcaconfig.php aktiviert. Fortan wurde bei normalen Inhaltselementen meine tinyCustom.php abgearbeitet. Bei Teasern wird sie aber offensichtlich ignoriert. Da hatte ich meine Icons immer. Deshalb war ich wohl auch eingangs mit meinem ersten Posting auf den falschen Zug aufgesprungen. Die nur gelegentlich vorhandenen Icons und zudem das verwirrende Bild-Icon (für eine Dateiauswahl) lockten mich aufs Abstellgleis.

Mein Versuch davor das smart_backend_theme rauszuwerfen, führte zu nichts - außer das ich weiter ein smart_backend habe, obwohl ich die Erweiterung deinstalliert habe. Das ist zwar wunderschön, macht mir aber auch ein wenig Angst...

Du hast das smart_backend deinstalliert und trotzdem ist es noch vorhanden. Das ist aber seltsam. Hast du jeden erdenklichen Cache gelöscht?

[Samson1964]

Skriptcache gelöscht, interner Cache ist abgeschaltet und zuvor das Theme deinstalliert. Trotzdem ist es noch da...

Inzwischen bin ich weiter auf die Suche gegangen - und mir selbst teilweise auf den Leim gegangen.
Das smart_backend_theme installiert eine weitere Erweiterung m17sticky, die bei der Deinstallation des Themes nicht wieder entfernt wird. Das restliche verbliebene CSS stammt allerdings aus diesem Tip...

Also alles bestens.

[mpietsch]

Ich habe mitgelesen und quer zum Thema gesucht und hoffe ich fasse den Stand richtig zusammen: Das Link-Popup fügt wie bekannt absolute Pfade ein. Es gibt [db-file-inserttag], was aber nicht allen Redakteuren zuzumuten ist. Es gibt aktuell keine Möglichkeit, Dateien dynamisch zu verlinken, z. B. indem das Link-Popup einen Insert-Tag generiert. Ist diese Zusammenfassung so korrekt?

[ISNC]

Hi ich habe folgendes Problem auf meinen neuen Installationen
Contao 3.5
Contao 3.6
und Contao 3.2

Bei allen neu installierten Versionen, funnktioniert weder die Bildereinbindung direkt in den Fließtext noch die Links und eigener HTML Code ist leer...
Gibt es hier mittlerweile eine Lösung?

[mpietsch]

Zuerst kurz nachgefragt: Was meinst du mir den Versionen 3.5 und 3.6?

Gesendet mit Tapatalk.

[ISNC]

Ups... verschrieben da hat meine Tastatur wohl gehangen...
ich meinte 3.15 und 3.2

[mpietsch]

Du willst Bilder und links im TinyMCE einfügen, richtig? Mit "eigener HTML Code" meinst du die Ansicht im Editor oder wählst du oben ein anderes Element aus statt Text?

Gesendet mit Tapatalk.

[ISNC]

Ich arbeite hauptsächlich mit dem Element Text.
Klar ich selbst könnte auch komplett alles mit HTML schreiben, aber ich gehe immer von meinen Kunden aus... die wollen es einfach...
Wenn die das Textelement sehen werden die das auch nutzen also Bilder, Links setzen und eben manche werden versuchen den Button html zu nutzen um den Code anzupassen.
Aber leider funktioniert das alles nicht so richtig. wie oben beschrieben.

Das HTML Fesnter welches sich öffnet ist komplett leer.
Links werden wenn man sie einträgt nicht gesetzt
und Bilder werden ebenso nicht eingesetzt.

Bei den älteren Versionen 2.9 oder 3.0 hatte ich da keine Probleme... vielleicht habe ich auch irgendwas anders gemacht oder es liegt an meinem Host Alfahosting früher war ich bei goneo.

[mpietsch]

Ok, Wasser nur eine Rückfrage wegen der Formulierung "Eigener HTML-Code".

Mit der HTML-Ansicht im Tiny gab es glaub ich mal einen Bug. Das wäre zu prüfen.

Links fügst du ein, indem du zuerst den Text schreibst, dann markierst und über den Dialog den Link hinterlegst?

Gesendet mit Tapatalk.

[ISNC]

Danke für deine Antworten.

Du beschreibst es genau richtig und wenn ein link bereits vorhanden ist, kann man diesen bearbeiten.

Bei mir sind aber die Felder leer und ja ich mache es nach der Beschreibung und es entsteht dabei kein Klickbarer text...
ist immer schwierig zu verstehen wie viel Verständniss das gegenüber hat, daher Danke das du es wirklich von Grund auf durchgehst... vielen fehlt da meist die Geduld.
Ich bin jetzt leider auf einem Meeting und kann erst Abends wieder antworten.
Vielleicht hast du ja noch eine Idee was für einen Fehler ich mache.

Wie gesagt Bilder kann ich auch nicht einsetzen.