Styx 3.4-alpha2 und PHP 8.0.3

Das ist nicht wirklich möglich - hagelnde Fehler wären dann auch schon bei 8.0.0 und 8.0.1 aufgetreten. Das sind nur Minor PHP 8 Versionen die Bugs fixen. Ich bin schon seit 2 Monaten auf PHP 8.0.3 und gerade eben auf 8.0.5 umgestiegen. Und ich finde nur noch sehr vereinzelt irgendwelche warnings, geschweige denn Fehler.

Es wäre also gut wenn du das noch mal anstellst und ich mir das ansehen kann. Und gerne auch hier behandeln, denn das mit den neuen Styx discussions betrifft dich gar nicht, so du doch eine so schicke Testinstallation hast.

Ich nehme mal an es hätte einfach einen ordentlichen Seitenreload gebraucht.

Doch wahrscheinlich hängt das (auch?) mit dem Nginx Proxy zusammen, der müsste dann mit der neuen Konfiguration ersteinmal vollständig durchgeladen werden.

In eingeloggtem Zustand kann ich nicht in einem zweiten Fenster kommentieren. Ich erhalte die Error-Page mit folgendem Hinweis:

Warning: Undefined array key "phone" in /plugins/serendipity_event_spamblock_bee/serendipity_event_spamblock_bee.php: 411.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.

Nach dem Speichern des letzten Kommentars erhielt ich folgende Anzeige:

Fatal error: Uncaught Error: Call to undefined function opcache_get_status() in /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/AdapterOpCache.php:36 Stack trace: #0 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/Cache.php(255): voku\cache\AdapterOpCache->__construct(Object(Closure)) #1 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/Cache.php(161): voku\cache\Cache->autoConnectToAvailableCacheSystem(Object(voku\cache\CacheAdapterAutoManager), false) #2 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions.inc.php(1579): voku\cache\Cache->__construct(NULL, NULL, false, true, false, false, false, false, '', Object(voku\cache\CacheAdapterAutoManager), false) #3 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions.inc.php(1585): serendipity_setupCache() #4 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions_comments.inc.php(926): serendipity_cleanCache() #5 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions_comments.inc.php(1115): serendipity_approveComment(7830, '2657', true) #6 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions_comments.inc.php(1253): serendipity_insertComment('2657', Array, 'NORMAL', 'internal', Array) #7 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions_routing.inc.php(428): serendipity_saveComment('2657', Array, 'NORMAL') #8 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/index.php(81): serveEntry(Array) #9 {main} thrown in /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/bundled-libs/voku/simple-cache/src/voku/cache/AdapterOpCache.php on line 36

Kann ich später ja wieder löschen (wegen den vollen Pfadangaben).

Das routing warning war nur oben (angemerkt *) und hatte mit dem cache Fehler Zeug (rechts) nichts zu tun.

* Ebenso wie das subscribe warning ebenda in routing Zeile 426, Das habe ich gerade auf Styx gefixt.

Der voku cache Fehler tritt aber auch auf wenn man im Frontend einen Kommentar sendet und verweist in seiner (#x) Stack trace Liste dann aber auf kein Seitenleisten cache file. Insofern ist da vielleicht noch etwa zu machen. Komisch ist nur dass ich lokal bei mir mit allem was an internen debugging Einstellungen möglich ist, bisher solches überhaupt nicht nachstellen kann. Und die sind viel schärfer als deine dev Version.

Das zeigt nur dass sie komplett nicht verstanden haben. Das sind Support Mitarbeiter, (meist) keine Admins. (Sie sollen aber den Admins den Rücken freihalten.) Man muss ihnen sehr genau erklären dass sie es (trotzdem) weiterzugeben haben an jemanden, der damit etwas anzufangen weiß. Denn phpinfo() Einstellungen verweisen auf PHP Server Einstellungen und sind meist nur dort sinnvoll zu verändern, vorallem wenn es sich um disabled functions dreht, die durchaus hinterfragbar sind. Die

opcache_get_status

Funktion ist ja gerade dafür gedacht herauszufinden ob man opcache überhaupt verwenden kann. Sonst macht das aktivieren der library ja auch gar keinen Sinn, meine ich.

Ok .. Ich sehe das war noch nicht durchdacht genug.

Probiere es mal damit (kompletter Ersatz)

$opcache = function_exists('opcache_get_status')) ? true : false;

use voku\cache\Cache;
// Configure voku/simple-cache to use templates_c as directory for the opcache files, the fallback
// when Memcached and Redis are not used. Returns the configured cache object. Used internally by
// the other cache functions, you most likely never need to call this.
function serendipity_setupCache() {
    global $opcache;
    if ($opcache === false) {
        return $opcache;
    }
    $cacheManager = new \voku\cache\CacheAdapterAutoManager();
    $cacheManager->addAdapter(
        \voku\cache\AdapterOpCache::class,
        static function () {
            global $serendipity;
            $cacheDir = $serendipity['serendipityPath'] . '/templates_c/simple_cache';

            return $cacheDir;
        }
    );

    $cacheManager->addAdapter(
        \voku\cache\AdapterArray::class
    );

    $cache = new Cache(
        null,
        null,
        false,
        true,
        false,
        false,
        false,
        false,
        '',
        $cacheManager,
        false
    );
    return $cache;
}

function serendipity_cleanCache() {
    global $opcache;
    if ($opcache === false) {
        return $opcache;
    }
    $cache = serendipity_setupCache();
    return $cache->removeAll();
}

function serendipity_cacheItem($key, $item, $ttl = 3600) {
    global $opcache;
    if ($opcache === false) {
        return $opcache;
    }
    $cache = serendipity_setupCache();
    return $cache->setItem($key, $item, $ttl);
}

function serendipity_getCacheItem($key) {
    global $opcache;
    if ($opcache === false) {
        return $opcache;
    }
    $cache = serendipity_setupCache();
    return $cache->getItem($key);
}

define('serendipity_FUNCTIONS_LOADED', true);
/* vim: set sts=4 ts=4 expandtab : */

Edit: Nachgebessert und global eingefügt, sorry!
Edit2: Schließende Klammern eingefügt

Seit dem Update erhalte ich keine E-Mail-Benachrichtigungen mehr

Seit welchem update, den drei Dateien oder seit 3.4-alpha2 ?

Nachtrag: Laut auftretender Fehlermeldung hast du die functions_comments.inc doch noch nicht upgedated. Das ergibt header already sent Fehler die möglicherweise das email versenden verhindern.

Aber eine solche ohne .inc gibts gar nicht...?

Das wäre natürlich blöd wenn PHP 8 irgend etwas am Mailversandt abstellen würde. Vorerst müssen wir uns aber auf all die kleinen Fehler konzentrieren, die dann einfach eine runtime Unterbrechung darstellen und womögliche Folgefehler provozieren.

Test mit der neuen functions_comments.inc.php

Oh Danke! committet.