Beiträge von hrybak

    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.

    Wichtig ist zunächst, dass die beiden Kategorien über Komponenten > JEvents > Kategorien verwalten > NEU definiert wurden. Da genügt der Eintrag des Titels.


    Die Zuordnung der jcs-Dateien zu diesen Kategorien erfolgt dann über Komponenten > JEvents > JEvents Dashboard > Kalender verwalten > NEU. Es erscheint folgende Eingabemaske



    Hier ganz oben einen beliebigen Namen eintragen (kann auch identisch sein mit den zuvor definierten Kategorien). Danach weiter unten bei Kategorie wählen eine der beiden Kategorien auswählen und darunter auf JA setzen. Andernfalls werden eventuell Kategorien übernommen, die in der jcs-Datei mit anderem Namen vordefiniert sind. Anschließend weiter mit URL etc.


    In der Kalenderübersicht sollte dann unter Kategoriename nicht nur DEFAULT stehen.


    Das war jetzt im wesentlichen wahrscheinlich schon bekannt, aber vielleicht doch an der einen oder andern Stelle etwas anders ausgeführt.


    Danach sollte bei der jetzigen Terminübersicht ganz unten eine Leiste erscheinen, wo die Kategorien ausgewählt werden können. Um dieses Kategorie-Menü nach oben zu bringen wäre leider ein Silver-Addon erforderlich. Es geht aber auch so über CSS:

    Code
    #jev_maincal { margin-top: 3em; }
    div.event_legend_container {position: absolute; top; xem }

    x ( =20 oder größer) muss so angepasst werden, das die Leiste in die Lücke rutscht.


    Alternativ und eventuell sogar besseer wäre folgende Lösung (das ist wohl das, was Elwood meinte): Für jede Kategorie wird ein eigener Punkt im Main-Menü angelegt. (Main-Menü > Neu > Menüeintragstyp = JEvents > Anzeige nach Kategorie. Darunter Kategorie auswählen.)


    Ich hoffe das hilft etwas.

    zum 1. Punkt zunächst eine Frage (wir selbst sind schon seit Jahren Gold Member - daher weiss ich nicht, ob das bei der Gratis-Version möglich ist): können Kategorien definiert und die Termine einer Kategorie zugeordnet werden?

    Aber, wie in meinem Post etwas höher geschrieben, kann man in einem Open Source Projekt ja selber tätig werden, und Teil des Ganzen sein. Und dann vielleicht auch mitbestimmen. Und dann vielleicht etwas unabhängiger werden.

    Und wie ich dazu geschrieben habe, muss dazu Zeit und Fähigkeit vorhanden sein. Das trifft auch auf folgendes zu

    Vorteile ist z.B. das es Kostenlos und der Quellcode einsehbar ist,

    Hilft mir nur, wenn ich den Quellcode verstehe oder zumindest eine Erklärung dazu vorfinde, welche Motivation und welche Ziele hinter dem Code stehen also die Beschreibung der Anforderung. (Dass ich das bisher bei den Pull-Requests immer noch nicht gefunden habe, mag natürlich auch an mir liegen.)


    Mir selbst liegt vor allem am Herzen, dass auch die sich beteiligen können, die kein Programmierkenntnisse besitzen oder einfach keine Lust mehr dazu haben (ich habe schon vor mehr 20 Jahren damit aufgehört - wollte einfach nicht mehr - aber Joomla hat mich dann doch dazu gebracht das eine oder andere Script zu schreiben X/ ), und vor allem transparente Prozesse und nachvollziehbare Entscheidungen vorzufinden.


    Das hatte ich bislang vermisst, duch den Hinweis auf RFC sehe ich da jetzt aber Möglichkeiten und werde mich da etwas mehr mit beschäftigen. Soweit ich sehe ist es das, was ich eigentlich wollte. Wegen vieler anderer Aktivitäten wird ein entsprechendes Feedback aber in paar Tage warten müssen.


    Aber noch mal zu dem Vergleich mit den Bits und dem Akkuschrauber. Ich denke der hinkt etwas. Denn es geht ja nicht um Änderungen der Oberfläche (Schraubenköpfe). Da gibt es eine Übergangsphase (Tausch der Werkzeug und Anpassung der Arbeitsmethoden) und gut ist. Bei Systemmigrationen geht es ja sehr oft um Änderung von Datenmodellen (Gewindeyp und -größe wäre hier vielleicht der angemessene Vergleich mit nachfolgender Überarbeitung von Gehäusen und Austausch von Komponenten) und dann entsteht richtig Aufwand. Und gerade das ist die Erfahrung der Nutzer mit dem Übergang von Joomla 3 nach 4 (Beispiel ist mein Lieblingsthema: Objektmodell und Verarbeitung von Bildern).

    Zunächsteinmal zu den kleineren Dingen

    Stellt ein Kunde eine Anforderung, die der Dienstleister nicht erfüllen kann gibt er einen Auftrag an einen Kollegen, der das umsetzen kann (und bezahlt ihn natürlich).

    Und was machst Du mit der sehr großen Zahl von Privatleuten, Vereinen und anderen Enthusiasten, die gerade nicht das Geld haben jemanden zu beauftragen, auf der anderen Seite aber durchaus meinungsbildend gegenüber anderen potentiellen Nutzern sind? Deren Wünsche und Anforderungen fallen dann hinten runter?

    Du übersiehst auch, dass Joomla keine Firma oder Konzern ist. I

    Gerade das übersehe ich nicht. Wie ich schon an anderer Stelle sagte, fehlt Jommla der größere Sponsor, der Joomla selber nutzt und daher wichtige Ressourcen (z.B. auch Marketingkapazitäten) zur Verfügung stellt. Nur mit der Friwilligkeit der Engagierten geht es aus meiner Sicht langfristig nicht.


    Hilfreich war jetzt aber der Link auf

    Ich habe mir das angesehne und danach verstehe ich einige der Deiner Anmerkungen nicht. Denn dort steht eigentlich mehr oder weniger dass, was ich eingefordert habe. Ich zitiere mal aus Proposal Process Meta Document - 1. Summary (https://github.com/joomla/rfc/…epted/RFC-0-rfc-meta.md):

    For a sustainable success of the Joomla project, Processes, Features and Specifications need to be well-thought and generally accepted. At the time of this writing (Jan 2020), the organisation does not have a defined process to ensure this.

    This proposal aims to define a way to enable everybody in the community to suggest processes, features or specifications, and to define, how the community / project decides on the proposal.

    Im weiteren steht dann open for non-developers usw. usf.


    Ich schaue mir die Tage noch etwas inteniver an und melde mich dann ggf. nochmal.


    Übrigens halte folgende Aussage für absolut kontraproduktiv

    Ob ich als Core Entwickler Lust habe, dein Anliegen oder das irgend eines andere Anwenders zu bearbeiten, oder lieber eins, das für mich wichtig ist? Wer weiß.

    Für mich heißt das, dass ich als Joomla-Nutzer den Launen der Entwickler ausgeliefert bin.