jein. Die meisten sollten auch bei Maria auftreten. Aber wir sind bei sowas immer auf Meldungen angewiesen. Wir können ja auch bei Maria nicht alle Versionen prüfen. Und einige Sachen kommen auch erst dazu. Genauso nutzt ja nicht jeder von uns alle Features.
Die meisten Warnungen sind ähnlich, also reicht uns meistens der Hinweis was es ist und wir können das dann für fast alle Queries anpassen, sofern sie denn von uns kommen.
Hat sich was beim Hoster geändert? ggf. iwo ein falsches Zeichen reingerutscht??
Also wie gesagt, die Datei wird abgelegt und danach versucht WE auf eine Datei zuzugreifen, wenn das nicht erfolgreich ist, wird das Speichern abgelehnt, weil man sich damit sonst aus WE aussperrt.
ja. Der Fehler soll dich vor Problemen bewahren!
Wir legen beim Speichern die Datei an und wenn danach WE nicht mehr erreichbar ist, wird das Speichern abgelehnt.
Wir entwickeln primär auf MariaDB, da diese auch bei den meisten zum Einsatz kommt. Die meisten Hoster haben darauf umgestellt.
Die Unterschiede der MySQL zur MariaDB sind nicht viele, daher unterstützen wir sie auch genauso weiter.
Die Warnungen, sind wie beschrieben Absicht um die Stellen identifizieren zu können und eben diese Stellen zu korrigieren.
Fehler sollten am besten direkt in der Bug-Base gemeldet werden.
Ja, genau - wir konnten 2022 nicht wissen, was 2026 in der aktuellen php Version deprecated oder gar entfernt werden würde.
Also aktuell hat keiner der Entwickler mehr eine MySQL zum testen. Die meisten Hoster haben auch auf MariaDB umgestellt.
Bisher war die MySQL weitestgehend kompatibel mit MariaDB.
Zu den Warnungen - die sind "neu". Wir wollten eigentlich bereits seit WE 9 die Warnungen der DB generell haben und auch fixen. Aufgrund eines Fehlers sind die Warnungen aber nicht geloggt worden.
Wir können hier aber nur fixen was wir sehen bzw. mitbekommen, es sind zu viele Queries um das alles überblicken zu können.
Bei den Warnungen haben wir auch teilweise schon bestimmte Fehlerkodes rausgenommen, damit nicht ständig was geloggt wird (dazu brauchen wir ggf den Fehlerkode). Wg der UTF8 Umstellung hab ich im anderen Post bereits was geschrieben. Das trifft sicherlich auch iwann MariaDB - aber MySQL geht da scheinbar gerade sehr aggressiv vor.
Not Null und das setzen von Null ist immer ein Fehler der in die Bug-Base gehört - der ist auch nicht MySQL spezifisch.
Wir hatten damit mal experimentiert. Aber bei einigen dürfte das Update nicht gehen, weil deren Tabellen damit auseinander fallen.
Das trifft v.a. die Klassen. Wenn hier zu viele Felder zu groß definiert sind, dann sprengt die Umstellung die maximale Zeilenlänge in MySQL von 64k. Die wird nämlich auf die maximal zulässigen Bytes gesetzt - also bei 1000 Zeichen MB3 sind das 3k, bei MB4 eben 4k.
aktuell haben wir noch keine Hooks dafür.
Da wird man sich ggf. mehr dazu überlegen müssen. Idr. macht man ja ein paar Ops hintereinander. Ob man das immer sofort an das CDN und den ganzen Cache weg weitergeben will....
probier es noch mal, evtl. hab ich da ne Version zu früh erwischt.
Derzeit ist Lukas der einzige der hier was dazu sagen kann. Wir anderen haben keinen Zugriff auf iein Office365.
Schreib besser noch mal ein Ticket. Afaik schaut er hier nie rein.
genau - und im Dokument kann man das dann immer x Monate weiter schieben.
Die Idee ist ja, das man daran denkt bestimmte Dokumente regelmäßig zu aktualisieren, bspw. Preislisten. Sowas hat aber eigentlich keinen Stichtag - und wenn, dann setzt man entsprechend das Datum x Tage davor.... Also dazu noch ein x Tage davor im Widget zu machen, dürfte wenig Mehrwert bieten
Wenn man das nur im Browser ausprobiert, kann das Problem darin liegen, das hier kein Cookie abgelegt wird.
Wie beschrieben, zunächst muß man webedition mit einem Admin Account öffnen (ganz normales Backend).
Dann kann man sich mit dem gleichen Account über davfs anmelden. Wie von Nils beschrieben nutzen wir dazu unter Linux davfs - und auch hier muß bei den Einstellungen die Cookies aktiviert werden, sonst dreht man sich in der Login-Schleife.
Ich denke unter MacOS dürfte das ähnlich funktionieren - wie es in Windows ist, weiß ich zugegeben nicht.
Wir binden das ganze damit auch in hg und netbeans ein - was durchaus recht gut funktioniert.
Das kann durchaus sein, das wir das absichtlich blockieren, weil das Update mit php 8 nicht durchläuft.
Während dem Update laufen ein paar Umstellungen, u.a. auf stärkere Typisierung, etc.
Du kannst ja, entweder den kostenpflichtigen Support für php 7 kurzzeitig in Anspruch zu nehmen für das Update, oder du versuchst bei dir lokal ein Update und spielst das ganze in eine neue Version wieder ein. Updates von WE 8 können in WE 9 nicht eingespielt werden!
Ich gebe zu bedenken, das bei normalen Webseiten viele Dokumente in diese Anzeige wären.
Wenn die Anzeige aber immer gefüllt ist, stumpft sie komplett ab und hat keinen Wert mehr, weil keiner mehr drauf schaut - sie ist ja eh immer da.
Alternativ schreibst du da eben Datum1>CURRENT_DATE( ) rein und sparst dir den PHP Schritt (Leerzeichen in den Klammern ist ggf nötig)
Oder du nutzt die we:condition:
<we:conditionAdd field="Datum1" type="today" compare=">"/>
also wirklich langsam ist die Install/Update ja nicht. Das läuft doch in einem Rutsch durch.
Im großen und ganzen werden die Daten vom WE-Server runtergeladen und dann eingespielt. Da ist nicht so viel Magie dabei.
Laufen zT. Aber teilweise gehen danach die Updates nicht. Weil die Rotuinen eben nicht wissen, das die Funktion danach entfernt wurde.
PHP ist da recht strikt. In der einen Version ist es deprecated, in der nächsten wurde es dann entfernt.
Ja, du kannst für das Update PHP 8.0 nutzen.
Das Flush ist das schon lange drin und soll dafür sorgen das Umbauten an den Tabellen sicher auf die Platte geschrieben werden. Das braucht es bei einigen Synchronisationen.
Ab PHP 8.1 wirft mysqli Exceptions - das war zu Zeiten von WE 9.1.x natürlich noch nicht bekannt....
Unsere aktuellen Versionen fangen den Fehler und machen unvermindert weiter.
