Update 0.9.9 funktioniert nicht

schlrech

Der webserver funktioniert schon, ich kann da andere php aufrufen nur nicht die index.php

gr

Hallo,

schau bitte das hier: http://www.i-doit.org/forum/index.php/topic,1363.0/topicseen.html

Dort wird über Probleme mit der config-Datei nach Update 0.9.9 berichtet. Können Sie mal auch Ihre Config-Datie prüfen?

schlrech

Das hatte ich schon angeschaut und ich sehe nichts falsches in der config datei.
Habe diese auch gelöscht und dann kommt ja ein setup-Dialog hoch, alles eingetragen inkl. neuer DB dann erstellt es ja ne neue auch diese geprüft und nichts geht.

ds

Wie siehts mit PHP Fehlern im Apache Error Log aus ?

schlrech

keine weder im error noch im access

fearnop

Bei mir tritt exakt der selbe Fehler auf.

Selbst nach einem haendischem Anpassen der config.inc.php welche aus der "config_template.inc.php" ihren urpsrung hat, will es nicht funktonieren.

Resultat: weisse Seite - egal welches Modul/Seite ich aufrufe.

Keinerlei Error Meldungen - weder im PHP, noch im Webserver-Log an sich.

Vll hat es keinerlei Bedeutung, aber wenn ich die Zeile 71 in der Datei "globals.inc.php" auskommentiere, komme ich zumindestens (nach erfolgreichem Login) nochmal zur /updates" Seite, welche dann auch erneut erfolgreich funktioniert, aber leider in einer weissen Seite endet.

"$g_pdo_drivers = PDO::getAvailableDrivers();" –> //$g_pdo_drivers = PDO::getAvailableDrivers();

Lass ich diese Zeile unkommentiert,komme ich nichtmal auf die /updates Seite.

...ich bin am verzweifeln...

gr

PDO::getAvailableDrivers() ist ein interner Funktion seit PHP 5.1 und kann ich mir nicht vorstellen wieso das nicht läuft, außer Sie benutzen PHP < 5.1

Das 2. Problem mit Config.inc.php: in index.php ab Zeile 137 gibt es so etwas:

/**

Initialize framework
*/
if(file_exists("src/config.inc.php") && include_once("src/config.inc.php"))
{
…

} else {
if(!require_once("setup/install.inc.php")) {
startup_die("Could not start installer. Setup files not found.");
}
}

Existiert die config-Datei nicht und kann die Datei nicht inkludiert, so wird es weiter mit install/update gemacht. Prüfe mal bitte die Datei-Rechte. Wenn Rechte Okay, dann ist vielleicht die Datei zerstört.

fearnop

…wenn ich die Datei config Datei verschiebe, lande ich in der Installationsroutine, wie es sich gehoert.

Wenn ich den o.g. Wert auskommentiere und auf die Startseite gehe, komme ich zu dem Loginprompt.. nur nach dem Login, erscheint folgende Meldung:

isys_exception_database : Query error: 'SELECT isys_catg_logb_list__isys_obj__id FROM isys_catg_logb_list JOIN isys_logbook ON isys_catg_logb_list__isys_logbook__id = '93'': Unknown column 'isys_catg_logb_list__isys_obj__id' in 'field list'

Dies deutet doch auf eine nicht geupdatete Mandanten-DB hin, wenn ich das recht verstanden habe, oder? Unverstaendlich waere auch dies, da ich diese bei update-prozedur explizit angab!

fearnop

Also da scheint grundsaetzlich etwas nicht zu stimmen…habe eben testweise alle Datenbanken sowie Verzeichnisse geloescht - also eine frische Installation... Ergebnis:

Weisse Seite, nach erfolgreicher Installation.

gr

So sieht bei mir die Tab isys_catg_logb_list aus:

CREATE TABLE isys_catg_logb_list (
isys_catg_logb_list__id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
isys_catg_logb_list__isys_logbook__id INT(10) UNSIGNED NOT NULL DEFAULT '0',
isys_catg_logb_list__status INT(10) UNSIGNED DEFAULT '2',
isys_catg_logb_list__property INT(10) UNSIGNED DEFAULT '0',
isys_catg_logb_list__title VARCHAR(255) COLLATE utf8_unicode_ci DEFAULT NULL,
isys_catg_logb_list__description TEXT COLLATE utf8_unicode_ci,
isys_catg_logb_list__isys_obj__id INT(10) UNSIGNED DEFAULT NULL,
PRIMARY KEY (isys_catg_logb_list__id),
KEY isys_catg_logb_list_FKIndex2 (isys_catg_logb_list__isys_logbook__id),
KEY isys_catg_logb_list__isys_obj__id (isys_catg_logb_list__isys_obj__id),
CONSTRAINT isys_catg_logb_list_ibfk_2 FOREIGN KEY (isys_catg_logb_list__isys_logbook__id) REFERENCES isys_logbook (isys_logbook__id) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT isys_catg_logb_list_ibfk_3 FOREIGN KEY (isys_catg_logb_list__isys_obj__id) REFERENCES isys_obj (isys_obj__id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=INNODB AUTO_INCREMENT=361 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

"isys_catg_logb_list__isys_obj__id" ist in meine Installetion vorhanden.

Ich habe auch die alten Versionen von Idoit untersucht und kann ich nicht nachvollziehen wieso das Feld bei Ihnen fehlt.

Können Sie uns sagen welche Version von I-doit Sie verwendet haben oder wie kommen Sie zur Version 0.9.9?

fearnop

Ich kam von Version 0.9.8-3

fearnop

Ich bekomme immer nur die selbe Debugmeldung:

(8.03@22:02:39) Notice : –----------------------------------------------------------------------
(8.03@22:02:39) Notice : ENTRYPOINT OF FRONT CONTROLLER (load=update): Debugger initialized.
(8.03@22:02:39) [!] Error : No method to autoload 'PDO'
Backtrace:
#0 _get_backtrace() called at [/var/www/cmdb.cst/idoit/src/debug.inc.php:133]
#1 isys_debugger_handler_default_error::execute(No method to autoload 'PDO') called at [/var/www/cmdb.cst/idoit/src/debug.inc.php:216]
#2 isys_debugger::handle(4, No method to autoload 'PDO') called at [/var/www/cmdb.cst/idoit/src/autoload.inc.php:202]
#3 __autoload(PDO) called at [/var/www/cmdb.cst/idoit/src/globals.inc.php:71]
#4 include_once(/var/www/cmdb.cst/idoit/src/globals.inc.php) called at [/var/www/cmdb.cst/idoit/index.php:163]

(8.03@22:02:40) Notice : –----------------------------------------------------------------------
(8.03@22:02:40) Notice : ENTRYPOINT OF FRONT CONTROLLER (load=update): Debugger initialized.
(8.03@22:02:40) [!] Error : No method to autoload 'PDO'
Backtrace:
#0 _get_backtrace() called at [/var/www/cmdb.cst/idoit/src/debug.inc.php:133]
#1 isys_debugger_handler_default_error::execute(No method to autoload 'PDO') called at [/var/www/cmdb.cst/idoit/src/debug.inc.php:216]
#2 isys_debugger::handle(4, No method to autoload 'PDO') called at [/var/www/cmdb.cst/idoit/src/autoload.inc.php:202]
#3 __autoload(PDO) called at [/var/www/cmdb.cst/idoit/src/globals.inc.php:71]
#4 include_once(/var/www/cmdb.cst/idoit/src/globals.inc.php) called at [/var/www/cmdb.cst/idoit/index.php:163]

fearnop

OK, die Applikation funktioniert nun wieder.
Der Fehler lag im fehlenden Modul von PHP.

i-doit nutzt mit dieser Version scheinbar die PDO API welche nicht mit einkompiliert bzw. die USE Flags fuer PHP nicht gesetzt waren, da vorher einfach nicht benoetigt.

Schade das keine Abfrage Seitens i-doit gemacht wird ob diese Funktion/API vorhanden ist…haette eine Menge Aerger erspart.

Dennoch Danke fuer die nette Unterstuetzung

Sadmin

Hallo,

habe das gleiche Problem und deshalb steige ich mal in den Thread ein.
Wie kann man denn die PDO API einkompilieren bzw. die USE Flags für PHP setzen?

mfg Sadmin

ds

Kommt auf dein Betriebssystem an und dein PHP Package an. In den meisten Fällen reicht es aber PDO einfach in der php.ini zu aktivieren. Kompilierung ist also nicht unbedingt erforderlich

Sadmin

Danke für deine schnelle Antwort.

Betriebssystem ist Windows 2003 Server und PHP Package ist v5.
Kann in der php.ini keinen Punkt "PDO" finden.

Sadmin

Habe die Anleitung von hier befolgt.
Habe den Server und alle für den Webserver und die DB nötigen Dienste neu gestartet.
Was kann man noch versuchen?

ds

extension=php_pdo.dll
extension=php_pdo_mysql.dll

In die php.ini. Vorher Überprüfen ob die Dateien auch im /php/ext/ (Extensions Dir) liegen. Dann alles neustarten

Sadmin

Habe ich alles schon versucht. Hilft nichts.

fearnop

Bei mir ist das komplilieren von Noeten gewesen, da ich Gentoo Linux benutze und das USE Flag fuer PDO default nicht gesetzt ist im PHP Package…daher ging leider einiges in die Hose, wie ich ja beschrieben hatte. Fuer die meisten anderen Distributionen wie RedHat, Suse, Debian und Co, duerfte das keine grosse Relevanz haben, da sie quasi von Werk aus alle gaengigsten Erweiterungen von PHP einkompiliert haben, was aber keine Devise von Gentoo ist. Weniger ist mehr. Insbesondere hinsichtlich Sicherheit.