Probleme mit Widget "Geschützter Bereich"

  • Hallo allerseits,


    ich habe Darstellungsprobleme mit dem "Geschützten Bereich" unserer Homepage.

    Es erscheint folgender Text auf einer weißen Seite beim Versuch die als "Geschützter Bereich" deklarierten Seiten zu öffnen.:


    Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /var/www/web1560/html/test/NEU/statistik.php:1) in /var/www/web1560/html/test/NEU/statistik.php on line 46

    Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /var/www/web1560/html/test/NEU/statistik.php:1) in /var/www/web1560/html/test/NEU/statistik.php on line 46


    Nehme ich das Widget heraus wird wieder alles einwandfrei dargestellt.



    Über die Möglichkeit Website-Features prüfen erscheint folgendes obwohl PHP 5.6 vorhanden ist.




    Woran könnte es liegen bzw. an welchen Schrauben müssen wir drehen?


    Benutzt wird die Zeta Version 15 Express-Edition.


    VG

    Marco


    PS: ich bin kein IT-ler ;-)

  • Steffen T.

    Hat das Thema freigeschaltet
  • Jetzt komm ich bis zum Anmeldefenster, nach Eingabe des festgelegten Kennworts kommt allerdings eine weitere Meldung.


    VG Marco


  • Also, es wurde auf der Seite Mitgliederliste ein jpg Bild eingefügt welches vor dem Passwortschutz (Geschützter Bereich) ja auch dargestellt werden konnte.

    Nun, nach dem ergänzen des geschützten Bereichs, lässt es sich mit dem vergebenen Passwort nicht öffnen. Ein Code wurde nicht händisch hinterlegt, nur mit der Entwicklungsumgebung gearbeitet.

    Was wäre nun zu tun? Würde mich über konstruktive Hilfe freuen.

    VG Marco

  • 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.

  • 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.

  • Nach Updates suchen wurde unten rechts "Dateien aktualisiert" angezeigt.

    Widget wurde im Bereich "Mitgliederliste" wieder eingefügt und veröffentlicht.


    Es erscheint leider wieder folgende Meldung:


    <br />
    <b>Warning</b>: session_start(): Cannot send session cookie - headers already sent by (output started at /var/www/web1560/html/test/NEU/mitgliederliste.php:1) in <b>/var/www/web1560/html/test/NEU/mitgliederliste.php</b> on line <b>46</b><br />
    <br />
    <b>Warning</b>: session_start(): Cannot send session cache limiter - headers already sent (output started at /var/www/web1560/html/test/NEU/mitgliederliste.php:1) in <b>/var/www/web1560/html/test/NEU/mitgliederliste.php</b> on line <b>46</b><br />
    ok

    VG Marco

  • 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…

  • Unser Admin hat es sich angeschaut.

    Die PHP.ini Variable “error_reporting“ hat in dem Verzeichnis “NEU“ folgende Werte.

    “24567“ temporär und

    “24567“ master. Die Konstante “E_ERROR“ findet er nicht


    VG Marco

  • Nun konnte noch eine Einstellung zum Fehlerhandling geändert werden.

    Momentan kommt die Fehlermeldung aus Beitrag #16 nicht mehr.


    Bei Eingabe eines falschen Passworts erscheint:

    Zugang abgelehnt. Das angegebene Kennwort ist nicht korrekt.


    Allerdings erscheint nun nach Eingabe des korrekten Passworts:

    Zugang gewährt. Die Seite wird geladen.


    Die erwartete Seite baut sich aber leider nicht auf und das Feld zur Passworteingabe erscheint.


    VG Marco

  • 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.

  • mail ist raus.


    Der geschützte Bereich ließ sich zwischenzeitlich vom Smartphone und Tablet erreichen, vom Laptop bisher nie.

    Aktuell nur noch vom Smartphone und auch nicht mehr vom Tablet.


    VG Marco

  • 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.“.

    Freundliche Grüße
    Stefan S. (Zeta Producer-Support)

    Einmal editiert, zuletzt von Hanabi ()

  • 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.

  • 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.

  • Ich hab es die letzten Tage mehrfach vom Smartphone probiert, das funktionierte immer tadellos.

    Vom IPad und Laptop allerdings nicht. Nur mal so zur Info.


    Den Wechsel der PHP Version lasse ich prüfen.


    VG Marco

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


    Ich schlage vor, dass Marco 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.

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


    Ich schlage vor, dass Marco 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.


    Die Ideen von Hanabi klingen doch sehr gut. Dazu bräuchte ich ggf. noch etwas Hilfe zur Vorgehensweise was, wie zu tun ist.

    Ich hatte es versucht, gelang mir aber nicht, vielleicht hatte ich aber auch etwas nicht korrekt ausgefüllt, dazu bräuchte ich noch Unterstützung.

    Allerdings dachte ich, da ich ja das Projekt kürzlich an den Support gesendet habe, das es schon auf einer anderen Plattform bzw. der Zeta Testplattform getestet werden konnte.


    Der Serverseitige Passwortschutz der kompletten Site wurde zwischenzeitlich mal raus genommen und auch so waren die mit dem Widget (geschützter Bereich) versehenen Seiten nicht erreichbar, das Passwortfeld erschien immer wieder, egal von welchen Gerätschaften getestet wurde. (Mit der 7 er PHP-Version)


    Mit der 6 er PHP-Version ging es zumindest schon vom Smartphone, sollte man das wieder Rückgängig machen?


    Welche Seiten muss ich alle deaktivieren, auch die System Seite und die darin befindlichen Seiten?


    VG Marco

  • Ich habe noch etwas gespielt läßt mir keine Ruhe. ;-)


    Jetzt habe ich außer die System Seiten und das Menü "Mitgliederbereich" und 3 darunter befindliche Seiten alle deaktiviert und es irgendwie geschafft über die Zeta Testplattform zu veröffentlichen und es mir anzuschauen. Dort funktionierte dann die Passworteingabe, es erschien auch ein Abmeldebutton.


    Es kam aber zuvor beim veröffentlichen eine Meldung "Sorry, ihre Website ist für unseren Testserver zu groß"

    Nach erneutem Aufruf von veröffentlichen >>> ftp server konfigurieren>>>neu>>>Protokoll auswählen>>>ftp konnte dann die dort

    hinterlegte Adresse (https://hosting.zeta-producer.com/6288637887) über den Rechtspfeil neben der Adresse geöffnet werden.

    Auf der ersichtlichen, abgespeckten Version der Website konnten dann die 3 hinterlegten Bereiche nach Eingabe des Passworts gesichtet werden.


    VG Marco

  • 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.

  • Das Problem lag nun wohl doch irgendwie bei Zeta!


    Abhilfe brachte, unter Erweitert --> Erweiterte Einstellungen--> Kodierung, den Haken bei "BOM schreiben" zu entfernen.

    Danach funktioniert nun das Widget "Geschützter Bereich" einwandfrei.


    Leider gibt es nun Probleme, das die Umlaute nicht immer korrekt dargestellt werden.

    Sollte ich dafür einen neuen Fall eröffnen?


    VG Marco

  • 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:

    Code
    1. # Zeichensatz setzen
    2. AddDefaultCharset UTF-8
    3. # Ende Zeichensatz setzen

    PS: Thread wird geschlossen.

  • Hanabi

    Hat das Thema 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.