In het introductiedeel van deze serie zei ik dat 'WordPress-tools' niet in één specifiek medium kunnen worden gedefinieerd: een WordPress-tool kan de vorm hebben van een WordPress-plug-in, een enkel PHP-bestand, een website of zelfs een desktoptoepassing.
In dit deel van de "Toolbox van de Smart WordPress Developer" -serie gaan we door twee verschillende tools in twee verschillende soorten medium: WXR File Splitter (als een desktop-applicatie) en WP Serialized Search & Replace (als een PHP-bestand).
Als u een freelance webontwerper bent of bij een webdesignbureau werkt en u dit artikel leest, is de kans groot dat u WordPress regelmatig op servers installeert, dus u weet een beetje (of veel) over het migreren van WordPress. En als je een van de weinige gelukkige WordPress-ontwikkelaars bent, had je misschien een klant met een enorme website die gemigreerd moest worden tussen twee servers.
Hoewel er tientallen verschillende technieken en opties zijn om WordPress-installaties te verplaatsen, hebben we in sommige gevallen niemand anders dan de meest betrouwbare: de WordPress Extended RSS (WXR) -back-ups.
Wat als uw klant u de inloggegevens van de oude, waardeloze gedeelde server WP-Admin geeft en niets anders? Wat als die nieuwe hippe WordPress-plug-in niet van uw oude server naar de nieuwe kan migreren? Wanneer de donkere tijden komen, moet je klaar en voorbereid zijn.
Als de WXR-back-up enorm is (en ik bedoel gigabytes van reusachtig), is de WXR-bestandssplitter degene die je tranen wegsnijdt.
Slecht nieuws eerst: deze tool, die werkt in Windows, is oud. Super oud. En het werkt niet. Ik bedoel, het werkt niet met de nieuwere WordPress-versies (waarschijnlijk de afgelopen twee jaar). ik maak geen grap.
Maar natuurlijk ga ik niet schrijven over een hulpmiddel dat totaal nutteloos is. Dus het goede nieuws is dat het heel eenvoudig is om het te laten werken - zo eenvoudig dat je gewoon even snel moet zoeken en vervangen in je back-upbestand.
Laten we de stappen bekijken:
tags in hoofdletters (door alleen de openingstags te zoeken en te vervangen-niet nodig om hetzelfde te doen
tags) en sla het bestand op.WXRsplit.exe
het dossier.Beproeving? Welnu, het zou moeten zijn: als uw klant het admin-paneel van een website overhandigt die wordt gehost op servers die in de Tweede Wereldoorlog worden gebruikt, zou de oplossing voor uw migratieprobleem niet eenvoudig moeten zijn. Rechts?
Oh, en er is een Mac OS X-versie ontwikkeld door een niet-gerelateerde ontwikkelaar, maar ik heb de kans niet gehad om het te proberen (en heb er een zenuwinzinking van omdat ik het heb) omdat ik geen Mac bezit.
Laten we nu verder gaan met onze tweede tool: WP Serialized Search & Replace.
Ik werkte een keer in 2012 bij een webdesignbureau. Op mijn eerste dag bekeek ik enkele projecten in het verleden om te zien hoe we met onze klanten werkten. Ik zag dat toen we een klant lanceerden, we begonnen met het bouwen van hun website in een subdomein van ons eigen merkdomein en ons werk aan de klant toonden wanneer dat nodig was; en toen alles was ingesteld (inclusief de laatste betaling), hebben we de website verplaatst naar het domein van de klant.
Die dag stelde ik onmiddellijk voor om deze workflow met onze klanten te veranderen, omdat het ons werk vertraagde; maar de baas verwierp mijn voorstel vanwege "financiële redenen". Hij legde uit dat in het verleden sommige cliënten dat hadden geprobeerd stelen ons werk vlak voor de laatste betaling, en dat is waarom we zo werkten. "Nonsens", dacht ik, maar hij was tenslotte de baas.
Mijn eerste werk was een klant met een hoge prioriteit die de website zo snel mogelijk nodig had. (Gelukkig was de inhoud van tevoren verzonden.) Ik installeerde snel WordPress naar een subdomein van onze website en activeerde het thema (geselecteerd door de klant) samen met een aantal plug-ins. Ik heb alle instellingen van de kern, het thema en de plug-ins aangepast en ben toen met de inhoud gaan werken.
Toen ik klaar was (en de baas onder de indruk had gemaakt door een hele website in minder dan vier uur te schilderen), hebben we de website aan de klant getoond en meteen een goedkeuring en een bericht ontvangen waarin stond dat de website morgen operationeel moest zijn gingen naar een expo.
Met vertrouwen besloot ik om wat overuren te maken en de website die dag te verplaatsen. Ik heb alle bestanden van FTP gedownload en in plaats van een snelle WXR-back-up te doen, deed ik een SQL-back-up in phpMyAdmin. Na het wijzigen van de website-URL's in de wp_options
tabel, ik heb de bestanden geüpload en de SQL ingediend bij de database van de klant. Oh, en ik heb snel alles in het ontwikkelingssubdomein verwijderd.
Toen ik merkte dat de afgebeelde afbeeldingen kapot waren gegaan, heb ik het SQL-bestand gecontroleerd en zag dat ze allemaal nog steeds URL's hadden van het subdomein van onze eigen website. Ik heb snel gezocht en vervangen, de wijzigingen in de back-up opgeslagen en de database overschreven met de nieuwe SQL. Toen ik de website bezocht, zag ik niet alleen dat de afbeeldingen nog steeds kapot waren, maar ook dat alle berichten verdwenen waren, ook al bevonden ze zich nog in de database.
Dat is de dag dat ik hoorde over "serialized entries". (Ik kwam ook om middernacht thuis, omdat ik de rest van mijn dag dezelfde website opnieuw heb gebouwd op de server van de client.) Uit die ervaring heb ik geleerd dat items in series worden opgeslagen met aantal tekens en als het aantal tekens niet is Niet consistent met de string, WordPress laat de invoer helemaal weg.
Dus, hoe kunnen we zoeken en vervangen in WordPress, inclusief de seriedragers? Met WP Serialized Search & Replace, natuurlijk.
WP Serialized Search & Replace is meer als een portable tool: u uploadt de map (in uw WordPress installatiemap) en start de index.php
het dossier. Dus als je WordPress-bestanden zich bevinden mywebsite.com/wp/
map, moet u het hulpprogramma uitvoeren mywebsite.com/wp/srtool/index.php
(de naam van de map van het gereedschap doet er niet toe, dus u kunt de mapnaam wijzigen als u dat wilt).
Nadat u de tool heeft uitgevoerd, ziet u vijf secties:
wp-config.php
het dossier.Ik moet zeggen, ik vond het ontwerp erg leuk, maar ik denk dat deze tool beter zou werken als WordPress-plug-in.
We hebben het tempo een beetje opgepikt voor dit gedeelte en hebben twee kleine WordPress-tools in één bericht doorgenomen. Ik vind dat ze allebei de eer verdienen, ondanks dat ze een beetje buiten de radar zijn in de WordPress-gemeenschap.
Wat denk je over deze tools? Ken jij betere alternatieven? Deel uw mening en ervaring met ons in het gedeelte Opmerkingen hieronder. En als je het artikel leuk vond, vergeet dan niet om het met je vrienden te delen!
Tot ziens in het volgende gedeelte waar we het hebben over de WordPress GitHub Plugin Updater, een geweldige tool om het updateproces voor WordPress-plug-ins te beheren die worden gehost op GitHub.