www.mgfi.info

Hi,

ich habe eben die Version 3.0.5 installiert und hatte dabei einige Klippen zu umschiffen, welche ich hier mal beschreiben will, um anderen die Installation zu erleichtern, bzw. um einen Anstoß zu geben, diese Probleme im Installations-Paket zu beheben Wink

:

Zur Systemumgebung kurz und knapp:
Ich benutze SuSE 9.3, Apache 2.0.53, MySQL 5.0.17 (default encoding utf8) und PHP 5.0.3

Problem 1:
Bei dem Erstellen der Datenbank-Struktur kam es zu einem SQL-Fehler "Index größer als 1000 Byte"
Dies liegt daran, dass ich die Datenbank als UTF-8 erstellt habe und nicht als Latin1 ...
Das Problem ist in diesem Fall, dass bei UTF-8 der maximale Speicherbedarf pro Zeichen 3 Byte sein kann, bei Latin dagegen nur 1 Byte.
Da MySQL gezwungen ist, immer den maximal benötigten Speicherplatz für einen Index zu reservieren muss also für UTF-8 im Vergleich zu Latin der dreifache Speicherplatz reserviert werden.
In diesem speziellen Fall wird im SQL-Skript "installation/sql/core_german.sql" eine Tabelle mit zwei Indizies erstellt, welche jeweils zwei CHAR(240)-Spalten umfassen.

Code:

CREATE TABLE `#__core_acl_aro` (
`aro_id` int(11) NOT NULL auto_increment,
`section_value` varchar(240) NOT NULL default '0',
`value` varchar(240) NOT NULL default '',
`order_value` int(11) NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`hidden` int(11) NOT NULL default '0',
PRIMARY KEY (`aro_id`),
UNIQUE KEY `section_value_value_aro` (`section_value`,`value`),
UNIQUE KEY `#__gacl_section_value_value_aro` (`section_value`,`value`),
KEY `hidden_aro` (`hidden`),
KEY `#__gacl_hidden_aro` (`hidden`)
) TYPE=MyISAM;

Das führt dazu, dass im Falle von Latin (240 Zeichen + 240 Zeichen) * 1 Byte = 480 Byte reserviert werden müssen,
bei UTF-8 jedoch (240 Zeichen + 240 Zeichen) * 3 Byte = 1440 Byte.
Leider kann MySQL nut Indizies bis zur Größe von 1000 Byte verwalten, wodurch dann der obige Fehler entsteht.

Einfach Lösung:
a) Datenbank als Latin1 erstellen

oder

b) Index verkürzen:
Dazu muss man in dem Skript einfach die Zeilen

Code:

UNIQUE KEY `section_value_value_aro` (`section_value`,`value`),
UNIQUE KEY `#__gacl_section_value_value_aro` (`section_value`,`value`),

abändern zu

Code:

UNIQUE KEY `section_value_value_aro` (`section_value`(20),`value`(20)),
UNIQUE KEY `#__gacl_section_value_value_aro` (`section_value`(20),`value`(20)),

Man kann die 20 natürlich auch durch höhere Werte ersetzen (bis zusammengerechnet 333, also zum Beispiel zweimal 150), aber das ist im Prinzip ja nicht nötig ... der Vorteil hierbei ist, dass der Index gleich noch kleiner wird.

oder

c) die Spalten entsprechend verkleinern, wovon ich aber abraten würde, da nicht abzusehen ist, was das für Auswirkungen haben könnte!

Problem 2:
Beim Einspielen der Daten für die Besucher-Statistik kam der Fehler "max_allowed_paket zu klein".
Ich hatte diese Variable auf der Standard-Einstellung belassen, nämlich 1MB, was wohl nicht ausreicht.
Hier wäre es natürlich wünschenswert, wenn die Daten in entsprechend kleinen Happen schon im Skript daher kommen, um dem Nutzer die Umkonfiguration von MySQL zu ersparen (ist zwar kein großer Akt, aber immerhin ... und manche Nutzer haben vielleicht auch gar keinen Einfluss auf die Konfiguration des Servers).

Tritt der Fehler auf, kann man sich damit behelfen, den Wert für max_allowed_paket auf 16M zu setzen und den Server neu zu starten ... dann sollte es gehen.
Man kann eventuell auch die Variable im laufenden Server selbst ändern, aber das ist nur eine Vermutung und ich habs nicht getestet.

Problem 3:
Beim Zugriff auf die Menü-Items "Inhalte"->"Alle Inhalte" bzw. "Inhalte"->"Inhalte nach Abschnitten"->... kam eine Fehlermeldung von MySQL, dass die Tabellenspalte access in der Tabelle mos_content angeblich nicht gefunden werden konnte.
Das scheint ein Problem mit verschieden restriktiven Interpretationen von Joins zu sein ... welche bei 4.1 so wahrscheinlich funktionieren, bei 5.x aber wohl nicht mehr ...
Ich habs nicht weiter ausgetestet, nur schnell bei mir gefixt:

Im Skript "administrator/components/com_content/admin.content.php", Zeile 201 muss man die Zeile

Code:

. "\n FROM #__content AS c, #__categories AS cc, #__sections AS s"

ändern zu

Code:

. "\n FROM #__content AS c"

Dann muss man nach Zeile 205:

Code:

. "\n LEFT JOIN #__content_frontpage AS f ON f.content_id = c.id"

die folgende Zeile einfügen:

Code:

. "\n , #__categories AS cc, #__sections AS s"

(im Klartext: die Tabellen, welche mittels LEFT JOIN und ON-Klause mit der ersten Tabelle "#_content AS c" verknüpft werden, müssen direkt hinter dieser Tabelle stehen und nicht noch durch normale Joins von dieser getrennt sein ...
Der Abschnitt sieht dann so aus:

Code:

$query = "SELECT c.*, g.name AS groupname, cc.name, u.name AS editor, f.content_id AS frontpage, s.title AS section_name, v.name AS author"
. "\n FROM #__content AS c"
. "\n LEFT JOIN #__groups AS g ON g.id = c.access"
. "\n LEFT JOIN #__users AS u ON u.id = c.checked_out"
. "\n LEFT JOIN #__users AS v ON v.id = c.created_by"
. "\n LEFT JOIN #__content_frontpage AS f ON f.content_id = c.id"
. "\n , #__categories AS cc, #__sections AS s"
. ( count( $where ) ? "\nWHERE " . implode( ' AND ', $where ) : '' )
. $order
. "\n LIMIT $pageNav->limitstart,$pageNav->limit"
;

Hm, tja, soweit erstmal zu meinen Erfahrungen ...
Hoffe mal, das hat noch nicht irgendjemand so ausführlich in eine Bug-Liste geschrieben, sonst hätte ich mir die Sache sparen können :-)

Gruß
Steffen