Beiträge von hrybak

    Wieso versuchst Du es nicht mal zuerst mit Standard Cassiopeia. Hier im Form sind bereits viele erfolgreich umgestiegen inkl. meiner Wenigkeit.


    Wozu eine zusätzliche Komponente, die Wartungsauswand mit sich bringt, aber kein wirklichen Vorteile (wie auch viele Dinstleiter bestätigen.).

    Mich nerven immer Seiten, wo sich in user.css oder template.css zu viel Spaghetti-Zeugs befindet, was vielleicht gar nicht mehr relevant ist, weil die zugehörige Erweiterung längst nicht mehr verwendet wird,

    Das ist alles grundsätzlich richtig.


    Wenn alter, unbenutzter Code vorhanden ist , ist das natürlich vor allem ein (schweres) Versäumnis des Entwickler. Unterschieden werden sollte allerdings zwischen Dienstleistern, die so was natürlich zu recht gar nicht mögen, und den Webseiten-"Designer" wie mich, die nur 2 Webseiten gestalten und schon aus Zeitgründen darauf achten (sollten), dass im Eigeninteresse alles "einfach - eindeutig - sicher" ist.


    Vorausetzung dafür sind regelmäßige Reviews der User.css und der use .js und ausführliche Dokumentationen. Da, wo allerdings die Komponente (wie z.B. JEvents) bereits integration von CSS und JS anbieten, habe ich natürlich gerne darauf zurückgegriffen.


    Was ich sagen will: letztlich entscheidet jeder selbst, welche Vorgehensweise für ihn die beste ist. Ich selbst bevorzuge wenn möglich einfache bis sehr einfache Lösungen.


    Übrigens: die Modulklasse gibt mir auch die Möglichkeit bestimmte Operationen auf mehrere Module (der gleichen Klasse) ohne Zusatzaufwand anzuwenden.

    Ich möchte dem Modul gern eine eigene .css Datei mitgeben

    Meine Gegenfrage: aus welchem Grund?


    Aus meiner Sicht wäre es viele einfacher, dem Modul über Erweitert eine Modulklasse (z.B. modulclass ) zu verpasen. Über die kannst Du dann in der user.css alle Anweisungen, die nur dieses Modul betreffen sollen, eindeutig zuordnen.

    Code
    .modulclass . . .

    Für mich gibt es drei unverzichtbare Erweiterungen auf jeder Website

    Hinsichtlich Akeeba stimme ich zu, Cache Cleaner ist hilfreich, aber nicht notwendig, und JCE ist am Ende auch nur eine weitere Komponente, die gewartet werden muss ohne substantielle Vorteile zu bringen (ich habe JCE sehr erfolgreich gegen TinyMCE ausgetauscht)..


    Zurück zum Thema: das mit den Autoren ist wirklich ein Problem. Da können Anleitungen geschrieben, Hinweise gegeben und auf negative Folgen falschen Handelns hingewiesen werden: es gibt immer jemanden, der meint, dass er es besser weiß. Ganz schlimm ist das bei der Beschränkung auf bestimmte Schrifttypen oder die EInhaltung eines mit der Web-Seite konsistenten Farb- und Designschemas. Leider kann nicht alles über die TinyMCE-Profile oder css abgesichert werden.


    Jetzt zu den Bildern: ich habe den Autoren grundsätzlich erst einmal "Einleitungsbilder" und "Komplete Beitrgasbilder" als erste Wahl empfohlen kann ich über Klassen und css am besten steuern). Dennoch gibt es eine Anleitung für direkt einfügte Bilder, die eigentlich sehr befolgt wird. Seit der Umstellung auf J4 und auch schon davor gab es nie Probleme.


    Allerdings muss dazu gesagt werden, dass ich alle figures und imgs - sofern sie nicht Teil einer Galerie sind - generell auf max-width: 390px gestzt habe. Das sichert eine einheitliches Layout der Webseite. Und für Vergrößerungen aller Bildertypen habe ich ein kleine javascript-Anwendung geschrieben.


    Im Zweifel reicht es sogar figures und imgs unter 992px auf max-width: 90% zu setzen und mittig anzuordnen.

    Wenn ich darüber hinaus weiterhelfen kann, bitte melden.

    Kommst du also unter 395px fängt der Versatz an, alles wird kleiner, nur die Tabelle Wochentage hört bei 395px auf.

    Das und den weiteren Rest dieses Beitrages kann ich überhaupt nicht verstehen.


    Mein eigenes Smartphone ist nicht gerade High-end und ich komme erst gar nicht unter 395 px. So dürfte es übrigens der überwiegenden Zahl der Samrtphonenutzer gehen.


    Und selbst wenn es jemanden geben sollte, der unter 395px kommt: dann wird halt min-width per css reduziert oder gleich auf 0 gesetzt, zumal min-width seitens JEvents eben nicht durch !important "festgezurrt" ist.


    Abgesehen davon werden die Spalten dann sowieso so schmal, dass selbst der Unwilligste von selbst in die Horizontale wechselt.


    Vera: nicht verwirren lassen.

    Danke für das Feedback.


    Der Punkt bei JEvents ist, dass manche CSS-Anweisungen nur in der user.css funktionieren und manche bzw. die meisten nur in der jevcustom.css. Die Regel dahinter habe ich bislang noch nicht vollständig verstanden. Im Zweifel probier ich es in beiden und eine geht dann schon.


    Im vorliegenden Fall war ich mir allerdings voab sicher, dass es die user.css sein muss . bzw. eine entsprechenden Helix-spezifische css-Datei.

    Da ist jetzt leider ein Beitrag verschwunden (ehemals #8) mit dem Hinweis, das die Wortlängen das Problem sind.


    Wäre ich nicht gerade durch ein Virusinfektion intellektuel etwas gehändicapt, wäre ich auf die folgende Lösung wahrscheinlich schneller gekomme. Aber irgendetwas muss je getan werden - augenommen Rümhängen auf dem Sofa. Absehen davon haben mich die so bestimmt vorgetragenen Statements über JEvents in die falsche Richtung geschickt.


    @Vera B: Folgende Zeile bitte in die user.css eintragen:

    CSS
    span.editlinktip.hasjevtip a.cal_titlelink {word-break: break-all !important;}

    Ist etwas brutal, sollte aber seinen Zweck erfüllen, zumal durch Klick auf den Event jederzei weitere Infos abrufbar snd.


    Ich konnte das mangels Zugang zur Seite (will ich eigentlich auch garnicht haben) nur eingeschränkt testen - inbesondere mögliche Seiteneffekte auf andere JEvents-Features. Aber auf jeden Fall können eventuelle Folgeprobleme hier komuniziert und besprochen werden.


    Elwood: Basiert Dein Beispiel auf dem Standard-JEvents-Thema? Und ohne Link auf die Seite kann ich garnichts tun. Auf jeden Fall solltest Du alle td dieer Seite auf 14% setzen. Hilft schon mal.


    Dann etwas Grundsätzliches:

    JEvents ist an dem Problem von Vera B. völlig unschuldig


    Ich habe vergeblich in JEvents nach einem entsprechend Staement als Ursache gesucht. Nichst da. Ursache ist ein unzureichendesTabellenmanagement des HELIX-Templates, den letztlich sind die Templates verantwortlich für deren Erzeugung und Verwaltung. Das wird einigen hier nicht gefallen, Jeder sollte sich aber bitte daran gewöhnen, dass jede Software fehlerbehaftet ist.


    Unabhängig davon kann ich überhaupt nicht verstehen, wie ohne mehr oder weniger tiefe Anlayse ein Systemwechsel empfohlen wird. Gerade im vorliegende Fall ist die Lösung sehr einfach. Aus meiner beruflichen Vergangenheit kenne ich Aufwand und Probleme bei Systemwechseln. Auch wenn Joomla-Kompenten bei Weite nicht so komplex sind wie z.B. PDM-Systeme, Das eher geringste Problem ist dabei die Prüfung der Daten hinsichtlich Konsistenz und Vollstandigkeit. Wir reden hier nicht über die Migration einer Bildergalerie - aber durchaus über kommerzielle Shops, die z.B. gegenüber Finanzbehörden auskunftspflichtig sind.


    Bevor also ein Komponentenwechsel empfohlen bitte die Ursachen der Probleme analysieren und erst danach regieren.

    Leider nein.

    Stimmt leider nicht komplett so. Nur die Standardversion ist nicht responsiv. Da hatte ich - zugegeben - aus den Augen verloren, da wir schon sei J3 Silver-Member sind. Kostet zwar was, aber das können wir nachvollziehen - auch Dienstleistung kann nicht jeder kostenfrei liefern. Unsere Tanztrainer müssen ja auch bezahlt werden. Bei einer Schule und der stetigen Mittelverknappung sieht die Welt leider anders aus.


    In der responsiven Darstellung des Kalenders wird halt die Anzeige zerissen.

    Das kann ich nun überhaupt nicht nachvollziehen. Welche jevents-Version. Welches Kalender-Thema. Wir nutzen extplus und haben damit noch nie Probleme gehabt. Und bei kleinern Dingen hat uns immer der excellente Support von JEvents geholfen.


    So nun zurück zm Thema. Wir Nutzen seitd er Umstellung auf J3 (mit 1.5 haben wir angefangen) auch JEvents und haben uns anfangs mit Workarounds beholfen, die ich gerade heraussuche und dann hier veröffentlichen werden. Ein paar CSS-Zeilen sind immer noch einfacher als ein Komponentenaustausch.

    Deshalb nutze ich JE nicht (mehr), da es nicht responsiv ist.

    Hier muss ich massiv widersprechen: JEvents ist responsiv.


    Lediglich bei der Monatsansicht und Wochenansicht wird die Übersicht in mehrere Zeilen angeordnet. Darunter folgen dann hintereinander alle Wochen- oder Monatstage untereinander mit farblicher Hervorhebung des aktuellen Tages.


    Soweit ich das auf die Schnelle beurteilen kann handelt es sich wahrscheinlich um ein Konfigurationsproblem. Ich melde mich dazu am Nachmittag - muss jetzt leider weg.

    Ich habe noch nie mit CSS animations gearbeitet und aus Neugier doch mal probiert. Nach ca. 30 min hatte ich folgende Lösung:


    Code
    @keyframes example {
      0%   {top: 150px; left: -100px}
    100%   {top: 150px; left: 2000px}
    }
    #igl-logo {
      position: relative;
      animation-name: example;
      animation-duration: 8s;
      animation-iteration-count: infinite;
    }

    Angewendet habe ich das auf das Logo unserer Webeite https://www.ig-lilienthal.de/


    Vielleicht ist es ja das, was gsucht wurde.


    Ich lasse die Animation mal einige Zeit drin (so für 2 Stunden)

    Wir benutzen JEvents schon seit einigen Jahren, aber diese Aufgabenstellung ist uns noch nicht untergekommen. Ich wüßte im Moment auch nicht, wie das zu lösen ist. In der Moduldefinition sind zwar vordefinierte Layouts wählbar bzw. das Layout kann customized werden, das Aufklappen weiterer Informationen sehe ich da allerdings nicht.


    Daher meine Empfehlung direkt ins JEvents-Forum (https://www.jevents.net/discussions) zu gehen. Die Engländer sind eigentlich sehr hilfsbereit und helfen wo sie können zumal die beiden Beispiele sehr gut sind.

    Es ist wirklich ärgerlich, wenn Entwickler ihre Produkte nicht weiterpflegen. Leider gibt es da keine Garantien nabhängig von der Unternehmensgröße,

    So ist es. Deshalb kann ich aus eigener Erfahrung mit der Migration nach J4 nur empfehlen, soweit wie nur möglich die gegebenen Standards zu nutzen (Cassiopeiy, TinyMCE, Media Manager). Da mag es den einen oder anderen Nachteil geben (habe ich allerdings noch nicht gefunden). aber es erleichtert (hoffentlich) zukünftige Migrationen.


    Denn gerade als nicht-kommerzieller Nutzer wird mir keiner den Aufwand bezahlen, den Upgrades und Migrationen mit sich bringen.


    Was kann nun das CMS Joomla dafür, dass du dir augenscheinlich die falschen Partner für Erweiterungen ausgesucht hast?

    Zu dieser Anmerkung habe ich eine Frage: woher weiß ich, dass ich den richtigen Partner für eine Erweiterung gewählt habe? Wenn ich z.B. seit J1.5 eine bestimmtes Template genutzt habe, immer gut und schnell unterstützt wurde und dann von Einzelkämpfer die Nachricht erhalte, dass eine Version für J4 nicht geplant ist?

    Ich würde eher zu Buden tendieren, die sich auch abseits ihrer Erweiterungen an der Community beteiligen.

    Und wie das Template-Beispiel zeigt ist auch das keine Garantie. Ich habe sowohl mit Einzelkämpfern als auch mit Entwicklerteams sowohl postive als auch negative Erfahrungen gemacht, wobei bei den negativen Erfahrungen hinsichtlich zukünftiger Weiterentwicklungen die Einzelkämpfer überwiegen. Aber das ist letztlich individuelles Schicksal.