Gelöst:Template Vorkonfiguration spinnt bei zwei Datenbanken

[Faar]

Hi,
ich habe ein seltsames Problem nach einem Serverumzug: Ein Template zeigt in der Vorkonfiguration ab einem bestimmten Modul nur noch dieses Modul in allen folgenden Container-Plätzen an.
Dort sollten aber andere Module enthalten sein.
Nehme ich dieses Modul raus, erscheinen auch alle anderen Module korrekt eingebunden.
Binde ich das betreffende Modul wieder ein, ist der gleiche Fehler wieder da.

Das Modul beinhaltet eine eigene Datenbank-Verbindung und ich musste dort fest einprogrammierte Pfade ändern.
Das Modul funktioniert insoweit aber das Template nicht, in dem dieses Modul eingebunden ist.

Weiß jemand, wo ich suchen müsste?

VG,
Faar

[Spider IT]

Hallo Faar,

schau dir mal das errorlog genau an, da müssten Fehlermeldungen enthalten sein zu dem Modul.
Ich hatte mal ein ähnliches Problem, welches durch ein fehlendes cInclude() verursacht wurde.
Die Template-Konfiguration zeigt davon nichts, die Fehlermeldung steht dann im errorlog.

Gruß
René

[Faar]

Hi Renè!
Dort stehen überwiegend folgende Meldungen:

next_record called with no query pending in Module ID 57.

MySQL error 1146: Table 'xxx.con_mod_translations' doesn't exist

Aber zwischendrin war mal auch diese:

Table 'xxx.con_mod' doesn't exist

... sieht aus, als ob nicht alle Daten vor dem Umzug gesichert wurden, sonst würden die nicht fehlen?

[Faar]

Mir ist gerade etwas aufgefallen:

MySQL error 1146: Table 'db_2.con_mod_translations' doesn't exist greift auf die Datenbank 2 zu, wobei die con_mod_translations in der db_1 wohl vorhanden ist aber nicht in der db_2.

Ich schrieb im ersten Thread ja, dass im Modul eine neue Datenbank-Verbindung aufgemacht wird.
Durch den Serverumzug sind die Datenbank-Verbundungsdaten anders: Host, DB_user und db_password sind bei db_1 und db_2 identisch.

Sieht mir danach aus, dass die Contenido-DB-Verbindung zur Datenbank 1 durch die neue im Modul ersetzt wird und alle nachfolgenden DB-Verbindungen auf die Datenbank 2 zugreifen wollen, wo natürlich nicht die passenden Daten sind.
Demnach müsste ich die DB-Verbindung im Modul so umbauen, dass sie die Datenbank-Verbindung von Contenido (mysql_connect() ) nimmt und bei mysql_select_db($db2 , $contenido) eben diese Contenido-Verbindung eingesetzt wird.

Renè, weißt du zufällig die DB-Verbindung von Contenido?
Was muss ich in mysql_select_db() rein schreiben?

[Faar]

Hier, ich habe wohl das gleiche Problem:
Neue Datenbank Verbindung schlägt fehl: http://forum.contenido.org/viewtopic.php?f=60&t=32150

Auf dem alten Server hatte das funktioniert aber auf dem neuen nicht mehr.
Wie xmurrix schreibt, muss ich eine neue Klasse schreiben die die db_contenido erweitert. *freu*

Ich vermute mal ganz vorsichtig, dass das das Problem mit dem Template und den restlichen Modulen verursacht.

Das kommt davon, wenn man fremde Projekte übernimmt...

[Spider IT]

Mir fällt dazu ein, dass ich ein ähnliches Problem auch schon hatte.
Bei der Modulkonfiguration gibt es wohl ein Problem, dass auf die zuletzt geöffnete Datenbank zugegriffen wird.
Ich konnte das dadurch lösen, dass ich am Ende meines Moduls die neu geöffnete Verbindung wieder geschlossen habe, danach hat Contenido dann wieder die eigene Verbindung für die weiteren Modulen genutzt.

Gruß
René

[Faar]

Hi René,
danke, die Idee ist gut und ich hab sie gleich ausprobiert aber da steckt womöglich noch mehr Wurm drin als gedacht.
Jedenfalls hat sich durch mysql_close() nichts geändert.

Die Seite wird übrigens nicht vollständig ausgegeben, das HTML bricht irgendwo mittendrin ab.
Statt ca. 930 Zeilen HTML werden nur exakt 500 ausgegeben.
Zum einen ist das auch klar, weil manche Module die News einblenden, nicht laufen, aber dann müsste immer noch das korrekte Ende der HTML Seite erscheinen und das tut es nicht.

Und die Fehlermeldungen reißen nicht ab, es gibt noch in anderen Modulen scheints diese Datenbank-Verbindung zur anderen Datenbank und Daten werden nicht gefunden weil wohl noch einige Pfade falsch sind.
Ich muss erst mal alle gefühlt hundert Module durchaurbeiten, bevor ich sehen kann ob dieses mysql_close() den Erfolg brachte.
Das System hat nicht nur Läuse, sondern auch Zecken und Wanzen und Flöhe vielleicht auch noch.
Damit meine ich nicht Contenido selbst, das würde sicher problemlos laufen, hab ja schon viele andere umgezogen.

[Spider IT]

Dann erstmal viel Erfolg, und wenn es anschließend noch immer nicht funzt, kann ich ja mal schauen wenn du magst.

Gruß
René

[Faar]

Hi René,

ich habe inzwischen eine ganze Latte an Programmmodulen überarbeitet und am Ende jeweils mysql_close() eingebaut aber die eine Seite funktioniert immer noch nicht.
Ich muss jetzt nach dieser Arbeit nochmal prüfen ob neue Fehlermeldungen-Meldungen wegen der Datenbankverbindung kommen.
Einige Pfade stimmen auch noch nicht und oft sind die versteckt irgendwo im Code, so dass ich jeweils den ganzen Code Zeile für Zeile durcharbeiten muss.
Vielleicht ist auch in der Datenbank noch ein Stück Pfad, den ich nicht gefunden habe.
Eigentlich sollten aus dem Grund ja nur relative Pfade gespeichert werden, oder noch besser, die Pfade werden zur Laufzeit zusammengebaut und teils aus einer config-Datei gezogen.
Da muss ich die Module noch so umprogrammieren, dass sie auf eine Config zu greifen und nicht mehr komplette Pfade speichern.
Und es sieht so aus, dass die individuellen Includes auch berücksichtigt werden müssen.
Das summiert sich ganz schön, denn eigentlich wollte ich nur einen Umzug machen und kein Refactoring.

Bevor ich das nicht fertig habe, kann ich noch keine Aussage machen ob du mir helfen könntest, denn jetzt ist es erstmal viel Fleißarbeit.
Was ich am liebsten hätte, das wäre die Möglichkeit, eine zweite Datenbank-Verbindung aufzubauen, so wie es Xmurrix angedeutet hat: http://forum.contenido.org/viewtopic.php?f=60&t=32150
Vielleicht greift die Methode mit mysql_close() nicht und man muss den Weg über die Contenido-Klasse gehen?

VG

[Spider IT]

Du musst die Pfade nicht aus eine config.php auslesen, die sind in Arrays vorhanden.

Code: Alles auswählen

var_dump($cfgClient);

gibt folgendes aus (Beispieldaten, geändert):

Code: Alles auswählen

array(2) {
  ["set"]=>
  string(3) "set"
  [1]=>
  array(8) {
    ["path"]=>
    array(2) {
      ["frontend"]=>
      string(74) "/var/www/Spider-IT.de/Spider-IT/"
      ["htmlpath"]=>
      string(24) "http://www.spider-it.de/"
    }
    ["images"]=>
    string(31) "http://www.spider-it.de/images/"
    ["upload"]=>
    string(7) "http://www.spider-it.de/upload/"
    ["htmlpath"]=>
    array(1) {
      ["frontend"]=>
      string(24) "http://www.spider-it.de/"
    }
    ["upl"]=>
    array(3) {
      ["path"]=>
      string(81) "/var/www/Spider-IT.de/Spider-IT/upload/"
      ["htmlpath"]=>
      string(31) "http://www.spider-it.de/upload/"
      ["frontendpath"]=>
      string(7) "http://www.spider-it.de/upload/"
    }
    ["css"]=>
    array(1) {
      ["path"]=>
      string(78) "/var/www/Spider-IT.de/Spider-IT/css/"
    }
    ["js"]=>
    array(1) {
      ["path"]=>
      string(77) "/var/www/Spider-IT.de/Spider-IT/js/"
    }
    ["tpl"]=>
    array(1) {
      ["path"]=>
      string(84) "/var/www/Spider-IT.de/Spider-IT/templates/"
    }
  }
}

Um also den Datei- und HTML-Pfad zu erhalten brauchst du die folgenden Angaben:

Code: Alles auswählen

$cfgClient[$client]['path']['frontend'] = Dateipfad des Mandanten auf dem Webserver
$cfgClient[$client]['path']['htmlpath'] = HTML-Pfad des Mandanten (z.B. http://www.domain.tld/cms/)

Angaben zum Backend und vieles mehr gibt es im Array $cfg, dafür kannst du aber selbst mal ein var_dump() ausgeben, am besten in ein <pre> eingeschlossen:

Code: Alles auswählen

echo '<pre>'; var_dump($cfg); echo '</pre>';

Achtung! Nicht öffentlich anzeigen, da sind auch Angaben zur Datenbank drin!

Gruß
René

[Faar]

Hallo René,
ich weiß und ich selbst nehme ja sonst auch die Contenido Pfade aber hier geht es um Pfade in einer anderen Installation mit anderer Datenbank auf dem gleichen Server, auf die zugegriffen werden müssen.
Und die stehen natürlich nicht in der $cfgClient oder $cfg.
Und diese Pfade hat mein Vorgänger nicht mittels eine ähnlichen Variable aufgebaut sondern mehr oder weniger fest in jedes Modul und jede andere Programm-Datei eingetragen.
...und teils auch als ganzer Pfad in der ersten und der zweiten Datenbank abgespeichert.

Und bis jetzt tauchen immer noch Fehler mit falscher Datenbank auf.
Die Trennung der Datenbank-Zugriffe klappt noch nicht richtig.

[Spider IT]

Wow, dann hast du ja mal so richtig die A***karte gezogen
Viel Erfolg

Gruß
René

[Faar]

Sobald ich die alle Module in denen ich diese externen Datenbank-Zugriffe gefunden habe, läuft die Seite (natürlich ohne die Inhalte der entsprechenden Module).
Da fiel mir ein, dass mit diesen Modulen eine Fehlermeldung häufig auftritt, bei der Contenido zwecks Modulübersetzung auf die zweite Datenbank zugreifen wollte.
Kann es sein, dass mi18n() jeweils einen Contenido-Datenbank-Aufruf auslöst?
Vermutlich gleiches für CMS_VALUE[].

Das würde bedeuten, dass ich mit einem mysql_close() am Ende des Moduls keine Wirkung erziele, weil zwischendrin im Modul eben doch noch Datenbankzugriffe auf die Contenido-Datenbank erfolgen.
Und die nehmen dann fälschlicherweise eben die zweite Datenbank.

[Faar]

Wow, dann hast du ja mal so richtig die A***karte gezogen
Viel Erfolg

Gruß
René

Ja

Aber der Kunde auch

[Spider IT]

Du kannst am Anfang des Modul-Inputs alle benötigten Daten in Variablen laden um das Problem zu umgehen, z.B.:

Code: Alles auswählen

$anzahl = intval("CMS_VALUE[0]");
$textAnzahl = mi18n("Anzahl");

Ist einiges an zusätzliche Arbeit, aber dafür funzt es dann auch.

Gruß
René