Beiträge von b3317133

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.

Zitat von niclas

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.

Zitat von Reshoka

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

Offenbar kommt Deine Installation nicht mit dem Mix aus alten und neuen Daten und dazu noch angepasstem DB-Prefix o.ä. klar, es wäre am Rande bemerkt auch verwunderlich, wenn sowas klappen würde.

Ein Lösungsansatz mit weniger Konfliktpotenzial wäre die Komplettübernahme aller Tabellen der alten DB in die (zuerst geleerte) neue DB, bei gleichbleibendem DB-Prefix.

Etwas off topic: Könnte jemand mit Zugriff auf ein "mobile Safari" bitte testen, ob/wann diese Meldung hier bzgl. CF7 4.8 zutrifft? Wäre ein weiterer Rollback-Grund... :-x

Lösche den Ordner /wp-content/plugins/silicon-counters - die in dem Plugin verwendeten Funktionsnamen kollidieren offenbar mit dem Plugin social-count-plus

Zitat von Henk1060

Wenn in deinen Theme keine [404.php] vorhanden ist, kannst du selbst eine erstellen ...

..und zwar auf Basis der Datei index.php des Themes. Welche Datei von WordPress für welchen Zweck in welcher Reihenfolge gesucht wird und welche als mögliche Alternative wird bzw. als Quelldatei für eigene Anpassungen verwendet werden kann, kann man sehr schön in der WordPress Template Hierarchy sehen.

Hier funktionierte es, wenn man bei der iframe das width-attribut direkt im HTML einfach hoch setzt. Man kann den responsive-Effekt natürlich auch sehen, indem man die iframe URL cruiseportal.de/modul/vs2/welcome.html?ref=cruiseportal direkt alleine im Browser lädt und dann die Fenstergrösse anpasst. Zum Thema Support stimme ich klar zu.

Zitat von Edi

Allerdings weiss ich nicht, was daran responsiv sein soll.

Der Inhalt passt sich an jeweils unterschiedliche iframe Breiten an, nur ist die Seite cp_demo-responsive.php selbst nicht repsonsive, daher merkt man das nicht. :lol: :roll:

Zitat von marcusfuerth

Die Agentur stellt aber auch XML Dateien und JSON Dateien zur Verfügung.
Hat man hiermit die Möglichkeit, diese irgendwie in Wordpress zu hinterlegen? So eine Art Schnittstelle etc.?!

Wenn man eine entspr. Schnittstelle baut, dann ja.

Wenn es um die reine Anzeige von Daten auf je einer Seite geht, kann man diese via XML oder JSON periodisch in einen Custom Post Type importieren, den man ggf. mit ACF Feldern ergänzt.

Sollen dagegen auch Buchungen vorgenommen werden, würde sich eher der Ansatz via iframe empfehlen, z.B. via Plugin, und keine sonstige Integration in WordPress, denn das dürfte dann zu komplex werden.

Das Formular kommt aus dem WordPress Core von get_the_password_form(), d.h. der Code ist bekannt.

Den Text und den Inhalt des Formulars kann man über den dort verwendeten [FONT=courier new]the_password_form[/FONT] Filter ändern, eine Unterscheidung, ob (noch) kein Passwort angegeben wurde oder ob es falsch war, ist dabei nicht direkt vorgesehen, das müsste man innerhalb des eigenen Filters dann ggf. über das [FONT=courier new]$_COOKIE[ 'wp-postpass_' . COOKIEHASH ] [/FONT][FONT=courier new])[/FONT] Cookie heausfinden.

In Deiner robots.txt (und in allen, die ich sonst kenne) ist kein einziges Zeichen, das eine UTF-8 Kodierung erfordern würde. Daher kannst Du die robots.txt auch einfach als ANSI o.ä. speichern und hochladen.

WordPress setzt die class-Namen nur dann automatisch richtig, wenn man vorhandene Seiten, Beiträge, Archivseiten, Kategorien usw. in das Menü einfügt.

Beim Einfügen manueller Links musst Du die class-Namen selbst setzen. Das Einfügen manueller Links in ein WordPress Menu sollte die absolute Ausnahme sein.

Das erste Zeichen (bzw. genauer die erste drei Bytes) in der robots.txt (auf dem Screenshot der rote kleine Kringel) ist ein UTF-8 BOM, der dort nichts verloren hat. Du kannst diese Zeichen/Bytes sehen, wenn Du Deine robots.txt mit einem Hex-Editor anschaust oder z.B. hier hochlädst.