Posts by mokraemer

Neben der Tatsache, das auch virt. Maschinen Updates brauchen, würde ich empfehlen dennoch die Versionierung zu aktivieren.

Die IT des Krankenhauses sollte mal ihre Backupstrategie überdenken....

Für Bugs haben wir normal den BugTracker:

Wir nutzen auch php-fpm, leiten die Anfragen aber nicht per http um, sondern setzen diese direkt über den offenen Socket ab.

Es hat uns daher die Frage bisher noch nicht ereilt.

Das Header mit "X" klingt eher nach optional und scheint auch nicht immer/überall verfügbar zu sein. Sicherlich können wir die Prüfung zusätzlich einbauen - besser wäre es natürlich, wenn man einfach erkennen könnte über welche Port der Request auf dem HTTP-Server eingeht (nicht in PHP)

Nutzt ihr cloudflair, das ihr das so abbildet, oder gibt es einen Grund das nicht über den Socket zu lösen?

Habt ihr die Versionierung von WE im Einsatz?

Die wird von unseren Kunden durchaus genutzt und funktioniert idr auch.

Aber dennoch sollte es ja immer ein externes Backup geben.

Die Objekte werden bei der internen Suche nicht mit Dokumenten verknüpft.

Das liegt u.a. auch daran, weil sie auf vielen Seiten eingebunden sein können. Wenn man bspw. "anstehende Termine" auf jeder Seite rechts anzeigt, würden diese ja dann auch auf jeder Seite gefunden. Zusätzlich müßte sich der Suchindex bei jeder Änderung des Objektes dann komplett neu aufbauen.

Also ich würde dir dringend empfehlen statt dem "," ein anderes Zeichen zu nutzen. Entweder "/" oder ":" - je nach Kontext.

Ich würde spontan sagen, das keiner bei den Kundenfeldern dran gedacht hat die Multi-Selektion zu implementieren.

auf die Idee bin ich zugegeben nicht gekommen bisher.

Müßte man mal nachvollziehen. Wäre aber eigentlich was für die Bugbase.

Werden die "dynamischen Inhalte" eigentlich genutzt? Da sie ja gar nicht so dynamisch sind, erschienen sie mir bisher immer etwas sinnfrei.

Die Variante auf den Verzeichnissen ist zumindest wartbar - die Variante, wie sie bei den Einträgen gab, hat eh länger nicht funktioniert. Dennoch frage ich mich nach einer sinnvollen Anwendung davon.

nee, der Eintrag hat damit nichts zu tun.

Kann es sein, das du auf der Klasse noch in einem Feld JS-Kode hinterlegt ist?

Das sollte eigentlich nicht sein, hab das aber schon ein paar mal gesehen....

Nein. Die Version 8.1.x wirst du mit PHP 8.3 nicht updaten können.

Zu dem Zeitpunkt gab es noch kein PHP 8.3 - und daher wird das Update nicht damit umgehen können. Du solltest auf PHP 5.6 zurück.

welche Auswahl könnt ihr euch denn vorstellen?

Ich würde quasi gerne für die Benutzer die Klassenauszeichnung zum Eintrag als Workaround weg haben. Ein Benutzer sollte keine CSS-Klasse setzen müssen

normal solltest du einfach we:form nutzen, da wird das Form-Token automatisch mitgeschickt.

field und dir_field nuzen Felder des Dokuments

Du hast glaube ich was verpaßt.

Die Datumsangaben sollen nicht mehr als Unix-Time angeben werden.

Du müßtest afaik nur

<we:conditionAdd field="EndDate" type="now" compare="<="/>

nutzen und die Variable weglassen. (Ob aktuell date_ noch nötig ist, hab ich grad nicht auf dem Schirm - Ziel sollte eigentlich sein, das wir die Tags so nutzen wie es in WE ist und nicht, wie man es in der DB nachschauen muß)

das klingt sonderbar. Die 2. Query ist eher wg einer anderen langsamen Update-Query.

Was steht denn im Update-Log - da könnte durchaus auch etwas geloggt werden.

Hast du deine max execution time so groß gewählt? Normal sollte die nicht >30 sein

was genau meinst du denn mit "Modern Authentification".

Ich kann nur vermuten, das du damit 2FA meinst.

Tja, schade das bisher niemand das Problem mal artikuliert hat, bzw. die Lösung einfach in WE eingebaut hat. Soweit ich das gesehen habe, kann WE das bereits zu 90%.

Du kannst ja per <we:form type="object" name="ob1".../><we:form type="object" name="ob2".../> mehrere Objekte zur Bearbeitung anbinden und WE kann die danach auch einzeln schreiben. Die Struktur des Posts bzw. das Handling ohne we:form müßte man da einfach mal überdenken.

Btw. ich hab auf die Schnelle auch kein Beispiel für ein we:write gefunden:

Tag-Hilfe

Die Zwischenversionen gibt dir der Updater automatisch vor.

Du mußt dann aber teilweise auch die PHP Versionen dazu besitzen. Ein WE 6.4 läuft vermutlich nicht mit PHP 8.4, sondern nur mit 5.6, während des Updates werden dann teilweise neuere Versionen benötigt.

Man sollte sich aber fragen, ob der Aufwand hier nötig ist, oder man einfach die Inhalte die noch relevant sind aus der alten Install übernimmt. Hängt halt davon ab, was da wie drin ist.

nein, das sollte sich nicht verdoppeln, da wir beim Speichern hardlinks setzen.

was ich leider auch von hetzner bestätigen konnte, das bei einigen Datenbanken beim MySQL Update Tabellen mit virtuellen Spalten Schaden genommen hatten - aber seltsamer Weise nicht alle. Hab sowas bisher nur bei MySQL gehört, bei MariaDB lief bisher immer alles gut durch

Hier der Bug. Euer Problem ist, das die php-Updates gemacht werden, aber eben nicht die WE Updates.

Wir wissen ja auch nicht immer, was die Zukunft bringt. Und wenn dann ein php Update etwas ändert gegenüber dem alten Verhalten, dann kracht es.

Die fehlenden Rechte wurden bei Euren Installs vermutlich schon immer geloggt, wir hatten aber keine Kenntnis.

Die sicherste Variante ist das Update mit php 8.0 laufen zu lassen. Ab WE 9.2.2 ist der Bug ja dann behoben.