Contenido Speichern oder Aufruf des WYSIWYG Editors

[siota]

Ich habe, um zumindest keine Altlasten aus dem Verzeichnis der Version 4.4.5 zu haben, die 4.6.2 in ein neues Verzeichnis entpackt. Dann die alten Tabellen in eine leere Datenbank importiert und ein Upgrade gemacht. So weit lief alles bestens.

Bei etwas komplexeren Seiten (2 spaltige Tabelle mit 10 Zeilen, Seite insgesamt 16kb) dauert das speichern oder das Öffnen der Seite im Editor ne halbe Ewigkeit. Auch wenn ich nur einen CMS_HTMLHEAD Container bearbeiten will. Ich vermute deshalb , dass das Problem beim Speichern entsteht.

Woran mag es liegen?

php Version.: 4.4.1 / 4.4.0-3
mysql 3.23.58 / 4.0.24

gestestet auf 2 Systemen

Danke schonmal, auch für die viele Arbeit an der neuen Version !!

[MediaMuchacho]

ich hab das selbe Problem, ich denke das liegt an den umfangreichen Möglichkeiten die der Editor zur Verfügung stellt. Das muss jedes mal geladen werden und benötigt entsprechend Ladezeit... just my 2 cents

[siota]

Ich bin etwas weitergekommen, die betreffende Seite generiert etwa 4300 Abfragen beim Speichern und legt 580 Einträge in der Tabelle keywords an.

Ruhe ist erst wenn ich die Funktion createkeywords in der Datei class.search.php abschalte. Welcher Teil dieser Funktion die hohe Zahl an Abfragen generiert kann ich allerdings noch nicht erkennen. Die Zugriffe auf den keywords Tabelle sind es nicht, die habe ich abgestellt.

[siota]

Da habe ich mich wohl verannt Es war natürlich die Funktion savekeywords und dort der Aufruf db->nextid. Kann man das nicht einfach abschalten und der Tabelle nen autoincrement verpassen? Übersehe ich da etwas?

[HighFidelity]

Im Thread "JavaScript-Fehler artObj (Verzweifelung)" verzweifle ich vielleicht an einem ähnlichen Thema. Drum hatte ich sofort das mit "createkeywords" ausprobiert, erfolglos. Demhingegen scheint "savekeywords" erfolgreich! Hurra, danke, ein Ansatz. Ich dachte schon, alles wäre irgendwie meine Dummheit...

Grüße,
Thorsten

[timo]

wenn du es probieren möchtest gerne

aber sämtliche Funktionen arbeiten mit der Sequenztabelle - d.h. du müsstest ALLE SQL-Statements in Contenido anpassen => unfug...

[siota]

Das mit dem autoincrement meinte ich nur für die Tabelle keywords, das müsste doch gehen Dann kann ich mir zumindest beim anlegen der keywords den Aufruf der Funktion nextid sparen. Womit wird eigentlich das Array stopwords befüllt, habe da leider nichts zu finden können.

Danke und Gruß
Simon

[HighFidelity]

@timo, dieses Problem macht Contenido aber zumindest in meinem Fall ziemlich unbenutzbar, deswegen, gibt es eine Alternative? Was für Seiteneffekte treten auf, wenn das erstmal deaktiviert wird in meinem System? Ich verwende ein recht altes Volltextsuche-Modul bisher (Volltextsuche v1.11)...

Grüße,
Thorsten

[HighFidelity]

Hallo,

also ich denke etwas drüber nach, leider fehlt mir der Überblick im System, ich habe mich damit kaum beschäftigt bisher. Die Frage ist, welche Seiteneffekte hat es, als Workaround in der class.search.php einfach erstmal das "start indexing the article" funktional auszukommentieren (Zeilen 213 bis 230). Die ganze Datei ist ja eine "API to search in the index structure", und im Vergleich zu Version 4.4.x (von der ich upgedated habe), ist das offenbar neu, oder? Das würde genannten Workaround für mich erstmal machbar erscheinen lassen.

So auf die Schnelle sehe ich im Code keinen Grund für den immensen Performance-Verlust beim Laden. Beim Speichern wird für jedes neue Keyword ein INSERT abgefeuert, sowas skaliert doch irgendwie schlecht und ist auch problematisch, wenn die Datenbankanbindung etwas suboptimal ist.

Weitere Frage, wenn derart indexiert wird, wurde der Index beim Update denn auch initial aufgebaut mit bestehenden Inhalten? Wieder flüchtiger Blick, da wird ein "Standardmodul" eingebunden bei Neuinstallation?

Eigentlich würde man sich wünschen, dass eine Indexierung im Hintergrund verläuft, wie lange der Server mit sich selbst beschäftigt ist, das interessiert den Nutzer ja weniger und wenn der Suchindex etwas hinterherhinkt, das fällt auch niemandem auf.

Grüße,
Thorsten

[siota]

Guten Morgen,

Ich habe nun für das Feld keyword einen Index angelegt, in der Funktion createkeyword nur Wörter ab 3 Buchstaben aufgenommen und den Aufruf der Funktion nextid deaktiviert. Für meine Zwecke läuft es so.

Jetzt muss nur noch das Array stopwords gefüllt werden.

[emergence]

ich verschieb das mal nach bugs...
das muss man sich genauer an sehen...
4000 queries sind eindeutig zu viele abfragen...

[emergence]

okay folgendes hab ich mal gefunden was in meinen augen unsinnig ist...

functions.con.php
in
function conSaveContentEntry
findet sich

Code: Alles auswählen

    # generate index of article content
    $oIndex = new Index($db);
    $aOptions = array("img", "link", "linktarget", "swf"); // cms types to be excluded from indexing
    # indexing an article depends on the complete content with all content types, i.e it can not by differentiated by specific content types.
    # Therefore one must fetch the complete content arrray.
    $aContent = conGetContentFromArticle($idartlang);

    $sql = "SELECT idart FROM ".$cfg["tab"]["art_lang"]." WHERE idartlang = ".$idartlang." AND idlang = ".$lang." ";
    $db->query($sql);
    if ($db->next_record())
    {
		$oIndex->start($db->f('idart'), $aContent, 'auto', $aOptions);
    }

ist zwar recht nett und schön aber ein absoluter blödsinn...

begründung:

diese funktion wird von

include.con_editcontent.php aufgerufen und zwar in einer for each schleife

Code: Alles auswählen

                foreach($data as $value){
....
                    conSaveContentEntry($value[0], "CMS_".$value[1], $value[2], $value[3]);

....
                }

für jeden content type wird einmal conSaveContentEntry aufgerufen
und dort werden aus dem artikel nochmals alle content typen selektiert und in der keywords liste ergänzt...

wenn ich sagen wir mal 15 content typen im template habe wird die keyword generierung 15 mal komplett aufgerufen...
da kann ich mir durchaus vorstellen das die sql abfragen anzahl explodieren wird...

es ist ja noch kein problem wenn in jedem CMS_HTML oder was auch immer wenig text vorhanden ist, aber sobald dort mal etwas wie 1500-2000 wörter zu finden sind, krachts gewaltig...

mein lösungsvorschlag:
den part mit
# generate index of article content
in eine eigene funktion auslagern die als parameter nur idartlang und lang ??(beim query wieso ?? idartlang ist ja eindeutig)

und in der include.con_editcontent.php nach der foreach schleife
einmal diese indizierung vornimmt...

das sollte das ganze doch um etliches beschleunigen...

nur damit man weiss von welchen relationen ich da eigentlich rede
kommentiere ich die keyword eintragung komplett aus, benötigt die speicherung/öffnen des editors nicht mehr 5 minuten sondern 5 sekunden... (die suchfunktion kann man dann halt nicht mehr verwenden..)

korrigiert man den ablauf wird das in etwas daumen x pi 20 sekunden benötigen....

[#ayshe]

Hm, kann das mal jemand komplett als Code posten - also die bereinigte functions.con.php?

[HerrB]

Da ist noch nix, emergence hat nur den Lösungsweg aufgezeigt - es gibt aber noch keine Umsetzung.

Gruß
HerrB

[stese]

ok habe es mal umgesetzt:

datei function.con.php öffnen und function conSaveContentEntry suchen.
folgenden part entfernen:

Code: Alles auswählen

    # generate index of article content
    $oIndex = new Index($db);
    $aOptions = array("img", "link", "linktarget", "swf"); // cms types to be excluded from indexing
    # indexing an article depends on the complete content with all content types, i.e it can not by differentiated by specific content types.
    # Therefore one must fetch the complete content arrray.
    $aContent = conGetContentFromArticle($idartlang);

    $sql = "SELECT idart FROM ".$cfg["tab"]["art_lang"]." WHERE idartlang = ".$idartlang." AND idlang = ".$lang." ";
    $db->query($sql);
    if ($db->next_record())
    {
      $oIndex->start($db->f('idart'), $aContent, 'auto', $aOptions);
    }

unter dieser funktion muss eine neue funktion eingefügt werden:

Code: Alles auswählen

/**
 * generate index of article content
 * 
 * added by stese
 * removed from function conSaveContentEntry  before 
 * Touch the article to update last modified date
 *
 * @see conSaveContentEntry
 * @param integer $idart
 */
function conMakeArticleIndex ( $idart ) {
   global $db, $auth, $cfg, $cfgClient, $client, $lang, $_cecRegistry;
   # generate index of article content 
   $oIndex = new Index($db);
   $aOptions = array("img", "link", "linktarget", "swf"); // cms types to be excluded from indexing
   # indexing an article depends on the complete content with all content types, i.e it can not by differentiated by specific content types.
   # Therefore one must fetch the complete content arrray.
   
   $sql = "SELECT idartlang FROM ".$cfg["tab"]["art_lang"]." WHERE idart = ".$idart." AND idlang = ".$lang." ";
   $db->query($sql);
   if ($db->next_record())
   {
      $aContent = conGetContentFromArticle($db->f('idartlang'));
		$oIndex->start($idart, $aContent, 'auto', $aOptions);
   }
}

datei include.con_editcontent.php öffnen und nach der foreach in zeile 46 folgenden aufruf einfügen:

Code: Alles auswählen

conMakeArticleIndex ( $idart );

sollte klappen.