Om in de 'lancering' fase van een project te komen, kan een enorme opluchting zijn. Je hebt eindelijk je ontwikkelingswerk gedaan, een site gemaakt volgens de opdracht van je klant of je eigen vereisten, en nu kun je op die metaforische knop drukken en de site voor de hele wereld lanceren om te zien.
Maar wacht.
Voordat u begint, moet u enkele controles uitvoeren om te controleren of deze robuust en toekomstbestendig zijn. Door deze controles uit te voeren voordat u elke nieuwe site start, kunt u later problemen voorkomen. In het bijzonder kunt u de hoofdpijn, schaamte en schade aan uw reputatie voorkomen door klanten of gebruikers problemen te laten opmerken nadat de site live is gegaan.
In dit artikel deel ik de controlelijst die ik gebruik voordat ik een site migreer om te leven. Ik beweer niet dat dit de heilige graal van lijsten is - je zult een aantal dingen hebben die je niet doet, die je anders doet, of die je naast deze dingen doet.
Het is vermeldenswaard dat pre-lanceringscontroles niet alleen relevant zijn onmiddellijk voorafgaand aan het starten van een site - afhankelijk van de complexiteit van uw project, zult u er veel van moeten inwerken terwijl u verder gaat. Dit zal u tijd besparen en opnieuw werken wanneer de site klaar is om live te gaan, en zal helpen bij het aftekenen en de geloofwaardigheid in fasen tijdens de ontwikkeling waar uw klant het werk op de site aan het beoordelen is..
Maar dat gezegd hebbende, ik denk dat het de moeite waard is om die lijst een laatste doorloop te geven voor de lancering, om zeker te zijn.
Mijn lijst is onderverdeeld in vier categorieën:
Project- of kort-specifieke controles
robuustheid
Toekomstbestendigheid
Laatste acties
Hieronder zal ik beschrijven waar elk van deze over gaat en een lijst met items voor elke categorie aanbieden.
1. Project- of briefspecifieke cheques
Ervoor zorgen dat de site voldoet aan de afgesproken instructies moet je altijd al doen, maar het is de moeite waard om een laatste controle uit te voeren voor de lancering.
Deze checklist zal voor elk project anders zijn, dus ik kan u niet echt een standaardlijst geven, maar er zijn enkele belangrijke tips die u kunt gebruiken. U moet deze lijst doorlopen voordat u de site naar de live server migreert:
Controleer de brief. Als de opdracht die u met de klant bent overeengekomen een controlelijst heeft met kenmerken of elementen van de site, controleer dan of deze allemaal zijn gedekt en zo niet, dat u dit met de klant bent overeengekomen.
Controleer problemen of taken. Als u een probleem- of taakvolgsysteem gebruikt (bijvoorbeeld problemen in GitHub), controleert u of alle problemen zijn gesloten of taken zijn voltooid en of er geen openstaande bugs of vragen zijn.
Controleer de gevraagde wijzigingen. Controleer of de wijzigingen die tijdens de ontwikkeling zijn aangevraagd (die mogelijk niet in de oorspronkelijke brief stonden) zijn gemaakt, tenzij deze worden opgeslagen voor na de lancering.
Test in-siteprocessen. Als de site processen of interacties bevat die gebruikers moeten uitvoeren, doorlopen ze die processen in meerdere browsers en apparaten om er zeker van te zijn dat ze werken volgens de instructies.
Ruimt gebruikers op. Als u dummy-aanmeldingsgegevens hebt gemaakt of bijvoorbeeld de site aan een PayPal-setup van een sandbox hebt gekoppeld, wijzigt u deze in de live versies (mogelijk moet u dit na migratie opnieuw controleren).
Controleer eventuele auteursrechten en / of tegoeden zoals fotokredieten.
Ruim tekst op. Als u vultekst hebt gebruikt (zoals lorem ipsum), controleert u of alles is vervangen door meer geschikte inhoud. Zelfs een notitie die bezoekers adviseert dat de inhoud van een pagina in ontwikkeling is, is veel handiger en professioneler dan die van lorem ipsum.
Aanpassingen voor testadministratie. Als je de WordPress-beheerder hebt aangepast, controleer dan of dit werkt voor alle gebruikersrollen die je client gebruikt.
Services van derden testen. Als de site is geïntegreerd met services van derden, controleert u of dit allemaal werkt en of die software up-to-date is (mogelijk moet u dit na migratie opnieuw controleren).
Dit is geen uitputtende lijst omdat uw project mogelijk extra items bevat die u moet overwegen, maar het geeft u een basis om vanuit te werken.
2. Robuustheid
De meeste items in deze checklist zijn van toepassing op alle sites, maar er kunnen enkele variaties zijn voor verschillende projecten, bijvoorbeeld als een client vereist dat u specifieke apparaten ondersteunt (hoewel ik altijd een apparaatonafhankelijke benadering van ontwikkeling zou aanbevelen).
Werk door het eerste deel van deze lijst voordat u de site naar de live server migreert:
Browser testen. Test uw site in alle browsers die u ondersteunt (wat u met uw klant zou moeten afspreken). Je zou dit moeten doen terwijl je meegaat en idealiter progressieve verbetering zou gebruiken, maar je zou de laatste controles moeten uitvoeren voordat je live gaat. Test inhoud met elke sjabloon in uw thema: enkele berichten, pagina's, archieven en aangepaste berichttypen.
Apparaatcompatibiliteit. Test uw site op alle apparaten die u ondersteunt. Nogmaals, dit had je moeten doen toen je op de site werkte, en een responsief ontwerp hebt gebruikt om verschillende schermformaten aan te passen. Als uw site plug-ins of uitbreidingen gebruikt met verschillende ondersteuningsniveaus op verschillende apparaten, controleert u wat gebruikers ervaren wanneer ze deze bekijken op deze apparaten en plaatst u een alternatief of een link naar ergens anders waar ze toegang hebben tot inhoud die anders niet beschikbaar is voor hen.
Valideer uw code de validator van de W3C gebruiken - opnieuw zou je dit echt moeten doen terwijl je doorgaat. Als uw code niet geldig is, kunt u soms besluiten deze niet te wijzigen, bijvoorbeeld als u HTML5-functies gebruikt die niet valideren. Als dit het geval is, zorg dan dat dit geen problemen oplevert in browsers die geen nieuwere functies ondersteunen (met behulp van de progressieve verbeteringsaanpak die hierboven al is genoemd).
Controleer of uw site toegankelijk is. Voor advies over toegankelijkheid in WordPress, zie de uitstekende webtoegankelijkheidsgids van Graham Armfield en de richtlijnen in de WordPress codex.
Na het migreren van uw site naar de live server, zullen er aanvullende tests voor robuustheid zijn die u mogelijk moet doen:
Test uw navigatie en koppelingen, vooral eventuele omleidingen.
Controleer of de database correct wordt gelezen en vanaf de juiste plaats - als je live site inhoud van je ontwikkelingsdatabase leest, zal dit niet meteen duidelijk zijn als je de inhoud van de database hebt gekopieerd, omdat de twee identiek zijn. Controleer met name de links in tekst widgets en afbeeldingen.
Controleer de integratie met software en services van derden. Deze moeten allemaal communiceren met uw live site, niet met uw ontwikkelsite.
Controleer of de site-instellingen verwijzen naar de live-URL (bijvoorbeeld de url van de site en de URL van WordPress).
Zorg ervoor dat permalinks correct werken voor alle inhoudstypen - mogelijk moet je deze configureren of ga je naar het Permalink-instellingenscherm om ze te spoelen.
gebruikers. Test uw site (front-end en admin) met behulp van alle WordPress-gebruikersrollen die uw klant zal gebruiken. Stel alle gebruikers in die u nodig hebt.
3. Toekomstbestendigheid van de site
De derde lijst gaat over het zorgen dat de site klaar is voor toekomstige ontwikkelingen en toevoegingen. Dit is met name belangrijk als u de site overdraagt aan uw klant zodat ze deze kunnen beheren en bijwerken.
Zorg ervoor dat basis-SEO is opgezet. Titels en metabeschrijvingen moeten in uw thema worden verwerkt of worden toegevoegd met behulp van een SEO-plug-in. Afhankelijk van de behoeften van het project, moet u mogelijk tijd besteden aan het configureren van de plug-in om aan de behoeften van uw klant te voldoen. Een andere belangrijke maar gemakkelijk over het hoofd gezien cheque: als je tijdens de ontwikkeling de toegang tot zoekmachines blokkeerde, verwijder je het blok bij de lancering, ofwel met behulp van de WordPress-instellingen of met een robots.txt het dossier.
Maak een back-up van de bestanden en database bij het opstarten.
Stel een geautomatiseerd back-upsysteem in voor thema- en plugin-bestanden en de database. Hoe dit wordt beheerd en wie de verantwoordelijkheid ervoor draagt, is afhankelijk van wat u met uw klant bent overeengekomen en van de hosting-instellingen die zij hebben. Hiervoor zijn een groot aantal WordPress-plug-ins beschikbaar, waaronder premium-plug-ins zoals Backup Buddy of gratis plug-ins zoals WordPress Backup naar Dropbox.
Configureer de site voor Google Analytics, via een plug-in of door de trackingcode toe te voegen aan uw thema.
Zet een systeem op voor het up-to-date houden van de site. Dit omvat niet alleen WordPress zelf, maar ook thema's en plug-ins. Of u dit nu doet, de klant doet het of de hostingprovider zorgt ervoor dat het afhankelijk is van wat u met uw klant bent overeengekomen. Mogelijk moet u hiervoor een specifiek contract voor het onderhoud van de site overeenkomen.
Maak een afspraak voor sitebeoordelingen. Eenmaal opgestart, zou een website niet alleen moeten worden gelaten. Ben het eens met uw klant hoe vaak u de prestaties en effectiviteit van de site zult beoordelen en zorg ervoor dat u contact houdt met uw klant zodat zij naar u toe komen wanneer zij verdere ontwikkelingswerkzaamheden nodig hebben.
4. Laatste acties
Het vierde en laatste deel van mijn checklist is erg kort en voltooit het startproces.
Herhaal indien nodig een van de bovenstaande controles. Als u wijzigingen heeft aangebracht na een van uw controles (bijvoorbeeld als u het thema hebt bewerkt nadat u de code hebt gevonden die niet werd gevalideerd), voert u de controle opnieuw uit die aanleiding gaf tot de wijziging en eventuele controles die u eerder had uitgevoerd, waarvan de resultaten mogelijk zijn beïnvloed . Is uw nieuwe gevalideerde code bijvoorbeeld geschikt voor alle apparaten of browsers??
Goedkeuring. Als er na uw controles significante wijzigingen zijn opgetreden, moet u mogelijk opnieuw clientuitmelding ontvangen.
Communiceren. Zorg ervoor dat uw klant en eventuele andere belanghebbenden weten dat de site live is gegaan. Als het uw eigen site is of als uw klant u heeft gevraagd om dit bekend te maken, doet u dit met behulp van sociale media, blogposts of andere kanalen. Voeg het toe aan je portfolio als je er trots op bent!
Betaald worden. Vergeet niet om uw klant een factuur te sturen voor de startfase van het project.
Samenvatting
Zoals ik eerder in dit artikel al zei, is deze lijst niet bedoeld als de definitieve lijst voor alle WordPress-ontwikkelaars, maar hopelijk is het nuttig voor iedereen die op zoek is naar enige consistentie in zijn migratieproces op de site..
Neem deze lijst en bewerk deze zodat het werkt voor uw manier van werken en uw projecten, Voeg toe, verander het en schrap dingen die niet relevant voor u zijn. Maar als u dit gebruikt om uw eigen checklist te ontwikkelen waarnaar u elke keer verwijst, kunt u erop vertrouwen dat u niets belangrijks mist en dat eventuele problemen door u worden opgemerkt voordat de site live gaat, niet door uw klanten of gebruikers achteraf.
Share
Accentsconagua
