NextPress

NextPress er et CMS-prosjekt der jeg gjenskaper den kjente WordPress-administrasjonen med Next.js og TypeScript. CMS betyr innholdsstyringssystem: verktøyet redaktøren bruker til å skrive, organisere og publisere innhold.

Utgangspunktet er et spørsmål: Kan redaktøren beholde en gjenkjennelig arbeidsflyt, samtidig som utvikleren får en annen teknisk plattform å bygge videre på? Prosjektet utforsker et alternativ til WordPress gjennom konkrete publiseringsoppgaver, fra innlogging til redigering og håndtering av bilder.

Utfordringen: kjent redigering på en annen plattform

Et administrasjonsverktøy består av mange små forventninger. Brukeren skal finne listen over innlegg, åpne riktig tekst, legge inn et bilde og forstå hva som skjer når noe lagres eller publiseres. Å flytte funksjonene til en annen teknologi gjør ikke disse forventningene mindre viktige.

Jeg tok derfor utgangspunkt i navn, adresser og arbeidsmåter fra en vanlig WordPress-installasjon. Målet var å arbeide med selve publiseringsopplevelsen, ikke bare å lage en forside som ligner.

Samtidig er NextPress en egen applikasjon. Den kjører ikke PHP-koden til WordPress, og WordPress-temaer og PHP-plugins kan ikke installeres og forventes å fungere. Det er en viktig avgrensning av prosjektet: det kjente grensesnittet må ha sin egen implementasjon av innhold, innlogging og regler.

Løsningen: NextPress som et gjenkjennelig CMS

Innlogging og administrasjon

Innloggingen og administrasjonsområdet følger kjente navn og ruter. Etter innlogging møter brukeren en administrasjon der innlegg, sider og medier har hver sin plass.

Dette er mer enn et visuelt valg. Plasseringen og navngivingen hjelper med å definere hva hver skjerm skal gjøre. En listevisning skal gi oversikt, mens redigeringen skal gi rom for å arbeide med ett innholdselement.

Lister og innholdsarbeid

Innlegg og sider har egne listevisninger med søk, filtrering, sortering og sideinndeling. Arbeidsflyten omfatter også utkast, publisert innhold og håndtering av papirkurven.

Det gir en konkret ramme for å arbeide med vanlige redaktøroppgaver:

• finne et innlegg uten å åpne hvert element;
• skille innhold som er publisert fra det som fortsatt bearbeides;
• gjøre enkle endringer fra en oversikt;
• flytte innhold til papirkurven og hente det tilbake.

Hver slik oppgave trenger både et forståelig grensesnitt og en regel på serversiden. At noe ser ut som et utkast i listen, må stemme med hvordan innholdet behandles når en side åpnes.

Blokkredigering med Gutenberg

Jeg bruker Gutenberg til redigeringen. Det gir en arbeidsmåte med blokker for tekst, overskrifter og bilder, innenfor en egen applikasjon bygget i TypeScript.

Redigering handler også om å ta vare på arbeidet. NextPress har implementert automatisk lagring, gjenoppretting etter at redigeringen åpnes igjen, forhåndsvisning og revisjonshistorikk. Planlagt publisering er også en del av den dokumenterte funksjonaliteten.

Slike funksjoner gjør tilstandsmodellen viktig. Et lagret utkast, en forhåndsvisning og en publisert side er forskjellige ting. Jeg må ta stilling til hvilken versjon som vises, hvem som kan se den, og hvilke endringer som blir offentlige.

Mediebibliotek og bilder

Mediebiblioteket håndterer bilder som kan lastes opp, få redigerte opplysninger og brukes i innholdet. Det omfatter også bilder i blokkredigeringen og valg av fremhevet bilde.

En bildefil og opplysningene om den må henge sammen. Redaktøren trenger å finne bildet igjen og forstå hvor det kan brukes. For utvikleren betyr det at opplasting, lagring og referanser fra innholdet må behandles som deler av samme arbeidsflyt.

Under panseret

NextPress er bygget med Next.js, React og TypeScript, med egne innholdsmodeller og SQLite som den første lagringsløsningen. Oppsettet krever en vedvarende Node.js-vert og lagring som består mellom omstarter.

Det sentrale utviklingsarbeidet er å knytte redaktøroppgavene til klare regler:

• Innlogging og roller: hvilke handlinger en bruker skal få utføre.
• Innholdstilstand: hva som er utkast, forhåndsvisning, planlagt eller publisert.
• Endringer over tid: hvordan automatisk lagring og revisjoner forholder seg til det offentlige innholdet.
• Medier: hvordan filer og innholdsreferanser lagres og tas vare på.

Jeg kan dermed arbeide med et kjent publiseringsmønster uten å basere den nye applikasjonen på PHP-utvidelser. Funksjoner som skal finnes i NextPress, må utvikles og vedlikeholdes for denne plattformen.

Det er også grunnen til at prosjektet har et avklart teknisk bruksområde. En løsning med lokal SQLite-lagring må ha et oppsett som passer det. Den kan ikke behandles som om alle deler er uavhengige av hvor og hvordan applikasjonen kjører.

Resultat og prosjektstatus

Prosjektet har en fungerende grunnmur for innlogging, administrasjon, innholdsredigering og bildehåndtering. De implementerte publiseringsflytene gir et konkret grunnlag for å arbeide videre med et eget CMS.

Samtidig er NextPress under utvikling. Ikke alle skjermer i referansen er gjenskapt, og full visuell likhet er ikke dokumentert. Det er heller ikke et system for å overta en vilkårlig WordPress-installasjon og kjøre de eksisterende temaene og utvidelsene uendret.

For meg ligger verdien i å forstå sammenhengen mellom redigering, innholdsmodell og publisering. En knapp for å lagre er enkel å tegne. Det mer omfattende arbeidet er å sikre at lagringen betyr riktig ting for utkastet, den publiserte versjonen og brukerens videre arbeid.

Relevant for dere hvis …

Dere trenger et publiseringsverktøy som passer dem som skal bruke det, eller en utvikler som kan arbeide med både redigeringen og funksjonene bak den. Prosjektet viser hvordan jeg undersøker kjente arbeidsflyter og bygger dem på en egen teknisk plattform.

For en vanlig bedriftsnettside kan WordPress være det riktige valget. På siden om WordPress-utvikling beskriver jeg arbeidet med temaer, blokker og integrasjoner. Ta kontakt om publiseringsbehovet deres, så vurderes løsningen ut fra oppgaven og hvem som skal ta den over.