Beiträge von b3317133

JABA-Hosting: Das Wichtigste nicht vergessen, die entspr. Sicherheitslückle identifizieren und stopfen!

Platt machen/neu installieren/reinigen alleine reicht nicht aus.

Bei der Einbindung externer Daten bist Du für solche Dinge selbst zuständig.

Woher sollte die interne WordPress Pagination wissen, wieviele Einträge es zu irgendeiner Suche noch in der externen Datenbank gibt usw.

Du könntest alternativ die entspr. Funktionalitäten selbst in Deinem Code nachbauen. Dabei lernt man dann auch WordPress ganz gut kennen (und kommt evtl. auf die Idee, das ein regelmässiger Import der Daten sogar inkl. Custom Fields oder Custom Taxonomies usw. am Ende gar kein so komplizierter Weg ist, auch was SEO-Möglichkeiten, Feeds, Kommentare und sonstige WordPress Funktionen angeht).

Zitat von StephanZ

War 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.

Zitat von mkronenfeld

.. 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.

Zitat von kris9k

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.

Zitat von am3

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.ä.

Zitat von ssv

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.