Verktyg för WordPress-projekt: En del av det jag använder dagligen
Utvecklare är ofta intresserade av hur andra utvecklare konfigurerar sina inställningar. Och jag förstår det.
Det vill säga, jag antar att det är baserat på idén att se vilka verktyg andra använder för att avgöra om du går miste om något, om du kan förbättra det du gör för närvarande eller om du är bekväm med det du har.
Oavsett vilket kommer jag ibland få e-postmeddelanden, tweets eller ICQ-meddelanden (vänta, vadå?) som frågar vilken svit av verktyg för WordPress-projekt jag vanligtvis använder för vart och ett av mina projekt.
Så jag tänkte dela med mig av en sammanfattning av varje applikation som jag vanligtvis använder och en kort beskrivning av hur jag använder var och en av dem i mitt dagliga arbete.
Verktyg för WordPress-projekt
Innan jag tar upp vad jag använder och hur jag använder dem, vill jag nämna att det är viktigt att notera att detta förutsätter att WordPress har alla sina felsökningsvärden korrekt inställda. Jag har täckt detta i ett tidigare inlägg, men kärnan (helt bokstavligen, till och med) av vad jag menar är följande:
<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );Med dessa uppsättningar kommer information att skrivas till felsökningsloggen, till skärmen och så vidare. Det lägger till att mycket av ett extra lager för att hjälpa dig att lokalisera problem i din kodbas.
Förutsatt att det är klart, här är en mycket kort sammanfattning av allt jag använder när jag arbetar med ett projekt.
Terminal
Min IDE (som jag kommer att prata om senare i det här inlägget) innehåller en integrerad terminal som jag använder regelbundet men att ha möjlighet att navigera mellan kataloger, dumpa information eller oftast interagera med PHP-skalet är anledningen till att jag använder en fristående instans av terminalen.
Generellt sett hjälper det att utvärdera kod i farten och testa saker som reguljära uttryck utan att behöva göra det inom ramen för en webbläsare.
Tanken är att om det fungerar i terminalen så kommer det att fungera i sammanhanget med funktionen där jag arbetar.
Sequel Pro
I flera år nu har detta varit min föredragna databasgränssnitt. Jag vet att många gillar att använda något i webbläsaren som PhpMyAdmin (eller det relaterade Adminer-pluginet för WordPress).
Men jag är ett fan av att ha ett fristående databasgränssnitt som stöder visning av databasen, genom vissa kriterier, eller genom att skriva in frågor direkt i ett gränssnitt.
Trösta
macOS konsolapplikation är utmärkt för att titta på felsökningsloggar. Detta är särskilt användbart om du gör något så här :
<?php
error_log(print_r($value, true));Detta gör att du kan skriva information om till loggen och sedan granska den i konsolen och följa hela stackspåret för hur informationen hämtades. Vidare kan den visa dig vilken information den hämtade faktiskt är och hur den kommer att uppfattas av PHP eller WordPress.
Visual Studio Code
Slutligen, efter att ha provat en mängd olika IDE:er genom åren, fortsätter jag att komma tillbaka till Visual Studio Code. Enkelt uttryckt, jag gillar hur det fungerar och hur det interagerar med mitt sätt att arbeta. Det känns mer som att det passar mitt arbetssätt snarare än att jag behöver anpassa mig till det.
Därifrån använder jag flera tillägg som:
- ESLint
- PHP-felsökning
- PHP DocBlock Generator
- PHP CodeSniffer
- PHPUnit
- ALLA höjdpunkter
- WordPress Verktygslåda
Jag använder också Fira Code och några andra verktyg som den integrerade terminalen för att få jobbet gjort.
Det finns fler
När det gäller de andra verktygen finns det saker som git (som jag använder från den integrerade terminalen i Code ), Kaledeiscope, WP-CLI, och så vidare, men jag antar att de är givna, mer eller mindre.
Ovanstående verktyg är de jag vanligtvis har öppna och använder dagligen när jag arbetar med ett projekt och behöver interagera med alla delar av projektet.