• Uff, nee, keine Chance. Alleine das Upgrade selbst auf der Console war an die gut 10 Minuten, also die automatisierten DB-Änderungen. Und dann wollte er eben noch utf8mb4 haben.

  • Jo, den anderen Krams habe ich auch noch gemacht, wie deprecated Folder und Files. Wegen DB Update auf utf8mb4 , keine 20 Sekunden. Und ich habe viele Webseiten. Auch hatte ich wärend des ganzen Prozesses htop auf. Auch wegen DB Upgrade ( meine jetzt nicht nur utf8mb4 ) Alles komplett in 2 Minuten gerockt. Aber der ist eh underfucked der Server.


    Ich habe immer noch kein CDN drauf bei Guten-Rutsch. Muss ich aber, aber das mache ich erst zum Schluss, bzw später-

    wenn etwas möglich erscheint mach ich das, wenn das nicht klappt gehts ans unmögliche und ansonsten das undenkbare.

    Ich denke, also BING ich!


    Support 24h Bereitschaft 0163 2161604 - NUR Für Kunden von SEO NW!

  • Was natürlich auch sein kann..... Was ist denn bei Dir unter "Datenbankfähigkeiten" mit dem "LOAD DATA INFILE". Ich bekomme das seit MariaDB nicht zum Laufen. Kann machen was ich will, der User hat keine Rechte, es zu nutzen. Bzw. behauptet das Matomo.


    Rechte hat der User schon, auch MySQL Zugrioffsrechte auf die Matomo-Gruppe. Ebenso ist "local-infile" in der Config aktiviert und "secure_file_priv" deaktiviert.

  • Irgendwas scheint an dem neuen Piwik nun aber anders zu sein, also am Tracker, denn nun wird der von "NoScript" überall blockiert. Also der Abruf der matomo.js geht noch, aber der Post der Daten dann nicht mehr, der wird abgefangen.

  • Es scheint wohl damit was zu tun zu haben:


    "setRequestMethod( method ) - Set the request method to either "GET" or "POST". (The default is "GET".) To use the POST request method, either 1) the Matomo host is the same as the tracked website host (Matomo installed in the same domain as your tracked website), or 2) if Matomo is not installed on the same host as your website, you need to enable CORS (Cross domain requests) as explained in this FAQ. When you force GET then it will automatically disable sendBeacon."


    Bisher war das in der Tat GET, nun ist es POST.

  • Und es scheint was mit der neuen "Evolution of page performance metrics" zu tun zu haben. Abgesehen davon, dass die Bezeichnung nicht übersetzt ist funktioniert just seit dessen Einführung die "durchschnittliche Generierungszeit" nicht mehr. Steht immer auf 0. Und diese steht in Zusammenhang mit dem "AlwaysUseSendBeacon" der seinerseits Abhängigkeiten zur RequestMethod POST hat.

  • So, ich habe nun die 4.1.x-dev-b1 drauf. Mich hat wohl ein Bug erwischt, der in der 4.0.3 war :( Heute Nacht waren die Tracker ausgefallen. Bzw. Tracking war noch da, aber die Archivierung nicht mehr. Die drehte sich im Kreis und erzählt mir was von


    Code
    INFO [2020-12-07 14:35:19] 20938 Will invalidate archived reports for today in site ID = 1’s timezone (2020-12-07 00:00:00).
    INFO [2020-12-07 14:35:19] 20938 Will invalidate archived reports for yesterday in site ID = 1’s timezone (2020-12-06 00:00:00).
    INFO [2020-12-07 14:35:20] 20938 Archived website id 1, period = day, date = 2020-12-06, segment = ‘’, 7 visits found. Time elapsed: 0.812s
    INFO [2020-12-07 14:35:11] 20938 Archived website id 1, period = week, date = 2020-11-30, segment = ‘’, 2349 visits found. Time elapsed: 2.424s

    .... Naja, heute ist halt nicht der 6.12. so weit ich weiß und die Woche begann nicht am 30.11.


    Die hatten wohl schon einen Bug-Fix für das "Will invalidate archived reports for" eingebaut, aber wohl eher erst in einer paar Stunden älteren Version 4.0.3. Meine drehte sich da im Kreis, konnte nicht fixen. Und nachdem dann heute auch noch eine neue Woche startete, ging nix mehr. Seit Mitternacht war es still.