Vorlagen

Die Verwendung von benutzerdefinierten CSS-Eigenschaften für das WordPress-Admin-Farbschema-System ist für den WordPress-Meilenstein 5.7 aufgeführt. Es fühlt sich unauffällig genug an, dass die meisten es als ein einfaches Upgrade übergehen würden, um mit der Zeit zu gehen. Dieses Feature kann jedoch Wellen erzeugen, die sich ausbreiten und dem Ökosystem in den kommenden Jahren zugute kommen.

Kirsty Burgoine, eine Front-End-Entwicklerin bei Human Made, kündigte die Einführung von benutzerdefinierten CSS-Eigenschaften für den WordPress-Admin an. Die erste Arbeit landete in einem Ticket zur Iteration der Admin-Farbschemata. In der ersten Phase wurde die Farbpalette von 199 Farben auf 99 reduziert, um eine vernünftige Liste zu erstellen, mit der man arbeiten kann.

In der zweiten Phase wird untersucht, wie man ein sinnvolles System für benutzerdefinierte CSS-Eigenschaften implementieren kann. Das bedeutet, die gefürchtete Arbeit der Benennung von Dingen zu erledigen. Das Core-CSS-Team ist derzeit auf der Suche nach Feedback darüber, wie die Eigenschaftsnamen in Zukunft am besten gehandhabt werden sollen und ist offen für alternative Implementierungsvorschläge.

Sobald die benutzerdefinierten Eigenschaften eingeführt sind, könnte das neue System langfristig eine Welt voller Möglichkeiten eröffnen.

Vorausschauend denken

Meine Hoffnungen auf WordPress-Admin-Themes lebten und starben mit jeder Nachricht über benutzerdefinierte Farbschemata, phantasievolle Mockups und den allgemeinen Hype um Projekte, die nie das hielten, was sie versprachen. Vielleicht mache ich mir jetzt wieder Hoffnungen.

Entwickler können seit WordPress 2.5 benutzerdefinierte Admin-Farbschemata registrieren, aber es war nie ein ideales System.

Eines meiner Lieblings-Plugins ist Admin Color Schemes, das von Designern aus dem WordPress-Kernteam gepflegt wird. Es fügt mehrere Schemata hinzu, aus denen die Benutzer wählen können.

Sass, das heute zur Generierung der Admin-Farbschemata im Core verwendet wird, hat den Prozess vereinfacht. Entwickler von Drittanbietern müssen jedoch immer noch dafür sorgen, dass ihre benutzerdefinierten Schemata zwischen den WordPress-Versionen aktualisiert werden. Das System ist nicht dafür ausgelegt, vor zukünftigen Kompatibilitätsproblemen zu schützen.

Benutzerdefinierte CSS-Eigenschaften ändern das Spiel. Mit ihrer weit verbreiteten Verwendung und der Kompatibilität mit modernen Browsern ist das benutzerdefinierte Admin-Thema – zumindest das Farbschema – viel mehr eine Realität.

Ich war nicht mehr so aufgeregt über die Möglichkeit von etwas Neuem, seit Tung Do 2013 sein kurzlebiges DP Dashboard Plugin veröffentlicht hat. Jetzt, ein paar Tage vor acht Jahren seit der ersten Beta-Testphase, habe ich wieder etwas Hoffnung.

In Anbetracht der kleinen Weisheit, die ich im Laufe der Jahre angesammelt habe, sehe ich jetzt, dass komplett angepasste Admin-Themes nie zum richtigen Weg geführt haben. Ich bin froh, dass wir ihn nie eingeschlagen haben. Administrationsoberflächen müssen für die Benutzer konsistent funktionieren und sich im Laufe der Zeit an Änderungen anpassen. Benutzerdefinierte Themes waren jedes Mal, wenn WordPress eine neue Funktion hinzufügte, ein Wartungsalptraum. Ein System, das auf benutzerdefinierten CSS-Eigenschaften aufbaut, bedeutet jedoch, dass Anpassungen nicht kaputt gehen – oder viel seltener kaputt gehen – wenn sich die Benutzeroberfläche der Software weiterentwickelt.

Während der Fokus im Moment auf Farbschemata liegt, hält nichts WordPress davon ab, in der Zukunft weitere Funktionen zu entwickeln. Es ist möglich, ein globales Stylesystem einzurichten, mit dem Designer den Admin auf alle möglichen interessanten Arten gestalten können, ohne etwas kaputt zu machen. Kleinere Optionen wie der Rahmenradius von Schaltflächen, die Wahl der Schriftart oder die Schriftgröße von Überschriften könnten mit der Zeit leicht eingeführt werden.

Da das Blocksystem weiterhin Teile der WordPress-Administration ersetzt, werden benutzerdefinierte Admin-Skins viel einfacher zu pflegen sein. Da alles im Blocksystem als Komponente aufgebaut ist, ist es zukunftssicherer gegen Rückwärtskompatibilitätsprobleme.

Es ist ein langer und kurvenreicher Weg zu einem funktionsreichen Admin-Skin-System. Es liegt jedoch nicht außerhalb des Bereiches des Möglichen.

Ich freue mich auf den Tag, an dem Theme-Autoren einfach Admin-Designs ausrollen können, die zum Frontend passen. Vielleicht ist eine Integration mit der theme.json des Blocksystems eine Möglichkeit. Ich hätte auch nichts dagegen, in Zukunft ein separates Admin-Theme-Verzeichnis zu sehen. Der Anwendungsfall ist vielleicht noch zu nischig, aber es schadet nie, die Idee im Hinterkopf zu behalten.

Zumindest erlaubt der Wechsel zu benutzerdefinierten Eigenschaften dem Team, das Admin-CSS aufzuräumen und macht es einfacher, benutzerdefinierte Farbschemata hinzuzufügen. Das ist ein Gewinn für das WordPress-Projekt.

WordPress 5.7 Beta 1 wurde diese Woche pünktlich veröffentlicht und ist bereit für breitere Tests. Diese Version wird 68 neue Funktionen und Verbesserungen, Dutzende von Fehlerkorrekturen und die Versionen 9.3 – 9.9 des Gutenberg-Plugins enthalten.

Einige der Highlights, die in 5.7 erwartet werden, sind die folgenden

Lazy-load iframes: Als WordPress 5.4 Lazy-Loading für Bilder einführte, diskutierten die Mitwirkenden darüber, dies auch auf Iframes auszuweiten. Nun, da das Lade-Attribut für iframe-Tags zum HTML-Standard hinzugefügt wurde, wird es in 5.7 im Kern unterstützt werden.

Vereinfachte Migration von HTTP zu HTTPS: WordPress kann nun erkennen, ob die Hosting-Umgebung eines Benutzers HTTPS unterstützt und ermöglicht einen Ein-Klick-Aktualisierungsprozess, der gemischte Content-Rewrites behandelt, wo dies möglich ist.

Standardisierung der in WP-Admin-CSS verwendeten Farben auf eine einzige Palette: WordPress implementiert ein System für benutzerdefinierte CSS-Eigenschaften, das das Hinzufügen von benutzerdefinierten Farbschemata vereinfachen wird.

Laufende Aufräumarbeiten nach dem Update auf jQuery 3.5.1

Neue Robots-API: Diese neue API ermöglicht es Entwicklern, den Inhalt des in die Seite eingefügten Robots-Meta-Tags zentral zu verwalten, und enthält eine Einstellung, mit der umgeschaltet werden kann, ob Suchmaschinen große Medien von der Website anzeigen dürfen. Standardmäßig wird eine max-image-preview:large robots-Direktive in das robots-Meta-Tag injiziert, die auf der neuen Einstellung basiert.
Diese Funktionen müssen getestet werden, zusammen mit der Vielzahl von Updates, die vom Gutenberg-Plugin übernommen wurden. Der Editor erhält die sichtbarsten Verbesserungen in 5.7, mit Funktionen wie dem Ziehen von Blöcken und Blockmustern aus dem Inserter in den Canvas, großen Verbesserungen am Button-Block, neuen Social Icons und vielem mehr.

Das offizielle Release wird in knapp fünf Wochen am 9. März 2021 erwartet. Testen ist ein wichtiger Teil des Prozesses, um WordPress mit jedem Update besser zu machen. Der einfachste Weg, um dabei zu sein, ist die Installation des WordPress Beta Tester Plugins (eingestellt auf den Bleeding Edge Channel und den Beta/RC Only Stream), oder das Herunterladen und Installieren der Zip der Beta-Version.

FSE und WordPress-Themes: Wie sieht das MVP aus?

Josepha Haden Chomphosy, die Geschäftsführerin von WordPress, postete eine Fortsetzung ihres Ausblicks auf das kommende Jahr. Es kamen Fragen auf, wie ein Minimum Viable Product (MVP) für Full Site Editing (FSE) aussieht, das im Gutenberg-Plugin voraussichtlich im April fertig sein wird. Das Kernteam strebt außerdem eine Einführung von FSE in WordPress im Juni an, wenn WordPress 5.8 ausgeliefert wird.

Dies scheinen hochgesteckte Ziele zu sein, aber Mitglieder der WordPress-Entwicklungs- und Business-Community fragten sich: „Was ist ein MVP für FSE?“ Dies ist keine neue Frage. Ob es nun das rasante Entwicklungstempo ist, eine Panne in der Kommunikation oder dass so viel von dem Projekt hinter vielen Schichten von GitHub-Problemen versteckt ist, es kann schwer sein, zu folgen. Es gibt keine große Webseite, die jeden Schritt bis ins kleinste Detail beschreibt, wohin das Projekt geht. Informationen können sich manchmal verstreut anfühlen. Das kann Drittentwicklern und Geschäftsinhabern, die wissen müssen, was sie erwarten können, um ihre Produkte zu aktualisieren, eine Pause verschaffen.

Joost de Valk, der CPO von Yoast, äußerte in den Kommentaren seine Frustration über diesen Prozess. Wir haben das später noch einmal genauer besprochen.

„Ich denke, FSE wird verändern, was ein Theme ist, und, wenn es richtig ausgeführt wird, wird es viel einfacher, ein Theme zu bauen, da Themes viel kleiner sein werden“, sagte er. „Das bringt die Last auf die Community, sich zuverlässige Methoden für das Styling auszudenken, und Konventionen für Klassennamen oder ähnliches, damit das Styling überall funktioniert. Ich verstehe derzeit nicht, was überhaupt als MVP für Full Site Editing in Betracht gezogen wird, und ich sehe auch keine Diskussionen darüber, wie es mit Themes funktionieren wird, die nicht speziell dafür gebaut wurden, und das macht mir Sorgen.“

Er teilt einige der gleichen Bedenken wie andere in der Community, die das Gefühl haben, dass es keinen Prozess für einen MVP gibt.

„So etwas gibt es nicht“, sagte er. „Eine Vision ohne Ausführung ist nur eine Halluzination.“

Chomphosy sagte, sie sei sich der Zusammenhänge bewusst. „Ich sehe auch, dass die Informationen, die wir veröffentlicht haben, nicht in einem aufgeräumten und nachvollziehbaren Beitrag sind, der den Leuten helfen würde, gute Entscheidungen für 39% des Webs zu treffen“, sagte sie.

Sie zeigte auf ein Ticket, das sechs (jetzt sieben) Meilensteine auflistet. Jeder dieser Meilensteine stellt zusammengenommen dar, wo FSE für ein MVP sein muss.

„Zusammen skizzieren sie eine Architektur, die es erlaubt, ein komplettes Thema mit Hilfe von Blöcken und einem Editor, der dieses Thema anpassen kann, auszudrücken“, schrieb sie. „Das MVP sollte es ermöglichen, eine Version des Twenty Twenty-One-Themes zu erstellen, die nur Blöcke verwendet, ohne jegliche Programmierkenntnisse.“

Es folgt eine Aufschlüsselung der Meilensteine, die erreicht werden müssen, bevor wir die erste Version von FSE in WordPress landen sehen:

Meilenstein 1: Infrastruktur und UI

Der vielleicht wichtigste Teil von FSE ist ein funktionierender Site-Editor. Die Verschmelzung des WordPress-Templating-Systems mit einer kohärenten Benutzeroberfläche ist die Grundlage des Projekts. Die zugrunde liegende Infrastruktur regelt, wie Templates und Template-Teile funktionieren. An diesem Punkt ist dieses Fundament an einer zuverlässigen Stelle. Es sind alle Funktionen, die darauf aufbauen, die mehr Arbeit benötigen. Dieser Meilenstein beinhaltet auch die Einrichtung der Schnittstelle für die Site-Bearbeitung und die Handhabung des Speicherns mehrerer Einheiten.

Die letzte Etappe des Meilensteins ermöglicht es den Benutzern, Vorlagen aus dem Post-Editor heraus zu bearbeiten und so effektiv zwischen der Bearbeitung von Inhalt und Design zu wechseln. Das FSE Outreach Program hat dieses Feature kürzlich getestet, um Feedback nach Gutenberg 9.6 zu sammeln.

Meilenstein 2: Browsing

Dieser Meilenstein umfasst die gesamte Arbeit für die Navigation auf der UI des Site-Editors. Es gibt viele bewegliche Teile, wie das Wechseln zwischen Seiten, Vorlagen, Vorlagenteilen, globalen Stilen und mehr. Die Benutzer müssen wissen, an welchem Element sie gerade arbeiten.

Dies ist der einzige Meilenstein, der als abgeschlossen markiert ist. Es gibt jedoch ein offenes Ticket für die Erforschung der Idee eines „Browsing“-Modus neben dem Bearbeitungs- und Auswahlmodus.

Meilenstein 3: Styling

Dieser Meilenstein konzentriert sich größtenteils auf das kommende Global Styles System. Das System erstellt eine Hierarchie, wie Stile auf Blöcke angewandt werden, von den Standardeinstellungen des Themas über globale Änderungen durch den Benutzer bis hin zu den Stiloptionen pro Block.

Während ein Großteil der Arbeit für ein MVP abgeschlossen ist, gibt es Dutzende von Feature-Tickets im Backlog. Dies ist auch ein Bereich, in dem das Blocksystem Jahre hinter den Page Buildern von Drittanbietern liegt. Erwarten Sie langfristige Funktionserweiterungen basierend auf dem Feedback nach dem Launch.

Meilenstein 4: Theme-Blöcke

Theme-Autoren sollten dieses Ticket genau im Auge behalten. Die einzige Möglichkeit, dass blockbasierte Themes für die meisten Theme-Entwickler Realität werden, ist, wenn alle Template-Tags einen entsprechenden Block im Site-Editor haben. Oder zumindest, wenn die meistgenutzten Template-Tags dies tun. Einige dieser Funktionen sind im Block-Editor nicht mehr anwendbar. Theme-Entwickler sollten sicherstellen, dass sie die Blöcke haben, die sie benötigen, um alles, was sie heute bauen, neu zu erstellen.

Zugegebenermaßen bin ich traurig darüber, dass die Blöcke für Bookmarks/Links wahrscheinlich nicht weiterentwickelt werden. Obwohl die Funktion veraltet ist, bin ich immer noch nostalgisch über die guten alten Blogroll-Tage. Vielleicht wäre es besser, dies als Plugin zu belassen. Eine Wiederbelebung des Link-Manager-Plugins könnte in Ordnung sein.

Meilenstein 5: Query-Block

Der Abfrage-Block und der zugehörige Schleifen-Block sind in gewisser Weise die wichtigsten Teile des Full Site Editing. Sie regeln, welche Beiträge geladen werden und wie sie angezeigt werden. Das Feature ist eines der komplexeren Puzzles, die zu lösen sind. Das Gutenberg-Entwicklungsteam hat monatelang daran gearbeitet, und es ist jetzt auf einer guten Basislinie. Es ist jedoch noch ein weiter Weg, bis es ernsthaft alle Dinge handhaben kann, die Theme-Autoren damit machen müssen.

Im Moment bietet der Query-Block nur eine Handvoll Optionen zum Anpassen der Abfrage. Das Team muss festlegen, welche Steuerelemente in der Seitenleiste für Endbenutzer verfügbar sein sollen und die Blöcke mit Mustern für verschiedene Arten von Post-List-Anzeigen integrieren.

Meilenstein 6: Navigationsblock

Abgesehen vom Abfrage-Block ist die Navigation der einzige andere Block, der einen eigenen Meilenstein benötigt. Probleme mit Navigationsmenüs plagen das WordPress-Projekt schon seit weit über einem Jahrzehnt. Es ist eines der schwierigsten Dinge, die man richtig hinbekommt. Während Navigationsmenüs in WordPress heute im Allgemeinen einfach zu handhaben sind, ist ihr Design vom Endbenutzer nicht anpassbar. Die Ausgabe liegt ganz im Ermessen des Theme-Autors. Die Vielfalt der möglichen Menüdesigns, die Theme-Autoren wünschen, zu berücksichtigen und sie für den Endbenutzer anpassbar zu machen, ist wahrscheinlich eines der schwierigsten Probleme für das Gutenberg-Projekt.

Es gibt mindestens ein paar Dutzend Untermenüs, die von den Autoren mitgestaltet werden müssen. Selbst dann könnte es noch mehrere Versionen dauern, bis der Navigationsblock für die komplexeren Muster, die heute in einigen Themes verwendet werden, bereit ist.

Meilenstein 7: Schrittweise Einführung

Nachdem die ersten sechs Meilensteine, die den MVP repräsentieren, abgeschlossen sind, braucht WordPress einen Weg, der es Endbenutzern und Theme-Autoren ermöglicht, FSE schrittweise zu übernehmen. In erster Linie wäre dies eine Mischung aus blockbasierten Templates und traditionellen PHP-basierten Templates. Entwicklern sollte es erlaubt sein, ihre Themes zu aktualisieren, ohne sie komplett zu ändern und damit möglicherweise Teile ihrer Benutzerbasis zurückzulassen.

Blockbasierte Widgets und Navigationsbildschirme fallen ebenfalls unter diesen Meilenstein. Beide Features wurden auf zukünftige Versionen verschoben, nachdem sie nicht in 2020 landen konnten. Sie werden jedoch Sprungbretter für Benutzer sein, die noch nicht ganz bereit sind, auf FSE umzusteigen oder dies aufgrund ihres Themes nicht können.

 

Automatisierung. Es ist einer dieser Träume in den Köpfen vieler Reviewer aus dem Themes-Team. Wenn es ein Tool gäbe, das sich um 90 % der Probleme kümmern würde, könnte sich das Team auf die 10 % konzentrieren, die von automatisierten Skripten nicht so leicht gefunden werden.

So entstand das Projekt Theme Review Action. Steve Dufresne, ein Mitarbeiter des WordPress-Meta-Teams, hat am Montag einen Aufruf zum Testen und Feedback für das neue Projekt veröffentlicht.

„Wenn wir einige der bestehenden Code-Analyse-Tools kombinieren, einen Teil der manuellen Tests automatisieren und sie für weitere Entwicklungs-Workflows öffnen könnten, könnten wir die Qualität von Themes verbessern, den Druck auf manuelle Tests verringern und den Theme-Review-Prozess beschleunigen?“, fragte Dufresne.

Das Projekt betreibt derzeit mehrere Testsuiten, darunter auch das aktuelle Theme Check Plugin. Theme-Autoren können die Texte ausführen, indem sie den NPX-Befehl in ihrem Theme-Ordner ausführen, ihn als Aktion auf GitHub hinzufügen oder ihn klonen und lokal ausführen. Das Ausführen über NPX wird derzeit unter Windows nicht unterstützt.

Im Moment werden Theme-Autoren benötigt. Unabhängig davon, ob Sie Themes für das Verzeichnis, Kunden, Drittanbieter-Marktplätze oder einen Theme-Shop erstellen, ist dies eine Gelegenheit, WordPress etwas zurückzugeben. Es ist auch eine Gelegenheit, die Werkzeuge zu verbessern, von denen Sie als Theme-Entwickler langfristig profitieren können. Automatisierte Theme-Tests helfen dem gesamten Theme-Ökosystem.

„Theme-Autoren müssen dafür offen sein und verstehen, dass es nicht nur um Anforderungen geht“, sagt Carolina Nymark, eine Vertreterin des Themes-Teams. „Es geht darum, die Qualität von Themes zu verbessern.“

Das Projekt wurde zum Teil durch einen Vorschlag des Themes-Teams von Anfang 2020 beeinflusst. Denis Žoljom identifizierte drei Probleme, gegen die das Team ankämpfte:

Die Leute lesen nicht gerne Anforderungen oder Handbücher.

Einige der Probleme, die auftauchen, sind sich wiederholend und könnten automatisch abgefangen werden.

Das Überprüfen von Themen in Trac ist sehr umständlich.

Der Fokus des Vorschlags lag auf der Verlagerung von Reviews nach GitHub, und konzentrierte sich auf den dritten Punkt. Das Theme Review Action Projekt könnte jedoch der Anfang sein, um einen oder mehrere Punkte zu behandeln.

Die offensichtliche Lösung ist, dass das Projekt automatisiert werden kann. Da das Theme Review Action-Projekt jedoch als GitHub-Aktion eingestellt werden kann, lässt es Raum für den GitHub-Review-Vorschlag des Teams.

„Zwei Dinge, die ich Steve gegenüber erwähnt habe – und das sind meine Meinungen -, sind, dass wir Überprüfungen brauchen, die beim Hochladen von Themes und bei Live-Themes laufen, und wir brauchen eine langfristige Lösung“, sagte Nymark. „Es gab schon früher Versuche, das Testen zu automatisieren, die nicht weiterverfolgt wurden, und ohne einen Plan, wie das Tool eingesetzt werden soll, mache ich mir Sorgen, Zeit darauf zu verwenden.“

Das Team hatte gehofft, dass das Theme Sniffer Projekt irgendwann zu mehr Automatisierung führen würde. Es ist schwer, sich Hoffnungen zu machen, nachdem frühere Ziele nicht verwirklicht wurden.

„Auch ich habe eine ähnliche Sorge, dass das Projekt nicht genug Akzeptanz bekommt, um es in die .ORG-Prüfung zu schaffen, und das ist einer der Gründe (neben der Tatsache, dass ich einfach super beschäftigt bin), dass ich nicht in der Lage war, die Prüfung [der Theme Review Action] zu priorisieren“, sagte William Patton vom Themes-Team.

Während das Team und einige Theme-Autoren immer noch den Theme Sniffer benutzen, lässt die Benutzeroberfläche noch viel zu wünschen übrig. Nymark wies darauf hin, dass es für Theme-Autoren schwer sei, zwischen den Basisanforderungen und den Empfehlungen zu unterscheiden.

„Meldungen von automatisierten Werkzeugen anzuzeigen, die nicht unbedingt Anforderungen sind, ist sehr schwer richtig zu machen“, sagte sie. „Wenn zum Beispiel ein Tool anfangen würde, CSS-Linting-Fehler für die WordPress-CSS-Codierungsstandards zu melden, würden viele Leute das zu rechthaberisch und einschränkend finden.“

Theme-Autoren, die Gruppe, die am meisten von den finanziellen Vorteilen und dem guten Ruf des Theme-Verzeichnisses profitiert, haben oft gezögert, sich zu beteiligen. Nur wenige Unternehmen erübrigen einen Mitarbeiter, um Reviews durchzuführen oder an Tools zu arbeiten, die Entwickler und das Team benötigen. Aufrufe zu Tests, Feedback und Diskussionen bleiben oft unbeantwortet, so dass einige wenige den Löwenanteil der Arbeit erledigen. Damit dieses Projekt erfolgreich wird und sich nicht wie etwas anfühlt, das ihnen aufgedrängt wurde, müssen die Theme-Entwickler mit einbezogen werden.

In der ersten Folge des WP Briefing-Podcasts sprach WordPress Executive Director Josepha Haden Chomphosy über die Fokussierung auf Automatisierung als eines der Ziele dieses Jahres. Wenn es ein Team gibt, das solche Tools gebrauchen könnte, dann wäre es das Themes-Team.

Newspack, ein von der Google News Initiative und WordPress.com finanziertes Projekt, hat einen Showcase mit 60 Nachrichtenseiten veröffentlicht, die auf der Plattform laufen. WordPress.com kündigte seine Pläne zum Aufbau des Newspack CMS vor zwei Jahren an und konnte bereits im ersten Jahr mehr als 50 Sites erfolgreich unter Vertrag nehmen. Die Cloud-basierte Plattform ist Open Source und hochgradig angepasst, um Einnahmen für kleine bis mittelgroße Publikationen zu generieren.

Zu den frühen Anwendern gehören die Austin Weekly News, Mississippi Today, Hong Kong Free Press, Oklahoma Watch, Bangor Daily News, The Oaklandside und viele andere Watchdog-Publikationen, die ihre Gemeinden mit wichtigen lokalen Nachrichten versorgen.

Der Showcase wurde mit dem Raindrop-Lesezeichen-Manager erstellt, der es dem Betrachter ermöglicht, nach einer bestimmten Seite zu suchen und alle verschiedenen Homepages auf einen Blick zu sehen. Die Vielfalt der Publikationen ist beeindruckend, aber wenn man sich zu ihren Websites durchklickt, wird klar, dass die meisten von ihnen eine enge Verbindung zu ihren Gemeinden haben, die sonst in der Post-Print-Nachrichten-Ära vielleicht verloren gegangen wäre.

Newspack zeichnet sich als erschwingliche, quelloffene Alternative zu proprietären Systemen aus. Verlage zahlen in der Regel $500-$2.000/Monat, wobei eine gleitende Skala auf der Grundlage ihres Jahresumsatzes gilt. Die Werkzeuge, die sie erhalten, sind offen und darauf ausgelegt, wirtschaftlich nachhaltigen Journalismus zu schaffen. Es ist nicht überraschend, dass sich um das Produkt eine Community gebildet hat, da kleine Verlage viele der gleichen Probleme haben. Ein spezieller Slack-Arbeitsbereich. erleichtert die Konversation und Zusammenarbeit von mehr als 150 Redakteuren, Designern, Produkt- und Geschäftsleuten, die alle die gleichen Bausteine verwenden, um ihre Publikationen zu betreiben.

Im Jahr 2020 erhielten dreizehn Newspack-Publikationen insgesamt mehr als 1 Million US-Dollar an Zuschüssen aus dem Facebook Journalism Program für lokale Nachrichten aufgrund von Covid-19. Das kostengünstige Online-Publizieren auf WordPress hat vielen dieser Publikationen geholfen, die Pandemie zu überstehen, anstatt zur Konsolidierung oder Schließung gezwungen zu sein.

Im Mai 2020 veröffentlichten die Analysten von News Revenue Hub eine Studie, in der sie untersuchten, wie die von Newspack betriebenen Redaktionen mit WordPress interagieren. Einige wichtige Ergebnisse zeigten, dass Newspack-Benutzer möglicherweise mehr Unterstützung bei der Verwaltung ihrer Websites benötigen, die den Block-Editor nutzen und mit mehr als 50 vorkonfigurierten Plugins geliefert werden:

Die Rolle von Newspack bei der Reduzierung oder dem Ersatz des Bedarfs an technischen Ressourcen für die Verwaltung von Websites ist unklar und hängt stark von den technischen Kenntnissen und Ressourcen der einzelnen Redaktionen ab.

Mögliche Verbesserungen in der Zukunft sollten sich darauf konzentrieren, tiefergehende, standardisierte Schulungen und Dokumentationen für breite Benutzergruppen anzubieten.

Der Bericht kommt zu dem Schluss, dass „Newspack sich als wertvolles Werkzeug für Redaktionen etabliert hat und eine wertvolle Methode für die gemeinschaftliche Erstellung von Websites darstellt“, warnt aber davor, dass das Projekt bei der Skalierung der praktischen Unterstützung, die die Pilotredaktionen in der Anfangsphase erhielten, vor Herausforderungen stehen könnte. Weitere umsatzfördernde Funktionen werden noch entwickelt, aber insgesamt waren die teilnehmenden Redaktionen sehr zufrieden mit der Plattform.