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.

Wird beim Indexieren von Seiten die Fehlermeldung The path to pdftools is not correctly set in the extension manager configuration. You can get the path with „which pdfinfo“ or „which pdftotext“ generiert obwohl der Pfad in der Extension-Konfiguration richtigangegeben ist, kann es am open_basedir liegen. Hier muss /usr/bin freigegeben sein, da mit is_file nach der jeweiligen Tool (catdoc usw.) gesucht wird.

Gefunden in den Kommentaren auf der Extensionseite.