Nach einem Serverumzug auf einen Apache2 und PHP via mod_fcgi Server endete ein WordPress MU Update in einem Apache Internal Server Error 500.
Andere Scripte mit längere Ausführungszeit endeten ebenfalls mit einem Internal Server Error 500.

Der Apache2 Error Log brachte folgendes Ergebnis (/var/log/apache2/error.log):

[warn] mod_fcgid: read data timeout in 40 seconds
[error] [client XXX.XXX.XXX.XXX] Premature end of script headers: index.php, referer: www.example.com/dir

Die Lösung war das anpassen der maximalen Wartezeit in Sekunden bis das Apache Modul Daten vom FastCGI Programm abgfrägt. Die alte Optionsbezeichnung war / ist IPCCommTimeout. Aktuell ist der Options Name FcgidIOTimeout. Je nach Installationsdatum beide Versionen funktional oder nur eine von beiden.
Das kann in der Datei /etc/apache2/mods-enabled/fcgid.conf erledigt werden:

<IfModule mod_fcgid.c>
   FcgidIOTimeout  7200
</IfModule>

In diesem Fall ist das Timeout sehr hoch eingestellt. Der oben verwendete Wert 7200 sind 120 Minuten. So hohe Einstellungen sind für den regulären Webseiten Betrieb nicht benötigt. Mehr über diese Option hier.

Anschließend den Apache neu starten.

/etc/init.d/apache2 restart

Das wars. Was auch immer vorher versucht hattet an länger laufenden Scripten auszuführen sollte nun funktionieren.

Keine Kommentare »
 

Mit der Shadowbox treten Probleme beim verwenden in Eingabefeldern (input Tags) und Textfelder (textarea Tags) auf. Die Leertaste sowie die links und rechts Tasten werden beim tippen in Textfelder nicht eingefügt bzw. das Textfeld reagiert nicht.

Die Ursache ist das Shadowbox.js, unsere Highlight-Box, die Tastensignale als Steuersignale für das Weiterschalten und der gleichen verwendet. Abhilfe schafft das Initialisieren der Shadowbox mit dem Parameter enableKeys: false. Beispiel Code:

Shadowbox.init({
     handleOversize: 'drag',
     modal: true,
     enableKeys: false
});
Keine Kommentare »
 

Version: xt:commerce 4.0.12 (höhere Versionen nicht getestet)

Ein kleiner Bugix für einen nervigen Fehler in der Artikelansicht nach Herstellern (manufacturer view). Der Fehler macht sich nach dem Klick auf die Hersteller Auswahl im Frontend bemerkbar. Anstatt eine gefilterte Artikelansicht nach Herstellern zu sehen bekommen werden alle Artikel aus dem Shop angezeigt.

Einen Dowload des Bugfix in Plugin Form geht es hier: xt:commerce Veyton Hersteller Manufacturer Ansicht / Filter Bugfix Download
Zur Installation des Bugfixes muss der Ordner „ld_manufacturer_bugfix“ in den xt:commerce Veyton Plugin Ordner kopiert werden.

In Eigenregie kann der Bugfix in der Datei xtFramework/classes/class.products_list.php eingefügt werden. Es reicht die Zeilen 62 und 63 der Datei auskommentieren. (Methode getProductListing der Klasse products_list)

	function getProductListing () {
##
## ... some code
##
		if (empty($current_manufacturer_id)) {
			$this->sql_products->setPosition('product_listing');
 
			if ($this->current_categorey_id == 0)
				$this->sql_products->setFilter('Startpage');
				$this->sql_products->setFilter('Categorie', $this->current_categorey_id);
 
			if (is_data($_GET['filter_id']))
				$this->sql_products->setFilter('Manufacturer', (int)$_GET['filter_id']);
		} else {
                        ## quick manufacturer view  / filter bugfix
			$this->sql_products->F_Manufacturer($current_manufacturer_id);
			# $this->sql_products->setPosition('product_manufacturer_listing');
			# $this->sql_products->setFilter('Manufacturer', (int)$current_manufacturer_id);
			if (is_int($current_category_id))
				$this->sql_products->setFilter('Categorie', $current_category_id);		}
		if (is_data($_GET['sorting'])) {
			$this->sql_products->setFilter('Sorting', $_GET['sorting']);
		} else {
##
## ... more code
##

Nach dem korrigieren des Quellcodes oder installieren des Manufacturer Bugfixes für Veyton sollte alles wie erwartet funktionieren. Es sei denn du hattest erwartet das Veyton diesen Bug hatte. 😛

Keine Kommentare »
 

Version: Magento 1.5 & 1.5.1

Themen spezifische Übersetzungen werden in Magento üblicherweise in der Datei /app/design/frontend/***BASE ODER DEFAULT***/***DEIN TEMPLATE***/locale/de_DE/tanslate.csv hinterlegt. Dabei muss das Format „***STRING IN TEMPLATE***“,“***ÜBERSETZTER TEXT***“ eingehalten werden. Teilweise sind auch Variablen wie %s enthalten. Die sind am Prozent Zeichen zu erkennen.

Die translate.csv im Template Ordner erhält, beim generieren der Übersetzungen, eine niedrigere Priorität als die standard Übersetzungen. Das nimmt der Möglichkeit Übersetzungstexte mit dem Template zu liefern die bereits in der standard Übersetzungstexten enthalten sind.

Um das zu ändern kann quick and dirty die Datei app/code/core/Mage/Core/Model/Translate.php in Zeile 558 folgendermaßen editiert werden:

    /**
     * Return translated string from text.
     *
     * @param string $text
     * @param string $code
     * @return string
     */
    protected function _getTranslatedString($text, $code)
    {
    	$translated = '';
        if (array_key_exists($text, $this->getData())) {
            $translated = $this->_data[$text];
        }
        elseif (array_key_exists($code, $this->getData())) {
            $translated = $this->_data[$code];
        }
        else {
            $translated = $text;
        }
        return $translated;
    }

Am einfachsten ist es die Methode _getTranslatedString() komplett zu ersetzen. 😉

Eine schönere Möglichkeit ist es die Datei app/code/local/Mage/Core/Model/Translate.php zu erstellen, mit den Inhalten der originalen Datei app/code/core/Mage/Core/Model/Translate.php zu füllen und dabei die Methode _getTranslatedString() mit der oben abgebildeten Methode zu ersetzen.

Wer möchte kann hier den fertigen Magento 1.5.X Translate Bugfix heruntergeladen werden. Der Fix muss gemäß der im Archiv enthaltenen Ordnerstruktur in das Magento root Verzeichnis kopiert werden.

4 Kommentare »
 

Version: Magento 1.5 & 1.5.1

Das Magento Kontaktformular versendet, nach einer frischen Installation, grundsätzlich schon E-Mails. Zumindest solange darauf geachtet wird den URL Rewrite der Seite auf der sich das Kontaktformular befindet nicht zu verändern. Das bedeutet das Blöcke in denen das Kontaktformular auf anderen Seiten integriert ist ebenfalls nicht funktionieren.

Um den Fehler zu beheben lasse ich den Pfad zur Not (wenn der Pfad leer ist) statisch ausgeben. Dabei verwende ich folgenden form-Tag im Template ***Theme Pfad***/contacts/form.phtml:

<form action="<?php $action = $this->getFormAction(); if (!empty($action)) { echo $action; } else { echo Mage::getBaseUrl().'contacts/index/post/'; } ?>" id="contactForm" method="post">

Der Fehler entsteht, weil die Methode $this->getFormAction() ein leeres Ergebnis zurück liefert, wenn man sich beim Formular Absenden nicht auf der Seite mit dem Rewrite /contacts/ befindet.

Ein Manko dieser Lösung ist die automatische Weiterleitung auf die Kontaktformular Seite nach dem Absenden des Kontakformulars auch wenn das Formular als Block in eine andere Seite eingesetzt wurde.

Alle Schritte beachtet und das Formular will noch nicht? Hast du deine E-Mail Adresse auch für das Magento Kontakformular hinterlegt? Falls nicht, du findest das Feld zum Eintragen der E-Mail Adresse im Magento Backend unter:

System -> Konfiguration -> Allgemein -> Kontakte

Erwähne das, weil ich nach dem lesen des Bugfixes zusätzlich noch die passende Mail Adresse vergessen hätte. 🙂

Keine Kommentare »
 

Nach dem Update auf WordPress 3.1 war in meinem Theme auf dieser Seite ein weißer Streifen am oberen Rand (on top) des Browserfensters mit 28px Höhe zu sehen. Dieser Streifen entpuppte sich nicht als Element sondern als Style Anweisung html { margin-top: 28px !important; }.

Der Fehler entsteht durch ein neues Freature in WordPress und ist nur im angemeldetem Zustand mit entsprechenden Rechten sichtbar. Kurz: Nach dem Update sehen euere Leser nicht den weißen balken, keine Sorge.

Beheben lässt sich der Fehler durch das Einfügen der wp_footer() Funktion innerhalb des body Tags in euer Theme / Template.

Nach dem Einfügen des wp_footer() Funktionsaufrufs bekommt ihr, nach dem aktuallisieren der Browser Ansicht, die neue WordPress Frontend Toolbar zu sehen.

Not a bug, It’s a feature

 

3 Kommentare »