Probleme mit Widget "Geschützter Bereich"

Hallo,

da müssten Sie uns zunächst mal die Web-Adresse nennen, wo der geschützte Bereich aufrufbar ist.

Können Sie hier übermitteln: https://docs.zeta-producer.com/nachricht-an-support.html

Hallo,

im Projekt steht bei den FTP-Einstellungen bei Web-Adresse vermutlich http://www.flugmodellclub-rca.de drin. Die Testumgebung läuft aber auf http://neu.flugmodellclub-rca.de. Bitte also mal die Web-Adresse anpassen und dann nochmals komplett neu veröffentlichen.

Hallo Marco,

hast Du zufällig einen Cookie-Blocker aktiviert?

Das kommt vermutlich von eigenem PHP-Code, den Sie auf der Seite eingefügt haben.

Na auf der Seite mitgliederliste.php

Dann entfernen Sie zunächst probehalber bitte mal das Widget „Geschützter Bereich“ von der Seite. Die Seite ist ja wohl ohnehin webserverseitig mit Passwort geschützt. Dann können wir sehen, ob die Seite dann immer noch den Fehler (der eigentlich nur eine Warnung ist) erzeugt.

Ok, danke. Schaue ich mir morgen nochmal an, habe gerade Ihre Zugangsdaten nicht parat.

Hallo,

ich habe ein Online-Update für das Widget für Version 15 veröffentlicht. Klicken Sie mal auf "Extras > Updates suchen". Nachdem Daten geladen wurden (Hinweis unten rechts), beenden Sie Zeta Producer. Dann starten Sie Zeta Producer wieder und fügen das Widget nochmals neu auf der Seite ein. Danach veröffentlichen. Lassen Sie uns dann hier wissen, ob es nun besser ist.

Hallo,

sehr eigenartig. Dann erkundigen Sie sich bitte bei Ihrem Provider, wie Sie die PHP.ini Variable "error_reporting" verändern können.

Diese sollte auf den Wert E_ERROR gesetzt werden. Dann werden nur wirkliche Fehler protokolliert und nicht auch Warnungen (wie in diesem Fall hier). Eigentlich setzen wir diesen Wert bereits in unseren Scripts, das scheint aber auf Ihrem Webserver nicht zu greifen…

Senden Sie mir bitte das Passwort für den geschützten Bereich und einen Link zu diesem Beitrag (als Referenz) per Mail an support[ät]zeta-producer.com ([ät] durch @ ersetzen), dann schaue ich morgen nochmal drüber.

Dann vermute ich, dass Sie die Seite. Manchmal mit und manchmal ohne „www.“ aufrufen. Es ist wichtig, die Seite immer genau so aufzurufen, wie die Webadresse in den ftp Einstellungen angegeben ist, also je nachdem, mit oder ohne „www.“.

Hallo,

irgendwie wird kein PHP Session Cookie im Browser gesetzt, in dem der Zustand des Logins abgelegt ist. Da der Login-Zustand unbekannt ist, wird immer wieder das Login-Fenster angezeigt.

Senden Sie mir bitte Ihr Projekt, damit ich mir das genauer ansehen kann. Dazu muss ich dann auch mal auf den Server veröffentlichen. Sie sollten also, wenn möglich, heute nicht veröffentlichen, damit wir unsere Änderungen nicht gegenseitig überschreiben.

1. Öffnen Sie Ihr Projekt in Zeta Producer
2. Gehen Sie auf das Menü "Extras"
3. Klicken Sie auf den Button "Optionen"
4. Klicken Sie auf "Aktionen"
5. Klicken Sie rechts auf die Aktion "Projekt Senden" damit diese Markiert ist
6. Klicken Sie unten auf den Button "Ausführen"
7. Geben Sie im 1. Feld Ihre E-Mail-Adresse ein, damit wir Sie für Rückfragen kontaktieren können
8. Geben Sie als Referenz ins Feld Bemerkungen den Link zu diesem Forum-Artikel ein (per Kopieren und Einfügen)
9. Klicken Sie auf den Button "Senden"

Während wir an Ihrem Projekt arbeiten, sollten Sie bei sich keine Änderungen durchführen, denn sonst müssten Sie das ggf. nochmals im von uns modifizierten Projekt durchführen.

Bisher kam kein Projekt an. Ich schau dann ggf. morgen nochmal.

Ja, ich bin aber noch nicht so recht schlau daraus geworden, was hier passiert. Irgendwie wird kein Cookie gesetzt und daher taucht der Login-Dialog immer wieder auf.

Haben Sie die Möglichkeit auf Ihrem Server die PHP-Version zu ändern? Es wäre mal einen Versuch wert auf eine 7er PHP-Version zu wechseln. Die meisten Provider bieten die Möglichkeit zum Einstellen der PHP-Version im Admin-Interface an.

Wir sind hier nach 13 Tagen bei inzwischen 31 Beiträgen, ohne dass sich etwas am Problem geändert hat.

Ich schlage vor, dass Flugmodellclub RCA im Projekt bis auf die Seite mit dem geschützten Bereich alle anderen Seiten deaktiviert (damit vermutlich unter 20 MB ist) und das Projekt dann auf dem Testserver von Zeta veröffentlicht. Damit könnte mit einem Versuch geklärt werden, ob es nun ein Zeta-Problem oder ein Hosting-Problem ist.

1. der genutzte Hoster (alfahosting) war in letzter Zeit mehrfach Thema hier im Forum in Bezug auf PHP-Anwendungen
2. es ist nicht bekannt, ob auf dem Server die Schreibrechte für den Ordner /php/ korrekt eingerichtet sind
3. der serverseitige Passwortschutz wird über eine .htaccess geregelt. Deren Inhalt ist nicht bekannt, so dass nicht ausgeschlossen werden kann, dass auch hier Beschränkungen in der Ausführbarkeit bestimmter Komponenten bestehen.
4. Auf den Testserver haben die Mitarbeiter des Supports bei Bedarf Zugriff, können also, falls tatsächlich ein Fehler im Projekt liegt, auf die kompletten Protokolle zugreifen.

Ohne Veröffentlichung unter kontrollierten und bekannten Umgebungsbedingungen sehe keinen Lösungsansatz für das Problem.

Ich schlage vor, Sie deaktivieren momentan mal den Geschützten Bereich, da die Website ja eh komplett serverseitig geschützt ist und aktivieren das Geschützter Bereich Widget erst wieder, wenn die Site unter der endgültigen Adresse online ist. Falls es dann auch nicht funktioniert, können Sie dann ja alternativ ebenfalls einen serverseitigen Kennwortschutz nutzen.

Hallo Marco,

Das sind ja gute Nachrichten. Damit wäre geklärt, dass das Problem nicht bei Zeta, sondern in der Server-Konfiguration liegt.

Hinweis: Nach Abarbeiten der einzelnen Schritte die Seite jeweils mit gelöschtem Browser-Cache oder gleich im "Inkongito/Inprivate-Modus" aufrufen, damit wir nicht eine im Browserverlauf gespeicherte ältere Version der Seite sehen.

die nächsten Schritte wären:

1. kontrollieren, ob auf dem Alfa-Server im Stammverzeichnis von /neu-modellflugclub... eine .htaccess liegt.
   1. hierzu via filezilla mit dem Alfa-Server verbinden und in das Verzeichnis wechseln, welches der subdomain neu.modell.. zugeordnet ist
   2. Wenn ja, umbenennen in "alt.htaccess", damit werden die darin enthaltenen Steuerbefehle wirkungslos.
   3. direkt danach testen, ob die Seite jetzt funktioniert.
2. kontrollieren, ob für das Verzeichnis /assets/php die korrekten Datei- und Ordner-Berechtigungen gesetzt sind
   1. wir bleiben bei Filezilla, wechseln in /assets/
   2. Mausklick rechts auf den Ordner /php/, dann auf "Dateiberechtigungen". Hier muss "755", alternativ 777
   3. Falls nicht einer der o. g. Werte steht, ändern auf "755", Häkchen rein bei "Unterverzeichnisse einbeziehen" und "Nur auf Verzeichnisse anwenden"
   4. Wechseln in den Ordner /php/formmailer, dort bei einer beliebigen Datei ebenfalls die Dateiberechtigungen anzeigen lassen. Für einzelne Dateien sollten diese bei "644" stehen.
   5. Falls nicht, zurück bis in das Verzeichnis /php, Dateiberechtigungen aufrufen, dort "644" eintragen, "Unterverzeichnisse einbeziehen" und "nur auf Dateien anwenden" auswählen
   6. Fehler in den Datei oder Ordnerberechtigungen können dazu führen, dass bestimmte Dateien nicht ausgeführt oder neue Ordner nicht angelegt werden können. Solche Fehler können bereits bei der Veröffentlichung unbemerkt zu Problemen führen
   7. "Zeta" öffnen, dort das Projekt mit den Zugangsdaten für den Alfa-Server öffnen
   8. "Erweitert" -> "Erstellen" -> "alle Seiten erstellen"
   9. "Veröffentlichen" -> "komplette Website veröffentlichen"
   10. Testen, ob die Seite jetzt funktioniert
3. PHP-Version kontrollieren / anpassen
   1. Zeta liefert bei Veröffentlichung eine zp-php-info.php aus, mit der die aktuelle PHP-Version und deren Inhalte angezeigt werden können. (PHP-Alfa-Server, PHP-Test-Server)
   2. Im Vergleich fällt als erstes auf, dass auf dem Alfa-Server eine veraltete PHP-Version verwendet wird, 7.1 ist "end of life" und erhält lediglich noch Sicherheitssupport bis zum 1. Dezember diesen Jahres.
   3. Im Alfa-Server-Kontrollzentrum anmelden, PHP-Version wechseln auf 7.2 oder besser 7.3 (Zeta 15 ist unter beiden lauffähig)
   4. Die Änderungen werden sofort wirksam, direkt danach testen, ob die Seite funktioniert
   5. Falls nicht, die beiden Links unter 3.1 nochmals aufrufen und direkt die beiden Versionen "händisch" vergleichen. Da ich kein PHP-Spezialist bin, kann ich jetzt aber nicht sagen, worauf genau geachtet werden muss.
4. kontrollieren, ob es auf dem Alfa-Server eine php.ini gibt, über die individuelle Einstellungen an der PHP-Version vorgenommen werden können.
   1. . Falls ja, diese umbenennen
   2. erneut testen

Wenn am Ende dieser Liste die Seite immer noch nicht funktioniert, direkt den Support von Alfa kontaktieren und mit den Ergebnissen konfrontieren.

Hinweis: Theoretisch gehört das Thema ab jetzt in die "Plauderecke", da es hier nicht mehr um Zeta, sondern eine fehlerhafte Serverkonfiguration geht.

Ja wer hat denn da den Haken reingemacht? Standardmäßig ist BOM nicht gesetzt!

Da wir hier inzwischen bei #38 sind, bitte einen neuen Thread aufmachen oder besser mal die Forumssuche benutzen. Vor einem neuen Thread bitte beim Hoster erkundigen, welches Charset standardmäßig aktiviert ist.

Lösung:

Alfahosting verwendet anscheinend noch immer ISO-8859-1 als Default-Charset. Im Control-Panel von Alfahosting den Punkt "default_charset" deaktivieren, dann sollte der Server den Zeichensatz anhand der Inhalte der Webseite identifizieren. Falls dies noch nicht ausreicht, folgenden Code zur .htaccess hinzufügen:

# Zeichensatz setzen
AddDefaultCharset UTF-8
# Ende Zeichensatz setzen

PS: Thread wird geschlossen.

Super, dass Sie das gefunden haben. Darauf kamen wir nicht, weil bei dieser Einstellung normalerweise statt der Seite nur eine weiße, leere Seite gezeigt wird, was bei Ihnen ja nicht der Fall war. Gut das es nun läuft.

Abschließend noch eine Erklärung, was durch BOM eigentlich passiert ist: BOM ergänzt jede Tastatureingabe durch ein zusätzliches Bit. Bei UTF-8 führt dies dazu, dass nicht das eingegebene Zeichen beim Server ankommt, sondern ein anderes Zeichen. Damit ist das Passwort permanent falsch, wodurch das Login-Fenster für die Eingabe dies richtigen Passworts erneut angezeigt wird. Die Darstellungsprobleme mit den Umlauten kommen daher, dass die Seite in UTF-8 ausgeliefert wird, der Server aber dummerweise auf ISO- 8859-1 getrimmt ist. Dies lässt sich durch die Lösung in Beitrag #39 umgehen.