- Wie genau hast Du die WordPress Installation umgezogen?
- Welche WordPress Version wird verwendet?
- Was erscheint bei der Seite selbst und im PHP Error Log des Hostings, wenn Du die Administrationsseite aufrufst?
Beiträge von b3317133
-
-
Das bedeutet: Du hast lt. eigenen Angaben ein Plugin für einen Shortcode erstellt und dazu ein Seitentemplate, das offenbar ähnlichen PHP-Code oder aber diesen Shortcode aufrufen soll. Und das funktioniert alles auf localhost. Der dazu gepostete Link zeigt etwas völlig anderes, offenbar eine Startseite aus Elementor und OceanWP.
Was Du ändern könntest: Erstelle eine Seite mit Deinem Seitentemplate (zum Inhalt siehe Beitrag #18) und poste einen Link zu dieser Seite. Wenn Dein Plugin nicht aktiv ist, wird dort einfach [FONT=Courier New][kalender_start][/FONT] erscheinen, und wenn Dein Plugin aktiv ist, die entspr. Ausgabe, die Dein Shortcode zurückgibt.
-
Dieser Link ist lt. body class und REST API ein Elementor Canvas Template und kein "Kalenderkarte" Template.
-
Weiss nicht, was Du da auf localhost machst, Du hast auch erst behauptet, das hier hätte dort funktioniert..
..was sehr schwer vorstellbar ist.Aktiviere Dein Plugin, füge den Shortcode wie in #18 beschrieben in Dein Template ein (und sonst nichts) und poste einen Link zu der Seite mit diesem Template, dann kann man das ggf. weiter betrachten.
-
Die aktuell unter [plain]https://www.erlebnis-seeblick.de/[/plain] sichtbare Seite ist nicht in WordPress erstellt worden und kann darüber auch nicht bearbeitet werden, sondern liegt als [FONT=Courier New]index.html[/FONT] im Verzeichnis oberhalb Deines [FONT=Courier New]/edersee/[/FONT] Ordners.
-
Wenn Du, was Dein Template-Codeauszug evtl. vermuten lässt, dort den gleichen Code einfügst wie in Deinem Plugin, wird das bei aktivem Plugin natürlich zu einer Namenskollision der [FONT=Courier New]small_kalender[/FONT] Funktionen und damit zu einem "weissen Bildschirm" kommen.
In Dein Template gehört nur Aufruf/Ausgabe des Shortcodes wie in #18 beschrieben.
Und generell wg. des o.g. anderen Codevorschlags: In einem Shortcode sollten keine [FONT=Courier New]printf()[/FONT] bzw. schon gar nicht [FONT=Courier New]exit()[/FONT] vorkommen, alle "Ausgaben" erfolgen nicht direkt sondern alleine nur per [FONT=Courier New]return ...;[/FONT] am Ende.
-
Ohne mehr Angaben zu den Anfragefeldern des Requests und/oder zeitlich dazu passenden Error Log Einträgen kann man "von aussen" da nur noch schwer weiterhelfen.
Die Problematik kann viele unterschiedliche Gründe haben, von einer wie auch immer zustande kommenden Inkompatibilität zwischen WordPress, Elementor, WPForms bis hin zu Arbeitsspeicher nicht für irgendwas ausreichend auf dem Server ist alles möglich.
Wende Dich am besten an eine Person in Deinem näheren Umfeld, die sich technisch gut mit WordPress auskennt und das mit Dir zusammen weiter analysiert. Zugang zum Hosting (Error Log) und WordPress Backend (Requests analysieren) wird nötig sein.
-
Verantwortlich für den endlosen Ladenbalken dürfte also der Fehler bei [FONT=Courier New]../admin-ajax.php[/FONT] mit dem "status of 500" sein, auch genannt "Server Error 500".
Mehr dazu findest Du vermutlich im PHP Error Log des Servers oder auch über die HTTP Anfragefelder des Requests im Netzwerk Tab.
Die Meldungen bzgl. SourceMap bzw. Dateien mit Endung [FONT=Courier New].map[/FONT] sind nicht relevant.
-
Lt. der og. sonstigen Angaben würde im Template ein [FONT=Courier New]echo do_shortcode( '[kalender_start]' );[/FONT] eingefügt werden und kein Datenbank-Script...
Wenn der Bildschirm "weiss bleibt", schau in das PHP Error Log des Servers für weitere Angaben oder nutze WP_DEBUG.
-
Beispielsweise statt [FONT=Courier New]if (!$db ...[/FONT] an dieser Stelle eher so wie im Beispiel #1 mysqli_connect() im o.g. Link...Die weitere Abfrage von [FONT=Courier New]mysqli_num_rows(...)[/FONT] macht an der Stelle eher keinen Sinn, man würde ja eine Datenbank-Abfrage mit mysqli_connect() überhaupt nur erst dann tätigen, wenn die Datenbank erfolgreich verbunden ist.
Die PHP Beispiele zeigen etwas mehr Struktur eigentlich ganz gut.
Ergänzung: Generell würde ich einen anderen Ansatz über eine eigene Instanz von [FONT=Courier New]$wpdb[/FONT] wählen und dann die WordPress API Funktionen für alle Datenbank-Operationen verwenden.
-
-
- Was passiert, wenn alle anderen Plugins (ausser Elementor und WPForms) temporär deaktiviert werden?
-
Ok, also war die Angabe bei strato macht er keine Verbindung falsch.
Weiter zur nächsten Zeile, dort steht im o.g. Code [FONT=Courier New]$wpdb[/FONT] wo man eher [FONT=Courier New]$db[/FONT] vermuten würde. Wie das auf localhost angeblich funktionert hat ist schwer nachvollziehbar.
Generell: Würde das Abfangen von Fehlermeldungen etwas strukturierter empfehlen.
-
- Sind WordPress, Elementor, WPForms auf aktuellem Stand, welche Versionen?
- Was passiert, wenn alle anderen Plugins temporär deaktiviert werden?
- Was passiert mit einem temporär anderen Theme?
- Und falls alles o.g. zu keinem Ergebnis führt, was erscheint in der Browser Console (google) wenn der endlose Ladebalken erscheint?
- Sind WordPress, Elementor, WPForms auf aktuellem Stand, welche Versionen?
-
Versuche es mal mit dem Beispiel #1 mysqli_connect() im o.g. Link...
-
Welche Fehlernummer / Fehlermeldung wird denn von mysqli_connect() zurückgegeben?
-
-
Mehr zu Selektoren siehe z.B. hier (google) oder zu !important siehe z.B. hier (google).
Das Forum soll eigentlich auch dazu dienen, dass man selbst dazulernt und nicht nur einfach Code kopiert.
-
-
Du könntest den free MyKinsta demo account dort ausprobieren.