Hellihello Christoph,
Probieren wirs mal: gib deiner /etc/php.ini einen anderen Namen oder verschiebe sie in ein temporäres Verzeichnis (wer weiß, vielleicht brauchst du irgendeine Einstellung nochmal und möchtest sie nachlesen). Danach legst du in /etc ganz einfach einen Systemlink auf /etc/php5/php.ini an, den du wieder php.ini nennst.
Die Sache mit den Systemlinks ist in Linux-Kisten schon was Feines.
tatich jetzt:
-rw-r--r-- 2 root root 128 Sep 27 21:58 php.ini
ist mit ln php5/php.ini php.ini eingerichtet. Warum da kein "l" an erster Stelle steht und nicht so ein schöner Pfeil (->php5/php.ini) versteh ich immer noch nicht, macht aber nischt, denn mit cat php.ini wir dann der Inhalt von php5/php.ini angezeigt.
Nach /etc/initi.d/apache2 restart bleibt die Funktion json_encode() aber unbekannt (das Skript läuft bei mir auf dem Rechner, seitdem ich hier auf 5.2.4 geupdatet hatte).
Und in der php5/php.ini steht nach wie vor:
include_path=".:/usr/share/php"
output_buffering=On
extension_dir = /usr/lib/php/extensions
extension=json.so
;safe_mode=off
stell ich den safe_mode auf on, wird das auch in der phpinfo() so angezeigt.
Komisch ist doch, das in /usr/lib/php/extensions massig *.so drinne stehen:
. calendar.so dbx.so ftp.so iconv.so mbstring.so mime_magic.so shmop.so sysvsem.so xslt.so
.. ctype.so domxml.so gd.so imap.so mcal.so mysql.so snmp.so sysvshm.so yp.so
bcmath.so curl.so exif.so gettext.so json.so mcrypt.so pgsql.so sockets.so unixODBC.so zlib.so
bz2.so dbase.so filepro.so gmp.so ldap.so mhash.so session.so swf.so wddx.so
darunter mittlerweile auch "meine" json.so. Aber scheinbar werden die ja alle garnicht eingebgunden, oder wie könnte ich das testen? Welche Funktion hängt denn von calender.so oder sonsteiner ab, die ich aufrufen könnte um damit zu schauen, ob diese extension wirklich eingebunden ist. Ah ich sehe die gd.so und, aber mit Datum September 2005, obwohl ich php erst letzlich -with gd-lib (oder so ähnlich) kompiliert hatte.
Dank und Gruß,
frankx