update auf TL 2.7.3 - Seite weg

[peter64]

Das update habe ich, wie immer, manuell vorgenommen. Nun habe ich zum ersten mal Probleme. Meine Seite ist im Frontend nicht mehr sichtbar. Auch die Vorschau aus dem Backend funktioniert nicht.
Es wird eine Fehlermeldung im Vorschaufenster angezeigt:
Fatal error: Call to undefined function unixtojd() in /srv/www/vhosts/xxx.de/httpdocs/system/modules/calendar/Calendar.php on line 372

Zum manuellen update möchte ich noch anfügen, dass ich als eine Variante auch alles gelöscht und neu hochgeladen habe.

Kann der o.a. Fehler dazu führen, dass die Seite gar nicht mehr angezeigt wird?

Gruß Peter

[do_while]

Hallo peter64,

schalte mal im Backend in den Einstellungen die Fehleranzeige ein und schaue noch einmal auf das Frontend. Meist kommt da dann die Fehlermeldung die Aufschluß über die Ursache gibt.

Den Fehler, den Du gepostet hast, kenne ich noch nicht. Hast Du evtl. eine zu alte PHP-Version?

[peter64]

Hallo Hagen,

die Fehleranzeige hatte ich eingeschaltet. Im Frontend kommt genau die selbe, mehr nicht.

Die php-Version ist state of the art. Mit Vers. 2.7.2 ging bis gestern ja noch alles.

Ich werde morgen mal versuchen, ob der Fehler jetzt auch mit der alten Vers. 2.7.2 auftritt. Aber ich habe im Vergleich gesehen, dass die Calendar.php in 2.7.3 geändert wurde.

Gruß Peter

[Stephan]

Hallo Peter,

das einzige, was mir noch spontan zu dem Fehler einfällt, ist das Fehlen der Calendar Funktion in deiner PHP-Version. Schau mal mittels phpinfo(), ob dort der Calendar support auf enabled steht.

[andreas.schempp]

Ich denke hier ist leo ein kleiner Fehler unterlaufen als er die Funktion eingesetzt hat... da wird eine PHP-Funktion eingesetzt, welche nicht zum PHP-Core gehört. Das sollte wohl besser nicht so sein.

[leo]

Ich denke hier ist leo ein kleiner Fehler unterlaufen als er die Funktion eingesetzt hat... da wird eine PHP-Funktion eingesetzt, welche nicht zum PHP-Core gehört. Das sollte wohl besser nicht so sein.

Ja, das stimmt leider. Die Erweiterung gehört zwar sehr wohl zum PHP-Core, allerdings muss PHP mit --enable-calendar kompiliert sein. Die Frage ist nun, ob es eine gute Alternative dazu gibt oder ob wir die Systemvoraussetzungen entsprechend anpassen.

[andreas.schempp]

Ich weis nicht wozu die Funktion verwendet wird, aber ich würde auf keinen Fall eine nichst-Standardkomponenten von PHP als zwingend voraussetzen...

[leo]

Manche Funktionen braucht man halt einfach, um gewissen Aufgaben zu erledigen. Sonst gäbe es ja nicht 100 zusätzliche Module und Erweiterungen. Die Kalender-Funktionen gehören zum PHP-Core, man muss sie nur beim Kompilieren einschalten. Dasselbe gilt aber auch für die MySQL-Funktionen, die man Deiner Aussage nach dann auch nicht verwenden dürfte

[leo]

Hier mal ein kleiner Auszug, damit Du siehst, was alles einkompiliert werden kann/muss:

--enable-gd-native-ttf
--enable-gd-imgstrttf
--with-zlib=yes
--with-bz2
--with-dom
--with-ttf
--with-imap
--with-ftp
--with-gettext
--enable-bcmath
--enable-trans-sid
--enable-inline-optimization
--enable-track-vars
--enable-magic-quotes
--enable-safe-mode
--enable-sockets
--enable-calendar
--enable-mbstring
--enable-mbstr-enc-trans
--enable-ftp
--enable-memory-limit
--enable-dbase
--enable-ctype

Wenn ich alle diese Funktionen nicht als Systemvoraussetzung voraussetzen dürfte, dann könnte man überhaupt keine ordentliche Applikation mehr schreiben.

[Nina]

Es wäre vielleicht ganz hilfreich, wenn du die Liste der benötigten Funktionen auf die Seite mit den Systemanforderungen einfügst (sofern der Aufwand des Zusammenstellens überschaubar ist).

Dann könnten die Leute diese Liste vorab an ihren Provider schicken und nachfragen ob diese Dinge kompiliert sind.

[andreas.schempp]

Nun die meisten gehören zum Standard, der Calendar eher nicht, oder? Nur sehr wenige Provider werden eine neue PHP-Version kompilieren weil ich TYPOlight benutzen will

[leo]

Ok, also noch mal: auch die Calendar-Funktionen gehören zum Standard! Ob sie jedoch verfügbar sind, hängt davon ab, ob sie beim Kompilieren aktiviert wurden (genau wie all die anderen genannten Funktionen).

Ein Shared-Hosting-Anbieter sollte normalerweise von einem "allow all"-Ansatz ausgehen und alle PHP Core-Features aktivieren, die kein Sicherheitsrisiko darstellen. Ich habe jedenfalls weder auf unseren, noch auf den externen Servern, auf denen ich Accounts habe, ein System ohne --enable-calendar gefunden. Daher gehe ich davon aus, dass nur wenige Nutzer betroffen sind.

[andreas.schempp]

Da hast du wohl recht. Habe gerade bei Metanet - einem der grössten der Schweiz - geschaut, da ist es auch aktiv.

[ATLAS]

Ich glaube es kommt darauf an, wo man hinschaut. Die Massenhoster haben oft nicht alles dabei. Aber auch die Rootanbieter haben nicht alles mit an Bord. Und mit den Verwaltungstools, z.B. Plesk oder Confix, sollte man ein Neu-Kompilieren von php tunlichst vermeiden.

Bei mir läuft bis jetzt alles. Ich füge aber mal zur Info meine aktuelle Konfiguration anbei. Sie ist wohlgemerkt fast unverändert und so, als wenn man morgen bei Strato einen Root mit Plesk bestellen würde, was auch jede Menge Leute tun. Manchmal helfen ja solche Informationen.

Configure Command

'../configure' '--prefix=/usr' '--datadir=/usr/share/php5' '--mandir=/usr/share/man' '--with-libdir=lib' '--includedir=/usr/include' '--sysconfdir=/etc/php5/fastcgi' '--with-config-file-path=/etc/php5/fastcgi' '--with-config-file-scan-dir=/etc/php5/conf.d' '--enable-libxml' '--enable-session' '--with-mm' '--with-pcre-regex=/usr' '--enable-xml' '--enable-simplexml' '--enable-spl' '--enable-filter' '--disable-debug' '--enable-inline-optimization' '--disable-rpath' '--disable-static' '--enable-shared' '--program-suffix=5' '--with-pic' '--with-gnu-ld' '--with-system-tzdata=/usr/share/zoneinfo' '--enable-force-cgi-redirect' '--disable-discard-path' '--enable-fastcgi' '--bindir=/usr/bin' '--disable-cli' '--disable-all'

additional .ini files parsed

etc/php5/conf.d/ctype.ini, /etc/php5/conf.d/curl.ini, /etc/php5/conf.d/dom.ini, /etc/php5/conf.d/exif.ini, /etc/php5/conf.d/ftp.ini, /etc/php5/conf.d/gd.ini, /etc/php5/conf.d/gettext.ini, /etc/php5/conf.d/hash.ini, /etc/php5/conf.d/iconv.ini, /etc/php5/conf.d/imap.ini, /etc/php5/conf.d/ioncube-loader-5.2.ini, /etc/php5/conf.d/json.ini, /etc/php5/conf.d/mbstring.ini, /etc/php5/conf.d/mcrypt.ini, /etc/php5/conf.d/mysql.ini, /etc/php5/conf.d/mysqli.ini, /etc/php5/conf.d/openssl.ini, /etc/php5/conf.d/pdo.ini, /etc/php5/conf.d/pdo_mysql.ini, /etc/php5/conf.d/pdo_pgsql.ini, /etc/php5/conf.d/pdo_sqlite.ini, /etc/php5/conf.d/pgsql.ini, /etc/php5/conf.d/soap.ini, /etc/php5/conf.d/sqlite.ini, /etc/php5/conf.d/tokenizer.ini, /etc/php5/conf.d/xmlreader.ini, /etc/php5/conf.d/xmlwriter.ini, /etc/php5/conf.d/xsl.ini, /etc/php5/conf.d/zlib.ini

[do_while]

Hallo,

ich fände es schade, wenn wir wegen einer solchen Kleinigkeit die Vorraussetzungen erhöhen müssen und dadurch doch in einigen Installationen Probleme bekommen, die wieder ein "TYPOlight läuft nicht" auslösen.

Kann man diese Funktion nicht anders lösen? Ich habe mir noch nicht angesehen, wo und wie unixtojd() verwendet wird aber bisher ging es doch auch ohne.