Beiträge von b3317133

Für Mitleser, verantwortlich für den Pfad war eine sog. Anhangseite für eine Datei Wochenkarte.pdf in der Mediathek.

Schau mal in Deine Mediathek...

Zitat von Am Ende des Lateins

Was war mein Fehler? Was habe ich nicht bedacht?

In der ACF Plugin-Dokumentation ist beschrieben, was [FONT=Courier New]get_xx()[/FONT] und [FONT=Courier New]the_xx()[/FONT] machen...

Weitere Lektüreempfehlung: esc_attr()

Der Fehler 500 tritt nicht mehr auf, wenn alle Plugins deaktiviert sind. Das deutet auf Überlastung des Hostings hin wenn alle Plugins aktiviert sind. Also doch finde erstmal das entspr. "zu hungrige" Plugin raus usw.

Warum dieser Konverter ansonsten nicht funktioniert, ergäbe sich ggf. aus dem error-log oder aus weiteren Tests z.B. mit anderen PHP-Versionen, WordPress-Versionen, Anzahl von Tags, Nachlesen bzgl.Kompatibilität im entspr. Support-Forum des Plugins, usw.

Und was ist unter "Einstellungen > Lesen" bei "Homepage" eingestellt?

Stelle bei "Homepage" Deine aktuelle statische Startseite ein, und bei "Beitragsseite" eine leere neue Seite, die Du dann ins Menü einfügen kannst. So funktioniert das bei den meisten Themes. Ansonsten hilft ggf. auch die Theme-Dokumentation weiter.

Ist eine Beitragsseite unter "Einstellungen > Lesen" eingestellt? Falls ja, nutze diese als Menü-Eintrag.

Zitat von Am Ende des Lateins

Jetzt habe ich noch probiert, was passiert wenn ich bei

Die Parameter sind in der the_post_thumbnail() Dokumentation unter "User Contributed Notes" ganz gut erklärt. Eingabefelder werden dadurch nirgends erzeugt.

Jetzt ist ungültiger HTML-Code vorhanden...

<class="post-thumbnail" aria-hidden="true">

Die ganze Zeile ist der öffnende Teil des Tags, den Du entfernen willst.

Ggf. etwas zu HTML-Grundlagen nachlesen, der Aufbau von HTML-Tags hat mit WordPress nichts zu tun.

Dann grenze am besten durch einzelnes nacheinander Aktivieren von Plugins ein, welches Plugin den Fehler verursacht und überlege, ob Du das zwingend brauchst, und falls ja, wende Dich an Deinen Provider für ein Hosting-Upgrade o.ä. auf einen leistungsfähigeren Account.

Im Bereich "Seiten" beim Bearbeiten des Menüs sollte sich im Tab "Alle anzeiten" eine "Startseite" befinden, füge die dem Menü hinzu und passe dann im Menü den "angezeigten Namen" ggf. wie gewünscht an.

Zu einem Anchor Tag [FONT=Courier New]a[/FONT] gehört der öffnende [FONT=Courier New]<a ...>[/FONT] und der schliessende [FONT=Courier New]</a>[/FONT] Teil des Tags. Der öffnende Teil ist nach wie vor vorhanden...

<a class="post-thumbnail" aria-hidden="true">

Der Fehler kommt möglicherweise einfach von einem überlasteten Hosting, die Meldung stammt auf jeden Fall so nicht direkt aus WordPress. Probiere es mal mit allen sonstigen Plugins deaktiviert, ist der Fehler dann genau gleich nachstellbar?

Jetzt erscheint in allen Browsern (Firefox, Chrome, IE) direkt eine 401 Seite ohne Abfrage von Zugangsdaten. Möglicherweise stimmt der [FONT=Courier New]AuthUserFile[/FONT] Pfad nicht. Wende Dich am besten an ein Forum zum Thema Apache bzw. .htaccess - mit WordPress hat das nichts zu tun.

Erstelle in [FONT=Courier New]functions.php[/FONT] des Child-Themes eine Kopie der Funktion [FONT=Courier New]twentysixteen_post_thumbnail()[/FONT] aus der [FONT=Courier New]inc/template-tags.php[/FONT] des Parent Themes und entferne dann im Child-Theme den Link. Weitere Info, warum das so funktioniert, gibt es z.B. hier, Thema "pluggable" (google).

Edit: Dateiname der Quelle im Parent Theme korrigiert, siehe auch @maxe

Hier erscheint derzeit in keinem Browser ein .htaccess Schutz.

Die empfohlene Minimalgrösse für Uploads beträgt bei MH Magazine lt. Theme-Dokumentation 1030 x 438 Pixel.

Dein aktuelles Bild ist nur 197 Pixel breit. Lade ein Bild hoch, das mind. 1030 Pixel breit ist.

Link zu einer Seite wo man das sehen kann? Screenshot wie es bei Dir aussieht? Betrifft es alle Browser?

Die empfohlene Minimalgrösse für Uploads beträgt bei MH Magazine lt. Theme-Dokumentation 1030 x 438 Pixel.

Wenn Du alles manuell im header einpflegen willst, benötigst Du als ersten Ansatz die WordPress Conditionals, aber wie gesagt, das ist ein Irrweg. Am besten macht man es mit einem Mehrsprachigkeitsplugin. Viel Erfolg, bin raus.

Zitat von Rumeri

.. bei verschiedenen Hoster untergebracht (Unabhängigkeit).
Von einem Plugin möchte ich aber absehen.
Oder gibt es hier Plugin-Möglichkeiten nur für die hreflang Implementierung?

Logischerweise kann es kein Plugin nur für href geben, wie sollte ein Plugin denn wissen, welche Seite im einen WordPress beim einen Hoster Du als Übersetzung einer Seite im anderen WordPress beim anderen Hoster betrachtest?

Für diese Problemstellung und um den vielen Aufwand zu vermeiden gibt es Mehrsprachigkeitplugins, die auf Basis von Unterordnern oder Subdomains oder Domains arbeiten können, mehr dazu z.B. hier (google), aber wie beschrieben logischerweise nicht auf Basis unterschiedlicher Hoster.

Du könntest mit noch viel, viel mehr Aufwand ein spezielles Plugin selbst erstellen (lassen), das via irgendeinem Mechanismus wie REST API o.ä. passende Seitenbezüge speziell zwischen Deinen verschiedenen WordPress Installationen anbieten und manuell absegnen lassen könnte, aber wirtschaftlich ist das sicherlichlich nicht.

Die diversen Mehrsprachigkeitsplugins für WordPress setzen diese Links und die Bezüge zwischen den übersetzten Seiten usw. automatisch.

Wird ein Mehrsprachigkeitsplugins verwendet?