Wende Dich an Deinen Hoster, lt. den Anmerkungen in der PHP Dokumentation wird GLOB_BRACE nicht auf allen Systemen unterstützt.
Beiträge von b3317133
-
-
Für Änderungen direkt in den Dateien eines Themes gilt das gleiche wie für die WordPress Core Dateien. Daher gibt es in WordPress die sog. "Child-Themes" die bei Updates des "Parent Theme" nicht überschrieben werden.
Der add_filter(...) Code gehört also in die functions.php des Child-Theme oder in ein kleines Plugin.
Eine komfortablere Lösung mit dem gleichen Ansatz aber ohne Programmierkentnisse wäre ggf. die Nutzung eines fertigen Plugins wie Change Password Protected Message (ungetestet).
-
Aber ich habe ein Vermutung... Du verwendest nicht zufällig ein Retina-Gerät?
Am Rande bemerkt: Falls es nicht daran liegt, ist es manchmal die Browser-Skalierung, die nicht auf 100% steht, das führt ggf. auch zu den interessantesten Effekten.
-
Änderungen in WordPress Core Dateien im Ordner wp-includes oder wp-admin sind hier (und auch sonst) keinesfalls die Lösung. Bei WordPress Updates gehen diese verloren.
Für Änderungen von Ausgaben wie z.B. diesem Formular stellt WordPress sog. Filter zur Verfügung. Diese nutzt man z.B. in der Datei functions.php des Themes oder in einem kleinen, eigenen Plugin.
Wie der entspr. Filter in diesem Fall genutzt wird, steht relativ ausführlich in den beiden Beispielen, also z.B. so oder so.
-
Falls Du auf der Einzelseite des Custom Post Types "jugendkrimi" den "slug" dieser aufgerufenen Einzelseite benutzen willst, um dann über diesen "slug" umfunktioniert als Wert der Custom Taxonomy "reihe" entspr. Beiträge zu ermitteln, würde man den "slug" in single-jugendkrimi.php z.B. so auslesen können:
PHPglobal $post; echo $post->post_name;
bzw. in Deinem CodePHP<?php global $post; $args = array ( 'reihe' => $post->post_name, ...
Das ist aber wirklich ein "hintenrum durch die Brust ins Auge" Ansatz... -
Welcher genaue Link soll was anzeigen?
Verstehe das Konzept nach wie vor nicht wirklich. Warum werden die Posts nicht direkt im Custom Post Type eingepflegt, ggf. hierarchisch? Oder warum verwendest Du nicht die von WordPress vorgesehenen Taxonomy Templates, um die Beiträge anzuzeigen? Wozu der Umweg über einen Custom Post Type?
-
Evtl. musst Du Dein Konzept etwas genauer beschreiben. Welcher genaue Link soll was anzeigen.
Beim o.g. Link example.com/jugendkrimi/bochum-detektive/ ist 'bochum-detektive' eine Einzelseite des Custom Post Types 'jugendkrimi'.
Das heisst, Deine Datei single-jugendkrimi.php wird geladen und normalerweise würde im post_type 'jugendkrimi' nach einem Post mit Slug 'bochum-detektive' gesucht.
Du überschreibst aber die WordPress Loop Funktion mit Deinem eigenen WP_Query. Dort fehlt übrigens die Angabe post_type, so dass der o.g. Code nur in den normalen Beiträgen (post_type=post) sucht.
Es geht also einiges schief, aus verschiedenen Gründen.
-
Für Custom Taxonomies gibt es in der WordPress Template Hierarchy die Möglichkeit für eigene Templates, z.B. taxonomy-reihe.php - das ergibt dann Links wie example.com/reihe/bochum-detektive/
-
Das Formular wird von der WordPress Funktion get_the_password_form() erzeugt. Über den dort verwendeten [FONT=courier new]the_password_form[/FONT] Filter kann man den Text ändern bzw. ergänzen, z.B. so oder so.
-
..Hat mal jemand Zeit gegen Entgeld den Fehler zu beheben. ..
Dafür gibt es hier im Forum die Jobbörse. -
Genau dieses Thema wird auch bereits hier behandelt...
-
Die Mehrsprachigkeits-Plugins sorgen normalerweise dafür, dass WordPress im HTML-Code der jeweiligen Seite die passende Sprache hinterlegt, z.B. [FONT=courier new]<html lang="de-DE">[/FONT] usw. und der Suchmaschine mitteilt, ob/wo es anderssprachige Versionen der Seite gibt, z.B. [FONT=courier new]<link rel="alternate" hreflang="en" href="http://..[/FONT] oder auch als Attribut in entspr. Sprach-Icons o.ä. oder über die Möglichkeit einer eigenen XML-Sitemap je Sprache ggf. durch andere Plugins usw., es passiert da viel mehr "hinter den Kulissen" als man auf den ersten Blick sieht.
Als ganz simple Variante kannst Du auch im Text-Editor der jeweiligen Seite einen Absatz entspr. manuell im HTML-Code auszeichnen (Editor dafür auf reine Texteingabe umstellen, nicht "Visual"), dabei verzichtet man dann aber auf die o.g. eigentlich für die Suchmaschinen wichtigen Dinge.
Details zum Thema Mehrsprachigkeit in HTML hier.
-
Danke für den Tipp. Wenn es jedoch mobil nicht funktioniert, ...
Die Lösung für dieses "mobil Menü" Problem bei WPGlobus steht in diesem Thread.
Ansonsten gibt es noch weitere Plugins, dazu siehe z.B. Anwort von Hille oder auch das kostenpflichtige Plugin WPML.
-
Beim Lesen der Seite des Theme Herstellers kann man aus den Kommentaren schliessen, dass Widgets offenbar nur im "2 column page template" angezeigt werden, evtl. muss man also bei den entspr. Seiten erst dieses Seitentemplate einstellen.
-
Evtl. hilft die Dokumentation des Plugins FormCraft weiter. Je nachdem ob das Formular auf einer Folgeseite oder auf der gleichen Seite ist, gäbe es da z.B.
- How To Populate Forms With Data From URL
- How To Populate Forms With Post Data (...It also works with custom fields in your post...)
-
Wenn man die Seite des verwendeten Plugins WPGlobus überfliegt, stösst man u.a. auf die WPGlobus Mobile Menu Erweiterung:
Zitat..makes the WPGlobus language switcher menu compatible with mobile devices and narrow screens.
Evtl. wäre das eine Lösung. -
Eine Datei "aktuell.php" wird von WordPress standardmässig nicht genutzt (Ausnahme wäre eine Page Template Datei).
Welche Dateinamen normalerweise im Theme wann für was genutzt/gesucht werden, kann man gut in der WordPress Template Hierachy z.B. unter "Home Page display" sehen.
-
Diese .htaccess hat mit eingeloggten Usern gar nichts zu tun.
Sich auf den Inhalt des dort geprüften Feldes HTTP_REFERER zu verlassen, ist eine trügerische "Sicherheit", es kann von Besuchern beliebig gesetzt werden, mehr dazu hier.
-
Danke. Kann ich die DB-Präfixe der neuen Tabelle abändern?..
Probiere es doch erstmal mit dem alten Präfix, sonst wirst Du ggf. nie rausfinden, wo das eigentliche Problem liegt/lag... -
Ergänzung: Vermutlich geht es in dem o.g. "mobile Safari" Thread um ein Formular, das per Ajax in eine Seite nachgeladen wurde, z.B. als Popup o.ä.
