Blog Archiv

Problem: Auf einer Kundenseite war auf den meisten Seiten im Footer des Themes die Übersetzung von Strings mittels WPML String translation und

1
_e('der Text der übersetzt wird', 'Sprachdomain')

in der richtigen Sprache sichtbar. Auf einigen wenigen Seiten war nur der deutsche String sichtbar, die Übersetzung in französisch funktionierte dort nicht. Die Tips aus den WPML-Foren halfen allesamt nicht, Stichwort „Look for strings while pages are rendered“ auf der String Translation Seite, bewirkte zwar das gewünschte Ergebnis, ist aber nur eine temporäre Lösung. Bei weiteren Recherchen fand ich heraus, dass das Problem nur auftrat, wenn das Plugin Contact Form 7 installiert ist.

Lösung:

Das Plugin Contact Form 7 Multilingual muss installiert und aktiviert sein, nur so wird der richtige String ausgegeben. Keine Ahnung warum ich damals diesen Plugin nicht verwendet habe, nach dem Aktivieren desselben funktioniert nun alles wie erwartet.

Wir hatten bei einer grossen TYPO3 Seite (TYPO3 10.4.15) nach dem Update das Problem, dass von Zeit zu Zeit die Navigation(en) sämtliche Links verloren, dh die sprechenden URLs in den Links auf der ganzen Seite waren weg, es wurde immer auf die Startseite verlinkt.
Ich vermutete ein Problem mit dem Routing, nach dem Löschen des Frontend-Caches funktionierte alles wieder normal.
Keine Fehlermeldungen im Backend oder der JS-Console.

Ein Post in der deutschsprachigen Facebookgruppe TYPO3 Fragen, Antworten – inoffizielle Gruppe verhalf schliesslich zur Lösung. Sven Wappler hat herausgefunden, dass der veraltete Typoscript-Parameter config.linkVars = L unter Umständen von Bots missbraucht wird und deshalb die Seiten fehlerhaft generiert werden können.

Parameter entfernen, Caches löschen – Problem gelöst!

Post bei TYPO3 Fragen, Antworten – inoffizielle Gruppe
Post bei Stackoverflow
Lösung bei Sven Wappler

Seit längerem kämpfte ich mit dem Problem, dass gelöschte Imap Ordner in Mozilla Thunderbird nach jedem Neustart als Phantom-Ordner wieder in der Ordnerliste erschienen. In kursiver grauer Schrift.

Alle Lösungen aus dem Mozilla Forum wie löschen der Files im Profile pancea.dat und *.msf brachten nichts.

Erst der Beitrag bei Stackoverflow bzw ein Kommentar des Beitrages offenbarte die Lösung: Auf dem Server existiert in der Mailbox ein File namens subscriptions in welchem die Ordnerstruktur der Mailbox geschrieben steht. Nach Editieren dieses Files, Löschen der nicht benötigten Ordnerbezeichnungen und Neustart von Thunderbird sind die Phantom-Ordner verschwunden.

Link zur Beschreibung der Lösung im deutschen Thunderbird Forum

 

Beim Umzug zu einem neuen Hoster oder der Kopie einer Webseite kann das Umbenennen des Datenbank-Prefix einer WordPress Datenbank dazu führen, dass der Administrator nich mehr ins Backend einloggen kann.

Es reicht nicht in der Options-Tabelle den Wert zur neuen Url bei siteurl sowie home zu ändern, es müssen auch alle Werte in den Tabellen Options sowie Usermeta geändert werden, welchen den alten Prefix beinhalten.

Datenbank-Prefix

Es reicht nicht nur siteurl und home zu ändern

 

Datenbank-Prefix suchen

Dazu kann man in Phpmyadmin folgende Abfrage zum Suchen solcher Einträge erstellen:

1
SELECT * FROM 'neuerprefix_options' WHERE 'option_name' LIKE 'alterprefix_'

sowie

1
SELECT * FROM 'neuerprefix_usermeta' WHERE 'meta_key' LIKE 'alterprefix_'

Datenbank-Prefix ersetzen

Anschliessend die Einträge direkt oder mit der Suchen-Ersetzen Funktion auf den neuen Prefix ändern. Dann klappt es auch wieder mit dem Einloggen.

Gefunden bei endurtech.com

Nach einer Umstellung der URL auf eine Umlautdomain in WordPress zeigte der Browser

ERR_TOO_MANY_REDIRECTS (zu viele Weiterleitungen).

Die üblichen Fehlerbehebungen wie Cache leeren, Cookies löschen und Plugins deaktivieren half alles nichts.

Erst ein Post von PAS solutions half mir auf die Sprünge: Die Urls müssen punycodiert werden, also statt zB. sönicht.ch muss xn--snicht-wxa.ch in die Felder WordPress-Adresse und WordPress-Url unter Einstellungen eingetragen werden.

Nach dem Update einer Webseite von 7.6 auf 9.5 hatten wir das Problem, dass die Erweiterung tinyaccordion im Frontend folgenden Fehler produzierte:

tinyaccordion nach Update auf 9.5

Eine Anfrage in der Facebookgruppe TYPO3 Fragen, Antworten – inoffizielle Gruppe half weiter: Durch das Installieren der Erweiterung typo3db_legacy wird die benötigte Kompatibilität zu den veralteten SQL-Abfragen wieder hergestellt.

Danke an Manuel Rotschkar.

Manchmal möchte man eine Landingpage der eigentlichen Webseite vorschalten, damit Besucher nicht den Passwortschutz oder die Baustelle der Webseite sehen. Somit wird beim Aufruf der Seite direkt index.html aufgerufen, durch Anhängen von index.php an die URL kann die WordPress Seite angezeigt werden.

Eigentlich sehr einfach machbar in dem File .htaccess:

1
DirectoryIndex index.html index.php

ABER: WordPress ignoriert dies, darum im functions.php des Themes folgende Zeile einfügen:

1
remove_filter('template_redirect', 'redirect_canonical');

Anschliessend Browser-Cache löschen und neu laden.

Menü mit aufklappbarer Suche

Immer wieder benötigt: Ein Such-Icon am Ende der horizontalen Navigation, welches sich auf Klick öffnet/schliesst.

Bearbeitet werden 3 Dateien: functions.php, searchform.php (falls vorhanden, ansonsten neu anlegen) und style.css (oder das jeweilige Stylesheet).

functions.php

Fügt am Ende des Hauptmenüs einen zusätzlichen Menüpunkt mit der Suche ein.

1
2
3
4
5
6
7
8
9
function fb_add_search_box ( $items, $args ) {
 
       // only on primary menu (or your menu-name)
       if( 'main-nav' === $args -> theme_location )
             $items .= '<li class="menu-item menu-item-search">' . get_search_form( FALSE ) . '</li>';
 
       return $items;
 }
 add_filter( 'wp_nav_menu_items', 'fb_add_search_box', 10, 2 );

searchform.php

Angepasstes Suchfeld.

1
2
3
4
5
6
<form role="search" method="get" class="search-form" action="<?php echo home_url( '/' ); ?>">
	<label>
	<input type="submit" class="search-submit button" value="<?php echo esc_attr_x( 'Search', 'yourtheme' ) ?>" />
		<input type="search" class="search-field" placeholder="<?php echo esc_attr_x( 'Suchen...', 'yourtheme' ) ?>" value="<?php echo get_search_query() ?>" name="s" title="<?php echo esc_attr_x( 'Search for:', 'yourtheme' ) ?>" />
	</label>
</form>

style.css

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
.menu-item-search .search-field {
	background-color: transparent;
	background-image: url(../images/lupe.svg);
	background-position: 5px center;
	background-repeat: no-repeat;
	background-size: 24px 24px;
	border: none;
	cursor: pointer;
	height: 37px;
	margin: 3px 0;
	padding: 0 0 0 34px;
	position: relative;
	-webkit-transition: width 400ms ease, background 400ms ease;
	transition:         width 400ms ease, background 400ms ease;
	width: 0;
}
 
.menu-item-search .search-field:focus {
	background-color: #fff;
	border: 1px solid #32B561;
	cursor: text;
	outline: 0;
	width: 200px;
}
.search-form
.search-submit { 
display:none;
}

Zusammengestellt aus folgenden Quellen:

Wieder einmal ein leidiges RealUrl Problem: Eine Multidomain-Seite funktionierte prinzipiell prächtig, nur bei fehlerhaften Einloggen oder beim Ausloggen der Fe-User trat das lästige „Segment 1 was not a keyword for a postVarSet as expected“ auf. Felogin ohne RealUrl funktionierte jedoch anstandslos.

Lösung:

In der RealUrl-Config fehlte in der Sektion init der Wert

1
'postVarSet_failureMode' => ' '

Nachdem Einfügen dieses Wertes funktioniert nun alles wie gewünscht.