Kategori: Utvecklingsmiljö & Programvara

Hur man Splittar Stora Loggfiler till Flera mindre filer

3 oktober, 2024 av Trekka12·0 kommentarer

På sistone har det hänt att jag har behövt felsöka PHP loggfiler eller HTTP loggfiler p.g.a. att hemsidan kanske kraschat via PHP Fatal Error eller p.g.a. DDoS-attacker.

DDoS-attacker mot hemsidor och vad man kan göra när de inträffar

DDoS-attacker är vanligare än man kanske tror och kanske mer så för populära och större hemsidor – tyvärr.

Det finns tillochmed företag inom affärsvärlden som anlitar folk för att sänka konkurrenter genom att ha dem skicka ut kodade bottar för att överbelasta hemsidor på olika sätt.

Ofta brukar detta dock vara olagligt, men kanske inte alltid så lätt att spåra ursprunget och komma fram till vem som ligger bakom.

Jag har erfarenhet av att ha stött på bottar utskickade från andra länder, kodade att överbelasta hemsidan på olika sätt.

En bot kan relativt enkelt (tyvärr) överbelasta en hemsida

En av de här bottarna gjorde det genom att låta botten basically ”klicka runt” på hemsidan så snabbt som bottens maskins processor klarade av.

Och vår server kunde inte hänga med.

Tänk dig själv hundratals- om inte tusentals klick på millisekunden på din hemsida. Där varje klick motsvarade anrop till servern, för handling som behövde tas av den.

Anrop som ofta involverade SQL-frågor till databasen, JavaScript funktioner att laddas och köras eller sidor att generera och laddas.

Det krävs inte ”rocket science” att lista ut att detta lätt överbelastar en servermaskins RAM-minne, processorkraft och övriga resurser, som annars delas mellan alla besökare till en hemsida.

Och skapar köer så långa att hemsidan till slut blir otillgänglig medan servern försöker hantera belastningen den utsatts för.

Om man tänker efter så behöver det inte vara så komplicerat att bygga något som kan förstöra för en hemsida, men det är synd att folk gör det och att det är så lätt för dem att åstadkomma det och komma undan med det.

Där finns en väldigt bra bok jag köpte för några år sen och läste för Hur man bygger Spiders, Bottar osv. skriven av en som arbetade professionellt med att enbart bygga bottar för olika affärsändamål som företag hade behov av.

Det kunde vara ändamål som att indexera priser från konkurrenters hemsidor, eller automatisera testkörning av formulär på olika hemsidor, och liknande.

Men då varje bot du bygger kommer köra så snabbt som processorn klarar av – om du inte säger till den något annat- så hade denna författaren som best praxis och regel alltid när han byggde bottar att ”simulera en människans beteende”.

Med detta menas för när en människa besöker hemsidor och hur ”fort” de då gör olika saker på en hemsida.

Han simulerade detta genom att lägga in någon sekunds delay mellan varje datahämtning.

Dels för att inte skada servern för hemsidan han arbetade mot med sina bottar
Dels då det är olagligt att krascha hemsidors servrar
Dels för att vara ”under radarn” och inte ge kanske konkurrenter osv. anledning att kolla närmare på hans bott och dess beteende

Boken är ”Webbots, Spiders, and Screen Scrapers: A Guide to Developing Internet Agents with PHP / CURL” av Michael Schrenk.

Kan varmt rekommendera boken för alla er nyfikna på hur man bygger Bot programvara med PHP. Enklare än man tror, på gott och ont.

Om inget annat så kan boken öppna ögonen och utöka förståelsen för vad en bot faktiskt kan åstadkomma på en hemsida, och hur, vilket även kan hjälpa till när du ska analysera och skydda dig från dem.

”Know Thy Enemy” som en vis man en gång sade, lite så.

Motverka DDoS och liknande attacker med Cloudflare och liknande tjänster

Ett populärt sätt att motverka detta som jag hört talas om men ännu inte haft möjligheten att implementera och testa själv är tjänster som Cloudflare som ska sätta upp en form av ”skyddsnät” framför din hemsida ut mot Internet som är tränad att känna igen- och kunna blockera dåligt beteende innan det når din faktiska hemsida och dess server.

Har hört många tala väldigt gott om det och att det ibland tillochmed talats om att vara typ ett av de- om inte det- bästa sättet att faktiskt skydda sig mot DDoS och liknande otrevligheter.

Förebygg framtida DDoS-attacker genom HTTP Access logganalys och IP-blockering

Alternativet brukar annars vara att man typ får gräva ned sig i loggfilerna och försöka identifiera IP-adresser som beter sig märkligt i HTTP Accessloggarna för att sen placera en IP-block för den typen av besökare i serverns brandvägg där hemsidan är hostad.

Men detta är också oftast något som upptäcks isf. och görs i efterhand vilket då brukar innebära att det är ”för sent” och skada redan kan ha skett.

När jag grävde i våra PHP-loggfiler för en plattformsbaserad hemsida så märkte vi att där genererades väldigt stora PHP loggfiler p.g.a. t ex. att PHP-version uppdaterats och vissa kodbitar för vissa tredjepartsmoduler osv. kanske inte var helt 100% anpassade vilket ledde till ofantligt många PHP notice osv. vilket kladdade ned hela PHP loggfilen och bidrog till enorma filstorlekar.

Det gick tillochmed så långt att filstorleken överskridit vad programmet jag brukar använda: TextPad – som jag btw varmt kan rekommendera för dig som arbetar i Windows miljö! – Klarade av att hantera, så hela datorn nästan hängde sig eller tog oändligt lång tid för att öppna filerna.

Splitta stora textfiler till flera mindre för att kunna öppna dem

Jag brukar samarbeta med erfarna utvecklare som stött på liknande problem tidigare och de tipsade mig då om GSplit och File Splitter tjänster/programvara, som är då designade att ta större textfiler, och dela upp dem i flera mindre textfiler.

När jag Googlade på det hittade jag även en StackOverflow tråd om hur man kunde åstadkomma detta med Git likaså.

Så istället för att ha en Loggfil på kanske 5 GB (ja det har hänt), så kunde man Splitta upp den i 5 filer om 1 GB per styck istället.

Vilket då underlättade i sin tur för TextPad att faktiskt klara av att öppna loggfilen.

Ett bra tips! För alla er som någon gång stött på liknande problem, där ni behövt ladda ned från FTP loggfilerna för att felsöka och analysera trafik eller felmeddelande för en hemsida och råkat ut för så stora filer att ni knappt kunnat öppna dem.

Kör ni via terminalen vilket många webbutvecklare kanske gör (om de har access) så kanske detta inte är ett lika stort problem, då det brukar finnas kraftfullare hanteringsmetoder via SSH och terminalkommando, jämfört med t ex. Windows OS GUI.

Men det är inte alltid man faktiskt har access till SSH och kanske måste undersöka loggfiler (om man ens har access till dessa) och då kanske man blir tvingad att använda t ex. FileZilla FTP klient för att ladda ned för att sen kunna undersöka och analysera i en vanlig texteditor på sin dator.

Superanvändbara Skärmklippsverktyget och Klipp & Skissa i Windows

24 september, 2024 av Trekka12·0 kommentarer

Flera gånger dagligen finner jag mig själv använda dessa två verktyg:

Skärmklippsverketyget
Klipp & Skissa

I skrivande stund på en dator med Windows 10 under mina arbetsdagar.

Det är ovärderliga verktyg som ersatte- för mig iaf.- PrtSc knappen på tangentbordet och mspaint (Microsoft Paint) genvägen för copy-paste och sen beskärningsredigering.

Screenshot hotkey tips

Om du vid något tillfälle skulle finna dig använde PrtSc knappen för att ta screenshot av något du önskar dela, ett tips – Använd ALT-knappen på tangentbordet för att begränsa en fler-skärms uppsättning till att bara ta en screenshot av den skärmen som just nu är aktiv.

Dela pedagogiska och precisa bilder med Windows Skärmklippsverktyget och Klipp & Skissa

De är verkligen supersmidiga verktyg i en webbutvecklares arbetsdag, kanske primärt p.g.a. deras funktion att markera valfritt screenshot-område sammankopplat med möjligheten att markera delar av screenshotten med röd eller annan färgad penna för tydlighet och pedagogik.

Effektivisera arbetsdagen och spara tid

Tyckte det var värt att lyfta de här såväl som liknande programvaror som kan effektivisera arbetsdagen och spara värdefull tid.

Användningsområden med dessa verktyg för mig själv inkluderar ofta att:

Ta screenshot via dem som sen automatiskt hamnar i urklipp för att kunna klistras in i Skype till partners
Såväl som i diverse chattapplikationer till kollegor
Eller e-post meddelanden

Värdefulla användningsområden för Skärmklippsverktyget och Klipp & Skissa

Eller bara för att spara ned för att ha som backup vid ändring man gör, eller för att dela designförslag, eller visa upp något man märkt.

Där finns många användbara och bra sätt att använda de här programmen i din arbetsdag.

Hur du använder programmen

Lyckades gräva fram en manual för Skärmklippsverktyget för både Windows 10 och 11.

Såväl som en PDF från Uppsala Seniornet.se som demonstrerar användning av Klipp & Skissa verktyget.

Parallell användning för ännu effektivare arbete

Har tillochmed märkt en fördel med att alternera användningen av de båda parallellt, då jag kanske använt den ena men ej har behovet/lusten att spara som en fil det jag fångat, däremot behöver jag fortfarande ha det uppe ibland under en period, och då kan det dyka upp nytt behov under denna period då jag hade behövt ta en ny screenshot.

Det är då här det andra programmet kommer in så jag kan alternera smidigt.

Lägga till inläggskategorier till WordPress inlägg via temafilsredigering med PHP

24 september, 2024 av Trekka12·0 kommentarer

Idag satt jag och kollade på den här hemsidans temafiler för när man öppnar ett inlägg så det är i fokus (single.php).

På den här hemsidan använder jag ett tema, som jag inte längre tror är så lätt att få tag i, som heter ”Flat”, detta då den här sidan skapades för ganska längesen och temat valdes när sidan skapades.

Tips för att skapa Child Theme för din WordPress sida

Hursomhaver, så har jag gjort ett Child Theme för sidan, med hjälp av det fantastiskt smidiga WP pluginnet WordPress Child Theme Configurator som man bör som best praxis, för att undvika ev. förlust av ändringar man gör vid temauppdatering i framtiden.

Ändra temafiler i WordPress

Som kanske många av er vet så är WordPress temafiler kodade med kodspråket: PHP, och det blir därför detta kodspråk vi kommer använda för att fixa in kategorier till mina inläggs temafiler.

Steg 1 – Hitta rätt temafil att börja gräva i för vart man behöver ändra

När man vill ändra filer från huvudtemat i sitt child theme så får man gå till Utseende > Filredigeraren i WordPress adminpanelen och bläddra fram uppe i högra hörnet originaltemat och dess filer.

Steg 2 – Inspektion av koden för att hitta vart man behöver ändra

När man väl har huvudtemats filer uppe så kan man inspektera hur koden ser ut för t ex. single.php som i vårt fall var relevant då jag ville ändra hur hemsidan presenteras när någon besöker ett specifikt inlägg på sidan.

Väl där inne möttes jag av följande kod:

Som ni kan se ovan så visar WordPress temaredigerare ”Enskilt inlägg” för min single.php.

Likaså kan ni se i själva koden get_template_part() WordPress funktionen som anropas som jag strukit under.

Denna funktion laddar in en annan template fil inuti den jag befinner mig i- och där koden är skriven (single.php i det här fallet).

I detta fall verkade temafilen content-single.php laddas in.

Steg 3 – Hitta koden vi behöver redigera

Så då letade jag upp denna för att inspektera hur den såg ut, då jag kunde se i single.php inte hade det jag ville komma åt att ändra – vilket i det här fallet var att lägga till kategorier intill mina taggar i slutet av inlägget.

Som vi kan se i ovan bild, så hittade jag det jag letade efter i content-single.php, nämligen DIV-elementet med class ”tags-links” som höll mina taggar i slutet av inlägg när besökt.

Remote FTP som alternativ för att enkelt arbeta med WordPress temafiler

Alternativ till ovan WordPress redigererare kan man ta fram hemsidans FTP via antingen FileZilla FTP client, eller någon form av Remote FTP som ex. den jag använder via min Notepad++.

Med Remote FTP behöver du bara:

”öppna” (ladda ned) filen efter du kopplat upp dig mot sidans FTP
Göra dina ändringar
Sen trycka CTRL + S för att spara (beroende på texteditor)

Därefter kommer ändringar automatiskt och direkt skickas upp till din hemsida så du kan se resultaten av din kod Live (på gott och ont).

Det kan dock vara bra att vara lite vaksam när man arbetar med Remote FTP, då session ibland kan disconnectas vid inaktivitet en längre tid.

Om det händer kan det hända att man behöver spara ändringarna i filen flera gånger, för att göra det kanske man behöver lägga till ”asd” eller annat godtyckligt så ens texteditor känner igen en ändring i filen för att tillåta omsparande, och kanske göra det 1-2 gånger. Så behöver jag iaf. göra i Notepad++ oftast vid disconnect.

Likaså kan det vara bra om man är flera som arbetar i samma filer att man håller lite koll på vem som sparar upp ändringar när och laddar ned filer de ska jobba i när, för det är lätt hänt att någon kan ha laddat ned samma fil som du vill jobba i tidigare, och gör ändringar i den för att sen synka upp till sidan, men när du laddar upp dina ändringar för den då äldre filen så skrivs deras ändringar över.

Detta extra viktigt att hålla koll på om man inte har Versionshantering via t ex. Git och GitHub eller liknande.

Kan varmt rekommendera Remote FTP för att göra temafilsändringar hellre än att hålla på att Ladda ned fil från t ex. FileZilla FTP klient, redigera, sen ladda upp manuellt.

Steg 4 – Redigera vår överskrivna temafil till så som vi vill ha det

Härifrån sen var nästa steg att skriva över denna content-single.php filen i mitt child theme.

Detta då jag ville göra egna ändringar till den för att komplettera hur den såg ut i nuläget för att forma hur inlägget ser ut till såsom jag ville ha det.

Steg 4.1 – Skapa override filen i vårt child theme

Så jag skapade content-single.php i samma mapp som mitt child theme (då temafilen inte låg inuti någon undermapp i huvudtemat).

Steg 4.2 – Kopiera över koden från huvudtemats temafil till override filen i child temat

Därefter kopierade jag koden från huvudtemats content-single.php fil till min nyskapade child theme content-single.php fil.

Steg 4.3 – Research för att ta reda på vad som behövs för att göra ändringar vi vill göra

Jag googlade lite för att hitta en WordPress funktion som det verkade som att andra tidigare använt för att göra det jag ville, get_the_category().

Steg 4.4 – Börja göra ändringarna och testa utfallet

Sen lade jag in en ny DIV-behållare för mina inläggskategorier och skapade inuti en foreach-loop för varje kategori så jag kunde formatera det i form av länkar som var klickbara.

Notera att detta basically bara är ”crude” test för att få det såsom jag vill. Exempelvis är ”Kategorier” inte kodat för flerspråkighet om man vill ha det, osv.

Jag hade också kunnat skippa flera echo statements och bara skrivit HTML-koden såsom resten av temafilen för övrigt var kodad. Men nu fick det bli såhär för just denna gång :)

PHP koden:

count(get_the_category())

Anropade jag bara för att testa om

Det gick att räkna antalet kategoriobjekt med count() i PHP, bara som en kontroll om WPTerm Array funkade som vanliga PHP-arrayer, för det är inte nödvändigtvis givet
Som förebyggande inför en viss typ av formatering jag först funderade på för sidan där jag tänkte ha kategorierna flödande utskrivna med komma-separerat emellan (förutom sista) vilket isf. hade kunnat fixas med en if-sats som kollade när loopen ej befann sig på sista och då skrev ut kommatecken i slutet efter länken för kategorin med hjälp av en counter-variabel i och med att vi använde oss av en foreach loop i just det här specifika fallet

Testa utfallet av anrop till ”nya” funktioner som man inte ännu är så bekant med genom printouts

Om man vill utforska mer i detalj returen från get_the_category() så hade man kunnat använda PHP’s var_dump() eller print_r() funktioner för att outputta returen på ett strukturerat och hyfsat lättläsligt vis på sidan för inspektion.

Tips för test på Live-sidor vid behov – fast som ej syns för besökare

Om man gör detta på en Live-sida kanske man inte vill att besökare ska kunna se att man håller på och testar, och då kan man istället ”wrappa” outputten i en style="display:none;" SPAN-tagg eller <pre>-block eller liknande.

Exempel:

<span style="display:none;">
   <?php echo print_r(get_the_category()); ?>
</span>

Hitta snabbt printout i koden med Google Inspector

Om man snabbt vill hitta det man outputtat i t ex. Google Code Inspector så hade man kunnat tilldela output elementet ett ID, en klass eller annat som är unikt på sidan så man via CTRL + F kommer direkt dit.

Steg 4.5 – Komplettera med CSS-Styling för utseende

Sen nästa steg att komplettera med lite CSS kod som ser ut som följer för att få det såsom jag ville ha det:

/*
* 24sept24
* */
.single-post div#cats-links {
   border-top: 1px solid #ccc;
   padding-top: 12px;
   margin-top: 40px;
   font-size: 14px;
}

.single-post div#cats-links a {
   color: #000;
   background-color: #eee;
   padding: 4px 10px;
   margin-right: 6px;
   margin-bottom: 6px;
   display: inline-block;
   padding-bottom: 1px;
   border: 1px solid #ccc;
}

.single-post .tags-links {
   font-size: 14px;
   margin-top: 10px !important;
}

.single-post .tags-links a {
   padding-bottom: 2px !important;
   border: 1px solid #ccc;
   color: #000;
}

.single-post #cats-links a:hover {
   background-color: #333;
   color: #fff;
}

Som ni kan se i ovan CSS-kod så har jag använt pixlar för måttenheter i just detta exempel av pedagogiska skäl då jag tycker det är lättast att förstå ”hur stort” det är, jämfört med relativa måttenheter som är baserade på annat mått procentuellt.

Inline-block som jag tilldelat till mina A-länktaggar är för att kunna applicera bl. a. margin-bottom då enbart inline-element inte tar det.

Färgkombinationerna var trial-and-error för att komma fram till, blev helt i extas när jag hittade kombon som är just nu som jag tyckte funkade alldeles utmärkt, jag kan tycka färgkombinationer är svårt och kräver ofta mycket experimenterande från min sida. Sen är ju smaken som baken också såklart.

Tips att använda ”failsafe” CSS-selektor för att begränsa CSS-kods applikationsområde

Ni kanske också märker jag lagt in en ”failsafe”-klass framför samtliga av mina regler jag lagt till mitt child themes ”Extra CSS”.

I just det här fallet för ”single-post”, vilket är en BODY-tagg klass som alltid finns när någon besöker ett inlägg på sidan, vilket garanterar att koden jag utformat enbart appliceras på just dessa sidor.

Kommentera datum/tid för ändring för kronologisk minneshjälp vid kodningsarbete

Notera också min kommentar med dagens datum i mitt speciella datumformat för CSS-tillskotten jag lade till, detta är mest för min egen skull för att ha ett hum om när vad tillkom i min CSS fil.

Jag upplever att det ger en form av kronologisk struktur som i kombination tillsammans med mitt eget minne skapar en tidslinje som kan hjälpa mig komma ihåg varför jag gjorde saker, när jag gjorde dem. Vilket kan vara ett vanligt förekommande problem att inte komma ihåg inom programmering osv. Därav kommentarer och deras funktion.

Ibland kompletterar jag även kommentaren om jag känner att det kan behövas, typ vid specialfix osv. Men i just det här fallet tyckte jag CSS-selektorer var ganska självförklarande och ansåg då det inte behövdes :)

För övrigt gillade jag designen med knapp-liknande klickbara både taggar och kategorier.

Visdom från UX guru Jakob Nielsens rekommendationer för mobilanvändare med touchscreen

Jag har alltid i bakhuvudet Jakob Nielsens UX best praxis rekommendation för mobilanvändare med att fingerblomman mätts upp till ca. 16x16px för klickytor på touchscreens, men i det här fallet gick jag faktiskt lite utanför denna rekommendationer och körde på mitt eget för att få något jag tyckte såg trevligt ut oavsett hur det var i förhållande till UX best praxis för mobil smartphone användare.

Kanske får justera för det i framtiden, men just nu får det vara som det är.

Såklart bör man alltid utveckla för att inkludera alla användare, eller åtminstone användare man riktar sig till och för att öppna upp för målgrupper, men ibland kan man göra temporära medvetna kompromisser i mån av brist av tid och prioritet i stunden.

I slutändan brukar man dock vid ett eller annat tillfälle komma tillbaka och fixa :)

CSS Filtreringsfunktion i Google Dev Tools / Google Inspector!

24 september, 2024 av Trekka12·0 kommentarer

Snubblade över en cool funktion i Google Inspector igår när jag satt och ville kolla upp vilket typsnitt Inleed.se använde, då jag tyckte deras typografi var väldigt stilren och lättläst.

Har tidigare missat denna funktion, filter-sökfältet är ganska diskret i Google Inspector.

Men så sjukt smidigt att kunna söka upp valfritt CSS-attribut man är intresserad av och letar efter istället för att slippa scrolla igenom alla CSS regler för ett specifikt HTML element på en hemsida.

Bra tips för dig som också sitter mycket och jobbar i Google Inspector och leker med CSS i realtid i webbläsaren via verktyget.

Introduktion till Mozilla Firebug och Google Developer Tools – för Smartare och Effektivare webbutveckling

29 maj, 2015 av Trekka12·0 kommentarer

Hej igen alla webbutvecklings entusiaster och fantaster :)

Jag ansåg att Mozilla Firebug och Google Developer tools behövde en ordentlig genomgång- och har därför beslutat mig för att skriva ett dedikerat inlägg till bara dessa. Men tanken med detta inlägg är att gå in på djupet i båda utvecklingsverktygen.

Vi kommer gå igenom dess gemensamma funktioner för både Mozilla’s Firebug såväl som Google’s Developer Tools – då båda verktygen är ganska lika funktionsmässigt. Vi kommer gå igenom alla funktioner jag har haft användning för själv vid tidigare webbutvecklings projekt, samt sådana som folk visat ett intresse för att lära sig. Tror vissa av funktionerna kan vara speciellt främjande för er som precis börjat med webbutveckling och går någon data/it linje på gymnasiet. Dessa utvecklingsverktygen kommer underlätta er felsökning, stiländrings testning, prototype utveckling m.m. betydligt!

Poängen med dessa verktyg?

Poängen med både Firebug såväl som Developer Tools är att effektivisera och underlätta webbutvecklingsprocessen genom att direkt i webbläsaren, kunna erbjuda dig som utvecklare möjligheten att redigera och granska både HTML-kod, CSS-kod samt JavaScript/jQuery kod (man kan testköra javascript funktioner och liknande via en konsollruta i verktygen).

Granskning av komponenter (element) på en webbsida i realtid

Granskningen av komponenter på en webbsida låter dig avgöra hur webbläsaren tolkat och presenterat din webbutvecklings-kod, såväl som ger dig möjlighet att komma åt varje enstaka komponents/elements CSS-stilar i högerspalten. Se bild nedan:

Printscreen där CSS-stilarna visas i både Mozilla firebug såväl som Google Dev tools

CSS-stilarna visade i både Mozilla firebug såväl som Google Dev tools

Dessa stilar är mycket enkla att modifiera/ändra, och när du gör detta, så kommer dina ändringar att direkt visas i själva webbläsarfönstret! Detta banar väg för en ofattbart användbar och efterfrågad/smart funktion som underlättar och snabbar upp många uppgifter en webbutvecklare måste ta sig an.

Några av dessa skulle t ex. kunna vara att kunna testköra CSS-kod/HTML-kodändringar såväl som JS-Funktioner, m.m. – direkt i webbläsaren för ens webbsida.

Alternativa sätt att förhandsgranska kodändringar och nackdelar med dessa

Alternativt sätt annars att förhandsgranska kodändringar på hade ju varit t ex. att behöva ändra i CSS/HTML/JavaScripts faktiska kods dokumenten som sen dessutom även hade behövts sparas innan ändringarna skulle vara möjliga att förhandsgranska och eventuell laddas upp till en server/webbhotell beroende på vilken kod man jobbar med, och även då så hade det funnits risk i värsta fall att man hade behövt rensa cachen i webbläsaren (via t ex. [Ctrl + Shift + R] / [Ctrl + F5] / [Ctrl + R] – olika hotkeys för olika webbläsare/inställningar) för att vara på den säkra sidan att ändringarna verkligen visas såsom man kodade dem senast.

Rensning av cachen i webbläsaren kan behövas ibland har jag själv märkt då ändringar som gjorts och sparats i filerna inte verkar synas när man förhandsgranskar sidan direkt efter, utan de kommer efter en fördröjning, vad orsaken till detta är är jag dessvärre inte helt säker på. Då ger rensning av webbläsare-cachen en grundlig ”reload” av webbsidan UTAN att ta hjälp av cachat material som annars kan förvirra och ge bilden av att inga ändringar gjorts, fastän de faktiska har blivit genomförda!

Rensning av cachen är det allra bästa sättet att försäkra sig på att inget sedan tidigare nedsparad kod påverkar resultatet av webbsidan man förhandsgranskar i stunden.

Eventuella nackdelar med att jobba i Firebug/Google Dev tools värda att vara uppmärksam på

Några saker man bör vara uppmärksam på är när man sitter och gör de här bekväma ändringarna i Mozilla Firebug och Google Developer tools, är det lätt att bli ”för bekväm”, vilket ibland har hänt mig och lett till att jag helt plötsligt nästan tagit fram en helt ny stylesheet till en webbsida. När man har använt sig så pass mycket utav verktygen och gjort så pass många olika ändringar i verktygen så bör man vara väldigt försiktig med att klicka fel, eller råka uppdatera sidan man jobbat på – för så fort man gör detta, så försvinner alla ändringar om du själv inte har manuellt sparat undan dem allteftersom (vilket jag inte gjorde de första gångerna tyvärr ;p).

Detsamma gäller om sidan har en automatisk uppdateringstimer, eller om du skulle råka trycka på en källkodslänk som tar dig till en annan undersida, även då brukar stiländringar och kodändringar man gjort försvinna. Detta händer mest troligt då alla ändringar endast görs flyktigt och inte sparas i de faktiska filerna när man gör det.

Fördelarna som ges av att jobba med Firebug och Google Dev tools är överlägsna över nackdelarna

CSS-ändrings test och experimentation som man kan genomföra direkt i webbläsaren är definitivt guld värt och en av de främsta anledningarna till varför det är lönt att ta sig tiden att bättre sätta sig in i verktygen Firebug och Developer Tools.

Och det är då enbart en av de många fina funktionerna som verktygen erbjuder!

Hur kommer man då åt Mozilla Firebug och Google Developer tools i webbläsaren?

För att komma åt verktygen i webbläsaren på en viss webbsida så kan du göra som jag själv brukar göra med enkelhet – bara högerklicka på sidan på ett valfritt ställe (jag brukar sikta in mig på specifika element på sidan, så förflyttas jag direkt till det elementet i källkoden när verktyget öppnas), och därefter välja t ex. ”Granska komponent” som det heter i Google Chrome, medan Firefox säger något liknande som ”Granska komponent i Firebug”. Se bild nedan som demonstrerar detta:

Öppna Google Developer tools via webbläsaren

Verktygets gränssnitt och dess placering i webbläsaren efter aktivering

När du väl öppnat upp respektive verktyg kommer dess interface/gränssnitt att visas i botten av din webbläsare som en integrerad panel (såvida du inte ändrat något i webbläsarens standard-inställningar) som kan expanderas både uppåt såväl som reduceras nedåt.

Möjlighet finns att förflytta panelerna till höger/vänster sida av skärmen/webbläsaren, eller bryta loss panelen från webbläsaren till sitt eget webbläsarfönster helt och hållet om detta är en bättre lämpad placering för just hur ni föredrar att arbeta. Ändring av panelplacering brukar i Google Dev tools kunna göras via en knapp uppe i högra hörnet av panelen som liknar två skärmar placerade ovanpå varandra.

Panelen består annars av flikar med olika möjligheter och funktioner att nyttja för olika typer av granskning och analys av webbsidan, dess komponent(er) och koden som bygger upp den. Alla ändringar genomförs omedelbart i realtid, vilket jag personligen tycker är riktigt häftigt och väldigt användbart ;)

Redigera HTML-kod med Mozilla Firebug och Google Dev tools

Under flik-alternativen, till vänster har vi som standard HTML-koden placerad (d.v.s. om du t ex. öppnade panelen och verktyget genom högerklick och granska komponent) och för att kunna redigera och genomföra ändringar i koden här (oroa dig inte, ändringarna genomförs inte på din vanliga webbsida, bara i webbläsare-versionen av din webbsida) så högerklickar ni på den tagg/element som omfamnar det område du önskar redigera och väljer ”Edit HTML”/”Redigera HTML” eller liknande. Se bild nedan för Google Dev tools, respektive Mozilla firebug:

Redigera HTML-kod via t ex. Google Dev tools

Redigera CSS-stilmalls kod i Mozilla Firebug och Google Dev tools

Ni har redan sett vart CSS-stilarna för element på sidan placeras i panelen i ovan printscreen – På höger sida av panelen kommer ni sen kunna se CSS-koden för vilket HTML-element som än har blivit markerat!

Högerspalten där CSS-koden står skriven brukar kunna scrollas ned ganska mycket- även om element inte fått tilldelat så många stilar av just dig, detta är för att verktygen även visar upp webbläsarstilar, såväl som andra stilmalls-koder du må använt för att ”normalisera” och eller övrigt påverka din webbsida och fixa kompatibilitets stöd för t ex. CSS3 kod som ännu inte stöds i alla webbläsare.

Med ”normalisering” menar jag en s.k. ”reset”/återställning av samtliga CSS-element till en fastställd standard att kunna utgå från UTAN de standardstilar som normalt sett gäller för HTML-elementen – typ som default-padding (standard utfyllnad av element), default-margins (standard marginaler/avstånd till andra element), standard typsnitt, teckenstorlek, etc. etc.

Du bör dock kunna se CSS-stilarna som du själv lagt till för ett element – oftast är dessa placerade överst, du har även möjlighet att direkt där i panelens del för CSS-kod kunna lägga till nya egna regler som direkt appliceras ovanpå webbsidan du granskar i verktyget. Detta är en väldigt kraftfull funktion som jag själv brukar använda för att testa nya stilar, och sen bara kopiera in i själva CSS-mallen när jag väl är nöjd med dem – går så mycket fortare och är så mycket lättare än att ständigt spara om och förhandsgranska på nytt.

Tips för snabbare redigering av CSS-stilarna i Mozilla firebug/Google Dev tools

Verktygen har möjlighet till en typ av ”tabb-navigering” mellan CSS-attribut och attributvärde, vilket underlättar och snabbar upp skrivandet av CSS-stilar i CSS-panelen.

Alla stilmalls koderna i högerspalten kan ändras och längst ned i CSS-panelen kan man även se hur CSS-marginaler, borders såväl som padding har blivit applicerat på elementet du har markerat för att se CSS-stilar för.

För att redigera CSS-stilarna i verktyget kan det dock vara behjälpligt att sedan tidigare ha studerat CSS-kodning så man har en hyfsat god uppfattning om det, och kan skriva lite kod på egen hand. Annars finns det gott om guider och manualer ute på nätet att hämta inspiration och vägledning från.

Jag kommer även skriva inlägg om CSS-kodning senare framöver som i detalj kommer gå igenom de delar jag själv anser vara viktiga att känna till och kunna hantera.

Lägga till fler attribut för ett redan existerande CSS-kodblock

För att göra detta kan man placera sig med musen på ett av de redan existerande attributen och sen bara fortsätta att [Tabb]:a vidare tills man kommer till det sista attributet och dess attributvärde, därefter tabbar man bara en gång till för att inleda skapandet av ett nytt attribut + attributvärde! Väldigt enkelt, och väldigt användbart ;)

Lägga till nya CSS-regler/kodblock för sidan med Mozilla Firebug/Google Dev tools

Det brukar finnas en knapp i CSS-kods panelen som heter ”Lägg till ny regel” eller något i den stilen, trycker man på denne så läggs en ny CSS-regel till, som brukar basera den nya CSS-regeln på HTML-elementet man hade markerat till vänster om CSS-panelen i HTML-panelen. Knappen brukar vara placerad ovanför det översta CSS-kodblocket i CSS-panelen i Mozilla Firebug och Google Dev tools.

Lägga till en ny CSS-regel för sidan via Google Developer tools

JavaScript konsolfliken

Verktygen har ytterligare en funktion som många tycker är väldigt användbar, och det är Mozilla Firebug respektive Google Developer Tools ”Console Window” / Konsolruta. I denna kan man kalla på- och testköra JavaScript funktioner som finns tillgängliga i sidans redan inladdade JavaScript kod. Men även skapa egna funktioner direkt i console-fönstret. Väldigt användbart för realtids debugging av ens JavaScript kod.

Testkör JavaScript konsolfönstret i Mozilla Firebug och Google Dev tools

För att testa detta kan ni gå till fliken kallad ”Console” eller liknande, och där längst nere för den fliken, ser ni en ”>”-större-än tecken som vid tryck efter detta tecken- man ges möjligheten att skriva in egna kommandon och egen JavaScript kod.

För att bara testa så det funkar kan ni skriva in följande efter ”>”-större-än tecknet:

console.log("Detta är ett console.log meddelande jag själv skriver för att testa Mozilla Firebug/Google Developer Tools JS-konsoll funktion");

Och tryck sedan [ENTER] för att se console.log-meddelandet dyka upp i logg-listan ovanför fältet där ni skrev in koden. Se bild nedan:

Console.log testmeddelande för Google Developer tools

Det kan hända här att webbläsartillägg som använder JavaScript skriver ut sina felmeddelande här – detta är en annan anledning varför konsolfunktionen är så användbar – så länge man har den öppen när man laddar en sida får man se om där finns några JavaScript felmeddelande för sidan (dessvärre verkar som sagt då även webbläsartilläggs felmeddelande komma med – men det kan då ses vilka felmeddelande som hör till webbläsartilläggen längst ut till höger där det står rad och fil som felmeddelandet hör till).

Direktlänkade klickbara filnamn och rader för vart felmeddelandena kom ifrån

Filnamnet och raden för vart felmeddelandet kommer från som syns längst till höger är klickbart och vid klick tar er till den exakta raden för JavaScript filen för webbsidan där felmeddelandet kom från.

Console.log populär JavaScript felsöknings funktion – bra och lätt att använda för test

Console.log som jag använde ovan för att demonstrera hur man kunde använda konsolfunktionen i verktygen är en ”debugging-funktion” som existerar i JavaScript som är ganska populär och behändig att använda sig av för enkel felsöknings utskrift :)

Rensa konsolfönstrets felmeddelande logg

Om man har mycket felmeddelande som man vet är ”onödiga”, så kan man trycka på den lilla ikonen högst upp i vänster hörn för konsolpanelen som liknar en cirkel med ett snett streck igenom, denne knapp rensar då hela felmeddelande loggen.

Användbar sökfunktion tillgänglig för att med enkelhet kunna identifiera specifika element för webbsidan

Båda verktygen har en inbyggd ”sökfunktion” där man i Google Developer Tools kommer åt denne genom att klicka på ett ganska litet (ser ut som ungefär 16×16 / 32×32 pixlar litet) förstoringsglas som är placerat högst upp i panelen till vänster, ganska svår att missa, medan i Mozilla Firebug den ser ut som en muspekare som klickar på en ”rektangulär ruta” – även denne högst upp till vänster i själva verktygspanelen, placerad bredvid Firebug-ikonen (till höger om den).

När ni har klickat på denna ”sök-ikon” så kan ni sedan dra musen till ett område på er webbsida (inte koden i Firebug/Google Developer Tools panelen – utan själva webbsidan och dess element i sig självt), och ni kommer förmodligen se en typ av ”highlight” att området ni håller musen över lyses upp och visar information om området, för att sedan markera detta område är det bara att klicka där ni håller musen, så kommer ni att direkt bli vidareskickade till det området ni markerade på själva hemsidan- i koden som finns tillgänglig i verktygets HTML-kods panel.

Se bild nedan för hur detta ser ut i Google Developer tools:

Demonstration av Google Developer tools sökfunktion

Detta är väldigt användbart för att hitta t ex. CSS-stilar eller förstå uppbyggnaden av HTML-element för någon annans webbsida snabbt och enkelt – såväl som för att kunna lägga till egna stilar för ett element för skoj skull ;)

Kreativ användning av Mozilla Firebug och Google Developer tools

Skräddarsy vilken webbsida ni än besöker utefter era egna preferenser utan problem!

En rolig sak som inte nödvändigt vis är för webbutvecklingssyfte är att ni själva kan skräddarsy vilken webbsida ni än besöker utefter era egna preferenser. Super användbart!

Besöker ni en sida där utvecklaren eller designern har valt att skriva texten med ett horribelt typsnitt? Inga problem, det kan vi enkelt råda bot på genom att identifiera elementen via Mozilla Firebug/Google Developer tools, som påverkas av typsnittet, och hitta roten i CSS-koden för vart typsnittet blir applicerat till dessa elementen, därefter kan vi gå in i CSS-panelen och manipulera/ändra attributvärdet till den font vi själva tycker känns trevligast att läsa på skärmen – vi kan till och med hämta in typsnitt från Google Web Fonts utan större problem (kan dock kräva lite extra ändring i CSS-panelen, eller i HTML-panelen för inhämtning av specifik font till sidan innan den kan användas).

Det är jätteroligt och kreativt att kunna använda verktygen på detta sätt :D Själv tycker jag det har hjälpt mig flertalet gånger då vissa webbsidor haft (enligt min åsikt) för liten typsnitts storlek – då har jag utan problem kunnat ändra det till en större storlek på samma sätt som jag beskrev i ovan stycke.

Gillar du inte färgerna på en webbsida? Gå in och ändra färgkoderna för specifika element, även det är enkelt :)

Allt detta, och mycket mycket mer kan göras med dessa verktygen, det är riktigt awesome :)

Praktiskt exempel av detta

Jag var tidigare inne på en sida hos WordPress Codex och kollade kommentarer folk hade publicerat till ett område, och ville då själv testa (lite i webbutvecklings syfte) hur det skulle se ut om inga s.k. ”avatars” visade sig till vänster om/bredvid kommentatorernas namn, så jag använde sökfunktionen i Google Developer Tools, klickade på profilbilden/avataren och gick sedan till CSS-koden och lade till ett nytt attribut kallat ”display: none;” vilket i princip ”tar bort” ett HTML-element från layouten av webbsidan – trots att elementet ligger kvar i koden (mer om detta i senare inlägg om CSS-kodning). Och då försvann samtliga profilbilder/avatars och jag kunde då se hur det skulle sett ut om de valde att ta bort det (eller i mitt fall- hur jag villa ha mina egna kommentarer presenterade för denna WordPress sidan ).

Slutkläm

Hoppas ni hade lika roligt som mig med det här inlägget, funderar på att eventuellt publicera ”kortfilmer” i framtiden där jag via korta filmsnuttar demonstrerar ovan genomgångna funktioner såväl som nya kanske? Om detta hade varit något av intresse :)

Tills nästa inlägg- :)