Das Theme-Review-Team möchte den Grad der Automatisierung bei Reviews erhöhen. Außerdem gibt es ein Update zur REST-API – so werden nun beispielsweise passwortgeschützte Beiträge unterstützt.
Core
Updates zur REST-API
In einem Beitrag auf Make/Core gibt K.Adam White Einblicke darauf, was in letzter Zeit im API-Team los war. So wurde beschlossen, dass passwortgeschützte Beiträge in Collections mit zurückgegeben werden, der Inhalt aber durch einen leeren String ersetzt wird. Der kann dann durch Übergabe des Passworts als GET-Parameter eingesehen werden. Auch bei der Handhabung von Sticky Posts gibt es Fortschritte. So wird er bei /wp/v2/posts ganz normal zurückgegeben, als wäre es ein normaler Post – ohne an den Anfang gestellt zu werden. Über den Parameter ?sticky=true können alle Beiträge geholt werden, die Sticky sind; über ?sticky=false können Sticky Posts von der Rückgabe ausgeschlossen werden.
Auch im Bereich Meta-Unterstützung und Website-Optionen hat sich was getan. Näheres dazu im verlinkten Beitrag.
Features-Meeting Twenty Seventeen am 27. September
Das Meeting zu den Funktionen von Twenty Seventeen scheint sich hauptsächlich um die Möglichkeit von Inhaltsblöcken gedreht zu haben. Es soll möglich sein, Inhalte mehrerer Seiten auf einer Seite darzustellen. Nun werden sich Gedanken dazu gemacht, wie das für den Benutzer am besten umgesetzt wird, ob nur im Customizer, in der normalen Bearbeitungs-Ansicht oder beidem.
Daneben ging es um Video-Header und Dummy-Inhalte. Weitere Punkte aus dem Meeting findet ihr in der Zusammenfassung von David A. Kennedy auf Make/Core.
Core-Meeting vom 28. September
In der Medien-Komponente braucht es einen weiteren Patch für die Durchsuchbarkeit von Dateinamen, da die aktuelle existierende JOINs kaputt macht. Außerdem wäre Hilfe und/oder Feedback zu der Einführung einer Funktion zur Änderung der Backend-Sprache wünschenswert und willkommen (#26511).
Mehr zum Meeting gibt es in den Notizen von Jeff Paul auf Make/Core.
Änderungen an den Panels im Customizer
Das oberste Panel im Customizer (wo es beispielsweise zu den Website-Informationen geht), wurde im DOM von den Panels und Sections getrennt, auf die es verlinkt. So muss nun für deren Positionierung weniger getrickst werden, wenn sie angezeigt werden. Außerdem ist es nicht mehr notwendig, aus Gründen der Barrierefreiheit die Kindelemente im Customizer sichtbar zu machen, während das Root-Element versteckt ist. Der Zusammenhang zwischen den im Code nun unabhängigen Bereichen wird über die aria-owns-Attribute beibehalten.
Mehr Infos dazu findet ihr im Beitrag von Piotr Delawski auf Make/Core.
Twenty-Seventeen-Meeting am 30. September
Im anderen Meeting zum neuen Standard-Theme wurde berichtet, dass die Design-Implementierung Anfang nächster Woche für einen Pull-Request fertig sein sollte. Daneben wurde über Fonts und Non-Latin-Fallbacks diskutiert. Die Zusammenfassung gibts im Beitrag von David auf Make/Core.
HTTPS-Meeting am 30. September
Im HTTPS-Meeting ging es um die Punkte, die im Beitrag HTTPS Working Group angesprochen wurden. Für das Erzwingen des HTTPS-Schemas für Bilder, Skripte, Canonical-URLs et cetera ist der aktuelle Plan, dafür verschiedene Konstanten (wie beispielsweise FORCE_SSL_CONTENT) einzuführen, damit es granular geregelt werden kann. Ob und wie diese Optionen am besten auch im Backend aktiviert werden können, muss noch diskutiert werden.
Für die Migration einer HTTP-Site auf HTTPS bleibt dann noch das Problem bereits eingefügter Bilder und anderer Dateien in bestehenden Beiträgen. Hier wäre eine Möglichkeit, the_content zu filtern, um das Schema auszutauschen.
Verschiedenes
- WordPress REST-API 2.0 Beta 14. Unterstützung für passwortgeschützte Beiträge und mehr.
Polyglots
Polyglots-Meeting vom 28. September
Im Meeting ging es unter anderem darum, ob es okay sei, sich für die Übersetzung eines Themes oder Plugins bezahlen zu lassen. Die Antwort darauf: Falls jemand die Zeit eines Übersetzers bezahlen möchte, damit er an einem bestimmten Plugin oder Theme arbeitet, ist das völlig in Ordnung. Nicht okay wäre hingegen, wenn ein Global-Translation-Editor nur an einem Projekt arbeitet, wenn er dafür bezahlt wird, während er gleichzeitig anderen Übersetzern im Weg steht.
Mehr Infos zum Meeting gibts in der Zusammenfassung von Bego Mario Garde auf Make/Polyglots.
Theme-Review-Team
Unvollständige Theme-Einreichungen
Das Theme-Review-Team hat in letzter Zeit täglich Anfragen bekommen, Tickets wieder zu öffnen, die wegen mehr als fünf Fehlern geschlossen wurden. Carolina Nymark stellt im Beitrag auf Make/Themes klar, dass die Autoren dafür verantwortlich sind, dass nur Themes eingereicht werden, die bereit für die Review sind, und dass dieser Zustand während der gegebenenfalls längeren Wartezeit auch durch Updates aufrecht erhalten wird, sollte es notwendig sein.
Außerdem werden häufiger unvollständige Updates beobachtet, bei denen der Reviewer wiederholt auf dieselben Probleme hinweisen muss, die noch nicht behoben wurden. Mehr dazu gibt es in verlinkten Beitrag von Carolina.
Warum wird an einer verbesserten Automatisierung für den Theme-Review-Prozess gearbeitet?
Kurz: Damit der Review-Prozess schneller geht. Dadurch, dass bei einem automatisierten Test mehr Fehler überprüft werden, müssen sich um diese Fehler die Reviewer nicht mehr kümmern. Aktuell gibt es das Theme-Check-Plugin, das jeden Theme-Upload überprüft. Aus verschiedenen Gründen müsste das komplett neu geschrieben werden, um es deutlich verbessern zu können. Die Nutzung von PHP CodeSniffer wurde auf dem WordCamp Europe bei einer Diskussion als beste Lösung gefunden.
Hierfür gibt es bereits WordPress-Coding-Standards, die erweitert werden müssten. Das passiert im GitHub-Repo des Theme-Review-Teams, wo es auch eine Liste mit den Sniffs gibt, die implementiert werden müssten. Aber auch beim CodeSniffer gibt es ein paar Grenzen, so versteht das Tool beispielsweise nicht, was gerade Objekt des Sniffs ist, es durchläuft einfach die Dateien. Ein Beispiel, das der CodeSniffer nicht prüfen könnte, wäre ein Theme das zwar das rtl-Tag hat, aber letztlich keine Sprachen von Rechts nach Links unterstützt. Dafür müsste ein spezielles Tool entwickelt werden, und auch da gibt es bereits Überlegungen für.
Einige Informationen mehr gibt es im Beitrag von Frank Klein auf Make/Themes.
Verschiedenes
Plugins
Verschiedenes
- Einige E-Mail-Anbieter scheinen ohne Benachrichtigungen E-Mails mit ZIP-Anhängen nicht zu versenden.
Community
Wie wärs mit einem neuen Support-Desk?
Alle E-Mails, die an die Support-E-Mail-Adresse von WordCamp.org gehen, werden aktuell mit SupportPress gehandhabt. Diese Lösung hat einige Grenzen, weshalb Hugh Lashbrooke sich alternative Lösungen angeschaut hat, die mehr oder passendere Funktionen bieten.
Mehr Details dazu findet ihr im Beitrag von Hugh auf Make/Community.