Skriptfehler bei den Versuchen, eine .xml-Datei zu exportieren & Tags in Kategorien zu konvertieren

Ich bin mit einem Blog beschäftigt, der inzwischen mit WP 5.1 sowie dem Theme Twenty Sixteen + Child Theme läuft:

http://peter-nowak-journalist.de/

In mindestens zwei Situationen erhalte ich folgende Fehlermeldung: "Die angeforderte Seite hat einen Script-Fehler verursacht."

Situation 1: Ich versuche - im back end - eine .xml-Datei der Blog-Inhalte zu exportieren:



Im vergangenen Jahr - als der Blog noch mit irgendeiner uralt-Version von WordPress lief - funktionierte der Export der .xml-Datei dagegen noch.

Situation 2: Ich versuche - ebenfalls im back end - Schlagwörter (Tags) in Kategorien zu konvertieren:



und



Beide Fehler traten auch bereits mit 5.0 auf und verschwanden durch Update auf 5.1 nicht. (Mit der vorhergehenden uralt-Version hatte ich das Schlagwörter-in-Kategorien-Konvertieren nicht ausprobiert.)


Situation 3: Wenn ich recht erinnere, erhielt ich - bereits mit WP 5.1 - die entsprechende Fehlermeldung auch einmal, als ich im front end versuchte, nach zwei Begriffen gleichzeitig zu suchen; ich ließ dann einen der beiden Begriffe weg und erhielt Ergebnisse für den anderen.
Den Fehler bei der Suche war ich jetzt aber nicht in der Lage zu reproduzieren.

Habt Ihr Ideen, was den Skriptfehler verursachen könnte und wie er sich beseitigen läßt?



PS.:

Außerdem möchte ich an meine beiden noch offenen Fragen erinnern:

• Automatische Einfügung von <more>-Befehlen

und

• Verlinkung von Beitragsbildern aufheben.

 

Auf der obersten Ebene des Servers gibt es u.a. einen Ordner "errordocs" - das sind aber nur die html-Dateien für die Fehlermeldungen - und einen Ordner "logs".

Dort beginnt die neueste Datei wie folgt:

Code:

Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!

Ist das das Benötigte?

Statt der Doppelkreuze stehen im Original lauter IP-Nummern (von wem auch immer). (Dass die erfasst werden, ist sicherlich auch nicht im Sinne der Blog-Betreibers. - Lässt sich das unterbinden?)

 

Danke; der Export funktioniert dann. Der Konverter bricht dann ohne Fehlermeldung ab:

 

Was ist denn in dem Zusammenhang der entscheidende Parameter für "leistungsfähiger"? (Da der Konverter auch dann nicht funktioniert, wenn alle anderen Plugins deaktiviert sind, scheint ja - wenn der Konverter funktionieren soll - kein Weg an einem Upgrade herumzuführen.)

 

Der Erfolg bzw. Nicht-Erfolg des Exportes der .xml-Datei hängt am Plugin All-in-One Event Calendar von Time.ly.

Läßt sich das durch ein anderes - mit WP 5.1 funktionierendes - Kalender-Plugin ersetzen, ohne daß alle bisherigen Veranstaltungen neu manuell eingegeben werden müßten?

 

Ist das das php memory_limit:

?

Hier scheine ich jetzt das Richtige gefunden zu haben:

Das wird mir unter folgender Überschrift angezeigt: "SERVERMODULE
Hier können Sie sich die Module zu den Scriptsprachen, die auf Ihrem Server installiert sind, anzeigen lassen.
Moduldetails für : PHP 5.2.17 (Stable)
Stand : 27.02.2019"

 

Soll ich da



dann mal 7-72STABLE auswählen? (Scheint nicht mehr zu kosten. Warum wird so etwas nicht automatisch vom Hoster aktualisiert? - Was hat es mit der "Sichere(n) Einstellung" auf sich? Soll ich das deaktiviert lassen oder aktivieren?)

 

Und bzgl. der error.log habe ich jetzt eventuell noch gefunden:

Wäre das die benötige Datei/Information? -

Wenn ich die Adresse aufrufe, erhalte ich allerdings folgende Fehlermeldung: "Proxy-Fehler
Die angeforderte Domain kann über diesen Proxy nicht genutzt werden."

Ich denke allerdings nicht, daß ich überhaupt einen Proxy benutze. Das wüßte ich doch, oder nicht?

 

Inzwischen habe ich folgendes festgestellt:

1. Unter der Überschrift

"SERVERMODULE
Hier können Sie sich die Module zu den Scriptsprachen, die auf Ihrem Server installiert sind, anzeigen lassen.
Moduldetails für : PHP 7.1.23 (Stable)
Stand : 28.02.2019"

wird mir ebenfalls nur

"Core
PHP Version 7.1.23
Directive Local Value Master Value
memory_limit 100M 100M"

angezeigt. - Kann das sein?

2. a) Im übrigen soll es sich wohl bei beiden Listen (der zu 5.2.17 und der zu 7.1.23) um Beschreibungen der php-Versionen als solches und nicht um das memory_limit, das tatsächlich zur Verfügung steht, zu handeln. Denn an anderer Stelle - https://www.df.eu/de/webhosting/ -
heißt es :

|| -------------------- || Basic - 3,99 €/Monat || Medium - 6,99 || Professional 9,99 €/Monat || Premium19,99 ||Ultimate 39,99 ||

|| DF ScriptPower || 64 MB RAM, 30 CPU-Sek. || 128 MB RAM, 40 CPU-Sek. || 128 MB RAM, 60 CPU-Sek. || 256 MB RAM, 60 CPU-Sek. || 256 MB RAM, 120 CPU-Sek.||

Danach scheint das memory_limit wohl nicht (nur<?>) von der jeweiligen php-Version, sondern (auch<?>) vom jeweiligen Tarif abzuhängen.

b) Im Moment läuft der Blog noch mit einem noch schlechteren Tarif als "Basic", für den ich aber nicht die Angaben zur "Script Power" feststellen konnte, sondern nur, daß er zum gleichen Preis jedenfalls weniger GB Web- und mail-Speicherplatz (2 statt 25 GB) biete. Zu

"
für interaktive Inhalte mit PHP, Perl und MySQL"

heißt es dort einfach nur "ja".

3. Ich hatte gestern den Content-Produzenten gebeten, sich bei seinem Hoster nach der error.log zu erkundigen; letzterer hat aber noch nicht geantwortet.

Nachher hier (noch mal) folgende Fragen:

a) Soll ich an der php-Version etwas ändern? [Mir ist allerdings nicht einmal ganz klar, ob aktuell PHP 5.6.34 (siehe oben den screen shot in Antwort #16) oder PHP 5.2.17 (Stable) installiert ist. Letzteres wird mir angegezigt, wenn ich dort:



in der Zeile "PHP5" in der letzten Spalte auf "Detaillierte Informationen" klicke. Anschließend wird mir - automatisch - dies:



angezeigt. Ich kann dort aber auch zu den anderen Versionen wechseln. Jedenfalls befindet sich dort - weiter unten - auch die - für 5.12.17 und 7.1.23 identische Angabe zum memory_limit.)

b) Was hat es damit auf sich, daß dort für alle php-Versionen ein memory_limit von 100 M angezeigt wird? - Hätte es unter den diesen Umständen überhaupt einen Sinn, zu einem teureren Tarif (als Basic, mit dem der Blog ab Mitte März laufen wird) zu wechseln oder, wäre php eh der Falschenhals?

 

Danke. - Kann ich die Umstellung auf php7 einfach so machen? Oder sollte ich vorher erst wieder die Datenbank sichern und die aktuelle .xml-Datei exportieren?

Ich habe inzwischen beide Sicherungen gemacht und auf php7 umgestellt. - Aber auch nach Umstellung funktioniert der Export der .xml-Datei nur dann, wenn ich vorher das Kalender-Plugin von time.ly deaktiviere.