Joy of FirePHP En Crash-Course

FirePHP er en Firefox plugin og server-side bibliotek kombinasjon som lar deg sende all slags saftig info ut av ditt webprogram til din nettleser, mye som konsollen.log () funksjonalitet med JavaScript. I denne PLUS-veiledningen og medfølgende screencast, lærer vi deg hvordan du kommer i gang helt fra begynnelsen!

Denne opplæringen inneholder en screencast tilgjengelig for Tuts + Premium medlemmer.

Så du tror du er en god webutvikler, va? Ikke les videre før du bestiller den første utfordringen: Svar (ærlig) "true" eller "false" om deg selv til følgende utsagn:

  1. Du bruker Firefox for webutvikling
  2. Du har installert den berømte Firebug-utvidelsen
  3. Du utvikler deg i PHP

Hvis du svarte alle tre med en rungende "sant", gi deg selv et klapp på ryggen. Jeg vil tilgi deg for ikke å få nummer tre, men hvis du ikke bruker Firefox med Firebug ... hvor har du vært!?

Du trenger denne vinnende kombinasjonsboksen for å fullføre denne opplæringen. Det siste du trenger - for å bli den store mesteren, uber-utvikleren, kode-slayer av drømmene dine - er den viktigste delen: FirePHP.


Hva er FirePHP?

FirePHP er en Firefox plugin og server-side bibliotek kombinasjon som lar deg sende all slags saftig info ut av ditt webprogram til din nettleser, på en finere måte enn vanlig:

 ekko $ variabel;

Denne koden er så vanlig. Noen ganger virker det som den raskeste måten å bare splat ut verdien av $ variabel så du vet hva det er på et gitt punkt med kodekjøring.

Men hva om $ variabel er ikke en streng eller et heltall; hva om det er en kompleks datatype som en matrise eller et objekt? I PHP ville ikke koden ovenfor være så nyttig:


"Bare bruk print_r ($ variable);" Jeg hører deg si. Alright smarty bukser, men det er ikke veldig elegant. Å prøve å finne verdien av en matrise i det rotet er en smerte. Og det sorterer fortsatt ikke ut gjenstander!

Når du ser hva FirePHP kan gjøre, vil du skifte deg! Det gjør debugging til en overraskende hyggelig prosess og resulterer i mye mer bærbar kode.

I denne opplæringen skal jeg vise deg hvordan du konfigurerer FirePHP i appen din, og noen gode måter å bruke den på for å øke hastigheten på utvikling og feilsøking.


Trinn 1: Sette opp server-siden

Hvis du ikke har installert FirePHP-utvidelsen, installer den nå.

FirePHP-utvidelsen (som jeg vil referere til som FirePHP fra nå av) er helt avhengig av Firebug, så du trenger det også. Server-side klassene (som jeg vil ringe FirePHPCore) er tilgjengelige som et frittstående bibliotek. Det finnes også en rekke plugins for de populære PHP-rammene og CMS.

Simon sier:

Selv om navnet antyder ellers, er FirePHP ikke bare for PHP-utviklere. Den bruker sitt eget sett med HTTP-overskrifter for å sende informasjon fra søknaden din til nettleseren, slik at den lett kan sendes til andre språk. Det finnes server-side biblioteker tilgjengelig for ASP, Ruby, Python og mer. Hvis det ikke er noe for språket ditt, kan du alltid utfordre deg selv og skrive din egen.

Dette gjør det også ideelt for AJAX-feilsøking, da det betyr at asynkrone svar er rent innhold som bare inneholder utdataene du vil se - ikke feilsøkingskoden.

Gå videre og last ned ditt foretrukne server-side bibliotek. I denne opplæringen vil jeg fokusere på å bruke det frittstående kjernebiblioteket. Instruksjoner for å sette opp andre biblioteker finnes på FirePHP wiki.

Simon sier:

Hvis du har PEAR-oppsett og foretrekker å bruke det, skriv du bare følgende to linjer på kommandolinjen:

 pærekanal - finn pear.firephp.org pære installer firephp / FirePHPCore

Når du har pakket ut pakken, går du inn i lib mappe og kopiere FirePHPCore mappe til din webserver eller app inkluderer mappe.


Companion Screencast


Simon sier:

En av de store tingene ved den frittstående FirePHPCore er støtten til PHP4. Så du kan til og med koble den til noen av disse retro-nettstedene du fremdeles kjører!


Trinn 2: Hei, FirePHP

Som med alle gode kodende opplæringsprogrammer, starter vi med et grunnleggende eksempel, "Hello, World" av FirePHP.

Opprett et nytt, tomt PHP-dokument. Jeg ringer til min test.php. Lagre det til roten til appen din.

For FirePHPCore å gjøre sitt arbeid, må vi aktivere utdatabuffering. Les mer om dette hvis du ikke har brukt det før, det er en god vane å komme inn i allikevel.

 

Selvfølgelig må vi ikke glemme å inkludere FirePHPCore-biblioteket. Hvis du kjører på PHP5, legger du dette til toppen av filen:

 include_once ('includes / FirePHPCore / fb.php');

Hvis du kjører PHP4, inkluderer du fb.php4 filen i stedet.

Simon sier:

Vi trenger ikke å inkludere klassefilen, da dette er inkludert i fb.php-filen.

Nå kan vi begynne å sende ut til Firebug-konsollen. Skriv inn følgende etter ob_start () og før ob_end_flush ():

 FB :: info ('Hei, FirePHP');

Simon sier:

FirePHPCore har en prosessorisk og en objektorientert API. Det er ingen forskjell mellom de to, og du kan bruke det du foretrekker.

Den bruker også singleton mønsteret for å spare minne og kommer med en helt statisk hjelpeklasse, som jeg foretrekker å bruke som det krever mindre koding.

Åpne Firefox, start Firebug og gå til denne siden. Du bør få noe slikt:


Hvor kult er det!? Vel, det er ikke en veldig spennende demo, så la oss prøve noe litt mer komplisert.


Trinn 3: Sende komplekse variabler

La oss se hva som skjer når vi går over i en kompleks variabel. Vi bygger en matrise og ser hva vi får. Legg til følgende kode like etter siste FB :: info () ring:

 $ array ['key1'] = 'noe innhold'; $ array ['anotherKey'] [] = 1234; $ array ['anotherKey'] [] = 5678; $ array ['anotherKey'] [] = 9012; $ array [] = null; FB :: info ($ array, 'My Array Test');

Lagre nå, gå til Firefox og oppdatere.


Ok, det ser bra ut, men hang på, hvor er all produksjonen? Hold markøren over den nye linjen.


Wow. Firebug-rammen viser oss alle dataene i vårt utvalg - ikke bare første nivå-arrayelementer, men også på nivellerende nivå - og på en nøyaktig, lesbar måte.

Det blir enda mer interessant med objekter! FirePHPCore gjør full bruk av refleksjon for å inspisere objektets egenskaper - selv private.

Simon sier:

FirePHPCore har en rekke alternativer som kan settes for å begrense inspeksjonsnivået til arrays og objekter. Du kan til og med lage et filter for objektegenskaper som du ikke vil at den skal overføres til brukeragenten.

Du kan finne ut mer om FirePHPCore API på FirePHPs hovedkontor.


Praktiske bruksområder

Det burde være åpenbart for deg at dette kan hjelpe med generell feilsøking, men nå skal jeg se på noen oppfinnsomme måter å bruke FirePHP.

1) Et PHP Profiling Tool

Hvis du bruker en enkelt frontkontroller til å rute alle forespørsler om og starte opp appen din, kan du tid på hvor lenge hver forespørsel til søknaden din tar for å behandle på serveren.

Noe som dette ville gjøre det:

 

Husk at dette ikke er en representasjon av responstiden, bare kode kjøretid - hvor fort serveren din utfører koden før du sender den til brukeragenten. Output må fortsatt reise fra serveren til klienten over nettverket.

Simon sier:

Du kan bruke YSlow-utvidelsen for Firebug til å spore overordnede sidetilfeltider og appresponsivitet.

2) Et enkelt SQL Query Inspection Tool

Hvis du bruker en sentral forespørselsfunksjon eller utvider en klasseklasse for databasekoblinger (for eksempel mysqli), kan du pakke en tidsur rundt eventuelle synkroniserte spørringer og sjekke hvor lenge hver enkelt tar.

Du kan også legge merke til SQL-spørringene selv. Faktisk kan du sette disse to bitene sammen. Og ville det ikke vært fint å vise det i et godt strukturert bord?

Brønn Firebug har en bordstruktur og FirePHPCore har også en wrapper for det:

 

Simon sier:

Jeg har kastet et par statister her inne. I filen myDb.class.php, hvis $ resultat variabel kommer tilbake falsk, det betyr at dette søket mislyktes. Så jeg bruker FB :: feil () å markere dette som en feil i Firebug og vise meg spørringen så vel som FB :: spor () for å vise meg prosessstakken som fører opp til det dårlige spørsmålet.

Nøkkelen er her FB :: tabellen () metode. Dette gjør det mulig å lage strukturert feilsøkingsinformasjon død lett.

Nå når du instantierer din myDb-klasse og utfører en spørring, spretter den detaljene til spørringen inn i en matrise. Vi får da tilgang til denne oppsettet senere å bygge vår FirePHP-tabell over alle spørsmålene du har utført for den forespørselen, hvor lang tid hver tok, og den totale kjøretiden for alle spørsmålene.


Det du har gjort her, med bare få linjer med kode, ville vært umulig med bare ekko. Du kunne ikke håpe å få noe så nyttig på så kort tid. Det gir noen rask feilsøking.

3) En AJAX Debugger

Bruke FirePHPCore for AJAX-forespørsler er ikke annerledes enn å bruke den til synkron forespørsler. Bare bruk funksjonene som du normalt ville. Når appen din gjør AJAX-forespørsler, kommer den ekstra FirePHP-headerinformasjonen gjennom, og klientens sideutvidelse behandler den i Firebug-konsollen. La oss prøve det.

Opprett en ny fil som heter ajax.php i roten til appen din. Legg inn følgende kode der inne:

 

Nå i din test.php fil, legg til følgende etter din siste FB :: info () samtale:

 ?>     

Forfriskende test.php i Firefox skal vise deg 'Klikk meg!' knapp. Når du klikker på det, skal nettleseren utføre en AJAX-forespørsel og laste svaret (i dette tilfellet ren tekst) i

.


Viktigere, FirePHP legger til en ny node til Firebug som viser oss eventuelle FirePHP meldinger vi loggte inn i ajax.php filen.

4) Standard Feil Handler

Hold dette i begynnelsen av appen din og til og med stygg gamle PHP-feil blir dumpet til Firebug!

 set_error_handler ( 'myErrorHandler'); // Du kan legge til valgfrie parametere $ errfile, $ errline og $ errcontext for mer detaljer funksjon myErrorHandler ($ errno, $ errstr) FB :: feil ($ errstr, 'Feilnummer'. $ Errno);  // Fortsett med normal utførelse

Dette er en mye renere og sikrere måte å rapportere feil på. Det blir enda bedre hvis du demonstrerer appene dine til klienter mens de er i utvikling (og i fare for å produsere ikke-kritiske feil). Hvis de ikke bruker Firefox, med Firebug og FirePHP, ser de ikke disse skrekkelige feilene , men du vil ... i Firebug. Ikke lenger endre feilmeldingsnivåene dine bare for å holde ting ryddig! Nå er det raskere utvikling.


Sikkerhet

Mens FirePHP er et flott verktøy for feilsøking under utvikling og testing, bør det ikke stå igjen når en app går i produksjon. Det kan potensielt vise alt for mye informasjon om at appen din gjør livet enda enklere for hackere.

Selvfølgelig, hvis du kobler til et nettsted over HTTPS, krypteres all headerinformasjon som standard. Ellers sendes det som vanlig tekst.

Det legger også til et overhead for appen din, som kan føre til en alvorlig reduksjon i ytelse og en buk i båndbredden din.

Dette bringer meg til et annet bra punkt om FirePHPCore: du kan legge ut FirePHP-koden på plass, men den vil ikke sende noen data hvis den er deaktivert eller hvis den forespørgende brukeragentstrengen ikke inneholder den spesifikke FirePHP-referansen.

Hvis du absolutt må aktivere FirePHP på produksjonssteder, for eksempel for ekstern feilsøking, må du kontrollere at den er på en bryter og ikke glem å slå den av når du er ferdig. Noe som:

 define ('DEBUG_MODE', true); FB :: setEnabled (false); hvis (DEBUG && $ _SESSION ['userIsAdmin']) FB :: setEnabled (true); 

Dette sikrer at selv om DEBUG_MODE er satt til «true» (dvs. «på»), vil bare en autentisert administratorsøkt med en brukeragent med FirePHP installert, utløse feilsøkingskoden og motta informasjonen om ekstra header.


Konklusjon

FirePHP er et glimrende verktøy. Det har slått perfekt inn i arbeidsflyten min. Fordi det alltid er der, boltet på verktøyene jeg allerede bruker daglig, er det blitt en annen natur å bruke.

Enda viktigere, det har reddet huden min mer enn noen få ganger. Jeg har vært i stand til å feilsøke nettsteder i produksjon uten å måtte ta ned nettstedene. Det har gjort AJAX debugging en veldig reell mulighet, og fordi den er åpen kildekode og gratis å bruke, er kostnaden ved adopsjon ekstremt lav.

Legg til dette faktum at appene mine nå er mer bærbare, jeg har bedre innblikk i dem, og jeg har lært noen få nye triks underveis, hva er det ikke å like?

Flere og flere webutviklere benytter nettleseren som deres primære utviklingsverktøy. Og hvorfor ikke? Det er der våre applikasjoner er ment å fungere. Så det virker på en eller annen måte mer naturlig å sette profilering og feilsøking rett i nettleseren; hvor vi tilbringer mesteparten av tiden vår feilsøking uansett!

Tenk det er på tide å slutte å bruke ekko nå? Gratulerer, Super-Dev!


FirePHP ble opprettet av Christoph Dorn. Versjon 0.3.1 er den nåværende stabile versjonen. 1.0 versjonen er i utvikling og lover noen spennende nye funksjoner.