Beiträge von b3317133

Vermutlich läuft eine andere/neuere PHP Version auf dem neuen Server, zu der die verwendete Theme Enfold Version nicht kompatibel ist, siehe z.B. auch hier im Enfold Forum.

Evtl. fehlen Updates des Themes. Am besten kann hier der Theme Enfold Support weiterhelfen, den hast Du mitgekauft.

Das geht z.B. direkt in der Datenbank via phpMyAdmin über das Hosting.

Link zur Seite wo man diese weiße Leiste ansehen kann? Siehe auch Forenregeln, Punkt II.

Für eigenen Code nutzt man am besten ein Child Theme oder ein eigenes kleines Plugin:

<?php
/*
Plugin Name: Seitenpasswort in Kleinbuchstaben konvertieren
Author: b3317133
Update URI: false
*/
function lc_login_form_postpass() {
   if ( !empty( $_POST['post_password'] ) )
       $_POST['post_password'] = strtolower( $_POST['post_password'] );
}
add_action( 'login_form_postpass', 'lc_login_form_postpass' );

Link zur Seite? Siehe auch Forenregeln, Punkt II

Du kannst z.B. das Passwort für die Seite in Kleinbuchstaben hinterlegen und damit die Eingabe vor dem Vergleich in Kleinbuchstaben konvertieren:

function lc_login_form_postpass() {
   if ( !empty( $_POST['post_password'] ) )
       $_POST['post_password'] = strtolower( $_POST['post_password'] );
}
add_action( 'login_form_postpass', 'lc_login_form_postpass' );

Kann die unterschiedlichsten Gründe haben. Probiere es mit unterschiedlichen Browsern. Deaktiviere temporär andere Plugins. Besteht das Problem bei allen Seiten oder nur bei einer? Was steht in der Browser Konsole wenn das Problem auftritt?

Zitat von pixselig

...TinyMCE und klassische Metafields wirken 2022 einfach hoffnungslos veraltet..

Daher nutzt seit vielen Jahren niemand mehr nur TinyMCE und klassische Metafields sondern mindestens sowas wie ACF bzw. sonstige komplexere Page Builder Plugins bzw. Themes.

Das Gutenberg Projekt ist den seit Jahr und Tag bestehenden Lösungen trotz vielfacher Bemühungen nichtmal ansatzweise gleichauf, auch wenn sich die entspr. Bubble das stetig reihum selbst versichert. Wer Gutenberg jenseits von ein paar Text und Bild Blöcken einsetzen will oder muss, lernt sehr schnell die Grenzen dieses Projekts in maximal beta Zustand kennen. Und wer eigene Blöcke lt. Doku soweit verfügbar erstellt hat, der durfte und darf diese nach jedem Release erneut prüfen und anpassen. Gesamt gesehen mehr Schaden als Nutzen für WordPress.

Was konkret ist falsch an der abgebildeten Struktur? Wo liegt der Fehler? Das ist augenscheinlich eine so gewünschte mobile Version des Websites die über das og. extra dafür verwendete Plugin dargestellt wird. Wende Dich am besten an die Person, die den Website so eingerichtet hat.

Was konkret lädt nicht korrekt? Was ist falsch? Was sollte anders sein?

Am Rande bemerkt: Das offenbar verwendete Plugin WP Mobile Edition ist uralt und wurde aus dem Plugin Repository entfernt..

Deaktiviere das Plugin WP Super Cache, bis das Problem gelöst ist.

1. Ein Shortcode gibt nichts direkt über [FONT=Courier New]echo[/FONT] aus sondern den auszugebenden Inhalt am Ende mit [FONT=Courier New]return $content;[/FONT] o.ä. zurück, siehe ShortCode API Dokumentation.
2. Die Anzahl und Art der Parameter des Callbacks [FONT=Courier New]projectcharter_form()[/FONT] ist falsch, siehe [FONT=Courier New]add_shortcode()[/FONT] Dokumentation
3. Das Einfügen der [FONT=Courier New]$_POST[][/FONT] Werte in [FONT=Courier New]value=".."[/FONT] ist 3x falsch, 1. die einzufügenden Variablen sollten aus [FONT=Courier New]$_POST[][/FONT] gelesen werden, 2. es fehlt esc_attr(), 3. der Fallback sollte leerer String sein, nicht [FONT=Courier New]null[/FONT].
4. Das [FONT=Courier New]action[/FONT] Attribut im [FONT=Courier New]form[/FONT] Tag lässt man leer oder weg, wenn die aktuelle Seite als Ziel gedacht ist.

function projectcharter_form( $atts, $content = null ) {
    $content = '<form method="post">
<input type="text" name="p_name" value="' . stripslashes_deep( esc_attr ( isset( $_POST['p_name'] ) ? $_POST['p_name'] : '' ) ) . '">
<input type="submit" name="submit" value="Speichern" />
</form>';
    return $content;
}
add_shortcode( 'example_projectcharter', 'projectcharter_form' );

(2. geändert, 3. & 4. ergänzt, Code ergänzt)

Derzeit ist dort [FONT=Courier New].tablepress -id-2 {..}[/FONT] statt nur [FONT=Courier New].tablepress {..}[/FONT] oder [FONT=Courier New].tablepress-id-2 {..}[/FONT] eingefügt, es ist also ein überzähliges Leerzeichen vor [FONT=Courier New]-id-2[/FONT] im Code.

Siehe auch Ende der autogenerierten CSS-Datei von Tablepress:

https://staging.glas-steenebruegge.de/wp-content/tablepress-combined.min.css?ver=10

Beschäftige Dich noch etwas mehr mit pre_get_posts, probiere Dinge aus usw., dann ergeben sich daraus alle nötigen Möglichkeiten.

Und man macht eine Funktion nie kaputt sondern reagiert nur bei Bedarf, z.B. wenn Dein Custom Field vorhanden ist, oder ein Passwort in speziellem Format o.ä.

Kurz runtergetippter Ansatz via WordPress Passwort pro Seite Funktion, setze als Passwort der Seite z.B. [FONT=Courier New]IP:123.123.123.123[/FONT]

function b3317133_the_password_form( $output, $post ) {
    if ( count( $pw = explode( 'IP:', $post->post_password ) ) == 2 ) {
        if ( $pw[1] != $_SERVER['REMOTE_ADDR'] ) {
            $output = "Falsche IP...";
        }
    }
    return $output;


}
add_filter( 'the_password_form', 'b3317133_the_password_form', 10, 2 );


function b3317133_post_password_required( $required, $post ) {
    if ( $required && count( $pw = explode( 'IP:', $post->post_password ) ) == 2 ) {
        $required = !( $pw[1] == $_SERVER['REMOTE_ADDR'] );
    }
    return $required;
}
add_filter( 'post_password_required', 'b3317133_post_password_required', 10, 2 );

In pre_get_posts ist das Query noch nicht ausgeführt, siehe Dokumentation. Somit kannst Du es anpassen oder aber auch wie in template_redirect vor jeglicher Ausgabe je nach IP reagieren und ausgeben was Du möchtest.

Bei der WordPress Passwort pro Seite Funktion kannst Du den Inhalt der "Passwort gebraucht" Ausgabe beliebig anpassen, siehe "Customize the Protected Text" in der bereits oben verlinkten Dokumentation.

Der Inhalt der Anfragen kommt v.a. auch auf Theme/Plugins an. Beispielsweise get_posts() setzt diesen Parameter standardmässig auf [FONT=Courier New]true[/FONT].

Nutze für Deine Problemstellung besser eine allgemeingültigere Action wie [FONT=Courier New]pre_get_posts[/FONT] oder je nach Projekt auch [FONT=Courier New]template_redirect[/FONT], grober Anhaltspunkt der Reihenfolge hier in der WordPress Dokumentation.

Und Tests mit den üblichen Cache-Plugins, Feed-Ausgabe u.ä. nicht vergessen...

Ergänzung: Ein alternativer Ansatz wäre die Nutzung bzw. Immitation der in WordPress integrierten Passwort pro Seite Funktion, in deren Filter Du dann Deine IP prüfst.

1. [FONT=Courier New].tablepress { width: 80%; }[/FONT]
2. Dokumentation TablePress: Reponsive Tables

Wenn eine Anfrage den Parameter [FONT=Courier New]suppress_filters[/FONT] auf [FONT=Courier New]true[/FONT] setzt, wird u.a. dieser Hook/Filter umgangen.

Wir haben bei einem grob ähnlichen Projekt die [FONT=Courier New]template_redirect[/FONT] Action genutzt.

Schau Dir den Punkt "Reverse Query" in der oben verlinkten Dokumentation des "Sehr hilfreichen Plugin für Custom Fields / Metadaten" an.

Wenn WordPress von sich aus eine Einrichtung mit Eingabe von Seitentitel, Admin E-Mail bzw. Datenbank-Zugangsdaten durchführen will, ist entweder die Datei wp-config.php nicht vorhanden oder die darin eingetragene Datenbank ist leer bzw. unvollständig z.B. weil der (hier nicht näher beschriebene) Import nicht wirklich funktioniert hat.

Die Einrichtung erstellt eine wp-config.php und die nötigen Tabellen in der Datenbank. Bestehende Datenbank-Inhalte sind danach im Regelfall weg oder z.B. wegen eines neuen Datenbank-Prefix nicht mehr in Verwendung. Die Einrichtung ändert ansonsten nichts an den Dateien/Ordnern usw., daher wurden die Plugins (nicht aktiv) aufgelistet.

Zum kompletten Löschen einer fehlgeschlagenen Installation gehört vor einem neuen Versuch auch das komplette Leeren der Datenbank.

Am Rande angemerkt: Der Vorschlag des Supports, diese Einrichtung durchzuführen und auf nachher bestehende Inhalte zu hoffen, lässt darauf schliessen, dass nur begrenzt Ahnung bzgl. WordPress vorhanden ist.

Wenn nach einer halben Stunde alles wieder verschwindet bzw. die Einrichtung neu getriggert wird, könnte es an irgendwelchen Cache- oder Load Balancing Mechanismen ausserhalb von WordPress liegen, oder auch an falsch eingerichteten serverseitigem "Managed WordPress", das seine dort hinterlegte Datenbank wieder in die wp-config.php überschreibt u.ä., für Hilfe hier ist die Beschreibung der Rahmenbedingungen aber zu ungenau.

• Wann / wo genau erscheint der Error 500?
• Was steht im PHP Error Log des Servers wenn der Error 500 erscheint? Ggf. beim Hosting nachfragen wo das einsehbar ist.