Hallo zusammen,
benutze für diese Seite Typo3 3.6.2. Jetzt habe ich Problem mit dem Editor interne Links zu erzeugen. So etwas hatte ich noch nie.
Beim setzen des internen Links wird ja folgendes erzeugt http://www.domain.de/?id=40, bei der Ausgabe der Seite fehlt jedesmal das index.php. Eigentlich sollte der Link in der Ausgabe aber so aussehen http://www.domain.de/index.php?id=40.
Hatte vielleicht jemand schon das gleiche Problem, wie kann ich das lösen?
Danke und Gruß
FlashKasper
hi,
habe genau den selben Effekt das index.php vom RTE entfernt wird.
Vorläufige Lösung: den link in der HTML Ansicht auf http://index.php?id=
kürzen und dann behält der RTE den link so bei.
Bei kommt noch hinzu das er das "&" Zeichen als Sonderzeichen schreibt, also daraus dies hier macht: &. z.B. bei &L=1
gruß
manfredo
Hallo FlashKasper und manfredo,
habt ihr mittlerweile eine Lösung für das Problem gefunden ?
Bei mir tritt das Problem zwar "nur" bei Verwendung von TemplaVoila und FCEs auf (also wenn ich einen Link im RTE setze in einem eigenen Contentelement das ich per Templavoila erstellt habe) aber dann habe ich exakt das gleiche Problem.
Die Lösung im Code selbst einfach das index.php zu vervollständigen ist in der Tat mehr als unschön, da man bei Verwendung von Alias-Namen (egal ob SimulateStatic oder gleich RealURL) natürlich dann immer manuell den Alias-Namen eingeben muss (damit die Seite auch wirklich per Aliasname verlinkt ist) und nicht pauschal immer nur "index.php" angeben kann .
habe das gleiche Problem 🙁 Benutze auch Templavoila und Typo 3.8.0
Problemlösung: In der Index.php folgende Zeile, wenn möglich zu oberst:
$_SERVER["REQUEST_URI"] = str_replace('/?id=', '/index.php?id=', $_SERVER["REQUEST_URI"]);
#angry# #angry# #angry#
.... mir wurde mittlerweile geholfen, ob es euch weiterhilft weiß ich natürlich leider nicht, da es bei mir im Zusammenhang mit Templavoila / RTE in FCEs zusammenhing
:o
der fehler lag bei mir an ganz simplen Anfängerfehlern in den TemplaVoila Data Structure ´s:
ich hatte
<typoscript> statt <typoscript> geschrieben (und analog </typoscript> statt </typoscript> ) im Bereich
<typoscript>
<![CDATA[
10 = TEXT
10.current = 1
10.parseFunc = < lib.parseFunc_RTE
]]>
</typoscript>
<proc type="array">
deshalb konnten die Einstellungen in lib.parseFunc_RTE nicht angesprochen werden.
Als weiteres hatte ich
<defaultextras>richtext[ * ] :rte_transform[mode=css]</defaultextras>
statt
<defaultextras>richtext[ * ] :rte_transform[mode=ts_css]</defaultextras> (damit die Transformation von <a href=""> in <link...> in der Datenbank stattfindet und RealURL damit wieder etwas anfangen kann).
SimonFE schrieb...ich hatte
<typoscript> statt <typoscript> geschrieben (und analog </typoscript> statt </typoscript> )...
Habe ich nen knick in der Optik, oder gibt es da wirklich keine Unterschiede??? 😉 😉
Also ich habe das Problem ohne TemplaVoila.
Bei mir läuft RealURL.
Hat da niemand eine Konfig, die funktioniert oder einen kleinen ganz profanen Tip? 😢
Markus
Also ich hatte das Problem nach dem Update auf die neuste HTML-Area Version.
Im Setup hab ich
config.prefixLocalAnchors = all
und im Seiten-Header der Root-Seite
RTE.default.classesAnchor.default.page >
RTE.classesAnchor.internalLink.titleText >
Ich kenn das Problem auch. Bisher hab ich die Adresse vor dem speichern zunächst wieder richtig geschrieben und versucht das Problem zu ignorieren, aber auf Dauer wirds lästig.
ich trage ein:
index.php?id=40&c=DE
RTE mach daraus:
http://localhost/typo3/index.php?id=40&c=DE
..also eine korrekte Adresse die auch als Link funktioniert.
wenn ich jetzt nochmal via RTE irgendwelche Inhalte editiere ändert RTE die Adresse wie folgt:
http://www.domain.de/?id=40&c=DE
...und schmeißt mir gleichzeitig das nette style-Fenster mit rotenRahmen rein. Link funzt nicht mehr.
Ich hab aber festgestellt, dass dieses Problem nur auftritt, wenn ich auf eigene PHP-Scripte verlinke, die auf eigene Datenbanktabellen zugreifen.
Solange die Verweisziele in den Contenttabellen von Typo liegen gibts dieses Problem nicht.
Ich wäre auch sehr dankbar, wenn sich das irgendwie beheben ließe.
cooper
Hallöchen,
stehe derweil vor dem gleichen bzw. ähnlichen Rätsel. Ein interner Link wird vom RTE in die Form http://intern.local:80/?id=[id] (HTML-Ansicht im RTE) gebracht. Ein erneuter Klick auf das "Link einfügen" - Symbol offenbart, dass der Link nur als externer Link identifiziert wird. Der DB-Eintrag für das Content-Element enthält jedoch den korrekten TypoLink-Tag: <link id="[id]" />...</link>, zumindest bis man den Eintrag ein zweites Mal speichert.
Das gleiche Projekt (100%ige Kopie der DB und des Filesystem) macht auf einem anderen Server keine Probleme. Die Unterschiede liegen in der PHP- und MySQL-Version sowie im Betriebssystem (SuSE, RedHat). Keine Ahnung, ob das ursächlich sein kann.
Vielleicht kann jemand helfen, bevor ich mir den letzten Haarbüschel vom Kopf gerupft habe.
Gruß
OleBrumm
Also bei uns tritt das problem mit simulateStaticDocuments auf. und zwar nur wenn htmlarearte version > 0.7.0 ist.
ohne templa.
--> schön langsam würden wir auch gerne eine der neueren Versionen des htmlarertes einsetzen. ein lösung wäre also mehr als angebracht, besonders in hinblick darauf, dass der htmlarearte in einer neueren version im typo3 4.0 als default editor kommt!!!
Hallo!
die Lösung hat schon einer genannt, es hat nur keiner gemerkt:
RTE.classesAnchor.internalLink.titleText >
sorgt dafür, daß kein title-Attribut reinkommt. Das muß man für die 5 oder 6 unterschiedlichen Link-Arten (sh. RTEHtmlarea-Doku) jeweils machen.
Nur ohne Title Attribut wird ein korrekter typolink erstellt.
Grüße,
Ext22
tatsächlich!
RTE.classesAnchor.internalLink.titleText >
in der tsconfig löst das problem. danke, extension22!
woher soll man das den wissen??
lustigerweise taucht jetzt bei mir ein neues phänomen auf: die internen links gehen nun standartmäßig in einem neuen fenster auf. im link wird der target=page gesetzt (wo auch immer dieses "page" herkommen mag...?). das kann ich nur verhindern, wenn ich explizit den target beim link-setzen auf "_top" stelle. aber damit kann ich leben.
(ich find typo3 wirklich prima und freue mich auch, dass es so viele leute gibt, die einem helfen und sich engagieren, aber das war mal wieder eins von den problemen die einen regelmäßig zur verzweiflung bringen. in keiner dokumentation findet man einen hinweis auf solche probleme und nur nach stundenlanger foren-suche hat man genug bruchstücke zusammen um sich eine lösung zusammenzureimen... mit effektivem arbeiten hat das leider wenig zu tun, schade.)
viele grüsse,
spog
da war ich ja schon nahr dran.
habe gestern durch herumprobieren herausgefunden, dass es mit dem Title zu tun hat.
Kann man auf diese Weise auch den Stil bei externen Links löschen, damit die häßlichen Symbole nicht mehr standardmäßig angezeigt werden?
Das Symbol soll auch bei internen Links weg.
Oder kann man vielleicht komplett die Stilauswahl entfernen, damit keiner auf die Idee kommt da was anzuklicken?
Wie würde man das realisieren können?
grüße
,noi
du kannst die entsprechenden style-sheet classen in der css-datei deiner webseite einfach überschreiben, so kannst du das aussehen der verschiedenen link-typen selber bestimmen (css_styled_content natürlich vorausgesetzt)
in deiner css-datei kannst du z.B. so was in der richtung eintragen:
a.internal-link{ color:#000; text-decoration:underline;}
a.internal-link:hover{ color:#f00; text-decoration:none;}
greetz,
spog
Hallo spogspog,
naja, bevor alle Stränge reißen, werden ich wohl oder übel zu dem Überschreiben greifen müssen, allderings kann ich mir nicht vorstellen, dass das nur so geht.
Also eigentlich will ich bei externen Links den Eintrag nicht umdefinieren, sondern per Standard keinen Stil auswählen. Das muss doch irgendwie machmar sein.
Falls nicht überschrieben, muss man andernfalls beim Anlegen von Links jedesmal den Stil auf "leer" ändern und das wäre etwas nervig.
Als addon sozusagen wäre es dann noch sinnvoll "external-link" & "external-link-new..." aus dieser Liste zu werfen, da sie bei mir nicht benötigt werden.
Irgendwie denke ich, dass auch das gehen müsste, da man bei Typo doch selten an Standardvorgaben strikt gebunden ist.
Ich nehme an, sobald man den Kram aus der Stil-Liste wirft, braucht man auch nicht mehr "kein-stil" als Standard zu wählen, denn das ist dann ja automatisch der Fall.
mfg
,noi
RTE.classesAnchor {
internalLink {
class >
titleText >
image >
}
externalLink {
class >
titleText >
image >
}
externalLinkInNewWindow {
class >
titleText >
image >
}
internalLinkInNewWindow {
class >
titleText >
image >
}
download {
class >
titleText >
image >
}
mail {
class >
titleText >
image >
}
}
Einfach das class Attribut leeren, sozusagen, oder ein value geben das man braucht: zb: lnk_f (für link_fliesstext).
--> wenn das gemeint war.
ps: danke ext22, habs tatsächlich überlesen, und nun funzts! sollte aber eigentlich standardmässig funktionieren. IMHO. ...
mfg bbb
vielen Dank!
ich war gerade beim Probieren der Lösung von:
http://lists.netfielders.de/pipermail/typo3-german/2005-November/006838.html
😉
p.s.
und jetzt muss ich nochmal schauen, warum bei den internen Links immer target=page drinsteht und egal was ich für Angaben bei Template oder TSConfig mache
simpel: in den constants PAGE_TARGET = _top
und im setup:
config {
extTarget = _blank
intTarget = _top
}
lg bbb
hi,
config {
extTarget = _blank
intTarget = _top
}
Das hatte ich vorhin schonmal probiert, hatte aber aus irgendeinem Grund nicht funktioniert. Ich bin mir aber nicht mehr sicher, ob ich in den Constants "PAGE_TARGET = _top" eingetragen hatte.
Aber!
ich hab endlich den Übeltäter gefunden. Bei mir gab es folgende Zeile im TypoScriptObjectBrowser
lib.parseFunc_RTE.tags.link.typolink.target = page
Also hab ich bei mir im Setup einfach die Zeile ohne dem Page eingetragen und schon funktioniert es wie es soll. Also folgendermaßen:
lib.parseFunc_RTE.tags.link.typolink.target =
vielen dank nochmal
,noi