[smartVISU v2.9] Calender Widget zeigt nichts an

[wvhn]

Hast Du gesehen, dass seit einiger Zeit bei jedem upgrade der Fehler "Error: Sub-process /usr/bin/dpkg returned an error code (1)" geschmissen wird?
Aus dem Log ist allerdings nicht ersichtlich, an welchem Paket das hängt.

Kann ich davon ausgehen, dass das Problem mit den upgrades am 25.6. begonnen hat?

Ich würde erstmal nichts mehr upgraden, bis wir das Problem gelöst haben.

[whe]

Ich erinnere mich, dass ein build process für scipy einem PiPy Paket schief gegangen ist; dem habe ich keine große Bedeutung beigemessen.

[wvhn]

Hier nochmal weitere Infos.

• bei mir gab es die gleichen Fehlermeldungen, wie bei Dir. Seitdem ich die Zertifikate installiert und ein App-spezifisches Passwort generiert habe, werden die Kalendereinträge von meinem Raspberry mit Apache2 korrekt angezeigt.
• die Debug-Funktion zeigt leider die Ergebnisse nicht vollständig an. Es müssten aber wenigstens die URLs der Kalender angezeigt werden und die ICS Rohdaten. Wenn das nicht der Fall ist, ist keine Verbindung zu iCloud zustande gekommen.
• Leider habe ich zu lange auf meinem Windows-System mit Apache getestet. Letztlich habe ich dann herausgefunden, dass der ICS-Parser empfindlich auf die Unterschiede bei den Zeilenenden in den verschiedenen Betriebssystemen reagiert. Nachdem ich das angepasst habe, zeigt SV die Daten auch da korrekt an.
• um zu prüfen, ob Deine Systeme unterschiedlich mit den Zeilenenden umgehen, könntest Du mal die beiden php.ini vergleichen und nach "EOL" oder "PHP_EOL" suchen.

Gruß
Wolfram

[wvhn]

whe , bist Du weiter gekommen?
Ich bin jetzt soweit durch:

• die Services bringen alle ihre eigene init()-Funktion mit. In der service.php sind deshalb die Zuweisungen aus dem PHP-Request überflüssig.und verursachen die irreführenden Fehlermeldungen, die wir beide gesehen haben. Für die kommende Version deaktiviere ich die Zuweisungen deshalb:
  

  public function init($request)
  	{
  		$this->debug = ($request['debug'] == 1);
  		error_reporting($this->debug ? E_ALL : 0);
  		
  		// the following section has been deactivated by wvhn 
  		// all services bring their own init functions which define the needed communication parameters
  		// (most services threw misleading errors here, because $request was empty)
  
  		//$this->server = $request['server'];
  		//$this->port = (int)$request['port'];
  		//$this->url = $request['url'];
  		//$this->user = $request['user'];
  		//$this->pass = $request['pass'];

• auch in der calendar.php werden solche Zuweisungen noch vorgenommen. Da diese zumindest im debug-Modus noch wichtig sind, fragen wir ab, ob sie über den PHP-Request angefragt wurden und setzen sie nur in diesem Fall:
  

  	public function init($request)
  	{
  		parent::init($request);
  
  		if(isset($request['count']))
  			$this->count = $request['count'];
  		if(isset($request['calendar']))
  			$this->calendar_names = preg_split('/[\s,]+/m', strtolower($request['calendar']));
  		$this->url = config_calendar_url;

• Sobald die "falschen" Fehlermeldungen nicht mehr geschmissen werden, zeigt die mit "debug=1" aufgerufene Seite .../iCloud.php die Daten vollständig an.

Ursache dafür, dass die debug-Seite durcheinander kommt, ist einerseits die Einstellung des Fehler-Reportings im Server, aber auch eine IMHO nicht ganz saubere Implementierung der verschachtelten Services - insbesondere der header()-Definitionen. Das werde ich mir nochmal in Ruhe ansehen.

Die geschilderten Effekte gelten übrigens nur für die debug-Seite. Das Kalender-widget funktioniert einwandfrei, seitdem Passwort und Zertifikate richtig gestellt sind.

Gruß
Wolfram

[whe]

Danke Wolfram für all Deine Mühen,

hatte ein paar Tage nicht mehr reingeschaut.
- die Geschichte mit dem App-spezifischen Passwort habe ich gemacht.
- an Zertifikaten habe ich nichts unternommen.
- mit Apache funktioniert es bei mir ja auch; nur nicht mit nginx, deshalb glaube ich ja von Anfang an, dass es ein nginx Problem ist, vielleicht auch in Zusammenhang mit Zertifikaten. Ich möchte aber jetzt nicht alles auf Apache zurückdrehen, weil Onkelandy ja seit 1.7 sein img auf nginx umgestellt hat.
- es kommen bei mir keine ICS-Rohdaten an; auch ein Indiz, dass es an nginx liegt

vielleicht warte ich sein neues img ab und seine angepasst nginx Konfiguration; ( danach hatte ich ihn schon gefragt )

[wvhn]

OK. Danke fürs Feedback.
Interessant wäre dennoch, wie sich die Fehlermeldungen im Server-Log verändern, wenn Du die o.g. Änderungen einspielst.
Wichtig ist mir, dass ich die Ursachen verstehe und solche Effekte möglichst ausschließe. Ich kann halt nicht alle Kombinationen aus Servern und Browsern durchtesten.
Wenn Ihr also etwas findet, lasst mich bitte teilhaben.

Gruß
Wolfram

[whe]

Oh Wunder,

meine Kalender Daten sind wieder da, ohne dass ich etwas geändert habe.
dann lag es wohl an ?????

Gruß Wil

[wvhn]

😮 Gar nichts? Kein Update von Systemdateien, nginx-Einstellungen ...?