IIRC war das für einige Browser (IE < 10?) unerlässlich, weil es unmöglich ist, auf noscript-Tags über JavaScript zuzugreifen, nachdem die Feature-Detection durchgeführt wurde. Ich glaube, @dan hat vor ein paar Jahren an diesem Problem gearbeitet?
Beachten Sie, dass es derzeit zwei Fallback-‘Modi’ gibt:
Die Crawler-Ansicht bereitstellen. Kein JS erforderlich. Dies ist abhängig von browser_update_user_agents.
Die vollständige App bereitstellen, Feature-Detection durchführen und durch Verschieben von noscript-Inhalten in body zurückfallen. Dies basiert nicht auf dem User-Agent.
Das Problem hier ist, dass (2) auf Mobilgeräten nicht funktioniert, da der Server keine noscript-Inhalte rendert. Wir müssen das beheben, ohne (1) für sehr alte Browser zu beeinträchtigen.
Ich schlage vor, wir aktualisieren die Schritte auf:
Wie wolltest du (2) implementieren, @sam? Eine Liste von ‘modernen’ User-Agent-Matchern im Kern pflegen? Und dann heben wir sie im Rahmen des stabilen Release-Zyklus an?
Ja, so etwas in der Art. Ehrlich gesagt sieht diese Woche für mich nicht allzu vielversprechend aus, ich schaffe es nicht, viel Programmierzeit freizuschaufeln.
Wahrscheinlich werde ich diese Arbeit weitergeben. Dein überarbeiteter Aktionsplan klingt großartig.
Es scheint, dass es einige Kommentare zu lösen gibt, aber es wird wahrscheinlich in den nächsten 24 Stunden zusammengeführt. Wir werden hier aktualisieren, wenn es soweit ist. Dann, vorausgesetzt, Sie sind auf tests-passed, können Sie /admin/upgrade auf Ihrem Forum besuchen und die Änderung übernehmen.
Interessanterweise sehe ich auf einem iPhone 5 im Browser Stack, der auf lokal weitergeleitet wird, eine weiße Seite, selbst nachdem ich mit include_crawler_content? herumgespielt und es auf true gesetzt habe.
Es kann sein, dass Ember CLI lokal etwas tut, das dieses Testen beeinträchtigt.
Es sieht sicherlich kaputt aus, wie es auf iOS 7 in der Produktion konzipiert ist. (Kein Inhalt, da wir ihn nicht ausliefern)
Es wird ziemlich schwierig sein, die Korrektur zu testen, aber ich schätze, ich kann lokal einige Dinge vortäuschen.
Dies sollte sowieso etwa 95 % unseres mobilen Traffics abdecken, sodass die Payload-Einsparung erheblich und das Risiko extrem gering ist.
@Falco, habe ich irgendwelche Browser vergessen? Firefox ist wie ein Tropfen auf den heißen Stein für Android, die überwiegende Mehrheit scheint einfach auf Chrome zu sein.
5 „Gefällt mir“
david
(David Taylor)
Hat dieses Thema aufgeteilt,
71
Das scheint gestern wieder kaputt gegangen zu sein. Ich bekomme eine weiße Seite ohne Fehlermeldung über meinen Browser und die App in denselben zwei von drei Foren
Ja, meta.discourse.org gibt eine leere Seite zurück, ebenso wie community.jenkins.io, genau wie in der ursprünglichen Beschwerde. Kann bestätigen, dass es irgendwann am Mittwoch begann.
Das ist jetzt auf Meta bereitgestellt, und die Mehrheit unserer gehosteten Kunden (einschließlich http://community.jenkins.io/). Seiten sollten jetzt unter iOS 12 wieder geladen werden. Danke für die Meldung des Problems @wake und @Ian_W!
Tolle Neuigkeiten, dass es wieder funktioniert. Ich schätze all Ihre Bemühungen.
Nur eine seltsame Beobachtung jetzt. Ich tippe die URL ein, drücke Enter und die Fortschrittsanzeige füllt sich langsam. Dann lande ich zunächst auf einer leeren Seite, aber etwa 6-7 Sekunden später erscheint der Inhalt! Das hat früher nur etwa eine Sekunde gedauert (also kaum bemerkbar). Seltsam.
