Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenWar dir bei der Antwort klar, dass die Daten aus einer WP-unabhängigen Datenbank kommen?
Nein, steht auch nicht in Deiner Beschreibung. Was spricht gegen das Einpflegen der Daten in WordPress?
Eine "transparente" Integration einer externen Datenbank in die WordPress-Suche geht natürlich auch, allerdings ist das dann ein Fall für die Jobbörse im Forum.
Eine regelmässige Übernahme externer Inhalte in einen CPT kann man z.B. auch zeitgesteuert automatisch machen.
.. kannst du außerdem mit wp_is_mobile explizit auf Mobilgeräte prüfen...
Aber Vorsicht, die Nutzung eines Cache-Plugins in den üblichen Standardeinstellungen ist hiermit nicht möglich.
Das An-/ oder Abschalten von Features wie Slider o.ä. sollte ausschliesslich im Client erfolgen und nicht auf dem Server entschieden werden.
Am Rande: wp_is_mobile() macht nichts anderes, als auf einige User-Agent Fragmente zu prüfen.
Man könnte in WordPress einen "Custom Post Type" für Einträge für CDBlatt erstellen und dann die Suche per post_type Parameter im POST entspr. auf den Custom Post Type begrenzen. Dadurch funktioniert diese Suche dann wie die ganz normale WordPress-Suche mit Pagination usw.
Hier sehen Thumbnail und grosses Bild gleich aus.
Das Bild kommt über irgendeinen wp.com Server, nicht direkt von Deiner Domain, evtl. liegt es daran.
Ergänzung: Vermutlich durch das Jetpack-Plugin, deaktiviere das doch mal.
Was genau soll denn passieren wenn welche URL aufgerufen wird?
Würde sagen, das Nachladen von Scripts von div. Werbe-Servern liegt am Tracker/Werbemodul "Lotame", das z.B. von Ghostery auf der Seite erkannt wird, wie/worüber auch immer das eingebunden ist. In der Folge dann auch ersichtlich aus den Redirect-Parametern.
viele Redirects und total dubiose Links
Hast Du davon ggf. mal einen Screenshot?
Also, WordPress ist schon drauf, siehe /wp-admin/install.php - allerdings eine sehr alte Version 3.8.1, siehe /liesmich.html - liegt ggf. an der index.php oder .htaccess im Hauptordner oder auch an einem auto_prepend_file o.ä. in den PHP Settings.
Oder auch an einer alten bbpress Version bzw. einem anderen Plugin. Man könnte mal per FTP testweise temporär einzelne Plugin-Ordner umbenennen.
Du kannst doch dein Browserfenster stufenlos verkleinern und vergrößern, dann siehst du ob es überall passt
Würde auch das hier empfehlen, dann sieht man gleich, was wann wie wo verschwindet/erscheint/herumspringt...
Mit OpenGraphCheck.com kannst Du testen/sehen, welche Meta-Daten des Beitrags für Facebook/Twitter o.ä. durch ein SEO-Plugin o.ä. hinterlegt sind.
Beim neusten Beitrag "Neues Mitglied" vom 24.01. ist das u.a. das Bild ".../default-user-image.png" im Format 512x512, Facebook hätte allerdings am liebsten ein Bild im Querformat mit im Optimalfall einer Auflösung von 1200x630, mehr dazu hier.
Würde also entweder im Beitrag die WordPress-Funktion "Beitragsbild" rechts im Sidebar verwenden, oder im SEO-Plugin ein entspr. passendes Bild für diesen Beitrag einpflegen.
Ergänzung: Der Punkt "auf Vorschau gehe, in der Vorschau des Beitrages dann diesen auf FB teilen will" ist die falsche Vorgehensweise. Geteilt bei Facebook wird der Beitrag erst nach dem Publizieren. Facebook kann natürlich nicht von aussen auf die Vorschau eines Beitrag zugreifen. Gleiches gilt übrigens natürlich auch für OpenGraphCheck o.ä.
Klar wäre das schön, hoffe mal er verfolgt das hier.
Wie sollte er das hier finden? Warum kontaktierst Du ihn nicht direkt? Plugin-Seite > Autor-Name -> seine Homepage -> E-Mail & Telefon im Impressum.
Wahlweise könntest Du natürlich auch das dafür gedachte Support-Forum nutzen.
Der erste Standardpunkt bei gekauftem Plugin wäre: https://www.megamenu.com/support/
Kleiner Tipp (für alle): Einstellungen -> Permalinks speichern erzeugt eine ggf. fehlende .htaccess neu.
Einmal Einstellungen -> Permalinks speichern.
Falls das nicht hilft, am besten Umzug neu machen mit Plugin Duplicator (Video anschauen, klärt viele Fragen), damit ist keine "Handarbeit" nötig.
Das Plugin wird offensichtlich aktiv betreut, frage doch einfach mal den Plugin-Autor, ob er Deine Anpassungen übernehmen möchte. Sonst musst Du die Anpassungen beim nächsten Update alle wieder per Hand "reinhacken".
Von überhasteter Umstellung war keine Rede. Aber von alles-bleibt-immer-beim-alten auch nicht.
Plugin- oder Theme-Autoren kann man relativ leicht entspr. Code-Fixes vorschlagen, viele Autoren nehmen das erfahrungsgemäss auch sehr gerne an, und wenn nicht, dann ist das ein guter Zeitpunkt, das Plugin/Theme auf die spätestens-mittelfristig-austauschen Liste zu setzen bzw. sich ähnliche Plugins/Theme zu suchen und bei Bedarf deren Autoren entspr. zu unterstützen.
So haben dann am Ende alle was davon, win-win, bzw. sogar win-win-win: Plugin-Autor, man selbst und noch der Rest der Community.
Die Weiterentwicklungsgeschwindigkeit ist natürlich nicht bei allen Projekten gleich schnell möglich, wir bevorzugen hier aber schon ein vergleichsweise aktives Vorgehen. Ausser bei WordPress selbst, da warten wir immer auf eine .2 subrevision oder je nach trac-Inhalt sogar noch etwas länger, bei 4.7 war das wieder mal goldrichtig.
Glückwunsch zur Problemlösung!
Früher oder später werden jedoch viele/alle Hoster auf PHP7.x umstellen, also ist es sicher kein Schaden, trotzdem der Sache auf den Grund zu gehen, immerhin hast Du für Theme-Support bezahlt und es ist am Ende evtl. sogar eine win-win Situation für Dich und den Support, wenn Du klar sagen kannst, dass das Problem abhängig von der PHP-Version ist.
Das sind einfache Media Queries anhand der Browserbreite, die müsste das Nexus schon selbst erkennen.
Vermute auf den ersten Blick irgendein Problem mit der CSS Einheit [FONT=courier new]vh[/FONT], denn die ist eben doch nicht so durchdacht wie man sich das mal vorgestellt hat, z.B. mit [FONT=courier new]100vh[/FONT] und iOS gibt es auch oft Probleme...
Schiebe das Browserfenster am Desktop in der Breite zusammen, dann kannst Du die Breakpoints schön nachvollziehen.
Edit: Das aufklappende Menü könnte man via JS sichtbar machen (= runterscrollen), aber ob das a) intuitiv bleibt und b) gut aussieht, wohl eher nicht.
Mehrfacher Aufruf ist kein Problem, [FONT=courier new]get_post_meta()[/FONT] nutzt intern den WordPress Object Cache.
Und wenn ein Post z.B. sehr viele post meta hat, z.B. durch manche SEO-Plugins, Übersetzungs-Plugins o.ä., dann bekommt man beim Abholen aller Daten auf einmal auch noch viel zu viel zurück.
Und bzgl. Überprüfung, alleine vor [FONT=courier new]$var['custom_field_b'][0][/FONT] müsste man schon manuell prüfen, ob [FONT=courier new]$var['custom_field_b'][/FONT] überhaupt existiert und dazu noch kein leeres Array ist, bringt unnötige Komplexität rein.
Nein. Ohne Cookie-Banner erscheint eine Menüzeile mit entspr. Dropdown-Untermenüs beim Drüberfahren, die man aber nicht sieht. Ab einem bestimmten Breakpoint wird die Menüzeile zweizeilig und dann ab einem weiteren Breakpoint erscheint das Icon für das mobile Menü ein Stück weiter oben. Dafür wird die Höhe von [FONT=courier new].custom-header[/FONT] vom Theme auf [FONT=courier new]75vh[/FONT] gesetzt, evtl. hat das Nexus Probleme mit der Einheit [FONT=courier new]vh[/FONT] als Höhe?
