Installation bei all-inkl.com klappt nicht
Eingetragen von phnad (67)am 02.09.2008 - 07:44 Uhr in
Auf meinem all-inkl.com-Shared-Hosting-Account laufen derzeit mehrere Drupal-5.x- und eine Drupal-6.0-Installation. Die Installationen haben da anstandslos geklappt.
Nun wollte ich unter einer neuen Domain (Inklusivdomain als Unteraccount im KAS) die aktuelle Version 6.4 installieren. Standardmäßig läuft bei mir PHP 4.4.8. Habe also noch vor dem Installationsskriptaufruf in der .htaccess folgendes hinzugefügt (so soll ich das laut all-inkl.com machen):
AddHandler php5-cgi .php
Daraufhin hat sich Drupal dann während der Installation beschwert, dass register_globals aktiviert sei (was laut phpinfo auch der Fall war). Also habe ich in der .htaccess (ebenfalls laut all-inkl.com) folgendes hinzugefügt:
php_flag register_globals off
Das hat Drupal aber nicht interessiert und die Fehlermeldung blieb: ich müsse register_globals deaktivieren. Hier ging die Installation nicht weiter.
Wenn ich nun aber gar nicht erst in der .htaccess auf PHP 5 schalte (also gar keine Änderung in der .htaccess-Datei vornehme), dann komme ich anstandslos durch. Es wird sich nicht über register_globals beschwert und ich soll Namen und Passwort der Datenbank angeben. Sobald ich das dann bestätige erscheint folgende Meldung:
- user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM drupal_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in /www/htdocs/w00a0321/includes/menu.inc on line 315.
- user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM drupal_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in /www/htdocs/w00a0321/includes/menu.inc on line 315.
Kann mir jemand weiterhelfen?
Liegen die MySQL-Warnungen nun daran, dass der Server auf PHP 4 lief? Warum wird bei aktiviertem PHP 5 meine Änderung der register_globals anscheinend nicht akzeptiert? Und warum wird bei PHP 4 das aktivierte register_globals gar nicht angekreidet? Hat sich was bzgl. der Installation zwischen 6.0 und 6.4 geändert? (denn eine 6.0'er läuft bei mir ja).
... wollte mal eben schnell Drupal installieren (wie ich es bisher auch immer gewohnt war) aber nichts ist ... hänge da nun schon 2 Stunden dran) :/
NACHTRAG
Habe es gerade noch mal unter einer anderen Domain (selber Server) mit der aktuellen Version versucht. Und da hat's direkt geklappt: und sogar ohne eine Änderung der .htaccess - also mit PHP 4.4.8 und register_globals ON. Habe bei beiden Unteraccounts mal die infophp.php-Ausgabe verglichen und die sind zumindest am Anfang alle identisch. Falls ich da was konkretes vergleichen soll, bitte melden. Falls es von Bedeutung ist: bei der funktionierenden Installation habe ich es in einem Unterordner installiert, bei der gescheiterten Installation im ROOT. Könnte das die Ursache sein?
- Anmelden oder Registrieren um Kommentare zu schreiben
Gleiches Problem auch im Unterordner
am 02.09.2008 - 20:54 Uhr
So, habe es nun unter der gewünschten Domain mal im Unterordner statt im Root-Verzeichnis probiert, aber da habe ich das gleiche Problem.
Möchte so gerne loslegen *grummel*
NACHTRAG
Habe jetzt mal auf diesem Server alles von Drupal gelöscht und nur eine selbsterstellte .htaccess sowie eine infophp.php hochgeladen.
Wenn ich nur "php_flag register_globals off" eingebe, zeigt mir infophp.php an, dass register_globals (local value) deaktiviert ist. Wenn ich aber nun "AddHandler php5-cgi .php" hinzufüge, ist register_globals wieder auf On.
Antwort des Supports
am 02.09.2008 - 23:43 Uhr
bzgl. register_globals off während ich PHP 5 aktiviert habe:
im cgi Modus können Sie keinen Änderungen per php_flag in der .htaccess einstellen.
Nun besteht die Möglichkeit, auf einen PHP-5-Server umzuziehen (wo ich dann register_globals wieder deaktivieren könne). Allerdings weiß ich noch nicht, ob ich das wirklich machen möchte, denn es sind viele verschiedene CMS installiert - hab bissl Angst, dass manches dann nichts mehr funktioniert.
PROBLEM GELÖST!
am 03.09.2008 - 05:50 Uhr
Hier hat ein User genau das gleiche Problem: http://www.drupalcenter.de/node/7262#comment-30204
Ist schon was älter, keine Ahnung ob er es mittlerweile gelöst hat?
Jemand vllt. einen Tipp?
Ich bin seit 6 Stunden und 30 Minuten mit dem all-inkl.com-Support in Mail-Kontakt: Hut ab! Leider bisher ohne Erfolg :/
UPDATE: Problem gelöst
Der Support hat mir nun doch indirekt den springenden Tipp gegeben (Danke, all-inkl.com!)
Ich fass' es nicht. Wenn ich mich nicht gerade so sehr auf Drupal freuen würde, würde ich nun noch mehr verzweifeln als bei dem Problem selbst ;-)
Kann das bitte jemand an die Verantwortlichen in höflich weiterleiten?
Liebes Drupal-Team,
wie wäre es mit Fehlermeldungen, aus denen man schließen kann, dass nicht der Provider oder die Illuminaten Schuld haben, sondern man es mit einem verdammten Layer-8-Problem zu tun hat?
Sobald man bei der Database configuration Datenbankname, Username und Passwort eingibt werden schön brav all die Tabellen in der Datenbank erstellt. Aber man wird nicht etwa mit einer lauffähigen Drupal-Installation belohnt, nein, nein, sondern mit MySQL-Warnungen. Kryptischen. Schönen. Und zwar "Warnungen", die eine unüberquerbare Mauer darstellen, und denen selbst der all-inkl.com-Support nicht gewachsen ist. Geschweige denn phnad. "Es ist was Grausiges, Schlechtes, Gefährliches, Schlimmes passiert!" lächelt mich die Fehlermeldung an. Klar, macht schon Eindruck, zugegeben. Aber manchmal tut es auch einfach ein: "Bitte lassen Sie Cookies zu"
Warum verflixt nochmal will Drupal eigentlich an dieser Stelle ein Cookie haben? Es geht da ja wohl um die nächste Seite (die nach den Datenbank-Informationen), denn schließlich wird die Datenbank korrekt erstellt. Warum oberverflixt nochmal wird diese Seite nicht einfach angezeigt und versagt einem erst dann beim Abschicken den Zugang in die weite, schöne Drupal-Welt? Macht natürlich schon Sinn (also das Cookie da), so stell ich mir das zumindest vor: Drupal will da sicher gehen, dass derjenige, der die Datenbankeinstellungen vornimmt, auch derjenige ist, der das Admin-Konto anlegt (und niemand dazwischenfunkt). Hat sich phnad das so richtig zusammengereimt? Das erklärt zwar nicht, warum der Fehler nicht erst da auftritt, wo es ans Eingemachte geht (oder schon da, bevor es überhaupt beginnt), aber was viel ja schlimmer ist: WARUM ... ja genau:
Besteht Hoffnung, dass zukünftige Tröten davor bewahrt werden, indem man einfach am Anfang der Installation checkt, ob Cookies aktiviert sind und dies ggf. visuell und verständlich ankreidet? Nennt's von mir aus den phnad-Check oder so ...
Wie jetzt SCherz oder was?
am 03.09.2008 - 05:51 Uhr
Wie jetzt SCherz oder was? Cookies is doch normal, dass man die aktiviert hat.
----------------------------------------
Alle Angaben ohne Gewähr!!:D
http://www.tobiasbaehr.de/
phnad schrieb UPDATE:
am 31.10.2008 - 01:14 Uhr
UPDATE: Problem gelöst
Der Support hat mir nun doch indirekt den springenden Tipp gegeben (Danke, all-inkl.com!)
Könntest Du den Tipp von all-inkl auch verraten?
dg, darktiger
darktiger schrieb Könntest
am 31.10.2008 - 17:34 Uhr
Könntest Du den Tipp von all-inkl auch verraten?
Steht doch im selben Beitrag, woraus du auch zitiert hast:
hatte für die Domain, unter der ich installierte, keine Cookies zugelassen. Aber Drupal kam nicht auf die Idee, das anzukreiden - hat aber trotzdem den Spielverderber gespielt.
Na ja, es steht was von
am 31.10.2008 - 18:04 Uhr
Na ja, es steht was von Layer-8 Problemen, getätigten Datenbankeinträgen und Cookies drin.
Es hätte ja sein können, dass da noch mehr verraten wurde als die Cookies anzuschalten...
dg, darktiger