Hallo!

Ich habe einige Entities geändert und dann den Sourcecode aufgerufen.
Die Sonderzeichen werden nicht korrekt dargestellt.
Da würde ich tatsächlich so einige Zeichen bei einsparen.

Die html Validierung spuckt aus, dass es Zeichen geben würde, die utf8 nicht zugeordnet werden könnten.
Aus dem Grund wird die Validierung abgebrochen.

Die Datenbank collation ist eingestellt auf utf8_unicode_ci

Ohne weitere Informationen kann man nur mutmaßen, woran es liegt.

Im Quellcode habe ich noch mehr Unsinn gefunden:

Das ist ab Zeile 244 drei Mal vorhanden. Davon sind zwei unnötig.

title-Attribute für die Links hast Du auch noch nicht ergänzt.

Der englische Kontaktlink ist mit unterstrichen, das gehört zu den Nudeln...

Und schau ernsthaft mal die ganzen IDs durch, ob id und class wirklich immer doppelt vorhanden sein muss, z.B. bei der

und dem Copyright-Div.

Matthes schrieb:

Im Quellcode habe ich noch mehr Unsinn gefunden:

Das ist ab Zeile 244 drei Mal vorhanden. Davon sind zwei unnötig.

Check!

Matthes schrieb:

title-Attribute für die Links hast Du auch noch nicht ergänzt.

Ich habe in den Links in den Blankboxen zu allen

einen title hinzugefügt.
Im footer sind aber noch links dabei, die mit PHP über ezpages erzeugt werden und keinen title haben.
Bin mit dem Footer eh nicht so richtig glücklich. Habe schon überlegt den ganzen footer per

Matthes schrieb:

Der englische Kontaktlink ist mit unterstrichen, das gehört zu den Nudeln...

Check!
Das übernimmt jetzt die neue Klasse .underline

Matthes schrieb:

Ohne weitere Informationen kann man nur mutmaßen, woran es liegt.

www.geany.org hats gerichtet. Es war vermutlich ein Problem mit BOM.

Matthes schrieb:

Und schau ernsthaft mal die ganzen IDs durch, ob id und class wirklich immer doppelt vorhanden sein muss, z.B. bei der

und dem Copyright-Div.

Habe die herausgesucht:

[css]#siteinfoLegal {
text-align:left;
margin:0 6px 0 6px
}[/css]

[css].legalCopyright {
float:right;
font:9px arial!important
}[/css]

Check!
Ich habe einfach mal die .legalCopyright rausgenommen. Darstellung so ist genau so gut oder genauso schlecht, nur anders. Hauptsache alles ist koherent.

Beim body habe ich in der stylesheet.css komischerweise keinen string finden können, der die Folge indexcategories enthält :confused:

Hinsichtlich der Spalten / Nudel-style

Ich will das beispielhaft mal an einem Code erklären.

category_row.php
$list_box_contents[$row][$col] =
array(\'params\' => \'class="categoryListBoxContents"\'
. \' \' . \'style="width:\' . $col_width . \'%;"\',

$col_width ist die Variable, die die Spaltenbreite enthält. Die wird anscheinend irgendwo vorher in der Datei berechnet.
Wenn man jetzt schaut, welche Werte $col_width haben kann, könnte man das Skript umbauen. Mal angenommen, du würdest auf der gesamten Seite nur zwei Spalten verwenden, dann wäre $col_width wahrscheinlich stets 50.
Verwendest Du mal zwei, mal drei und mal vier Spalten, wird $col_width 50, 33 und 25 sein.
Statt also die style-Angabe anzuhängen, könnte man es wie folgt machen:[css]/* Ergänzung der CSS-Datei */
.col50{width:50%}
.col33{width:33%}
.col25{width:25%}[/css]

Check!

/* Anpassung der PHP-Datei */
$list_box_contents[$row][$col] =
array(\'params\' => \'class="categoryListBoxContents col\'.$col_width.\'"\',
Das führt dazu, dass die style-Angabe wegfällt und die class-Angabe eine weitere Klasse erhält, die die Spaltenbreite vorgibt.

Es läuft :thumbup:

Check! bei den Kategorien
Check! bei den neuen Artikeln in der Hauptspalte
Check! bei den empfohlenen Artikeln in der Hauptspalte
Check! bei xsell Produkten auf der Artikelseite
Für die new_products und featured_products in den Sideboxen finde ich die PHP Dateien nicht. Habe jetzt etwas rumgestochert aber auch find -iname *new_products* brachte keine weiterführenden Ergebnisse.

leftboxcontainer, sideboxcontent centeredcontent?
Aber da sehe ich keine Verbindung zum o.g. array

PS: Ist der Inhalt des meta tag "generator" irgendwie wichtig? Ich habe ihn gekürzt und individuell gestaltet.

Krisis schrieb:

Die html Validierung spuckt aus, dass es Zeichen geben würde, die utf8 nicht zugeordnet werden könnten.
Aus dem Grund wird die Validierung abgebrochen.

Die Datenbank collation ist eingestellt auf utf8_unicode_ci

Hast du in deinem Editor mal die Codierung auf UTF8 ohne BOM umgestellt? Das hat bei mir Besserung gebracht.

Na, es wird doch. Beim Überfliegen sieht der Quelltext schon anders aus als noch zu Beginn.

Krisis schrieb:

Habe die herausgesucht:

[css]#siteinfoLegal {
text-align:left;
margin:0 6px 0 6px
}[/css]

[css].legalCopyright {
float:right;
font:9px arial!important
}[/css]

Check!
Ich habe einfach mal die .legalCopyright rausgenommen. Darstellung so ist genau so gut oder genauso schlecht, nur anders. Hauptsache alles ist koherent.

Du kannst die beiden auch zusammenlegen, in der Regel braucht nicht jedes Element eine ID und wenn es sich um spezielle Klassen handelt, diese schon gar nicht extra. Also den Inhalt von .legalCopyright in die CSS-Anweisungen für #siteinfoLegal kopieren und es passt sicher wieder.

Krisis schrieb:

Beim body habe ich in der stylesheet.css komischerweise keinen string finden können, der die Folge indexcategories enthält :confused:

Wenn Du Klassen oder IDs findest, die es in der CSS-Datei nicht gibt, prüfe kurz noch, ob sie in einer JavaScript-Datei vorkommen. Tun sie es nicht, können sie weg.
Eine weitere Verkürzung:
Sind die

immer innerhalb des

Ja, ich bekomme so langsam einen Blick für das Quelltextgerüst :thumbup:
Habe mich schon mal etwas auf anderen Seiten umgesehen und es überkommt einen das :scared:
Langfristig werde ich wohle alle Bereiche optimieren müssen. Darunter die Artikeldetails, die Suchergebnisse (scheint auch nicht einfach zu sein hinsichtlich DC und description) etc.
Die Startseite soll einfach ein gutes Muster sein und eine gute Ausgangssituation für die weitere Arbeit darstellen

jquery stammt vermutlich noch aus der Zeit, als ich mit dem 2klick social plugin experimentiert haben. Check!

Die Macher des deutschsprachigen Zen-cart Support Forums und der deutsprachigen Version von ZC wünschen, dass der Link im footer drin bleibt. Für den generator meta-tag gibt es aber keinen Hinweis. Also komplett entfernt.
Check!

Sind die

immer innerhalb des

? In jeder Datei?
Falls ja, kann man die Klassen rauslöschen und innerhalb der CSS-Datei ".content p" als Selektor verwenden.

Da fehlt mir der Überblick. In den Artikeldetails verwende ich die Klassen nicht. Da gibt es nur ein einfaches

. Bei älteren unwichtigeren Artikeln nicht einmal das. Das ergänze ich jetzt nach und nach. Ob diese Klassen sonst noch irgendwie gemeinsam oder getrennt verwendet werden, weiß ich gerade nicht.

Ich suche über das Dev-Kit des Shops in allen .php Dateien.
Die noch vorhandenen Kommentare auf der Startseite, wie etwa finde ich darüber komischerweise nicht. Die Sideboxen verhalten sich da scheinbar einfach anders.
Bin dran!

Ich habe über die col Konfiguration bei den Sideboxen nachgedacht und einen möglichen Grund zusammengesponnen, warum es keinen solchen array für die sideboxen gibt.
Die Spaltenbreite der beiden Sideboxen wird über die Datenbank übertragen und über das Front-End in pixeln festgelegt. Es findet an dieser Stelle einfach keine weitere Definition von Spalten statt. Ist vlt. aber auch totaler Quatsch was ich da rede.
Ich glaube, in den Sideboxen gibt es anderen Code zu optimieren wie etwa "width" und "height". Ich glaube, dass ich etwas optimieren wollte, dass es gar nicht gibt.
Befindet sich in den Sideboxen "Neue Artikel" und "Empfohlene Artikel" Nudelsuppe die sich gut auslagern lässt :confused:

Etwas offtopic: Mit der Einbindung der Links im Footer bin ich mir noch nicht sicher. Macht es Sinn, die von php erzeugten targets zu notieren und die links in der footer.php einfach von Hand als

festzulegen?
Wenn ich mir den Quelltext ansehe, dann macht das ezpages Modul eh nichts anderes.

Krisis schrieb:
Ich suche über das Dev-Kit des Shops in allen .php Dateien.
Die noch vorhandenen Kommentare auf der Startseite, wie etwa finde ich darüber komischerweise nicht. Die Sideboxen verhalten sich da scheinbar einfach anders.
Bin dran!

Aber auch das muss irgendwoher kommen. Versuch mal FileSeek und den Stammordner, vielleicht ist es in irgendeiner Datei fest eingetragen.

Krisis schrieb:
Die Spaltenbreite der beiden Sideboxen wird über die Datenbank übertragen und über das Front-End in pixeln festgelegt. Es findet an dieser Stelle einfach keine weitere Definition von Spalten statt. Ist vlt. aber auch totaler Quatsch was ich da rede.
Ich glaube, in den Sideboxen gibt es anderen Code zu optimieren wie etwa "width" und "height". Ich glaube, dass ich etwas optimieren wollte, dass es gar nicht gibt.
Befindet sich in den Sideboxen "Neue Artikel" und "Empfohlene Artikel" Nudelsuppe die sich gut auslagern lässt :confused:

Ja, es gibt inline-styles mit "position:relative" sowie onmouseover und onmouseout als Eventhandler. Außerdem sind die CSS-Klassen arg lang: "centerBoxContentsNew centeredContent back col33" - da könnte man vielleicht einiges zusammenlegen oder streichen. Und prüfen, ob es die IDs braucht, "whatsNew" und "specialsDefault".

Krisis schrieb:
Etwas offtopic: Mit der Einbindung der Links im Footer bin ich mir noch nicht sicher. Macht es Sinn, die von php erzeugten targets zu notieren und die links in der footer.php einfach von Hand als

festzulegen?
Wenn ich mir den Quelltext ansehe, dann macht das ezpages Modul eh nichts anderes.

Ich bin mir nicht sicher, was Du meinst.
Du kannst die Links natürlich einfach fest ins Template schreiben, das ist kein Problem. Wenn Du was anderes meinst, müsstest Du es erklären.

Krisis schrieb:
PS: html/text ratio bei ca. 19,5% abhänfig von den geladenen Inhalten.

Auf 25% kommen wir sicher noch...

Matthes schrieb:

Auf 25% kommen wir sicher noch...

Hallo Matthes,
das wäre wirklich unglaublich gut!!

Check!
Kommentare in den Sideboxen sind alle entfernt. Die Kommentare wurden dynamisch aus der ID erzeugt. Aus dem Grund waren die Suchstrings der Sideboxen nicht auffindbar, wenn man nach dem Sichstring gesucht hat.

Zum Footer:

Wenn Du was anderes meinst, müsstest Du es erklären.

Ich habe die footer-links jetzt neu gestaltet. Ich weiß bei den Footerlinks hinsichtlich Trust und PR nicht, was am besten ist. Impressum, AGB und Datenschutzerklärung habe ich auf dofollow gelassen, um den Trust aufrecht zu erhalten.
Seobility sagt, dass ich aber immer noch zu viele dynamische Links hätte.
Seitenreport findet die nofollow links auch nicht so toll. -> Punktabzug
Ich habe von Sculpting gelesen. Es ist aber eigentlich eher eine Frage des Webdesigns. Im vorhandenen Design erscheint mir das nofollow im Footer als passend, weil es einfach auf jeder Seite mitgeladen wird, aber diese Seiten nur wegen der Gesetzeslage vorhanden sind.
Der Benutzer legt meiner Meinung nach keinen großen Wert drauf. Es muss wegen der Gesetzgebung einfach da sein. Ich möchte solche Links gerne auf nofollow setzen. Vielleicht managen die Suchmaschinen das aber eh schonselbständig?

Zu Sideboxen:

Ja, es gibt inline-styles mit "position:relative" sowie onmouseover und onmouseout als Eventhandler.

Der Image Handler ist ein nachträglich installiertes Plugin und erzeugt alle Bilder in allen Auflösungen in Echtzeit. Der IH legt einen "bmz" Cache an. Ich würde das aus Stabilitätsgründen lieber später optimieren wollen wenn ich mehr davon verstehe. Wenn hier aber der große Anteil an schlecht optimiertem Code liegt, dann sollten wir diesen Teil doch zuerst erledigen.
Die Definition für die Größe der Sideboxen habe ich in der Datei classes/bmz_image_handler.class.php gefunden. So sieht der String aus:

Die centerboxontens wären langfristig aber wichtiger als sie Sideboxen


return $parameters . \'style="position:relative" onmouseover="showtrail(\' . "\'$products_image_zoom\',\'$alt\',$width,$height,$zoomwidth,$zoomheight,this," . $this->zoom[\'startx\'].\',\'.$this->zoom[\'starty\'].\',\'.$this->zoom[\'width\'].\',\'.$this->zoom[\'height\'].\');" onmouseout="hidetrail();" \';

Zur Breite der Sideboxen habe ich in der sidebox.php folgenden Eintrag gefunden:

31 Mal bearbeitet aber nie die Zeilen umgebrochen... Tststs...

Wenn zwischen Deinem Beitrag und einer neuen Information viel Zeit liegt, antworte ruhig erneut. Sonst muss man immer schauen, ob es Neuigkeiten gibt, weil Bearbeitungen nicht gesondert angezeigt werden.

Dass die Meta-Keywords entfernt werden können magst Du mir nicht glauben, hm?
Dann entferne wenigstens den anderen Unsinn.


Die Verifizierungen sollten immer über eine separate Datei erfolgen, nie über Einträge im Code.

Das ist eigentlich unnötig:

Ist doch egal, ob IE die Imagetoolbar anzeigt. Wer deine Bilder klauen will, kann das auch ohne.
Und

ist jetzt auch nicht wirklich wichtig.

Dass Du die letzten Kommentare gefunden hast, ist gute Arbeit. Du arbeitest Dich immer mehr und besser ein. Bald bist Du ein Zen-Cart-Experte...

Die Breite der Sideboxen kannst Du analog zur Breite der Columns (col33 & Co.) umschreiben. Bei der Gelegenheit kannst Du auch gleich die ID löschen, die braucht es nicht. Jedem Element eine ID zu geben ist einfach nicht notwendig.
Anstatt zwei Buchstaben bei der Änderung von col33 zu c33 zu sparen, würde ich eher Konstrukte wie centerBoxContentsNew etwas einkürzen.

Um die Image-Handler-Geschichte mit den onmouseirgendwas-Handlern umzuschreiben müssen wir HTML und JavaScript anpassen. Das ist vielleicht etwas unübersichtlich, daher würde ich das lieber losgelöst von dem anderen machen.
Allerdings könntest Du den Inline-Style "position:relative" aus schon einmal aus dem Code herausnehmen und in die CSS-Datei verlagern. Dann hat man eine Kleinigkeit für diese Baustelle schon einmal erledigt.

PS: Die Footer-Links habe ich völlig vergessen.
Die können ruhig alle nofollow sein. Es sind unwichtige Seiten. Ich handhabe es bei mir in der Regel so. Allerdings habe ich das Sculpting nie ernsthaft praktiziert, weil ich auch ohne gute Ergebnisse erziele. Für den Seiteninhalt irrelevante Links knipse ich meistens aus, den Rest lasse ich in der Regel.

Die dynamischen Links sind praktisch alle Produkt- und Kategorielinks, die haben mit dem Footer nichts zu tun.
Gemeint sind diese Links:
index.php?main_page=product_info&cPath=68_65_83_89&products_id=930
Schöner ist da in der Regel irgendwas wie produkt/bla/id/usw., die zumindest rein optisch statisch aussehen, also auf Query-Teile verzichten.
Das kann man irgendwann in der Zukunft angehen.

Guten Morgen Matthes!

Ich kann auf meine eigenen Beiträge nicht antworten. Da bleibt mir nur das editieren.

Matthes schrieb:

Dass die Meta-Keywords entfernt werden können magst Du mir nicht glauben, hm?

Check!
Aus dem html_header entfernt. Ich will nur nichts "verschlimmbessern".

Matthes schrieb:
Dann entferne wenigstens den anderen Unsinn.


Die Verifizierungen sollten immer über eine separate Datei erfolgen, nie über Einträge im Code.

Ich dachte mir das mit dem author schon. Also Check!
Aus dem html_header entfernt. Der verify meta-tag ist auch raus.

Matthes schrieb:
Das ist eigentlich unnötig:

Ist doch egal, ob IE die Imagetoolbar anzeigt. Wer deine Bilder klauen will, kann das auch ohne.
Und

ist jetzt auch nicht wirklich wichtig.

Check!
Aus dem html_header entfernt.

Matthes schrieb:
Dass Du die letzten Kommentare gefunden hast, ist gute Arbeit. Du arbeitest Dich immer mehr und besser ein. Bald bist Du ein Zen-Cart-Experte...

Matthes schrieb:
Die Breite der Sideboxen kannst Du analog zur Breite der Columns (col33 & Co.) umschreiben.

TO DO

Matthes schrieb:
Bei der Gelegenheit kannst Du auch gleich die ID löschen, die braucht es nicht. Jedem Element eine ID zu geben ist einfach nicht notwendig.

TO DO

Matthes schrieb:
Anstatt zwei Buchstaben bei der Änderung von col33 zu c33 zu sparen, würde ich eher Konstrukte wie centerBoxContentsNew etwas einkürzen.

TO DO

Matthes schrieb:
Um die Image-Handler-Geschichte mit den onmouseirgendwas-Handlern umzuschreiben müssen wir HTML und JavaScript anpassen. Das ist vielleicht etwas unübersichtlich, daher würde ich das lieber losgelöst von dem anderen machen.

OK! Das sehe ich auch so

Matthes schrieb:
Allerdings könntest Du den Inline-Style "position:relative" aus schon einmal aus dem Code herausnehmen und in die CSS-Datei verlagern. Dann hat man eine Kleinigkeit für diese Baustelle schon einmal erledigt.

Den String position:relative habe ich nur in einer Datei gefunden. Und zwar in der classes/bmz_image_handler.class.php. Weiter komme ich hier leider nicht, weil ich mit dem Ort des Suchstrings im Dateisystem nichts anzufangen weiß.

return $parameters . \'style="position:relative"
onmouseover="showtrail(\' . "\'$products_image_zoom\',\'$alt\'
,$width,$height,$zoomwidth,$zoomheight,this," . $this->
zoom[\'startx\'].\',\'.$this->zoom[\'starty\'].\',
\'.$this->zoom[\'width\'].\',\'.$this->zoom[\'height\'].\');"
onmouseout="hidetrail();" \';

Ich habe nebenbei in den Sidebox_templates den String für width gefundenstyle="width: <?php echo $column_width;

Matthes schrieb:
Die Footer-Links habe ich völlig vergessen.
Die können ruhig alle nofollow sein. Es sind unwichtige Seiten. Ich handhabe es bei mir in der Regel so. Allerdings habe ich das Sculpting nie ernsthaft praktiziert, weil ich auch ohne gute Ergebnisse erziele. Für den Seiteninhalt irrelevante Links knipse ich meistens aus, den Rest lasse ich in der Regel.

Ich habe befürchtet, dass das Ausschalten der footer links schon als sculpting interpretiert werden würde.
In einem Beitrag, den ich leider nicht mehr wiedergefunden habe, wurde mit dem nofollow der "privacy" eine negative Entwicklung in den SERPs festgestellt. Ein Wechsel auf noindex brachte wieder Erholung der SERPs. Es "scheint", dass TRUST verlorengegangen ist.
Weil mit privacy vermutlich gar nicht die Datenschutzerklärung gemeint ist, sondern das Impressum oder die AGB, habe ich vorsichtshalber alle drei Seiten auf dofollw gelassen. Die anderen vier Seiten, die nichts mit Identität und daher auch nichts mit TRUST zu tun haben sollten, habe ich auf nofollow gesetzt, um zumindest davon den Fokus wegzunehmen.

Matthes schrieb:
Die dynamischen Links sind praktisch alle Produkt- und Kategorielinks, die haben mit dem Footer nichts zu tun.
Gemeint sind diese Links:
index.php?main_page=product_info&cPath=68_65_83_89&products_id=930
Schöner ist da in der Regel irgendwas wie produkt/bla/id/usw., die zumindest rein optisch statisch aussehen, also auf Query-Teile verzichten.
Das kann man irgendwann in der Zukunft angehen.

OK! Lassen wir das erst einmal so stehen.

Dann mal ran an die Buletten!