Homepage von Basti1012 = ,Hauptmenü
Hier im Forum bekommt ihr bei euren fragen schnelle hilfe.Hier geht es rund um das Web SeitenProgrammieren.Alles rund ums Javascript,Html,Php,Css und Sql.Auf fast allen Fragen haben wir eine Antwort.
Der Soforthilfe-chat verspricht das ,was sein Name sagt. Hier sind Leute Online die sofort ihre hilfe anbieten.Seht in der OnlineListe nach und wenn einer Online ist werdet ihr auch antwort bekommen. Admine ,Moderatoren und Helfer sind unsere Spezialisten in Sachen Web Programierung


PWAs auf iPhones waren schon immer schwierig und werden jetzt noch schwieriger umzusetzen. (Foto: Shutterstock)

Es klingt erstmal gut. Apples neuer Safari blockiert alle Dritt-Cookies konsequent. Aber, das ist nicht die ganze Wahrheit.

Apple hat sich in der Vergangenheit stets als Unternehmen positioniert, dass sich der Privatsphäre seiner Nutzer in besonderer Weise verpflichtet fühlt. Wer kennt nicht die jüngere Werbung, die versichert, dass alles, was auf einem iPhone passiert, auch auf dem iPhone bleibt?

Ebenso hat Apple schon seit Jahren die sogenannte Intelligent Tracking Protection in Betrieb, die eigentlich die Aufgabe hat, Cross-Site-Tracking über den Safari-Browser zu unterbinden. Das wird allgemein als positiv wahrgenommen und wurde mit der Ankündigung der vollständigen Cookie-Blockade nochmal verstärkt.

Aber, wie es so ist mit dem Framing, man kann Begriffe auch so definieren, dass sie nebenbei einer anderen Agenda zu dienen vermögen. So wissen wir seit geraumer Zeit, dass PWA, also progressive Web-Apps, Apple ein Dorn im Auge sind.

Das ist aus Unternehmenssicht verständlich. Immerhin lebt Apple in steigendem Maße von Einnahmen aus seinem App-Store. Der wiederum beinhaltet native Apps, die auf den Geräten der Apple-Kunden installiert werden. Viele dieser Apps könnten auch als PWA funktionieren, also als per HTML, Javascript und CSS umgesetzte Web-App. Sie müssten nicht installiert werden, stünden stets in der aktuellsten Version zur Verfügung und würden keinen Speicherplatz auf dem Gerät belegen.

Zur allgemeinen Sinnhaftigkeit einer PWA im Vergleich zu einer nativen App haben wir uns bereits geäußert. Mit dem Zustand der PWA-Entwicklung im Jahr 2020 haben wir uns ebenfalls bereits beschäftigt.

Progressive Web Apps: Zusammenstellung unter PWA Rocks

Apple führt Zwangslöschung für lokal beschreibbare Speicherfunktionen ein

Damit eine PWA vollwertig funktionieren kann, muss sie Zugriff auf die Geräte-APIs, sowie einige andere technische Strukturen wie Indexed DB, LocalStorage, Media-Keys, SessionStorage oder Service Workers haben. Nicht jede PWA braucht dabei Zugriff auf alle eben genannten Features, aber ohne alle dieser Features funktioniert keine PWA.

Mit dem jüngsten Update des Safari-Browsers führt Apple einen 7-Tage-Löschrhythmus für genau diese Funktionen ein. Nutzt eine PWA etwa LocalStorage zur Datenablage, zum Beispiel für eine einfache Listen-App, so stehen die darin gespeicherten Daten nur noch für sieben Tage zur Verfügung, bevor sie der Apple-Löschroutine zum Opfer fallen. Ebenso verhält es sich mit den anderen eben genannten script-beschreibbaren Funktionen. Dabei gilt der Fristbeginn als letzter Zeitpunkt, an dem ein Nutzer die Website benutzt hat und kann so natürlich durch rege Nutzung stetig nach vorne geschoben werden.

Das bestätigt Apple im Beitrag ?Full Third-Party Cookie Blocking and More? unter dem Zusatz ?and More? und hofft dabei möglicherweise, dass es nicht so sehr auffällt. Immerhin klingt der Titel ansonsten überaus zustimmungswürdig.

Apple beschwichtigt: Homescreen-Web-Apps nicht betroffen

In einem weiteren Absatz versucht Apple klarzustellen, dass Web-Apps, die Nutzer zu ihrem Homescreen hinzugefügt haben, nicht in gleicher Weise von dieser 7-Tage-Regel betroffen sein sollen. Damit meint Apple natürlich die PWA, die der Konzern konsequent lieber als ?Home Screen Web Apps? oder ?HTML5 Apps? bezeichnet.

Wie PWA nun aber betroffen sind, lässt Apple offen und orakelt stattdessen, dass Websites auf Homescreens nicht Teil von Safari seien und insofern ihre eigenen Lösch-Timer hätten, die wiederum von der konkreten Nutzung dieser Web-App abhängig wären. Man ginge nicht davon aus, dass es zu Löschungen bei solchen Apps käme und sei es doch der Fall, sollten sich die Entwickler an Apple wenden, denn das würde als ?ernster Fehler? betrachtet.

Ohne Schwurbelei: Apple lehnt das Konzept der PWA ab

Dem PWA-Entwickler nutzt diese blumige Umschreibung nichts. Hier wären klare Aussagen wertvoller gewesen. Ein weiteres Problem, neben der Unsicherheit, was nun mit den ?Home Screen Web Apps? nach X Tagen passiert, stellt der Fokus darauf dar, dass es sich um ?Home Screen Web Apps? handeln muss, um eine gewisse, wenn auch unklare Verschonung von Apples rigidem Lösch-Regime für sich erwarten zu dürfen.

Immerhin definiert sich eine PWA nicht dadurch, dass sie irgendwer auf seinem Homescreen ablegt. Sie definiert sich vielmehr technisch durch ganz andere Features. Am Ende all dessen kann sich der Nutzer entscheiden, eine PWA auch auf seinem Homescreen abzulegen, muss es aber nicht. Tut er es künftig unter Safari weiterhin nicht, wird er in jedem Fall mit der 7-Tage-Löschung konfrontiert. Das bringt PWA-Entwickler wie Andre Garzia zu Recht auf.

Garzia sieht darin ? und in der Beschränkung aller Browser unter iOS auf die Webkit-Engine ? den transparenten Wunsch Apples, Entwickler ins System nativer Apps und damit den eigenen App-Store zu zwingen. Man kann es ihm nicht verdenken?

Passend dazu:



Google+ Beiträge per WordPress Plugin einbetten

Es ist soweit. Nachdem Twitter schon eine gefühlte Ewigkeit lang die Möglichkeit bietet, Tweets auf der eigenen Website oder dem eigenen Blog einzubetten, zog ja bekanntlich auch Facebook vor gut einem Monat nach und implementierte eine entsprechende Funktion. Damals stellte ich ein WordPress Plugin zur Verfügung, um die Facebook Embedded Posts bequem einzubetten.

Seit wenigen Stunden ist nun auch das dritte große Soziale Netzwerk, Google+, mit von der Partie. Ähnlich wie bei den Facebook Beiträgen lassen sich auch Google+ Posts mit Hilfe eines kurzen Code Snippets in jeder beliebigen externen Webseite anzeigen. Dabei gelten ungefähr die selben Richtlinien wie beim blauen Konkurrenten: Beiträge, die nur mit bestimmten Kreisen, also nicht öffentlich, geteilt wurden, können logischerweise nicht eingebettet werden.

So sieht ein eingebetteter Google+ Post aus

Hier ein kurzes Beispiel, wie ein eingebundener Beitrag aussehen könnte:

[gp-post href=“https://plus.google.com/114421677831789165567/posts/5SLVJraiZ4P“]

Was ist zu beachten?

Möchte man Google+ Beiträge auf seiner Webseite oder Blog einbetten, muss man einige Richtlinien beachten. Beispielsweise muss die verwendete Post-URL korrekt sein, da es hier unterschiedliche Varianten gibt.

Korrekt ist:

  • https://plus.google.com/110174288943220639247/posts/cfjDgZ7zK8o

Nicht korrekt ist:

  • https://plus.google.com/+LarryPage/posts/MtVcQaAi684
  • https://plus.google.com/u/0/106189723444098348646/posts/MtVcQaAi684

Außerdem gibt es Stand heute einige Einschränkungen hinsichtlich der verwendbaren Formate.

In Ordnung sind:

  • Beiträge mit Bildern
  • Beiträge mit Videos
  • Beiträge mit Links zu einer Community

Nicht in Ordnung sind:

  • Beiträge innerhalb einer Community
  • Beiträge, die auf eine Google Apps Domain beschränkt sind
  • Private Beiträge
  • Event Beiträge
  • Hangout on Air Beiträge

Die Google+ Embedded Posts verwenden

Wie bereits eingangs geschrieben, stellt Google Webseitenbetreibern ein kleines Code Snippet zur Verfügung, um die Beiträge auf der eigenen Webseite einzubetten. Dies ist vergleichbar mit dem Einbau des +1 Buttons. In der Google Entwicklerdokumentation findet man hierzu einen englischsprachigen Hilfe-Artikel.

So könnte es beispielsweise in der Praxis aussehen:

WordPress Plugin zum schnellen Einbetten

Wer WordPress als CMS oder Blogsystem einsetzt, kann sich hier direkt das (hoffentlich erste) Google+ Embedded Posts WordPress Plugin herunterladen.

Das Einbetten der Beiträge geht damit noch schneller von der Hand. Nach der Aktivierung steht euch in Artikeln und Seiten der Shortcode gp-post zur Verfügung, an den ihr den Parameter href übergeben könnt. Hier einmal ein vollständiges Beispiel, dass die Funktionsweise recht gut veranschaulichen sollte:

An die benötigte URL kommt man übrigens sehr einfach, in dem man bei einem Beitrag auf den jeweiligen Zeitstempel klickt. Nun öffnet sich der Post in einem neuen Tab und ihr könnt die URL aus der Browser-Adresszeile kopieren. Aber wie gesagt darauf achten, dass der Beitrag den Richtlinien entspricht bzw. öffentlich ist.

Aktuell könnt ihr das Plugin von meinem Server oder von GitHub herunterladen. Anschließend den entpackten Ordner in euer WordPress Plugin Verzeichnis hochladen und über das Backend aktivieren.

Plugin auf GitHub

Umwetter Warnumgen und Wetter vorschau