Å komme til "lanseringsstadiet" av et prosjekt kan føles som en stor lettelse. Du har endelig gjort utviklingsarbeidet ditt, skaper et nettsted i henhold til klientens korte eller dine egne krav, og nå kan du trykke på den metaforiske knappen og starte nettstedet for verden å se.
Men vent.
Før du starter, må du kjøre noen sjekker for å sikre at den er robust og fremtidssikker. Ved å kjøre disse kontrollene før du starter hvert nytt nettsted, kan du unngå å løse problemer senere. Spesielt kan du unngå hodepine, forlegenhet og skade på omdømmet ditt forårsaket av at klienter eller brukere oppdager problemer når nettstedet har gått live.
I denne artikkelen deler jeg sjekklisten jeg bruker før du overfører et nettsted for å leve. Jeg hevder ikke at dette er den hellige grillen av lister - du vil ha noen ting du ikke gjør, at du gjør annerledes, eller at du gjør i tillegg til dette.
Det er verdt å merke seg at førstartskontroller ikke bare er relevante umiddelbart før du starter et nettsted - avhengig av prosjektets kompleksitet, må du jobbe mange av disse innom du går. Dette vil spare deg tid og omarbeide når nettstedet er klar til å gå, og vil hjelpe deg med avlogging og troverdighet i etapper gjennom hele utviklingen der klienten vurderer arbeid på nettstedet.
Men etter å ha sagt det, synes jeg det er verdt å gi den listen en endelig gjennomføring før lanseringen, bare for å være sikker.
Min liste er delt inn i fire kategorier:
Prosjekt eller kortspesifikke kontroller
Robusthet
Future isolasjons
Endelige handlinger
Nedenfor beskriver jeg hva hver av disse handler om, og gir en liste over elementer for hver kategori.
1. Prosjekt eller kortspesifikke kontroller
Å sørge for at nettstedet oppfyller avtalt kort er noe du bør gjøre hele tiden, men det er verdt å kjøre en endelig sjekk før lanseringen.
Denne sjekklisten vil være forskjellig for hvert prosjekt, så jeg kan egentlig ikke gi deg en standardliste, men det er noen nøkkelindikatorer du kan bruke. Du bør løpe gjennom denne listen før du overfører nettstedet til live-serveren:
Sjekk kort. Hvis den korte avtalen du har avtalt med klienten har en sjekkliste over nettstedets funksjoner eller elementer, sjekk disse er alle dekket, og hvis ikke, at du har avtalt dette med klienten.
Kontroller problemer eller oppgaver. Hvis du bruker et problem eller oppgavesporingssystem (for eksempel problemer i GitHub), må du kontrollere at alle problemer er stengt eller at oppgavene er fullført, og at det ikke finnes noen utestående feil eller spørsmål.
Sjekk ønskede endringer. Kontroller eventuelle endringer som ble bedt om under utviklingen (som kanskje ikke er i den opprinnelige korte), med mindre de blir lagret for etter lanseringen.
Test på stedet prosesser. Hvis nettstedet inneholder prosesser eller interaksjoner, må brukere utføre, kjøre gjennom disse prosessene på flere nettlesere og enheter for å være sikker på at de fungerer i henhold til korte.
Rydd opp brukere. Hvis du har opprettet noen dummy-pålogginger eller, for eksempel, koblet nettstedet til en sandkasse PayPal-oppsett, endrer du disse til liveversjonene (det kan hende du må sjekke dette igjen etter overføring).
Kontroller eventuelle opphavsrettigheter og / eller kreditter for eksempel fotokreditter.
Ryd opp tekst. Hvis du har brukt fillertekst (for eksempel lorem ipsum), må du sørge for at alt er blitt erstattet av mer passende innhold. Selv et notat som anbefaler besøkende at innholdet på en side er under utvikling, er mye mer nyttig og profesjonell enn lorem ipsum tekst.
Test admin tilpasninger. Hvis du har tilpasset WordPress-administrasjonen, må du kontrollere at dette fungerer for alle brukerroller som kunden din skal bruke.
Test tredjepartstjenester. Hvis nettstedet er integrert med tredjepartstjenester, må du kontrollere at alt dette fungerer og at programvaren er oppdatert (det kan hende du må sjekke dette igjen etter overføring).
Dette er ikke en uttømmende liste da prosjektet ditt kan ha flere elementer du må vurdere, men det vil gi deg grunnlag for å jobbe fra.
2. Robusthet
De fleste av elementene i denne sjekklisten gjelder for alle nettsteder, men det kan være noen variasjoner for ulike prosjekter, for eksempel hvis en klient krever at du støtter bestemte enheter (selv om jeg alltid vil forutse en enhetlig agnostisk tilnærming til utvikling).
Arbeid gjennom den første delen av denne listen før du overfører nettstedet til live-serveren:
Nettlesertesting. Test nettstedet ditt i alle nettleserne du støtter (som du burde ha avtalt med klienten din). Du bør gjøre dette når du går og ideelt bruker progressiv forbedring, men du bør gjøre endelig kontroll før du går live. Test innhold ved hjelp av hver mal i temaet ditt: enkelt innlegg, sider, arkiver og egendefinerte innleggstyper.
Enhetskompatibilitet. Test nettstedet ditt på tvers av alle enhetene du støtter. Igjen burde du ha gjort dette mens du jobbet på nettstedet, og brukte responsiv design for å imøtekomme forskjellige skjermstørrelser. Hvis nettstedet ditt bruker plugin eller forbedringer med varierende støttestøtte på tvers av enheter, må du kontrollere hvilke brukere som vil oppleve når de ser det på disse enhetene, og sette inn et alternativ, eller en kobling til et sted de kan få tilgang til innhold som ellers ikke er tilgjengelig for dem.
Bekreft koden din ved hjelp av W3Cs validator - igjen bør du virkelig gjøre dette mens du går. Hvis koden din ikke bekreftes, kan du noen ganger bestemme deg for ikke å endre den, for eksempel hvis du bruker HTML5-funksjoner som ikke validerer. Hvis dette er tilfelle, sørg for at det ikke forårsaker problemer i nettlesere som ikke støtter nyere funksjoner (ved hjelp av den progressive forbedringsmetoden som allerede er referert til).
Sjekk at nettstedet ditt er tilgjengelig. For råd om tilgjengelighet i WordPress, se Graham Armfields utmerkede webtilgangsguide og veiledningen i WordPress-kodeksen.
Etter at du har overført nettstedet ditt til live-serveren, vil det bli flere tester for robusthet som du kanskje må gjøre:
Test navigasjonen og koblingene, spesielt omdirigeringer.
Kontroller at databasen blir lest korrekt og fra det rette stedet - hvis ditt nettsted leser innhold fra utviklingsdatabasen din, vil dette ikke være umiddelbart tydelig hvis du har kopiert databasens innhold på tvers av, da de to vil være identiske. Spesielt sjekk linker i tekst widgets og bilder.
Dobbeltklikk integrering med tredjeparts programvare og tjenester. Disse skal alle kommunisere med ditt nettsted, ikke ditt utviklingssted.
Sjekk at nettstedinnstillingene refererer til den levende nettadressen (for eksempel webadressen url og WordPress url).
Pass på at permalink fungerer som de skal for alle innholdstyper - Det kan hende du må konfigurere disse eller gå til skjermbildet for innstillinger for å spyle dem.
brukere. Test nettstedet ditt (front-end og admin) ved å bruke alle WordPress-brukerrollene klienten din skal bruke. Sett opp eventuelle brukere du trenger.
3. Fremtidspåvirkning av nettstedet
Den tredje listen handler om å sørge for at nettstedet er klart for fremtidig utvikling og tillegg. Dette vil være spesielt viktig hvis du overleverer nettstedet til klienten din slik at de kan administrere og oppdatere.
Sørg for at grunnleggende SEO er opprettet. Titler og metabeskrivelser bør bearbeides i temaet ditt eller legges til ved hjelp av en SEO-plugin. Avhengig av prosjektets behov kan det hende du må bruke tid på å konfigurere pluginet for å møte kundens behov. En annen viktig, men lett oversett oversikt: Hvis du blokkerte tilgangen til søkemotorer under utviklingen, fjerner du blokken ved lansering, enten ved hjelp av WordPress-innstillingene eller med en robots.txt fil.
Lag en sikkerhetskopi av filene og databasen ved lansering.
Sett opp et automatisert backup system for tema og plugin filer og databasen. Hvordan dette styres og hvem har ansvar for det, vil avhenge av hva du har avtalt med din klient og på hvilken hostingoppsett de har. Det finnes en rekke WordPress plugins for dette, inkludert premium plugins som Backup Buddy eller gratis plugins som WordPress Backup to Dropbox.
Konfigurer nettstedet for Google Analytics, enten ved hjelp av et plugin eller ved å legge til sporingskoden til temaet ditt.
Sett inn et system for å holde nettstedet oppdatert. Dette inkluderer ikke bare WordPress selv, men også temaer og plugins. Uansett om du gjør dette, gjør kunden eller deres hosting leverandør seg etter at det avhenger av hva du har avtalt med klienten din. Det kan hende du må godta en bestemt vedlikeholdskontrakt for dette.
Godta en tidsplan for nettstedanmeldelser. Når en gang er lansert, bør et nettsted ikke bare stå alene. Enig med klienten din hvor ofte du vil vurdere nettstedets ytelse og effektivitet, og sørg for at du holder kontakten med klienten din slik at de kommer til deg når de trenger ytterligere utviklingsarbeid gjort.
4. Endelige handlinger
Den fjerde og siste delen av sjekklisten min er svært kort, og fullfører lanseringsprosessen.
Endre noen av de ovennevnte kontrollene etter behov. Hvis du har gjort endringer etter noen av dine sjekker (f.eks. Hvis du har redigert temaet etter å ha funnet kode som ikke bekreftet), gjentar du sjekken som ba om endringen og eventuelle kontroller du gjorde før det hvis resultatene kan ha blitt berørt . For eksempel fungerer den nye validerte koden på alle enheter eller nettlesere?
Godkjenning. Hvis det er noen vesentlige endringer som følger med sjekker, kan det hende du må oppnå klientlogging igjen.
Kommunisere. Pass på at klienten din og andre interessenter vet at nettstedet har gått live. Hvis det er ditt eget nettsted eller kunden din har bedt deg om å publisere den, gjør du dette ved hjelp av sosiale medier, blogginnlegg eller andre kanaler. Legg den til porteføljen din hvis du er stolt av det!
Får betalt. Ikke glem å sende klienten en faktura for lanseringsfasen av prosjektet.
Sammendrag
Som nevnt tidligere i denne artikkelen, tar ikke denne listen seg til å være den endelige listen for alle WordPress-utviklere, men forhåpentligvis er det nyttig for alle som ønsker å presentere litt konsistens i deres nettsteds migreringsprosess.
Ta denne listen og rediger den slik at den fungerer for din arbeidsform og dine prosjekter, Legg til i den, endre den og skrap ting som ikke er relevante for deg. Men hvis du bruker dette til å utvikle din egen sjekkliste som du refererer til hver gang, kan du være sikker på at du ikke vil savne noe viktig, og at eventuelle problemer vil bli oppdaget av deg før nettstedet går live, ikke av dine kunder eller brukere etterpå.
Share
Accentsconagua
