Ich hatte die Komplexität des Pakets WordPress gesehen. Hier einfach etwas zu ändern, damit das dann passt, war nicht einfach. In dem Fall ist es immer besser, zu schauen, was andere so machen.
Also meldete ich mich im WordPress Forum an und suchte denjenigen, der schon einmal einen Blog in ein Subdomain gelegt hatte und nicht das Logo noch einmal dort speichern wollte.
Yanur Islam Piash hatte vor 9 Monaten genau dieses Problem und fragte in einem Forum, wie er den Link für das Logo setzen kann. Die Antwort kam schnell und verriet, wie Anpassungen von Themes gemacht werden sollten:
function my_custom_logo_link() {
$custom_logo_id = get_theme_mod( 'custom_logo' );
$html = sprintf( '%2$s',
esc_url( 'oceanwp.org' ),
wp_get_attachment_image( $custom_logo_id, 'full', false, array(
'class' => 'custom-logo',
) )
);
return $html;
}
add_filter( 'get_custom_logo', 'my_custom_logo_link' );
Bei WordPress kann ich also per functions.php in der Child Theme den normalen Ablauf nachträglich verändern. Das las sich doch ganz gut. Ich fragte mich, wie effizient das denn sein möge. Da wird zunächst per Abfrage in einer Datenbank die URL eines Logos ausgerechnet, dann aber verworfen und ein Pfad eingetragen.
Hat das mit WordPress überhaupt Sinn? Kurz hielt ich inne. Dann wandte ich die Regel „Optimieren kommt später“ an und widmete mich den Anpassungen.
So minimal wie möglich wollte ich die Änderungen in der Child Theme halten. Ich brauchte nur functions.php und sonst nichts weiter. Also löschte ich alle anderen Dateien in Ordner Bhari-Child. Überrascht stellte ich fest, dass der Blog die Standard Theme anzeigte. Was war passiert?
In den Einstellungen war keine Bhari-Child Theme mehr zu sehen. Das Verzeichnis war noch da, aber WordPress sucht nach einem styles.css, damit das als Theme gilt. Ich wollte Änderungen im css über das Feld „zusätzliches CSS“ im Customizer machen. Also legte ich eine leere styles.css an und alles war wieder gut.
Den Customizer habe ich dann um die Angabe von dem Pfad zum Logo erweitert. Das liest sich gut, aber hat auch wieder ein paar Haken und Fallstricke.
function your_php_code( $wp_customize ) {
$wp_customize->add_setting( 'logo_url', array(
'capability' => 'edit_theme_options',
'default' => 'logo.gif',
'sanitize_callback' => 'sanitize_text_field',
) );
$wp_customize->add_control( 'logo_url', array(
'type' => 'url',
'section' => 'title_tagline', // Add a default or your own section
'label' => __( 'Logo' ),
'description' => __( 'Pfad zum Logo.' ),
) );
$wp_customize->remove_control( 'custom_logo' );
}
add_action( 'customize_register', 'your_php_code' );
Nur ein Control zu erzeugen und mal sehen, ob das ganze funktioniert geht bei WordPress nicht. Mit add_setting gebe ich an, was ich setzen will und mit add_control sage ich, dass es eine URL sein soll.
Die Anzeige des Logos machte ich dann über diese Funktionen in functions.php:
function my_custom_logo_link() {
$custom_logo_url = get_theme_mod( 'logo_url' );
if ( $custom_logo_url ) {
$custom_logo_attr = array(
'class' => 'custom-logo',
'itemprop' => 'logo',
);
$html = sprintf( '<a href="%1$s" class="custom-logo-link" rel="home" itemprop="url">%2$s</a>',
esc_url( 'https://www.gawehns.de' ),
'<img src="' . $custom_logo_url . '" border="0">'
);
}
// return "<img alt='" . $custom_logo_url . "' src='https://www.gawehns.de/gawehns.gif' border='0'>";
return $html;
}
add_filter( 'get_custom_logo', 'my_custom_logo_link' );
Die harte Angabe der Logo-Url half bei der Entwicklung ungemein. Sie war immer der Punkt, an dem ich sicher zurückkehren konnte. Dann konnte ich noch einmal sehen, dass ich etwas Funktionierendes habe. Solche Punkte helfen mir immer, obwohl das eigentlich unnütz ist, weil nichts Neues gelernt wird. Ich hatte das ja schon einmal so gesehen. Aber mit einem Fehlschlag leidet ja das Unbewusste. Das muss dann wieder aufgebaut werden.
Nun fehlte mir nur noch die richtige Farbe für den Header. Es sollte das komische Gelb sein. Die Menüleiste wollte ich auch so färben.
Wie wird so etwas umgesetzt?
In den Foren fand ich folgende Statements, die aber nicht so richtig funktionierten:
.site-header,
.main-navigation,
.main-navigation ul ul {
background: #ffffcc;
color: #000
}
Das mit dem Main Navigation bezeichnet die Klasse im css. Aber klappen wollte das einfach nicht. Hier entschloss ich mich, einfach mal im support forum des bhari Templates nach zu fragen.
Nach dem Mittagessen war die Lösung da:
.main-navigation a {
color: #000;
}
.main-navigation .current-menu-item a,
.main-navigation a:focus,
.main-navigation a:hover {
background-color: #ffff95
}
Einbauen und schon klappt das mit den Farben. Ich finde das Gelb ein wenig gelber zu machen, passt ganz gut.
Damit hatte ich zum einen meine Anpassungen fertig, zum anderen die Gewissheit bei WordPress eine aktive Gruppe von freundlichen, hilfsbereiten Forenmitgliedern zu haben. Ich fügte noch ein Zählplugin hinzu. Es nennt sich Statify und wurde von einem pluginkollektiv entwickelt. Hier gab es den ersten Hinweis auf den Cache. Wenn so etwas verwendet wird, muss ein wp_footer() aufgerufen werden.
Damit klärte sich dann auch die Frage nach der Performanz. In einem Cache werden die wichtigen Seiten gehalten. Diese werden schnell dargestellt. Nur für Seiten, die nicht so wichtig sind, gibt es die Erzeugung von verkehrten Inhalten, die durch eine Anpassung nachträglich wieder geändert werden.