WM-Loose Die von mir beschriebene Schwierigkeit triit sowohl bei Verwendung des "Kettensymbols" auf als auch bei Eingabe der URL im Editor
drmenzelit Das war die Lösung! Herzlichen Dank für deine Antwort. Nach Umstellung des TinyMCE auf "Absolute" wurden alle bis jetzt verkürzt als "Relative" im HTML integrierten URLs automatisch wieder als in der ausführlichen, absoluten Form ins HTML geschrieben. Ich brauchte also nicht die mir wichtigen Links nachträglich zu editieren!
Die Extension OS Booking Services versendet eMail mit Buchungsbestätigungen usw. Der Inhalt dieser Mails ist frei definierbar über den normalen Joomla-Editor. Ich verwende da den TinyMCE. In diesen eMails füge ich einen Link zu einer Bilddatei hinzu, die auf meiner Joomla-URL liegt, also z.B. https://meine-site.de/images/anfahrtsplan.jpg
Nun haben sich einige Kunden beschwert, dass dieser Link in der Mail nicht funktioniert. Ich fand schnell heraus, dass in den Mails der Link verstümmelt eingefügt wird, nämlich als:
/images/anfahrtsplan.jpg
Klar, dass dann nix kommt, wenn der Kunde auf den Link zum Anfahrtsplan klickt. Nun habe ich gedacht, dass der Editor diese Abkürzung verursacht, wenn ich den Link über die Link-Einfügefunktion, also über die UI vornehme. Daher habe ich den vollständigen Link nun im Code-Modus des Editors eingefügt und dann gespeichert. Aber beim Speichern wird sofort wieder automatisch der Anfang der URL rausgelöscht.
Frage: Wie kann ich das verhindern und dafür sorgen, dass die komplette URL unverändert in der Mail-Vorlage gespeichert wird?
Ich habs auf dem Server gefunden. Webgo bietet ein Cronjob und einen Cronjob Lighjt an. Der Unterschied erschließt sich mir nicht.
Ich habe CronjobLight verwendet und dort einen 1-stündigen Rhytmus sowie die vom Entwickler genannte URL eingetragen:
xxxxxxxx.de/index.php?trigger_code=OSBREMINDER
Ferner will Webgo noch Username und Passwort haben. Ich vermute, die Credentials der entsprechenden Joomla-Website. Und danach noch meine Mailadresse.
Nach knapp einer Stunde kam die erste Mail. Inhalt war der komplette Source meiner Homepage! Grrrr
Daraufhin habe ich die Mailadresse wieder aus dem Cronjob gelöscht.
Ich habe auch eine Test-Buchung vorgenommen, sodass ich morgen eine Erinnerungsmail bekommen müsste, falls ich beim Cronjob alles richtig gemacht hätte....
Der Mist ist halt, dass ich erst nach mindestens 1 Tag Warten heraus finden kann, ob der Cronjob mit der Erinnerungsmail wirklcih funktioniert.
Ich benutze die Extension OS Services Booking von Joomdonation. Wenn ein Kunde in diesem Termin- / Sprechstunden-Buchungssystem eine Buchung vorgenommen hat, soll er als Termin-Erinnerung z.B. 24 Stunden vor diesem gebuchten Termin eine Erinnerungs-Email erhalten.
In der Extension muss dazu ein Cronjob angelegt werden, der eine Bezeichnung hat: OSBREMINDER
Leider reicht anscheinend dies alleine nicht aus und es bedarf einer zusätzlichen Einstellung, die auf dem Server bzw. Webspace vorgenommen werden muss. Ich habe keine Ahnung, wo und wie das geht! Zudem laufen drei Websites auf meinem Account meines Webhosters.
Ich habe gerade den Support von Joomdonation gefragt und die Antwort war eine Gegenfrage:
Have you setup the cron task on your server to run this url: xxxxxxxx.de/index.php?trigger_code=OSBREMINDER
Und da dieser Trigger offensichtlich serverseitig angelegt werden muss, ist das nicht unbedingt die Aufgabe des Supports, mir Servertechnik beizubringen – das verstehe ich. Und deshalb frage ich jetzt mal hier nach.
Shuffle Sowohl bei DPCalendar als auch bei iCagenda wird eine Bestätigungsmail gesendet. Diese beinhaltet aber keinen Link, den der Bucher anklicken muss, um den Buchungsvorgang endgültig zu bestätigen. Genau um diese Funktion ging es. Und natürlich darum, dass eine unbestätigte Buchung nach einiger Zeit automatisch gelöscht wird.
Die Ki-Info war FakeNews (siehe oben).
Nach den guten Erfahrungen, die ich mit Joomdonation gemacht habe, kann es sein, dass ich die Extension Event-Booking zusätzlich lizenziere.
Will nur noch sagen:
Die Ki hat sich etwas zusammen gesponnen! FakeNews von der KI. Ist ja auch mal ganz unterhaltsam..... 
Vielleicht schaffe ich ja doch noch mal später die Extension EventsBooking an. Mit OS Booking Services von Joomdonation bin ich jedenfalls hervorragend zufrieden und auch der Support reagiert sehr schnell. – Ich fand übrigens heraus, dass OS Booking Services die einzige Joomla-Extension ist, mit der man ein zuverlässiges und leicht bedienbares Arzt- oder Therapeuten-Buchungssystem in Joomla aufbauen kann.
Wenn ich damit Geld verdienen könnte, würde ich es investieren.
Meine Events dienen nur sekundär dem Geldverdienen. Es sind Events, mit denen ich meinen Bekanntenkreis erweitere, also so etwas wie "Investition in PR".
Auslöser für meine Frage war nicht, dass ich aktuell Probleme mit Spaßbuchern hätte, sondern dass jemand, der den Praxis-Buchungskalender nutzt und daher diese "Bestätigungs-Link-Mails" kennt, verwundert angefragt hat, ob seine Buchung eines Events denn jetzt abgeschlossen sei, da er eben keinen Link anklicken musste.
Ich erkenne an, dass manche meiner Gäste / Kunden doch sehr scharfsinnig und logisch unterwegs sind!
DPcalendar und Jevents hatte ich betr. Doku (so weit verfügbar) sorgfältig durchgelesen. Nirgends wird die von mir gewünschte Bestätigungsfunktion beschrieben. Im Gegensatz dazu wird sie z.B. bei dem von mir genannten Events-Booking von Joomdonation besonders hervor gehoben.
Ich vermute zunehmend, dass diese Funktion, wenn sie sicher implementiert ist, so viel Aufwand bedeutet, dass dadurch die Extension nicht mehr kostenfrei sein kann.
PS:
Sag noch einer was gegen KI. Soeben erhielt ich folgende KI-Antwort über den Brave-Browser und das darin integrierte LEO-KI:
Generating Email with Confirmation Link in iCagenda
Based on the provided 
results, iCagenda offers features for sending confirmation emails with links to users who register for events. Here’s a step-by-step guide:
Das Ganze habe ich natürlich jetzt noch nicht probiert. Ich melde mich wieder dazu.
Ich verwende bis jetzt iCagenda, um einzelne Veranstaltungen von mir zur Buchung anbieten zu können. iCagenda hat zwar eine integrierte Überprüfung der Gültigkeit von eingegebenen Mailadressen. Aber was ich vermisse, ist eine Absicherung gegen "Spaßbucher".
Dagegen hilft nur, nach der Buchung eine Bestätigungsmail zu versenden, in der ein Bestätigungslink angeklickt werden muss. Geschieht dies nicht innerhalb einer bestimmten Zeit, wird die Buchung automatisch gelöscht. Solch eine Funktion ist in dem von mir benutzten Praxis-Buchungskalender OS-Services-Booking enthalten. Leider eignet sich diese Extension nicht für Veranstaltungen und deren Buchungen.
EventsBooking, das ebenfalls von Joomdonation.com stammt, würde die gewünschte Funktion bieten und noch sehr viele weitere nützliche Features dazu. Aber das wären schon wieder Jahr für Jahr ca. 40 Euro zusätzlich zu OS-Services-Booking. Obwohl ich sparsam mit Extensions bin, kommen mittlerweile pro Jahr über 250 Euro nur für Extensions zusammen. Nur für die wenigen Veranstaltungen, die ich anbieten möchte und deren Erlöse sehr gering ausfallen, lohnt es sich einfach nicht, eine kostenpflichtige Extension zu nutzen.
Meine Fragen also:
Gibt es eine Möglichkeit, in die Bestätigungs-Mail, die iCagenda regulär versendet, einen Bestätigungslink einzubauen? Und wenn der nicht angeklickt wird, ist die Buchung zumindest "in Warteposition" und nicht abgeschlossen.
Welche kostenfreie Extension würde ähnlich wie iCagenda funktionieren, aber diese Bestätigungsfunktion beinhalten? Ich habe bisher keine gefunden.
Rolf Dautrich Caniuse hatte ich damals konsultiert, ehe ich die media queries ausprobiert hatte. Caniuse ist nach meiner Erfahrung nicht zuverlässig, was Mobilbrowser betrifft.
markowski Danke für deinen Hinweis. An die Höhe hatte ich bei den media queries bisher nicht gedacht. Um möglichst jetzt schon eine Lösung zu erhalten, habe ich eine zusätzliche query eingefügt und zudem in YooTheme die Positionierung des Signets geändert auf "sticky when scrolling up". Dies gilt dann allerdings für alle Geräte und Portrait- sowie Landscape-Darstellung. Konkret ist das Signet beim Aufbau der Webseite oben positioniert. Scrollt man nach unten, verschwindet das Signet zusammen mit dem Inhalt der Seite nach oben. Sobald man auch nur ein bisschen wieder nach oben scrollt, schiebt sich das Signet wieder an die normale Position.
Die dank deines Tipps zusätzliche Query verringert die Breite und Höhe des Signet abhängig davon, ob bei einem bestimmten Bereich der Screenwidth eine bestimmte Höhe nicht überschritten wird:
.uk-logo img {
@media screen and (min-width: 641px) and (max-width: 960px) and (min-height: 500px) {
width: 60vw !important;
min-width: 400px;
max-width: 500px;
margin: 10px 0 6px 5px !important;}
}
.uk-logo img {
@media screen and (min-width: 641px) and (max-width: 960px) and (max-height: 499px) {
width: 41vw !important;
min-width: 200px;
max-width: 350px;
margin: -12px 0 -12px 5px !important;}
}Dank dieser Lösung ist es mir nicht mehr so wichtig, das Signet immer sticky zu halten, ausgenommen bei Smartphone im Querformat.
Danke an alle, die mir hier geholfen haben bzw. Hinweise gegeben haben!
Danke für deinen Hinweis. Mit clamp() habe ich bereits vor knapp einem Jahr experimentiert, um die Fontgröße eines Textes zu variieren, die über einem Bild liegt (Overlay). Das Bild skaliert gut auf den verschiedenen Geräten. Aber die Schrift muss sehr genau angepasst werden, damit sie harmonisch passt und auch nicht wichtige Bildteile verdeckt.
Clamp hat bei einem guten teil der Browser nicht zuverlässig funktioniert.
Es gibt erstaunlich viele CSS Definitionen, die nicht wirklich in allen möglichen Browsern zuverlässig funktionieren. So hatte ich hier ja im Frühjahr versucht zu klären, wie man mit CSS appearance() die Mobilbrowser dazu bringen kann, die Formular-Eingabefelder und Option-Felder so darzustellen, wie ich das gerne hätte. Nada! Jeder Browser macht da was er will!
Aktuell definiere ich die Größe des Logo / Signet mittels media-query wie folgt:
@media screen and (max-width: 480px) {
width: 80vw !important;
min-width: 300px;
max-width: 400px;
padding-bottom: 0px;
margin-left: 6px;}
}
Die weiteren queries folgen diesem Prinzip. Das führt dazu, dass das Logo z.B. auf einem Tablet im Potraitmodus gut aussieht, aber auf einem Smartphone im Querformat, was ja ungefähr ein ähnliches Pixelmaß hat wie das Tablet, über ein Drittel der Bildschirmhöhe vom Signet eingenommen wird.
Mir fehlen also nicht Definitionsmöglichkeiten, die vom Pixelmaß abhängen, sondern das Kriterium ist: Smartphone im Querformat.
Und dann ist sogar die Bedingung "pointer: coarse" zu ungenau, weil sie ja auch für Tablets und Laptops mit TouchScreen gelten würde.
Ich fand (witziger Weise mit Hilfe der KI im BraveBrowser) folgendes Javascript, um Smartphones über den UserAgent zu erkennen:
const isMobile = {
Android: function() {
return navigator.userAgent.match(/Android/i);
},
BlackBerry: function() {
return navigator.userAgent.match(/BlackBerry/i);
},
iOS: function() {
return navigator.userAgent.match(/iPhone|iPad|iPod/i);
},
Opera: function() {
return navigator.userAgent.match(/Opera Mini/i);
},
Windows: function() {
return navigator.userAgent.match(/IEMobile/i);
},
any: function() {
return (isMobile.Android() || isMobile.BlackBerry() || isMobile.iOS() || isMobile.Opera() || isMobile.Windows());
}
};
if (isMobile.any()) {
// Mobile!
} else {
// Not mobile
}Nun müsste dieser Code noch durch die Bedingung "if orientation = landscape" ergänzt werden. Oder durch "aspect-ratio".
Ferner bin ich bereits mit der vermutlich einfachen Aufgabe überfordert, die "if" und "else" Zeilen so zu ergänzen, dass der gewünschte Effekt "sticky" oder "non-sticky" zustande kommt.
Vielleicht findet sich ja noch jemand hier, der mir dabei hilft?
Matzeweb Hast du diesen Teil meines ersten Beitrags gelesen?
Bevor ich diese jQuery-Lösung eingebaut habe, hatte ich versucht, die Aufgabe per CSS media-query zu lösen und verwendete z.B.
@media only screen and (orientation: landscape) and (pointer: coarse)
Leider werden diese media-queries anscheinend von vielen Browsern nicht beachtet, speziell nicht von Mobil-Browsern. Wenn es funktionieren würde, wäre es ja Klasse und ich müsste dann nur den CSS-Code aus der Klasse uk-sticky als Definition hinein kopieren. – Script-Lösungen kann ich leider gar nicht selbst basteln, weil ich nix davon verstehe.
Da diese media query anscheinend von manchen Mobilbrowsern ignoriert wird, wäre es doch eine clevere Idee, die Mediaquery durch Javascript erledigen zu lassen. Und dazu hatte ich ja den Codeschnippsel der bereits aktuell genutzte Teil-Lösung gepostet. Dieses Script setzt aber nur das "Attribut" 770px zur CSS-Klasse "uk-sticky", welche sich dann auf Elemente der Klasse tm-hedaer-mobile auswirkt.
Mein Wunsch ist, die Mediaquery durch jQuery oder anderes JS ausführen zu lassen, wodurch dann in dem gewünschten Fall "Touch-Device und Querformat" das Signet auf non-sticky gesetzt wird. Javascript-basierte Media-Queries funktionieren anscheinend zuverlässiger, als reine CSS-basierte.
WM-Loose hast du meine Frage verstanden? Ich beschrieb ja, warum eine einfache media-query mit der Screenwidth nicht zum gewünschten Ergebnis führen kann. Im Übrigen ist solch eine Query zurzeit auf der Website aktiv und funktioniert. Sie liefert aber bei einem Smartphone im Querformat nicht das gewünschte Ergebnis.
Wenn meine Frage also so grundsätzlich unverstanden blieb, was soll da noch eine URL helfen? – Aber bitte, daran soll's nicht liegen:
Clemens' Psychotherapie Weinheim – Startseite
Ich arbeite mit Uikit bzw. YooTheme Pagebuilder. Auf meinen Websites habe ich mein Signet immer oben sichtbar (=sticky) bzw. in der uikit-Sprache = uk-sticky
Das Signet verändert seine Größe abhängig vom Viewport, weil ich seine Breite per CSS mit vw und max-width definiert habe. Das sieht elegant aus, ausgenommen bei der Darstellung im Smartphone-Querformat. Moderne Smartphones haben eine derartig große Pixelbreite, dass das Signet dann mehr als 1/3 der Bildschirmhöhe einnimmt.
Um das zu vermeiden, wurde versucht, das Signet erst ab 770 Pixel Breite sticky zu machen. Eine nur von Screenwidth abhängige Unterscheidung reicht aber bei den heutigen Smartphones nicht mehr aus: So hat mein Google Pixel 8 ein Display von 412 x 915 px bei Faktor 2,63.
Mein Ziel ist:
Es soll erkannt werden, ob die Website auf einem Smartphone im Querformat angezeigt wird. Wenn ja, soll mein Signet "nicht sticky" angezeigt werden. In allen anderen Fällen der Darstellung soll es am oberen Rand stehen bleiben während der sonstige Inhalt der Webseite scrollt.
Einen jQuery-Lösungsansatz habe ich, leider nur mit dem einzigen Unterscheidungskriterium Screenwidth. Aber diesen Script-Schnippsel könnte man evtl. erweitern, sodass die gewünschte Funktion erreicht wird?
jQuery(function($) {
$('.tm-header-mobile .uk-sticky').attr('uk-sticky','media: 770');
});
tm-header-mobile repräsentiert das Signet. .uk-sticky ist die CSS-Klasse im UIkit, durch die das Element fixiert wird.
Bevor ich diese jQuery-Lösung eingebaut habe, hatte ich versucht, die Aufgabe per CSS media-query zu lösen und verwendete z.B.
@media only screen and (orientation: landscape) and (pointer: coarse)
Leider werden diese media-queries anscheinend von vielen Browsern nicht beachtet, speziell nicht von Mobil-Browsern. Wenn es funktionieren würde, wäre es ja Klasse und ich müsste dann nur den CSS-Code aus der Klasse uk-sticky als Definition hinein kopieren. – Script-Lösungen kann ich leider gar nicht selbst basteln, weil ich nix davon verstehe.
Mit welchen Lösungen habt Ihr gute Erfahrungen gemacht?
Oh ja, ich muss vorher auf den Tab "Overrides" gehen. Sie erstellen eine neue Struktur, in der ich dann die "com_user" finde.
Ich danke dir herzlich!
Gestern hatte ich erst eine meiner Sites abgesichert. Heute wollte ich bei den anderen die Absicherung nachholen. Nun stelle ich fest, dass es bei drei weiteren Sites weder im Cassiopeia-Template noch im YooTheme-Template ein Unterverzeichnis "com_users" gibt. Eine dieser Sites wurde gerade erst frisch installiert und kann daher wohl kaum kaputt gefrickelt worden sein.
Wie kann das sein? Wo liegt denn in solch einem Fall die "com_users"?
Mir ist es schwer gefallen, die zu ändernde default.php zu finden. Ich habe die default.php per Override nun gefüllt mit:
<html> <head> <meta http-equiv="refresh" content="0; URL=/"> </head> <body> </body> </html>
und der Test mit den beiden oben im Thread stehenden Links verlief positiv: Nach kurzem Flackern landete man wieder auf der Homepage.
Herzlichen Dank!
Andreas24 Genau deshalb habe ich die Zahl 22 genannt, weil dieses Forum ja öffentlich lesbar ist. Wer sagt denn, dass ich wirklich 22 Stellen verwende?
Und wenn doch, rechne mal aus, wie viele Kombinationen es aus zwei 22-stelligen "Wörtern" gibt (Admin-Name 22-stellig und Passwort 22-stellig) und dann noch das Handicap, dass nach drei oder wie viel vergeblichen Versuchen bereits die IP durch BruteForceStop gesperrt wird. Besonders in Verbindung mit diesem Handicap dürfte es unrealistisch sein, hier eine Gefahr zu vermuten.
Da würde ich eher die Sorge haben, dass doch mal eine LogIn-Komponente den eingegebenen Code nicht 100% zuverlässig prüft und der Hacker dann doch eindringen kann.
Jedenfalls bin ich jetzt wieder beruhigt. Diskussionen wie die in dem o.g. Thread component users ausschalten nützen wenig, bringen aber "den Aufreger des Tages".
Nachtrag:
Immerhin hat die GHSVS-Accordion-Lösung den Vorteil, dass ich mir auch den Wunsch nach h2-Tags (oder anderen) für die Accordion-Title-Items erfüllen kann, damit es sich positiv auf SEO auswirkt.
Dass sich ein Text eines beliebigen Accordion-Item ausklappt, wenn dieses Item über einen Link angesteuert wird, sehe ich allerdings bei der GHSVS-Accordion-Lösung nicht.
Aber ich danke euch für die Anregungen, um diese Aufgabe lösen zu können!
Ich habe mich versucht, durchzuwursteln mit den Override-Empfehlungen usw. bin aber nicht wirklich weiter gekommen damit. Eine dieser Änderungen führte gleich zum Ausfall der Website. Nicht lustig!.
Nachdem ich die Empfehlung von WM-Loose gelesen habe, bleibe ich doch jetzt bei dem, was ich schon habe: Das Kubik-Rubik-Intrusion System macht exakt das, was das kostenfreie Plugin Brute Force Stop auch macht. Und das funktioniert schon seit Joomla 1.x für mich zuverlässig.
Ich habe doch sowieso immer im Backend eine LogIn-Möglichkeit für den Admin. Ob ein Angreifer versucht, darüber ins System zu gelangen oder über das Frontend, ist doch völlig Wumpe. Hauptsache, er wird nach 2 oder 3 Versuchen zuverlässig ausgesperrt. Allerdings sperre ich das Backend sowieso mit einer htaccess.
Solange Joomla im LogIn-Plugin keine Sicherheitslücke reinbaut, bin ich auf der sicheren Seite: Der Admin-Name / Benutzername besteht bei mir aus einem 22-stelligen passwort-artigen Gebilde und das Passwort hat ebenfalls 22 Stellen.
Solange jetzt keine Gegenargumente kommen von Menschen, die mehr KnowHow haben als ich, lasse ich alles so, wie es jetzt ist.
Wie seht Ihr das?