CMSimple_XH 1.7.0rc1

[knollsen]

Kurz zum Thema Calendar

Beitragvon lck » Fr Jun 02, 2017 7:30 pm
frase hat geschrieben:
Der Zwerch hat geschrieben:
Ich nutze auch die [Calendar plugin version 1.2.10 ], da sie meinen Ansprüchen völlig genügt.
Ich übrigens auch ...
Ich auch

@cmb - da ja doch einige die easy-Version verwenden und Du lieber diese Version im Vordergrund stellen könntest, hätte ich auch eine Angegung.
- Die Weiterschaltung der Monate <<< Juni >>> vielleicht doch über Javascript zu lösen, denn bei einer OnePage-Seite wo die Seite wegen den neuen Monat geladen wird macht sich nicht sehr gut Bsp, Header ..../index.php?Aktuelles#Aktuelles/Calendar nach klick .../index.php?Aktuelles&month=7&year=2017
- Eingabe einer detaillierten Info mit Bildern wie bei NEWS oder Realblog (eventl. jeden Eintrag nicht in einer Datei sondern in separater Datei)
Das sollte allgemein auch bei News oder .... mal überdacht werden, denn man hat schnell über 1MB an Text in so einer Datei. Da ja keiner löscht wird das im Laufe der Zeit immer voller, wo dann Datenbanken schneller werden, da sie ja nur den Teil und nicht das ganze laden. Für Calendar wäre dieser Punkt aber ehr unwichtiger als bei News oder etc.

Funktionell läuft die kleine Version ohne Probleme auf 1.7, damit könnte man diese Version auch als kompatible betrachten. (mit Mod. von Seite3)

[cmb]

@cmb - da ja doch einige die easy-Version verwenden und Du lieber diese Version im Vordergrund stellen könntest, […]

Da habe ich übrigens in der Zwischenzeit schon einiges gemacht.

- Die Weiterschaltung der Monate <<< Juni >>> vielleicht doch über Javascript zu lösen, denn bei einer OnePage-Seite wo die Seite wegen den neuen Monat geladen wird macht sich nicht sehr gut Bsp, Header ..../index.php?Aktuelles#Aktuelles/Calendar nach klick .../index.php?Aktuelles&month=7&year=2017

Diese Navigation gedenke ich ohnehin auf Ajax umzustellen, falls verfügbar. Das ist auch bei einer "normalen" Site relevant, damit man nicht immer wieder scrollen muss, falls der Kalender weiter unten auf der Seite erscheint (und auch, weil es einfach schneller ist).

Bezüglich der URLs würde das aber wenig ändern. Das sollte eigentlich bei einem Onepager von einem JS-Skript übernommen werden, das interne URLs entsprechend umschreibt (besser wäre es, wenn Core und Plugins gleich konforme URLs erzeugen, was gerade auch für clean URLs wichtig wäre, aber das wird wohl noch dauern). Jedenfalls dachte ich, dass würde Onepage_XH bereits machen, aber ich bin mir gerade nicht sicher.

- Eingabe einer detaillierten Info mit Bildern wie bei NEWS oder Realblog (eventl. jeden Eintrag nicht in einer Datei sondern in separater Datei)

Genau das möchte ich vermeiden. Das hat bei Calendar 1.3/1.4 zu einer ernomen Aufblähung des Codes geführt (da war schon mal die Rede vom Calendar-CMS). Ich finde es geht doch auch mit einem Link zu einer internen (versteckten) Seite, wo man sich bei Bedarf austoben kann.

Das sollte allgemein auch bei News oder .... mal überdacht werden, denn man hat schnell über 1MB an Text in so einer Datei. Da ja keiner löscht wird das im Laufe der Zeit immer voller, wo dann Datenbanken schneller werden, da sie ja nur den Teil und nicht das ganze laden. Für Calendar wäre dieser Punkt aber ehr unwichtiger als bei News oder etc.

Beim jetzigen Calendar 1.2 ist das praktisch völlig irrelevant, da dieser sowieso schon mit wenigen hundert Einträgen überfordert ist. Bei anderen Plugins (und letztlich auch bei content.htm) ist das aber schon lange ein potentielles Problem, und ich würde dann die Verwendung von SQLite empfehlen – das ist auch bei wenigen Daten kaum langsamer als eine einfache Datei (wenn überhaupt), und skaliert prima hoch. Wer will kann diesbezüglich ja mal Realblog_XH 3.0beta5 (noch mit "FlatfileDB") und eine aktuellere Version (mit SQLite-DB) vergleichen. Ich selbst hatte nur mit vielen Artikeln (1000 bzw. 10.000) verglichen, und da wurde 3.0beta5 langsam – bei 3.0beta6 war keine Verzögerung festzustellen.

[knollsen]

Das ist auch bei einer "normalen" Site relevant, damit man nicht immer wieder scrollen muss, falls der Kalender weiter unten auf der Seite erscheint (und auch, weil es einfach schneller ist).

Nicht nur das - auch bei Modalboxen nicht nur bei OnPages, deswegen würde ich das mit den URL jetzt nicht überbewerten.
Datenabruf:

...mit Bildern wie bei NEWS oder Realblog (eventl. jeden Eintrag nicht in einer Datei sondern in separater Datei)

hat bei Calendar 1.3/1.4 zu einer ernomen Aufblähung des Codes geführt

Wie das denn? Ohne das ich mir die MaxiVersion näher angeschaut habe, kann ich mir das nur vorstellen das die Datenmenge einen sehr kritischen Punkt angenommen hat. Oder speichert Calendar 1.3/1.4 in separaten Dateien??? Wie meinst Du das?

Beim jetzigen Calendar 1.2 ist das praktisch völlig irrelevant, da dieser sowieso schon mit wenigen hundert Einträgen überfordert ist

Echt? Also generell ist das ja ein altes Thema und wurde schon öfters diskutiert. Datenbank hin oder her. Ob schneller oder langsamer! Entscheidend ist doch das alles erst geladen werden muss. Und wenn ich ein Fan wäre von Datenbanken wäre ich nicht hier gelandet. (je nach Verwendung)
Über die Content.htm brauchst Du dir keine Gedanken zu machen, der Trent geht immer mehr weg von den aufgeblähten Seiten.
Aber bei so News-Krams wird ja nie was gelöscht, da alle Daten von Jahren noch im Archiv sein sollen!
Ob Datenbank oder csv - der Kram muss eh verarbeitet werden und die paar Sekunden Unterschied machen den Kohl nicht weg.
Wenn jemand (und ich hab jemand) der z.Bsp. neue Gesetze, Beschlüsse o. Texte v. Büchern ... die schon 5xkopiert worden sind, sind zum einem, 45% aller Zeichen "Sonderzeichen" Müll - und zum 2. schnell mal bei nur 10 Newsblöcken - 2MB an Daten in der CSV o. Datenbank...
Ich brauch jetzt nicht mehr weiter zu schreiben - weist was ich mein. (dieses Plugin oder was weis ich - bringt die Seite ins schwitzen)
Wenn ich aber den TimeStamp, Titel, Erstellungszeit, Configdaten nur in die CSV-speichere und erst beim Klick die TimeStamp-Datei lade die Kurzbeschreibung/Beschreibung enthält - geht nix in die Knie. Wenn ich noch ne ordentliche Ordnerstruktur nach Kategorien auf dem Server habe, sieht das auch noch etwas übersichtlicher aus.
Klar 1000 db Dateien auf den Server sieht nicht schön aus, aber das juckt doch keinen mehr! Früher hat man mit Speicherplätzen gegeizt, aber das heut doch nicht mehr. Jeder lebt in einer schnellen Zeit und wenn ne Seite länger als ne Minute dauert - dann iss der weg.
(ältere Daten würde ich sogar komprimieren nach ner Zeit.)
die csv/db oder ... mit Ihren kurzen Inhalt ist immer sofort da. Ich könnte wetten das ich mit meiner Methode und CMSimple schneller bin als Wordpress mit Datenbank. (gewagte Aussage)

[cmb]

hat bei Calendar 1.3/1.4 zu einer ernomen Aufblähung des Codes geführt

Wie das denn? Ohne das ich mir die MaxiVersion näher angeschaut habe, kann ich mir das nur vorstellen das die Datenmenge einen sehr kritischen Punkt angenommen hat. Oder speichert Calendar 1.3/1.4 in separaten Dateien??? Wie meinst Du das?

Mir ging es um den eigentlichen PHP-Code, nicht die Daten. Und der PHP-Code von Calendar 1.2 ist schon schwerlich wartbar…

Beim jetzigen Calendar 1.2 ist das praktisch völlig irrelevant, da dieser sowieso schon mit wenigen hundert Einträgen überfordert ist

Echt? Also generell ist das ja ein altes Thema und wurde schon öfters diskutiert. Datenbank hin oder her.

Hier geht es nicht so sehr um die Speicherung, sondern um das Bearbeitungsformular, welches um die zehn Felder pro Veranstaltung enthält. Beim Speichern wird jedes Feld versendet, und bei hundert Datensätzen sind das halt 1000 Felder, und da könnte max_input_vars u.ä. den Spaß vermiesen. Bei Calendar 1.4 wurde dann irgendwann ein Workaround eingebaut, so dass nur geänderte Datensätze übertragen werden (erfodert JS), aber auch dann gibt es bei vielen Events ein Problem, weil editevents() eine Unmenge HTML ausspuckt – hier fehlt auf jeden Fall eine Paginierung.

Wenn ich aber den TimeStamp, Titel, Erstellungszeit, Configdaten nur in die CSV-speichere und erst beim Klick die TimeStamp-Datei lade die Kurzbeschreibung/Beschreibung enthält - geht nix in die Knie.

Aber eine Suche über den Inhalt der Kurz-(Beschreibung) dürfte doch wieder Performance-Problem bereiten. Grundsätzlich stimme ich aber zu: flat-files können sehr effizient sein.

Ich könnte wetten das ich mit meiner Methode und CMSimple schneller bin als Wordpress mit Datenbank. (gewagte Aussage)

Ich denke, die Aussage ist nicht gewagt. WordPress arbeitet immer mit einer MySQL-Datenbank (CMIIW), und da kostet der Verbindungsaufbau eben eine gewisse Zeit, derweil die relevanten Daten-Dateien, wenn sie klein sind, eingelesen werden könnten.

[isometric]

Ich habe gerade mal das neue Datumfeld mit Chrome getetestet. Wenn man in den Kalender klickt wird nur das Datum, aber keine Uhrzeit (z.B. 00:00) übernommen und CMSimple beschwert sich dann über das unvollständige Datum. Kann man da keinen Default einstellen, damit das Feld mit einem Klick komplett belegt wird?

Datumsfeld.jpg

[cmb]

Ich habe gerade mal das neue Datumfeld mit Chrome getetestet. Wenn man in den Kalender klickt wird nur das Datum, aber keine Uhrzeit (z.B. 00:00) übernommen und CMSimple beschwert sich dann über das unvollständige Datum. Kann man da keinen Default einstellen, damit das Feld mit einem

Ich glaube, das geht nicht. Ich bin inzwischen aber nicht mehr sicher, ob ein DateTime-Picker überhaupt sinnvoll ist. Wird zwar von Chrome und Edge unterstützt, aber nicht z.B. von Firefox. Seit ein paar Versionen kennt Firefox aber Date-Picker und ich glaube auch Time-Picker (müssen derzeit noch optional aktiviert werden) – vielleicht sollten wir das doch noch mal umbauen (also separate Date- und Time-Picker)?

[frase]

Seit ein paar Versionen kennt Firefox aber Date-Picker und ich glaube auch Time-Picker (müssen derzeit noch optional aktiviert werden)

Die Aktivierung habe ich noch nicht gefunden.
Vielleicht doch lieber einen fertigen JS-(bzw. jQuery)-Date-Picker?
Das sollte dann zumindest im Admin-Modus funktionieren.

[isometric]

Ich glaube, das geht nicht. Ich bin inzwischen aber nicht mehr sicher, ob ein DateTime-Picker überhaupt sinnvoll ist. Wird zwar von Chrome und Edge unterstützt, aber nicht z.B. von Firefox. Seit ein paar Versionen kennt Firefox aber Date-Picker und ich glaube auch Time-Picker (müssen derzeit noch optional aktiviert werden) – vielleicht sollten wir das doch noch mal umbauen (also separate Date- und Time-Picker)?

Da sich bei Firefox und IE schon seit Jahren in dieser Richtung nichts tut, fände ich eine jQuery-Lösung auch gut.

Wie funktioniert den das?

Can be enabled in Firefox using the dom.forms.datetime flag.

Im Chrome würde die Ein-Klick-Lösung übrigens mit einem andern type funktionieren:

Code: Select all

<input type="date" size="16" maxlength="16" name="publication_date" value="">

Gibt es den Date-Typ eigentlich auch für die Plugin-Konfigurationen?

[cmb]

Seit ein paar Versionen kennt Firefox aber Date-Picker und ich glaube auch Time-Picker (müssen derzeit noch optional aktiviert werden)

Die Aktivierung habe ich noch nicht gefunden.

Siehe Fußnote 1.

Vielleicht doch lieber einen fertigen JS-(bzw. jQuery)-Date-Picker?
Das sollte dann zumindest im Admin-Modus funktionieren.

Ich bin kein Freund von JS-Datepickern. Die brauchen oft jede Menge JavaScript und CSS, und viele, die vor nicht allzu langer Zeit noch aktiv gewartet wurden, werden das nun nicht mehr. Und auf der anderen Seite finde ich es gut, wenn der Druck auf Browserhersteller wächst, die diversen date/time Inputs auch nativ zu unterstützen. Jedenfalls würde ich es gerne vermeiden, heute noch einen JavaScript-Date/Time-Picker in den Core zu integrieren – in wenigen Jahren hat sich das sowieso erledigt[1], und wenn überhaupt machen diese dann nur noch bezüglich des Look-and-Feel Sinn, was ich im Backend für weniger relevant erachte.

Und schau Dich mal bei CMSimple(_XH) Plugins um. Da gibt es mehrere mit Date/Time-Pickern, aber ans Update denken nur wenige. Realblog_XH schleppt als Fallback noch immer einen DatePicker von 2005 mit, in Calendar 1.4.6 steckt einer von 2011 oder so – schön, wenn diese alten Scripte auch heute noch "überall" funktionieren, aber sicher wäre ich mir da keinesfalls. Klar, nun könnte man die Scripte auch einfach aktualisieren, aber dummerweise werden sie nicht mehr gewartet. Also müsste ein neuer Date-Picker integriert werden, und das Spielchen geht von vorne los.

[1] http://caniuse.com/#search=date gibt schon jetzt über 80% zumindest partielle Unterstützung an, und Firefox 57 wird wohl Date- und Timepicker per Voreinstellung aktivieren, IE stirbt langsam (oder hoffentlich nicht so langsam) aus, und Safari spielt keine allzu große Rolle mehr (und vielleicht wird ja auch dort mal ein Date/Time-Picker integriert).

[isometric]

Ich habe den Date-Picker jetzt mal in der Developer-Version, als auch im aktuellen Firefox-Browser ausprobiert. Funktioniert beides nur, wenn man den Typ des CMSimple-Datumfeldes auf "date" ändert.

Die Aktivierung habe ich noch nicht gefunden.

Wer es testen will:
Um die Funktion zu aktivieren, muss man in die Adresszeile folgendes eingeben:

Code: Select all

about:config

Anschliessend nacht "dom.forms.datetime" suchen und mit Doppelklick die beiden deaktivierten Punkte aktivieren.