📋 Komplett WordPress-jukselapp
Åpnet functions.php og glemte hvordan du kobler opp sidepanelet? Det skjer alle som håndkoder et WordPress-tema. Du trenger én side for hånden, ikke ti faner på developer.wordpress.org.
Her finner du det viktigste innen WordPress-utvikling: 13 malfiler og hierarkiet for å velge dem, den grunnleggende loopen, inkluderingskoder og bloginfo()-parametere, deretter kroker og filtre, betingede koder, innkøing av skript, kortkoder, WP_Query, dataescaping, REST API og WP-CLI-kommandoer. Alle kodeeksempler fungerer. Hold denne fanen åpen under utvikling og sjekk etter hvert som du jobber.
💡 Rask oversikt:
- Bokmerk denne siden og hold den åpen i en egen fane mens du bygger temaet ditt.
- Start med «Anatomi av et tema»-delen: opprett temafilene fra listen før du skriver kode.
- Kopier den grunnleggende WordPress-loopen inn i
index.phpog pakk den inn med inkluderingskoder for topptekst, sidepanel og bunntekst. - Slipp
bloginfo()- ogget_bloginfo()-koder fra tabellen rett inn i maler, og kryssjekk mot «Hva den viser»-kolonnen. - Før publisering, gå gjennom
style.css-reglene: valider CSS, minifiser og legg til utskriftsstiler. - Lenger ned på siden finner du referansen: malhierarki, kroker og filtre, betingede koder, innkøing av skript, kortkoder,
WP_Query, escaping, REST API og WP-CLI.
Anatomi av et WordPress-tema
Et WordPress-tema er et sett med PHP-filer forent av felles logikk og styrt av malhierarkiet. Nøkkelkomponenten: style.css, som håndterer visuell styling og samtidig fungerer som temaets identifikator i administrasjonspanelet. Men grunnlaget for ethvert klassisk tema er PHP-maler: hver håndterer sin egen del av siden og kalles i den rekkefølgen WordPress-hierarkiet bestemmer.
For å lage et standardtema trenger du følgende filer, tretten av dem, som hver dekker en bestemt sone på nettstedet:
- header.php,
<head>-delen og toppen av siden: metadata, nettstedstittel, inkludering avstyle.css, åpning av<body>-taggen. - index.php, hovedmalen, inngangspunktet. Setter sammen andre filer til en enhetlig side via inkluderingskoder. Hvis en spesialisert mal ikke finnes, faller WordPress tilbake til
index.php. - sidebar.php, sidepanelet: widgeter, kategorier, søk, sekundærmeny.
- footer.php, bunnteksten: opphavsrett, sosiale lenker, analyseskript, avsluttende
</body></html>-tagger. - page.php, mal for sider (statisk innhold, «Om oss», «Kontakt»).
- single.php, mal for et enkelt blogginnlegg.
- comments.php, kommentarfelt og innsendingsskjema.
- 404.php, 404-feilside. Hvis denne filen mangler, viser WordPress en standard systemmelding, noe som er dårligere for den besøkende.
- search.php, mal for søkeresultater.
- searchform.php, søkeskjema (i klassiske temaer; moderne bruker ofte en widget).
- archive.php, mal for arkiver: kategorier, stikkord, datoarkiver.
- functions.php, det funksjonelle hjertet i temaet: egendefinerte kroker, innkøing av skript og stiler, menyregistrering, widgetområder, egendefinerte innholdstyper. Alt som legger til temafunksjonalitet bor her.
- style.css, den eneste ikke-PHP-filen på listen, men uten den eksisterer ikke temaet: den lagrer temahodet og definerer nettstedets utseende.
Du kan klare deg med færre maler, for eksempel utgjør index.php + style.css allerede et minimalt tema. Men for et fullverdig nettsted er det bedre å beholde alle tretten: hver fil er skreddersydd for sin egen oppgave, og WordPress velger selv den rette etter hierarkiet. En typisk index.php ser slik ut:
1 <?php get_header(); ?> 2 3 <!-- Main content, including the Loop --> 4 5 <?php get_sidebar(); ?> 6 <?php get_footer(); ?>
Så går vi videre til det viktigste kodefragmentet, som ingenting vises uten.
WordPress-loopen
Loopen er den sentrale mekanismen for å vise innhold. Uten den måtte du manuelt ha kodet visningen av hvert innlegg og hver side i temamalen. Loopen gjør akkurat det navnet lover: den går gjennom alle innlegg som samsvarer med gjeldende spørring og bruker din spesifiserte HTML/PHP-markering på hvert enkelt.
Grunnleggende loop-syntaks:
1 <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?> 2 <!-- HTML markup and template tags for each post --> 3 <?php endwhile; endif; ?>
have_posts() sjekker om det er innlegg å vise. Hvis det er det, initialiserer the_post() WordPress sin interne peker til gjeldende innlegg, hvoretter dusinvis av malkoder blir tilgjengelige inne i loopen: the_title() for tittelen, the_content() for innleggstekst, the_permalink() for lenken, the_excerpt() for utdraget og mange andre.
Loopen plasseres vanligvis i index.php for å vise en liste over innlegg, men ingenting hindrer deg i å bruke den i single.php, page.php eller archive.php, logikken er den samme, bare konteksten er forskjellig. Inne i loopen legger du til eventuelle HTML-omslag og PHP-koder, WordPress vil bruke dem på hvert innlegg etter tur.
Praktisk eksempel, visning av tittel og dato for hvert innlegg:
1 <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?> 2 <article> 3 <h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2> 4 <time><?php echo get_the_date(); ?></time> 5 </article> 6 <?php endwhile; endif; ?>
Nå om hvordan loopen samhandler med resten av temaet, via inkluderingskoder.
Inkluderingskoder for maler
Inkluderingskoder er PHP-funksjoner som laster innholdet fra én temafil inn i en annen. De danner skjelettet til en typisk index.php: topptekst, innhold, sidepanel, bunntekst. Fire grunnleggende funksjoner:
<?php get_header(); ?>, inkludererheader.php. Vanligvis den første linjen iindex.phpog enhver annen mal som trenger en topptekst.<?php get_sidebar(); ?>, inkluderersidebar.php. Hvis sidepanelet ikke trengs, fjern kallet.<?php get_footer(); ?>, inkludererfooter.php. Alltid på slutten av malen, avslutter siden.<?php comments_template(); ?>, inkluderercomments.php. Plasseres inne isingle.php, etter visning av innleggsinnhold.
Alle fire funksjonene leter etter filer i mappen for det aktive temaet. Hvis filen ikke finnes, viser WordPress rett og slett ingenting (unntatt get_header() og get_footer(), deres fravær vil ødelegge layouten).
Neste nivå, koder som ikke bare inkluderer filer, men henter data fra databasen.
Bloginfo-koder
bloginfo()-kodene henter informasjon om nettstedet fra WordPress-databasen, den samme informasjonen du fyller inn under Innstillinger → Generelt og i brukerprofilen. Funksjonen returnerer en streng og viser den umiddelbart på skjermen. De mest brukte parameterne:
Parameter | Hva den viser |
|---|---|
| Nettstedstittel |
| Nettadresse |
| Slagord (nettstedsbeskrivelse) |
| Tegnsett (standard UTF-8) |
| Nettadresse til aktivt temas |
| Installert WordPress-versjon |
| Nettstedets språk |
| RSS-feedadresse (RSS 0.92) |
| RSS-feedadresse (RSS 2.0) |
Dette er bare toppen av isfjellet, den fullstendige listen over parametere finnes i WordPress-dokumentasjonen.
Get_bloginfo(), når du trenger å lagre i stedet for å vise
For tilfeller der nettstedsinformasjon må brukes i kode i stedet for bare å vises på siden, bruk funksjonen get_bloginfo():
1 <?php $info = get_bloginfo( $show, $filter ); ?>
$show, nøkkelordet. Støttede verdier er'name'(tittel),'url'(adresse),'description'(slagord),'admin_email'(administrator-e-post) og andre; fullstendig liste i dokumentasjonen.$filter, filtreringsmodus:'raw'(verdi «som den er», standard) eller'display'(verdien sendes gjennomwptexturize(), konverterer anførselstegn, tankestreker, tegn).
Eksempel: hent nettstedsbeskrivelsen og vis den med et prefiks:
1 <?php $site_description = get_bloginfo( 'description' ); ?> 2 <?php echo 'Your site tagline: ' . esc_html( $site_description ); ?>
Resultat: «Din side-tagline: Beste premium WordPress-temaer».
I tillegg til bloginfo har WordPress et omfattende system av mal-tagger: generelle tagger, forfattertagger, miniatyrbildetagger, kategoritagger, lenketagger, alle fungerer både innenfor og utenfor loopen, og kombinasjoner gir full kontroll over innholdsutdata.
Tema-stilark
style.css har to roller. For det første identifikasjon: toppteksten helt øverst i filen forteller WordPress temanavn, forfatter, versjon og lisens. For det andre det visuelle: alle CSS-regler som styrer nettstedets utseende. En standard topptekst ser slik ut:
1 /* 2 Theme Name: Theme Name 3 Theme URI: https://www.example.com/theme 4 Author: Your Name 5 Author URI: https://www.example.com/ 6 Description: Responsive WordPress theme with support for... 7 Version: 1.0 8 License: GNU General Public License v2 or later 9 License URI: http://www.gnu.org/licenses/gpl-2.0.html 10 Tags: responsive, two-columns, right-sidebar, custom-header 11 Text Domain: mythemename 12 */
Beste praksis når du jobber med style.css:
- Følg WordPress’ CSS-kodestandarder, konsekvent stil forenkler vedlikehold.
- Valider CSS gjennom W3C-validatoren.
- Minifiser CSS i produksjon, men behold en lesbar kilde for utvikling.
- Legg til utskriftsstiler (
@media print), mange lesere skriver ut artikler. - Stil alle standard HTML-elementer som kan dukke opp i innleggsinnhold.
WordPress’ malhierarki
For hver forespørsel avgjør WordPress selv hvilken PHP-fil fra temaet som skal inkluderes, dette er malhierarkiet. Én regel: fra den mest spesifikke filen til den mest generelle, med index.php som siste tilbakefall for enhver gren. Å kjenne rekkefølgen fjerner spørsmålet «hvorfor vises ikke endringen min i single.php på kategorisiden».
1 Single post → single-{post_type}-{slug}.php → single-{post_type}.php → single.php → singular.php → index.php 2 Page → {template from editor}.php → page-{slug}.php → page-{id}.php → page.php → singular.php → index.php 3 Category → category-{slug}.php → category-{id}.php → category.php → archive.php → index.php 4 Archive → archive-{post_type}.php → archive.php → index.php 5 Search → search.php → index.php 6 404 error → 404.php → index.php 7 Front page → front-page.php → home.php → index.php
WordPress tar den første eksisterende filen fra venstre mot høyre. Så single-product.php vil overstyre single.php bare for innlegg av innleggstypen product, og lar resten være urørt.
Hooks: actions og filters
Hooks er WordPress’ utvidelsespunkter: de lar deg koble deg på kjernefunksjonalitet uten å redigere filene dens. Actions utfører en sideeffekt (legg til et skript, send en e-post), filters mottar en verdi, endrer den og må returnere den tilbake. En glemt return i et filter er den vanligste årsaken til tomt innhold.
1 // Registration 2 add_action( 'hook_name', 'callback', 10, 1 ); // priority, number of arguments 3 add_filter( 'hook_name', 'callback', 10, 1 ); 4 5 // Execution (in core or your code) 6 do_action( 'hook_name', $arg ); // action: returns nothing 7 apply_filters( 'hook_name', $value, $arg ); // filter: RETURNS value 8 9 // Removal (priority must match the one used when adding) 10 remove_action( 'hook_name', 'callback', 10 );
Eksempel, legg til et avsnitt på slutten av hvert innlegg:
1 add_filter( 'the_content', 'my_append_note', 20 ); 2 function my_append_note( $content ) { 3 return $content . '<p>Thanks for reading!</p>'; // without return content disappears 4 }
Sentrale temahooks:
after_setup_theme, registrer funksjonsstøtte (add_theme_support()), menyer, miniatyrstørrelser.wp_enqueue_scripts, det eneste riktige stedet å laste inn frontend-CSS og -JS.init, tidlig initialisering: registrer innleggstyper og shortcodes.the_content, filtrer innleggs-HTML før utdata.
Lavere prioritet kjører tidligere (standard 10). For at en callback skal motta mer enn ett argument, øk den fjerde parameteren accepted_args.
Betingelsestagger
Betingelsestagger er funksjoner som returnerer true eller false avhengig av hvilken side som er åpen. De bygger logikken for «vis sidefelt her, men ikke på 404».
1 is_home() // blog post feed 2 is_front_page() // site front page 3 is_single() // single post 4 is_page() // single page 5 is_singular() // any single post/page/CPT 6 is_archive() // any archive 7 is_category() // category archive 8 is_search() // search results page 9 is_404() // 404 error page 10 is_user_logged_in() // user is logged in 11 is_admin() // request is in admin (NOT "user is administrator")
Hovedfellen: spørringsrelaterte betingelsestagger (is_single, is_page, is_home og andre) fungerer bare etter at hovedspørringen er dannet, det vil si inne i malfiler og loopen eller fra og med template_redirect-hooken. Å kalle dem tidlig i functions.php eller på init er for tidlig: WordPress vil utstede _doing_it_wrong() og returnere et feil resultat. Unntak er is_admin() og is_user_logged_in(), de avhenger ikke av spørringen og er tilgjengelige tidligere. Og husk: is_admin() sjekker kontekst (admin mot frontend), ikke rolle; for rolle bruk current_user_can( 'manage_options' ).
Innlasting av skript og stiler
Fristelsen til å skrive <link> og <script> direkte i header.php er sterk, men det er en feil: du mister avhengighetshåndtering, versjonering for cache-busting, strategier for defer/async og beskyttelse mot dobbel lasting (to utvidelser kan enkelt laste jQuery to ganger). Riktig vei er WordPress-køen på wp_enqueue_scripts-hooken.
1 add_action( 'wp_enqueue_scripts', 'my_theme_assets' ); 2 function my_theme_assets() { 3 // Theme style with version from style.css header 4 wp_enqueue_style( 5 'my-theme', 6 get_stylesheet_uri(), 7 array(), 8 wp_get_theme()->get( 'Version' ) 9 ); 10 11 // Script with dependency and modern syntax (WP 6.3+) 12 wp_enqueue_script( 13 'my-app', 14 get_theme_file_uri( 'assets/js/app.js' ), 15 array( 'jquery' ), // dependencies 16 '1.0.0', // version → cache busting 17 array( 18 'in_footer' => true, 19 'strategy' => 'defer', 20 ) 21 ); 22 }
Fra og med WordPress 6.3 er den siste parameteren til wp_enqueue_script() en $args-tabell (in_footer, strategy), selv om den gamle formen med boolsk true for footer fortsatt fungerer. For frontend bruk wp_enqueue_scripts, for admin bruk admin_enqueue_scripts, for innloggingssiden bruk login_enqueue_scripts.
Shortcodes
Shortcodes gjør en kort oppføring i hakeparenteser om til vilkårlig HTML, praktisk for knapper, gallerier og skjemaer inne i innhold. Behandleren må returnere en streng, ikke skrive den ut via echo, ellers vil resultatet «hoppe ut» til begynnelsen av siden.
1 add_shortcode( 'btn', 'my_button_shortcode' ); 2 function my_button_shortcode( $atts, $content = null, $tag = '' ) { 3 $a = shortcode_atts( 4 array( 'url' => '#', 'label' => 'Button' ), 5 $atts, 6 $tag 7 ); 8 return sprintf( 9 '<a class="btn" href="%s">%s</a>', 10 esc_url( $a['url'] ), // escape on output 11 esc_html( $a['label'] ) 12 ); 13 } 14 // Usage in post: [btn url="https://example.com" label="Buy"]
shortcode_atts() legger brukerattributter oppå standardverdier. Hvis du trenger å kjøre shortcodes inne i en streng eller mal, pakk den inn i do_shortcode(), men for å kalle din egen funksjon, kall den direkte, uten mellomleddet.
WP_Query og egendefinerte spørringer
WP_Query er klassen for alle innleggsutvalg: siste nytt i sidefeltet, kategorisamling, feed for egendefinert innleggstype. Etter loopen din, kall alltid wp_reset_postdata(), ellers vil malkoder lenger ned på siden få feil innlegg.
1 $q = new WP_Query( array( 2 'post_type' => 'post', 3 'posts_per_page' => 5, 4 'category_name' => 'news', 5 'orderby' => 'date', 6 'order' => 'DESC', 7 ) ); 8 9 if ( $q->have_posts() ) { 10 while ( $q->have_posts() ) { 11 $q->the_post(); 12 the_title( '<h3>', '</h3>' ); 13 } 14 wp_reset_postdata(); // restore global $post 15 }
For å endre hovedsidespørringen (for eksempel antall innlegg på forsiden), ikke bruk den utdaterte query_posts(), den kjører en ekstra databasespørring og ødelegger paginering. Riktig tilnærming er pre_get_posts-hooken, som endrer spørringen før den kjøres:
1 add_action( 'pre_get_posts', 'my_main_query' ); 2 function my_main_query( $query ) { 3 if ( ! is_admin() && $query->is_main_query() && $query->is_home() ) { 4 $query->set( 'posts_per_page', 12 ); 5 } 6 }
Sikkerhet: escaping og sanitisering
Den gyldne WordPress-regelen: sanitér på input, escape på output, valider overalt. All brukerdata renses før lagring i databasen og escapes før output i HTML, selv om den allerede er renset.
1 // Escaping ON OUTPUT 2 echo esc_html( $text ); // text inside tag 3 echo esc_attr( $value ); // attribute value 4 echo esc_url( $href ); // href/src links 5 echo wp_kses_post( $rich_html ); // safe HTML set for content 6 7 // Sanitization ON INPUT (before writing to DB) 8 $clean = sanitize_text_field( $_POST['name'] ); 9 $email = sanitize_email( $_POST['email'] ); 10 $num = absint( $_POST['count'] );
Beskytt skjemaer og handlinger med nonces, engangstokens mot CSRF:
1 // In form: 2 wp_nonce_field( 'my_save_action', 'my_nonce' ); 3 4 // During processing: 5 if ( ! isset( $_POST['my_nonce'] ) || 6 ! wp_verify_nonce( $_POST['my_nonce'], 'my_save_action' ) ) { 7 return; // request rejected 8 }
I praksis er de fleste sårbarheter i temaer og utvidelser nettopp manglende output-escaping. Gjør det til en vane: ikke en eneste variabel går inn i HTML uten esc_*.
WordPress REST API
REST API returnerer nettstedsdata i JSON-format, brukt av mobilapper, hodeløse frontender og integrasjoner. Basisadressen er /wp-json/wp/v2/.
1 GET /wp-json/wp/v2/posts // posts 2 GET /wp-json/wp/v2/pages // pages 3 GET /wp-json/wp/v2/media // media files 4 GET /wp-json/wp/v2/users // users 5 GET /wp-json/wp/v2/posts/123 // single post 6 GET /wp-json/wp/v2/posts?per_page=5&search=theme&_embed
Egendefinerte ruter registreres på rest_api_init-hooken. Parameteren permission_callback er påkrevd, uten den vil WordPress gi en advarsel; for offentlig lesing bruk '__return_true'.
1 add_action( 'rest_api_init', function () { 2 register_rest_route( 'myplugin/v1', '/items/(?P<id>\d+)', array( 3 'methods' => 'GET', 4 'callback' => 'my_get_item', 5 'permission_callback' => '__return_true', 6 ) ); 7 } );
WP-CLI: kommandoer for hånden
WP-CLI administrerer nettstedet fra terminalen, raskere og mer pålitelig enn å klikke i admin, spesielt ved vedlikehold av flere nettsteder. Vanligste kommandoer:
1 wp core update # update WordPress core 2 wp core version # what version is installed 3 wp plugin install akismet --activate # install and activate plugin 4 wp plugin list # plugin list with status and version 5 wp theme activate twentytwentyfive # switch active theme 6 wp db export backup.sql # database dump to file 7 wp search-replace 'old.com' 'new.com' --dry-run # always dry run first 8 wp user create bob [email protected] --role=editor # create user 9 wp cache flush # flush object cache
wp search-replace forstår serialiserte data, så den endrer trygt domene ved migrering av et nettsted, i motsetning til en direkte SQL-spørring som ødelegger serialiseringen. Før enhver farlig operasjon, kjør wp db export.
Klassiske temaer og blokktemaer i 2026
I midten av 2026 (gjeldende versjon: WordPress 7.0 «Armstrong», anbefalt PHP 8.3+) er klassiske PHP-temaer fortsatt fullt støttet og forblir den mest utbredte typen. Men all ny kjerneverktøyutvikling skjer for blokktemaer og full nettstedsredigering (Full Site Editing): theme.json i stedet for deler av functions.php-innstillinger, HTML-maler i stedet for PHP. Løkken, bloginfo(), betingede tagger og hooks forblir relevante i hybridtemaer og eventuelle PHP-fragmenter inne i FSE-temaer, så dette juksearket mister ikke verdi. Den praktiske veien i 2026 er et klassisk fundament pluss målrettet blokkstøtte der det faktisk trengs.
⁉️🤔 Ofte stilte spørsmål
Er det obligatorisk å opprette alle 13 filene for et tema?
Nei, det minimale fungerende temaet er
index.php+style.css. Men for et fullverdig nettsted er det bedre å beholde det komplette settet: hver fil gir WordPress muligheten til å velge den optimale malen. For eksempel, utensingle.phpvil et innlegg bli rendret gjennomindex.phpog miste kommentarfeltet.
Hva er forskjellen mellom get_bloginfo() og bloginfo()?
bloginfo() sender verdien direkte til skjermen (echo). get_bloginfo() returnerer en streng til en variabel, du kan behandle den, legge til noe i den eller bruke den inne i et annet uttrykk før faktisk utskrift.
Hvor plasserer jeg loopen hvis siden har flere innholdstyper?
Loopen kan kjøres flere ganger. Typisk scenario: én loop for hovedinnholdslisten, en andre for en «siste nytt»-widget i sidefeltet. Før den andre loopen tilbakestiller du pekeren med wp_reset_postdata(), ellers vil den påfølgende koden på siden få feil innleggskontekst.
Fungerer dette juksearket for blokktemaer (FSE)?
Delvis. Blokktemaer (Full Site Editing) bruker
theme.jsoni stedet forfunctions.phpfor mange innstillinger og maler i HTML i stedet for PHP. Men loopen,bloginfo()og include-tagger forblir relevante for hybridtemaer og eventuelle PHP-maler inne i FSE-temaer.
Hva gjør jeg hvis functions.php blir for stor?
Bryt logikken opp i separate filer og inkluder dem fra
functions.phpviarequire_onceellerinclude. For eksempel:require_once get_template_directory() . '/inc/custom-post-types.php';. Dette forbedrer lesbarheten og forenkler vedlikehold, en beste praksis for ethvert tema med mer enn 20-30 hooks.
Hva er forskjellen mellom en action og et filter?
En action utfører en sideeffekt og returnerer ingenting (last inn et skript, send en e-post). Et filter mottar en verdi, endrer den og må returnere den, en glemt
returni et filter vil nullstille innhold. De registreres identisk:add_action()ogadd_filter().
Hvorfor fungerer ikke is_single() i functions.php?
Betingede spørringstagger er bare tilgjengelige etter at hovedspørringen er dannet, det vil si i malfiler eller fra og med
template_redirect-hooken. I begynnelsen avfunctions.phper spørringen ikke klar ennå, så WordPress vil utstede_doing_it_wrong(). Bareis_admin()ogis_user_logged_in()fungerer uten spørringsavhengighet.
Hva du bør ha for hånden når du utvikler i WordPress
Dette juksearket er rammeverket som WordPress-utvikling starter fra. Temafiler og malhierarki, loopen, include-tagger og bloginfo() setter sammen temaet, mens hooks og filtre, betingede tagger, innlasting av skript, shortcodes, WP_Query, escaping, REST API og WP-CLI dekker det store flertallet av rutineoppgaver. Resten er praksis og dokumentasjon.
For grundigere studier er håndboken for temautvikling på developer.wordpress.org den første adressen. Referansen for maltagger med hundrevis av funksjoner for alle anledninger finnes også der. Hvis du går fra HTML-oppsett til et ferdig tema, start med steg-for-steg-guiden for å lage et WordPress-tema fra HTML, der loopen og tagger forklares i praktisk kontekst, fra oppsett til fungerende tema.
Bokmerk dette juksearket og ha det for hånden under utvikling.
Hvilken tagg eller hook slår du oftest opp? Skriv i kommentarfeltet hvilken WordPress-oppgave du støtte på og del ditt brukstilfelle, levende erfaringsutveksling er verdt et dusin offisielle guider.
Et profesjonelt team av forfattere og redaktører som spesialiserer seg på å lage kvalitetsinnhold.