Dies ist das technische Support-Forum für WPML - das mehrsprachige WordPress-Plugin.

Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team beantwortet Anfragen im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.

Heute stehen keine Supporter zur Arbeit im German-Forum zur Verfügung. Sie können gern Tickets erstellen, die wir bearbeiten werden, sobald wir online sind. Vielen Dank für Ihr Verständnis.

This topic contains 16 Antworten, has 3 Teilnehmer.

Last updated by Cristina vor 11 Monate, 3 Wochen.

Assigned support staff: Cristina.

Autor Beiträge
Oktober 17, 2018 um 8:36 am #2823772

Harald

Ich versuche:
Umstellung http auf https

Erwartet hatte ich zu sehen:
- normale Funktion im Backend

Stattdessen bekam ich:
Nach der Umstellung von WordPress auf https (home+site url in backend) funktioniert WPML im Backend nicht mehr richtig. In der Seitenübersicht fehlen die Übersetzungsicons und ich bekomme oben eine Fehlermeldung angezeigt. In den WPML Einstellungseiten sieht es aus, als könnte hier ein CSS nicht geladen werden, die Inhalte werden nicht wie gewohnt angezeigt.

Oktober 17, 2018 um 3:01 pm #2825057

Cristina

Hallo Harald,

vielen Dank für Ihre Anfrage und die beigefügten Informationen.

Ich habe eben die Webseite besucht, und in dem Browserfenster keine Fehlermeldungen bezüglich "mixed content" bekommen, die bei https-Problemen üblich sind.

WPML ist an sich transparent gegenüber https oder https.

Wenn die Probleme nur das Backend betreffen, könnte es aber sein, das gecachte Inhalte in WPML vorhanden sind, welche die URLs für Sprachumschalter und Icons betreffen.

Bitte überprüfen Sie ob:

- Der Seiten-Cache nach der Umstellung geleert wurde
- In Einstellungen > Allgemein beide Einträge das "https" enthalten. In den Debug-Log Informationen erscheinen jetzt die SiteURL mit "http" und die HomeURL mit "https". Bitte setzten Sie beide Einträge (Webadresse und Seitenadresse) auf https.

Das sollte auch in der DB in der Tabelle _options beides auf https gesetzt sein. Es sind die beiden ersten Einträge dieser Tabelle.

Danach gehen Sie bitte auf WPML > Support > Fehlerbehebungsseite und leeren den WPML Cache. Sie können auch die Cache-Vorlagen für den Sprachumschalter deaktivieren und wieder aktivieren, damit das neu gelesen wird. Damit würden die Ressourcen (Icons, Flaggen) neu geladen.

Abgesehen davon, habe ich in der Debug Information gesehen, dass die WordPress Installation selbst nur 40 M Arbeitsspeicher hat. Das ist zu wenig, wenn rechenintensive Plugins wie WPML und andere genutzt werden.

Es wäre daher besser, die Seite an die Mindestanforderungen anzupassen. Dafür können Sie folgende Zeilen der Datei wp-config.php hinzufügen:

Die Datei befindet sich im Root-Verzeichnis Ihres WordPress und die beiden Zeilen können direkt vor der Zeile mit dem Text “happy blogging” hinzugefügt werden.

define('WP_MEMORY_LIMIT', '128M');
define('WP_MAX_MEMORY_LIMIT', '128M');

Damit werden die WPML und WCML Prozesse genügend Arbeitsspeicher besitzen, um störungsfrei zu arbeiten.

Haben Sie vielleicht direkt von einer alten Version 3.3.1 auf die aktuelle Version gewechselt?
Sollten Sie hier weitere Warnungen im Backend bekommen, könnte es sein, dass der Upgrade nicht ganz sauber verlieft. Da zwischen diesen beiden Versionen verschiedene Änderungen an der DB-Struktur vorkamen, könnten eventuelle Hinweise darauf zurückzuführen sein. Es ist aber nur eine Möglichkeit.

MfG,
Cristina

Oktober 17, 2018 um 4:11 pm #2825274

Harald

Hallo Christina,

vielen Dank für die umfangreichen Hilfestellungen! Vorweg: ich habe das Memory Limit schon auf 128M erhöht.

Ich kann das ganze nun auch rekonstruieren:
1) sowohl in den Einstellungen > Allgemein habe ich https (Anm. ich habe das Aufgrund des Fehlers jetzt wieder entfernt)
2) Auch in der Options Tabelle sind die Einträge 1+2 mit https vorhanden
3) sobald ich nun mit https im Backend anmelde, bekomme ich den beschriebenen Fehler. Melde ich mit http an ist alles ok.
4) Hier habe ich ausserdem ein Problem: WPML > Support > Fehlerbehebungsseite: WPML Cache leeren: der Javascript Button funktioniert nicht wegen des fehlerhaften WPML Backend Aufbaus (siehe Screenshot), damit kann ich hier leider auch nichts "leeren". Die Oberfläche sollte eigentlich auch anders aussehen > Screenshot
5) Update von 3.3.1: Nein die Version wurde laufend und regelmäßig aktualisiert. Auf meinem Entwicklungsserver auf dem ich eine Kopie der Seite laufen habe habe ich auch keine Probleme.

Oktober 17, 2018 um 6:03 pm #2825577

Cristina

Hallo Harald,

Wenn es auf dem Dev-Server korrekt funktioniert, kann es auf dem Live-Server etwas geben, was hier zusätzlich die Abfrage der JS-Dateien blockiert.

Gibt es einen gravierenden Unterschied zwischen beiden Plattformen?

Eventuell voreingestellte Dienste auf dem Server oder spezifische Weiterleitungen, die für einen Konflikt im Javascript sorgen würden?

Passiert der Backend-Fehler nur im Zusammenhang mit WPML oder sind auch andere Admin-Bereiche betroffen (ACF, Yoast, Wordfence)?

Wenn es möglich wäre, den Debug.log für WordPress zu aktivieren, könnte man zumindest PHP Fehler, die Fehlermeldungen im WordPress selbst, checken.

Dafür müssten Sie in der Datei wp-config.php im Root-Verzeichnis der WordPress-Installation diese Zeile suchen:

define('WP_DEBUG', false);

Bitte ändern Sie dort "false" auf "true" und fügen Sie eine weitere Zeile ein, so dass es wie folgt lautet:

define('WP_DEBUG', true);
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY',false);

Damit werden die PHP-Fehler in eine Datei namens debug.log im Verzeichnis /wp-content/ gespeichert. Die dritte Zeile verhindert, dass die Fehler auf der Seite selbst erscheinen.

Es handelt sich um eine Textdatei, die wir über den Link kopieren und analysieren können.
Wenn Sie den Inhalt in die kopieren und auf pastebin.com verlinken könnten, wäre das sehr hilfreich für uns.

Ich müsste das an die Devs eskalieren, damit die Kollegen die Seite auf mögliche Fehler oder Interaktione mit WPML analysieren.

Um das zu debuggen, müssten die Kollegen aber Einsicht in die Seite haben. Ich habe in unseren Bugs und aktuellen Problemen nachgeschlagen, aber keine vergleichbaren Fälle gefunden. Es hat mal Schwierigkeiten gegeben, wenn spezielle Setups wie Bedrock oder andere Konfigurationen genutzt wurden, aber hier scheint es ja ein ganz normaler Apache_Server zu sein.

Ich aktiviere die private Antwort, falls Sie damit einverstanden sind, einen Zugang zu erteilen. Wenn nicht, wäre es hilfreich, die Fehlermeldungen und Logs zu sehen, damit wir uns ein Bild machen können, was genau hakt.

MfG,
Cristina

Oktober 18, 2018 um 11:16 am #2827750

Harald

Hallo Christina,

danke, ich muss noch kurz Rückfrage halten wegen der Zugangsdaten.

Zu den Fragen: nein, soweit ich weiß gibt es auf dem Live-Server selbst nichts was die JS blockieren könnte, grundsätzlich ist das ein 1:1 Klon (domain in db serialisiert per search and replace db script geändert) - so wie ich es schon oftmals gemacht habe.

Ausser WPML kann ich auch keine weiteren Fehler bei anderen Plugins feststellen.

debug.log habe ich aktiviert, log-file wird aber nicht erstellt (vermutlich weil kein php Fehler auftritt?)

Aber das Stichwort "JS blockieren" triffts, soweit ich das sehe ist das ursächliche Problem, dass unter https unsichere http Ressourcen vom Browser blockiert werden (also kein php Fehler).
Daher die fehlenden WPML Flags, nicht funktionierenden JS-Buttons und ein paar fehlende CSS.

Wenn ich auf die Seiten-Übersicht gehe, bekomme ich derartige Fehler in der Console:

Mixed Content: The page at 'hidden link' was loaded over HTTPS, but requested an insecure stylesheet 'hidden link'. This request has been blocked; the content must be served over HTTPS.

Gleiches bei Bildern:
Mixed Content: The page at 'hidden link' was loaded over HTTPS, but requested an insecure image 'hidden link'. This content should also be served over HTTPS.

Inspecte ich die Seiten-Übersicht, habe ich auch den Übersetzungslink - durch das Fehlen der Flags ist das <a> tag allerdings 0x0 px und ist dementsprechend nicht sichtbar.

Nachdem WPML ja http und https unabhängig sein sollte kann ich mir aber gerade nicht erklären woher die http Ressourcen beim Laden der Plugin Komponenten im Backend kommen.

Vielen Dank soweit, ich melde mich noch mit den Zugangsdaten.
LG, Harald

Oktober 18, 2018 um 6:31 pm #2829216

Cristina

Hallo Harald,

diese mixed content Fehler hatte ich auf der Seite beim ersten Check nicht in der Browserkonsole bekommen, sonst hätte ich Ihnen sofort dazu geraten, das Plugin Really Simple SSL zu installieren, was viele Seiten nutzen, um diese mixed content - Warnungen zu fixen. (https://wordpress.org/plugins/really-simple-ssl/)

Damit werden alle Ressourcen-Anfragen über zwangsweise über https geleitet.

Sie könnten dann auch die aktuelle Sprachumschalter entfernen, den Cache leeren und die Switcher dann wieder einfügen. Das wird die Ressourcen dann neu laden.

Damit sollten diese Fehler nicht mehr vorkommen. Ob das aber dann das ganze Problem löst, bin ich nicht sicher, denn mixed content Warnungen behindern nicht das Laden und Anzeigen einer Seite.

MfG,
Cristina

Oktober 22, 2018 um 7:46 am #2837004

Harald

Guten Morgen,

ich habe das Plugin really-simple-ssl versucht, leider diese Probleme im Backend aber nicht weg bekommen. Könnten Sie mir nochmals die private Nachricht für die Zugangsdaten aktivieren? Besten Dank!

LG, Harald

Oktober 22, 2018 um 5:08 pm #2839112

Cristina

Hallo Harald,

kein Problem, ich aktiviere hier die private Antwort für die Daten. Ich werde das ansehen und an den 2nd Level eskalieren, wenn es etwas komplizierter ist als auf den ersten Blick aussah.

MfG,
Cristina

Oktober 25, 2018 um 12:51 pm #2849852

Cristina

Hallo Harald,

ich bin nicht sicher, was hier passiert, ob es eventuell auch etwas Speicherknappheit ist, weil der PHP Speicher nur 128 M hat.

Das ist zuwenig, und es waren wohl schon einmal mehr, weil der erste Debug-Log hier 256M für PHP anzeigte, was ok ist. 128 MB ist für WordPress RAM in Ordnung, aber der PHP Speicher sollte etwas höher sein.

Bitte erhöhen Sie den PHP - Speicher, das ist eventuell zu wenig.

Schon ein Plugin wie Wordfence kann hier einen Streich spielen, wenn es zu strikt eingesetzt wird. Auch Broken Link Checker ist ein Ressourcenfresser. Wenn das mit WPML zusammen betrieben wird, reichen die 128 eventuell nicht aus.

Die Verbindung ist aber auf jeden Fall sehr langsam und im Debug_Log findet man Hinweise wie hier:

[25-Oct-2018 12:02:18 UTC] PHP Notice: Trying to get property of non-object in.../wp-content/themes/.../templates/components/main-navigation.php on line 87]

Bei der Einstellung für URLs in Verzeichnissen gibt es einen Hinweis auf einen cURL Fehler:
"cURL error 7: Failed connect to xxx.com:80; Connection refused"

Könnten Sie nachsehen, ob die PHP-Extension cURL mit Version 7.34 oder höher aktiv ist?

Diese PHP-Extension ist für die Serververbindungen notwendig. Wenn sie nicht aktiv ist oder die Version zu alt, kann es Verbindungsprobleme geben und Dateien blockieren.

Bitte testen Sie auch, ob das Problem mit https ohne WordFence ebenfalls auftritt. Wordfence "lernt" z.b. dazu, wenn die Firewall eingerichtet wird, da kann es auch mal zu falschen Positiven kommen und eine benötigte Datei blockiert werden, beispielsweise ein Jquery. Da die Firewall jetzt einige URLs als Whitelist führt, könnte es auch passieren, dass hier externe Scripts wie jquery nicht geladen werden können. Das ist aber die Standardbibliothek für viele Adminskripte.

Auch Warnungen wie diese deuten auf eine zu strenge Sicherheit hin:

[PHP Warning: Ein unerwarteter Fehler ist aufgetreten. Es scheint etwas bei WordPress.org oder mit dieser Serverkonfiguration nicht zu stimmen.... in ....wp-includes/update.php on line 156]

Im Adminbereich treten auch Warnung zu Ajax-Fehlern auf, die auf Verbindungsproblemen zur WordPress-Updatefunktion weisen, wahrscheinlich wegen der fehlenden https.

Ich habe in WPML > Sprachen das Ajax Cookie aktiviert, um die Sprachfilterung für AJAX zu unterstützen, denn WPML scheint hier ok zu funktionieren.

Aber hier deutet alles eher auf die Serverkonfiguration, was auch erklärt, dass es im Staging-Bereich kein Problem gibt.

Probieren Sie dieses:

- PHP Speicher wieder auf 256 M erhöhen
- WPML deaktivieren und davor den WPML Cache leeren
- Auf das Default-Theme wechseln
- WordFence deaktivieren
- HTTPS einstellen
- WPML wieder aktivieren
- Wenn alles korrekt ist, WordFence wieder aktivieren

Da der Debug.Log aktiv ist, würden PHP Fehler hier registriert.
Der Server-Fehlerbericht informiert dann über Verbindungsprobleme oder MySQL Probleme.

Wenn es ein Server-Problem ist, sind wir leider total blind.

MfG
Cristina

Oktober 25, 2018 um 1:54 pm #2849997

Harald

Hallo Christina,

vielen Dank für die Analyse.

Ich habe den Speicher auf 256M gesetzt, zur Info: auf der Staging Site treten die Probleme mit 128M nicht auf.

Es läuft cURL mit Version 7.29.0 - ich muss ein Update leider beim Hosting-Provider beauftragen.

Dieser Fehler [PHP Warning: Ein unerwarteter Fehler ist aufgetreten. Es scheint etwas bei WordPress.org oder mit dieser Serverkonfiguration nicht zu stimmen.... in ....wp-includes/update.php on line 156] – liegt vermutlich am fehlenden https? "WordPress konnte keine sichere Verbindung zu WordPress.org herstellen. Bitte kontaktiere deinen Server-Administrator."

Ich bin auch Ihre Liste durch, leider hatte ich sofort beim letzten Schritt "WPML wieder aktivieren" auf https die bekannten Probleme.

Allerdings gab es dann einen neuen Eintrag im log:
[25-Oct-2018 13:25:14 UTC] WordPress-Datenbank-Fehler Duplicate entry '120-de' for key 'trid_lang' für Abfrage UPDATE `wp_icl_translations` SET `language_code` = 'de' WHERE `translation_id` = '460' von require_once('wp-admin/admin.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, call_user_func_array, SitePress->rebuild_language_information, TranslationManagement->add_missing_language_information, TranslationManagement->add_missing_language_to_posts, TranslationManagement->add_missing_language_to_post

LG, Harald

Oktober 25, 2018 um 2:27 pm #2850139

Harald

Hallo Christina,

was vielleicht auch eine wichtige Info ist: die alte Website lief bis vor kurzem auf der gleichen live-Umgebung ohne Probleme (also mit gleichen Plugins inkl. WPML, bzw. waren auf der alten Seite sogar mehr Plugins aktiv), insofern hatte ich bisher die Serverumgebung als zentrale Ursache eher ausgeschlossen.

LG, Harald

Oktober 25, 2018 um 8:20 pm #2851052

Harald

Hallo Christina!

Ich habe mich heute nochmals intensiv damit beschäftigt und sehr viele Varianten getestet.
Es scheint als hätte der Zusatz $_SERVER['HTTPS'] = 'on'; in der wp-config.php den Erfolg gebracht.
Ich werde das morgen nochmal im finalen Verzeichnis am Live-Server reproduzieren und gebe dann hier noch Bescheid.

LG, Harald

Oktober 26, 2018 um 7:59 am #2852312

Yvette
Supporter

Languages: Englisch (English ) Spanisch (Español )

Timezone: Europe/Madrid (GMT+02:00)

Hello

Cristina is not available today but will be back on Monday. I understand that you have possibly resolved the issue yourself with a modified wp-config.php file. This is great news!

If you can confirm that this additional configuration resolved the issue definitely, please let us know and close this ticket.

If you still get a PHP database error in your log, then open a new ticket for us to resolve this database inconsistence as it presents a different and new issue.

Kind regards

Oktober 29, 2018 um 8:20 am #2857118

Harald

Hallo Christina,

ich kann nun bestätigen, dass die Fehler im Backend behoben sind! Lediglich beim Sprach-URL-Format bekomme ich noch einen Fehler für die Verzeichnisse angezeigt (cURL Fehler). Aber das ist ein anderes Thema, vermutlich weil die cURL Erweiterung zu alt ist.

Noch eine Bitte: könnten Sie aus dem Post vom OKTOBER 25, 2018 UM 12:51 PM #2849852 die Domainnamen entfernen, vielen Dank!

Besten Dank nochmals für Ihre Hilfestellungen!
LG Harald

Oktober 29, 2018 um 5:00 pm #2858869

Cristina

Hallo Harald,

vielen Dank für das Feedback und ich bin wirklich erleichtert, dass es jetzt funktioniert.

Ich hätte nicht gedacht, dass man diese Https - Variable eigens in die wp-config hinzufügen müsste, aber da habe ich jetzt auch etwas dazu gelernt.

Den Domainnamen habe ich aus dem Post entfernt, das war mir entgangen.

Schönen Gruß,
Cristina