Det viste sig at de flere steder brugte OR i deres WHERE clauses. Hvilket var det første problem.
Mens en OR i en SELECT eller CASE clause ikke er noget stort problem, er det generelt ikke en god idé at have OR i din WHERE clause. Dette fordi en OR resulterer i at der laves et fuldt tablescan.

Lad os prøve at se på det konkrete eksempel jeg havde ude hos kunden, for at se hvordan vi kan gøre det bedre.

Nedenstående rå SQL query tager mig over 30 sekunder at eksekvere på min database gennem SQL Server Management Studio (SSMS):

SELECT *
FROM GetCustomerPurchases_View
WHERE (
         CardIdentification IN ('ABC', 'DEF', 'JKL', 'ASD')
         OR CustomerId = 123
      )
      AND PurchaseTime > '2021-11-17 00:00:00'
      AND CardIdentification IS NOT NULL

Ændrer jeg koden til at bruge UNION i stedet for OR, vil den resulterende SQL query komme til at se således ud:

SELECT *
FROM GetCustomerPurchases_View
WHERE CardIdentification IN ('ABC', 'DEF', 'JKL', 'ASD')
      AND PurchaseTime > '2021-11-17 00:00:00'
UNION
SELECT *
FROM GetCustomerPurchases_View
WHERE CustomerId = 123
      AND PurchaseTime > '2021-11-17 00:00:00'
      AND CardIdentification IS NOT NULL

Når jeg har lavet query om til at bruge UNION i stedet for OR, tager det mig under et sekund at eksekvere min query, og jeg får det samme datasæt tilbage.

Hvorfor er querien med UNION hurtigere end OR?

Som nævnt tidligere, resulterer en OR i vores WHERE clause, at der bliver lavet et fuldt tablescan. Men med UNION får SQL Server i stedet lov til at lave en eksekutionplan hvor den vælger den optimale strategi for de enkelte subqueries, inden der bliver lavet UNION på datasættene fra vores subqueries. Dette kan resultere i nogle meget hurtigere subqueries, og af hvad jeg har erfaret, er det konsekvent hurtigere end et fuldt tablescan.

Da kunden kører med EntityFramework skulle vi have implenteret vores query som

At få det implementeret i rå SQL som LINQ var dog straks sværere.

Et intuitivt første forsøg ville være at gøre som herunder, hvor vi blot omskriver vores SQL query til LINQ:

var listWithCustomerPurchases = context.GetCustomerPurchases_View
   .Where(x =>
      cardIdentificationList.Contains(x.CardIdentification)
      && x.PurchaseTime >= cutOffDate)
   .Union(
      context.GetCustomerPurchases_View
      .Where(x =>
         x.CustomerId == Customer_Id 
         && x.PurchaseTime >= cutOffDate
         && x.CardIdentification != null)
      )
   .ToList();

Men i det konkrete eksempel ude hos kunden, resulterede det i at vi nu stadig fik et uønsket OR i vores SQL statement fra LINQ:

SELECT *
FROM [GetCustomerPurchases_View] AS [Extent1]
WHERE (
   ([Extent1].[CustomerId] = @p__linq__0) 
   OR (([Extent1].[CustomerId] IS NULL) AND (@p__linq__0 IS NULL))
) 
AND ([Extent1].[PurchaseTime] >= @p__linq__1) 
AND ([Extent1].[CardIdentification] IS NOT NULL)
@p__linq__0=13213;@p__linq__1=65465

Dette uønskede OR kom fra at LINQ kunne se at vores Customer_Id kunne være NULL.

Så, for at fjerne vores uønskede OR, skal vi sikre os at Customer_Id ikke kan være NULL. Ude hos kudnen gjorde vi det helt konkret ved at tjekke for om Customer_Id er NULL, og hvis ikke, tage value fra denne over i en variable som ikke er nullable.

Denne løsning ses implementeret herunder

var query = context.GetCustomerPurchases_View
   .Where(x =>
      cardIdentificationList.Contains(x.CardIdentification)
      && x.PurchaseTime >= cutOffDate);

if(Customer_Id .HasValue){
   var customerIdLong = Customer_Id.Value;

   var queryWithCustomerIds = context.GetCustomerPurchases_View
      .Where(x =>
         x.CustomerId== customerIdLong 
         && x.PurchaseTime >= cutOffDate
         && x.CardIdentification != null);
      )
   query = query.Union(queryWithCustomerIds);
}

var listWithCustomerPurchases = query.ToList();

Nu hvor jeg kun laver union når jeg ved at Customer_Id ikke er null, kommer den resulterende SQL til at se ud om vi ønsker den.

SELECT *
FROM [GetCustomerPurchases_View] AS [Extent1]
WHERE ([Extent1].[CustomerId] = @p__linq__0) 
AND ([Extent1].[PurchaseTime] >= @p__linq__1) 
AND ([Extent1].[CardIdentification] IS NOT NULL)
@p__linq__0=13213;@p__linq__1=65465

Det har også den øgede bonus at querien er endnu hurtigere hvis Customer_Id rent faktisk er NULL, da der så er lidt mindre at checke for vores WHERE clause.

SELECT *
FROM [GetCustomerPurchases_View] AS [Extent1]
WHERE ([Extent1].[PurchaseTime] >= @p__linq__0)
AND ([Extent1].[CardIdentification] IS NOT NULL)
@p__linq__0=65465

Siden 2018 har mine kollegaer, især de der har deres primære fokus på C#, snakket meget om Blazor, hvor vildt det var og at det skulle være fremtiden for frontend-udvikling.

Jeg må indrømme, at jeg altid har været skeptisk. Da jeg først hørte om det var alle mine associationer knyttet til Razor pages fra ASP.NET, som jeg ikke havde de bedste erfaringer med. Hvis man gerne ville have den typestærke tilgang, hvorfor ikke bare bruge Typescript. Hvad er problemet i at snakke med et GraphQL API gennem en JS klient?

Hvis du har det som jeg, er du kommet til det rette sted. I det følgende vil jeg forsøge at redegøre for hvilke dele af Blazor hypen der kan retfærdiggøres, og hvor jeg tror evangelisterne tager fejl, samt hvor vi som skeptikere måske har misforstået Blazor.

Det bliver ikke en lang gennemgang, men jeg linker løbende videre til en del kilder hvis du er interesseret i at lære mere.

Blazor udnytter introduktionen af WebAssembly (WASM) i 2015, til at muliggøre eksekvering af C# på klient-siden af en webapplikation.

Blazor er et frontend framework for SPA (Single-Page Applikation), som bruger C# som fullstack. Blazor gør det dermed muligt at skrive klient-side applikations-kode i C#, uden at skulle gøre brug af JavaScript, som du ellers ville gøre det med jQuery, Angular, React og lignende. Tanken er at Blazor i din webapplikation skal erstatte disse JS-frameworks.

Kombineret med en .NET Core backend, muliggør det at have .NET kode end-to-end. En .NET backend udvikler bliver pludselig en fullstack udvikler, i stand til også at skrive klient-koden i webapplikationen.

Der er som udgangspunkt to udgaver af Blazor. Der er den server-side renderede udgave, og så er der den klient-side renderede. Hver har sine fordele og ulemper, men fordelen ved dem begge er at det er samme kode, der bruges begge steder.

Ved server-side rendering sendes alle UI ændringer fra serveren til browseren via SignalR. På den klient-renderede udgave, sendes DLL’er til klienten, som så renderes af dotnet.wasm. Klientudgaven (WebAssembly udgaven) er hvad vi bedst kan sammenligne med moderne JS frameworks så som Angular & React.

Debugging af koden kan ofte være en stor del af arbejdet. Derfor er det også meget relevant for os at se på hvordan den oplevelse egentligt vil være i Blazor i forhold til traditionel frontend (JavaScript).

Med frameworks som Angular & React vil en stor del af debugging oplevelsen foregå direkte i browseren med de indbyggede værktøjer der er at finde her. Det er også muligt at debugge direkte i browseren med Blazor, men det kræver lidt ekstra opsætning, og er ikke en lige så lækker oplevelse som det er det for JavaScript/TypeScript. En uddybende gennemgang af hvordan debugging af Blazor fungerer kan findes på StackOverflow.

Blazor introducerer, sammen med WebAssembly, et nyt paradigmeskifte for den måde vi tænker frontendudvikling.

• Gør det muligt at eksekvere C# i din frontend
  • Bryder JS monopolet på frontend
  • Hvis du allerede kender C# har du lynhurtigt også en frontend, uden at du behøver være programmerings polyglot
• Hurtig udvikling, kort Time To Market
  • Det er nemt for en enkelt udvikler at producere både frontend og backend, og sende begge dele til produktionsserveren 
• Baseret på WebAssembly
  • Muligt at dele forretningslogik & validering i både front og backend
• .NET IL har potentialet for at være hurtigere end JavaScript kode. Dette kan gøre Blazor til det foretrukne værktøj ved udvikling af spil og andre performance-afhængige applikationer
• Hvis du ikke er glad for WPF, kan du forholdsvist nemt bruge Blazor sammen med WPF i .NET6
• Blazor applikationer er natively stateful
• Samme kodebase for web, desktop & mobil
• Samme kodebase for WPA, native & hybride cross-platform apps

Desværre kommer Blazor ikke uden sine egne udfordringer. 

• Blazor kan ikke arbejde med DOM elementerne direkte. Derfor vil der fra tid til anden være brug for JavaScript Interop, til at udfylde de huller denne manglende funktionalitet resulterer i. Det er derfor i mange tilfælde ikke muligt helt at droppe javascript.
• Blazor er i øjeblikket (2021) langsommere end JavaScript. Microsoft har dog en god track record i forhold til performance optimeringer, så dette skulle gerne være et mindre problem på længere sigt
• Debugging er ikke en lige så god oplevelse som  den er det ved etablerede JS frameworks.

Alt efter hvilken renderings-tilgang du bruger, har de også hver deres ulemper.

• Stor payload.
  • Ud over at skulle downloade applikationens WASM og .NET biblioteker til browseren, skal Mono.wasm også hentes ned. 
  • En “Hello World” applikation har en payload på ca. 1Mb i .NET 6, men det løber efter sigende hurtigt op i 5-6Mb når man først har en færdig applikation. Nogle melder om +10Mb.
  • 1Mb for en “Hello World” applikation er meget når man sammenligner med størrelsen på andre frontend frameworks: https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1
  • Lazy loading kan løse lidt af disse problemer, men det er stadig noget begrænset og omstændigt

• Kræver konstant adgang til backend.
  • Hvis forbindelsen brydes, stopper applikationen med at virke, indtil forbindelse kan genetableres
  • Hvis serveren genstartes, vil applikationen stoppe med at virke og state tabes 
• Svært at skalere, klienten vil kun fungere med den server som gemmer dens state. Kan løses med Sticky Sessions i SignalR
• Ikke muligt at lave til en PWA
• Introducerer en del crosstalk frem og tilbage mellem klient og server. Kan give store problemer hvis responstid er høj / hvis du er en mobil-bruger

Med ulemperne ved henholdsvis klient-rendering og serverside-rendering, kan det være svært at finde det oplagte sted at bruge Blazor. Især hvis man er afhængig af at applikationen starter hurtigt op.

Det er dog muligt at køre en hybrid af de to renderinger, ved at køre en hybrid løsning. Sergey Zaikin har lavet en gennemgang af hvordan han formåede at løse denne hybrid Blazor opsætning i et demoprojekt.

Blazor er et stærkt værktøj, i den rette usecase.

Som landskabet for Blazor ser ud lige nu, er Blazor rigtigt stærkt hvis du laver enterprise applikationer, hvor du er sikker på at dine brugere altid tilgår applikationen med en computer. Hvis dine brugere bruger mobile enheder, skal du være villig enten til at:

• Lade dine brugere vente et stykke tid på at applikationen er indlæst (WASM)
• Acceptere at applikationen ikke kan virke offline (ServerSide)

Blazor viser rigtigt sine styrker når der er tale om at størstedelen af applikationen består af CRUD operationer mod en .NET backend. Især fordi man så har muligheden for at dele forretningslogik mellem backend og frontend gennem webassembly. Denne centralisering af fx valideringslogik gør det noget nemmere at vedligeholde komplekse forretningsgange.

I fremtiden vil payload på download af mono.wasm, .NET DLL’er samt applikationens DLL’s blive mindre og mindre. Vi har allerede set dette da vi gik fra .NET core til .NET5. Og .NET6 ser også ud til at give massive performance forbedringer.

Hvis  Blazor skal blive bredt accepteret som en platform for webudvikling, er der dog stadig et behov for nedbringelse af payload. Det er en hård konkurrence at skulle kæmpe med JavaScript, når JavaScript eksekverer direkte i browseren, uden at være afhængige af at skulle køre ovenpå en runtime skrevet i WebAssembly (som skal hentes ned som det allerførste i applikationens levetid).

Jeg kan ikke forestille mig en fremtid hvor Blazor erstatter JavaScript. Blazor vil derimod sikkert blive som så mange andre frameworks, biblioteker og værktøjer. Nogle vil undgå det, andre vil omfavne det. Uagtet vil internettet forsætte sin vante udvikling, præcis som vi har set det med udviklingen af de forskellige JavaScript frameworks.

Hvis du ønsker at lære mere om Blazor, kan du finde links til yderligere læsning samt referencer til demoprojekter på Awesome Blazor‘s git repo.

Det er først vigtigt at sige, at en af de største syndere i forhold til en langsomt WordPress hjemmeside, er det brugte tema. Du kan gøre mange ting i forhold til optimering og forskellige plugins, men hvis dit tema generelt er langsomt og/eller er meget afhængigt af javascript for bare at vise de mest simple ting, er der desværre lang vej til en hurtig hjemmeside. Mit tema er ikke det hurtigste, og der er ting som kunne optimeres fra forfatterens side. Men dette skal ikke stoppe os i at gøre det så godt som vi nu engang kan.

Der findes mange muligheder for at tilkøbe sig optimering af ens hjemmeside. Især ved optimering og levering af billeder er der mange muligheder for at betale for en færdig løsning. Jeg har i det følgende gjort en dyd ud af kun at finde gratis løsninger.

Med blot 2 plugins kan du komme UTROLIGT langt i forhold til at optimere din hjemmeside. Om ikke andet, så vil jeg på det kraftigste anbefale at du får installeret de to følgende plugins.

W3 Total Cache

Den første her er W3 Total Cahce, det nok vigtigste plugin. Pluginnet kan en masse, men de vigtigste funktioner er for mig at se de følgende:

Page Cache

Denne funktion er den nok vigtigste funktion i dette plugin. Det forsøger at lave alle dine sider om til statiske sider. Dette betyder at i stedet for at skulle spørge databasen om hvilket indhold der skal vises, og derefter begynde at “tegne” den enkelte side, gemmes en forud genereret side på serveren. Når en bruger så skal se en side på din hjemmeside, hentes denne forud-genererede side frem. Markant bedre end at hjemmesiden skal på arbejde for at genere siden forfra. Dette plugin alene kan spare oceaner af tid for dine brugere, og ressourcer på din server. Mindre arbejde til serveren = hurtigere svartider, samt at serveren kan håndtere flere samtidige brugere.

W3 Total Cache – page cache

Browser Cache

Browser cache sørger for at din hjemmesides ressourcer gemmes lokalt i den enkelte brugers browser. Dette sikrer at dine brugere henter så lidt data fra serveren som muligt, og i stedet hele tiden tjekker browserens cahce for om data allerede er hentet og ligger lokalt.

W3 Total Cache – browser cache

Der er mange andre ting man kan sætte op i W3 Total Cache, men disse to funktioner er de to jeg har fundet altid virker, og har en stor indvirkning på hjemmesiden. Et dybere dyk i alle de indstillinger der er for W3 Total Cache, kan findes hos premium.wpmudev.org. Her går de virkeligt i dybden med de enkelte dele.

Autoptimize

Hjemmesider er bygget op af en masse henvisninger. Hvert billede kræver fx. et ny forespørgsel til serveren. En stor del af ventetiden på hjemmesiderne, er de mange forespørgsler til serveren, men det er ikke kun de tunge billeder der er problemet her. Hvis din hjemmeside gør brug af flere forskellige stylesheets og javascript filer, skal disse hentes hver for sig. Det tager tid. Auoptimize hjælper på dette problem. Den gennemløber din hjemmesider og finder henholdsvis alle javascript filerne og alle stylesheet (CSS) filerne. Når disse er fundet, samler den alle javascript filerne i én fil, komprimerer denne fil (minimize), og udstiller denne. Det samme sker for CSS filerne. I stedet for en masse refernecer, er der kun kun 2 små tilbage. Dette hjælper også en del på hastigheden.

W3 Total Cache er i princippet i stand til at komprimere (minimize) javascript og stylesheets. Men jeg har personligt ikke gode erfaringer W3 Total Cache her, og Autoptimize lade til (for mig) at virker bedre og generelt gøre et bedre job.

Op imod 75% af de data bliver leveret fra hjemmesider verden over er billeder. Det er en meget stor del af din hjemmeside, så kan vi optimere hvor hurtigt billederne bliver leveret til brugerne, kan vi drastisk optimere på hastigheden af vores hjemmesider.

Det første step du kan gøre for at optimere leveringen af dine billeder, er at gøre dem mindre. Dette kan både gøres ved at ændre på størrelsen af billederne, så du ikke leverer et billede der er 1200px bredt hvis browseren bagefter gør billedet mindre så det kun fylder 600px. En halvering af bredden kan give dig et billede der kun fylder 25% af originalen.

Ud over at ændre på størrelsen af dine billeder kan du også ændre lidt på kvaliteten. Som det ses på billedet herunder kan der være mange KB data at hente ved blot at reducere størrelsen på et billede en smule.

Lossy Compression Ratios

Til at gøre mine billeder mindre bruger jeg EWWW Image Optimizer. Det er dejligt fleksibelt, relativt overskueligt, og har meget funktionalitet med sig. Dertil er deres Pixel Perfect komprimering virkeligt god til at fjerne data fra billederne uden at man rigtigt kan se det på det endelige resultat.

Nogle gange kan du også få en del ud af at skifte billedformat. Fx kunne du konvertere dine JPG/JPEG billeder over til PNG formatet. Dette giver rigtigt god mening hvis der er tale om fotografier eller lignende, men har du tekst på dine billeder vil jeg klart anbefale dig at holde dig til PNG.

Til dette plugin bruger jeg PNG to JPG. Jeg konverterer billederne enkeltvist, da det som tidligere nævnt ikke er i alle tilfælde du ville ønske at bruge JPG billeder.

WebP er et billedformat der er meget på vej frem, og har været det siden 2010. WebP billeder har vist sig at være i gennemsnit 25-35% mindre end JPG billeder, personligt har jeg set besparelser op imod 70% af den oprindelige billedstørrelse, uden at jeg har kunnet se forskel på de to billeder.

Når det omhandler generering af webp billeder, er EWWW Image Optimizer det bedste plugin jeg har fundet indtil videre.

Desværre kan du ikke bare konvertere alle dine billeder over til WebP. Det er nemlig ikke alle browsers, der i skrivende stund (marts 2020) understøtter WebP. Apple enheder (og det døde Internet Explorer) understøtter endnu ikke WebP.

Herunder kan du se de browsers som i øjeblikket understøtter WebP

EWWW har indbygget en funktionalitet til at kunne levere det rigtige til de enkelte browsers. Desværre er denne funktionalitet baseret på at EWWW læser hvilken browser du besøger hjemmesiden med, og så leverer det billede du kan bruge. Dette virker dog ikke sammen med cache løsninger så som CloudFlare. Ikke med mindre at man betaler sig til funktionaliteten hos CloudFlare. Alternativt stiller EWWW  noget javascript til rådighed som kan håndtere det. Men dette tilføjer blot mere data som skal indlæses af vores klienter, hvilket heller ikke er ønskværdigt.

Derfor bruger jeg WebP Express til at generere den nødvendige HTML så både Apple enheder og alle andre enheder får leveret et billede når de besøger min hjemmeside. WebP tilbyder nemlig muligheden for at kunne omskrive HTML’en så der i stedet for bare at være et <img> tag på hjemmesiden, nu kommer et <picture> tag som indeholder både WebP og JPG eller PNG billeder. Det tillader at HTML’en kan caches af CloudFlare, og lægger ansvaret over til browseren om at downloade det billede den kan forstå.

Det skal dog siges at EWWW har givet udtryk for at de arbejder på en lignende funktionalitet, og det kan ske vi derfor engang i fremtiden kan undvære WebP Express.

Du kan se de indstilligner jeg har valgt til WebP Express her:

WebP Express – CDN Friendly

WebP Express – Generelle Indstillinger

WebP Express – Ingen Live Conversion

WebP Express – Rediger HTML

Vær opmærksom på at jeg har valgt ikke at refererer WebP billeder som ikke er genereret. Meningen med denne funktion er at man kan slå den til, sammen med live conversion, og så få genereret de WebP billeder man har brug for. Desværre har jeg oplevet at konverteringen nogle gange kan tage MEGET lang tid, og endda nogle gange gå helt i stå. Det ønsker jeg ikke at mine brugere skal opleve, så derfor konverterer jeg billederne på forhånd.
Dertil er det ikke altid fordelagtigt at konvertere til WebP, nogle gange bliver billederne større end hvis man leverede dem i JPG. Derfor sparer vi også noget data for brugerne ved kun at konvertere og vise de WebP billeder som rent faktisk er mindre end hvis vi havde leveret dem et JPG billede.

På denne måde kan vi levere de mindre WebP billeder til de browsers der understøtter det, og have en fallback til “normale” billeder til de browsers der ikke understøtter det nye format.

Hvis du vi dykke dybt i optimering af billeder på hjemmesider, og især dykke ned i den tekniske del, kan jeg klart anbefale e-bogen “Essential Image Optimization” af Addy Osmani. Det er en “lang” artikel, men den kan klart anbefales hvis du vil vide mere dybdegående information om emnet.

Lazy loading er et udtryk for at alle elementer på hjemmesiden ikke hentes på én gang, men derimod først når de rent faktisk skal bruges.

I dag bruger jeg Lazy Loader til at klare denne opgave. Tidligere brugte jeg BJ Lazy Load, som også er et rigtigt fint letvægts plugin. Desværre virker BJ Lazy Load dog ikke for AMP, og den kan heller ikke håndtere <picture> & det dertilhørende <source> tag, hvilket betyder at indlæsningen af webp billeder ikke kan gøres med Lazy Load.

Hvis dit site skal være AMP ready, kan du ikke bruge BJ Lazy Load. Til gengæld kan du bruge det lazy load der følger med Jetpack, hvilket er hvad jeg er skiftet over til de steder hvor AMP er vigtigt.

Et andet plugin jeg har fundet, som jeg synes er en skam flere ikke kender til, er Super Progressive Web Apps. Min erfaring er dette plugin hjælper med at cache de besøgte sider på den enkelte bruger telefon. Sidder brugeren og navigerer rundt, og kommer forbi de samme sider igen, er disse sider allerede gemt lokalt på telefonen. Dét er en stor fordel, og giver en utroligt god brugeroplevelse. Pluginnet kan også komme op med en notifikation om at man kan tilføje hjemmesiden som et bogmærke på startskærmen. Gøres dette bliver der oprettet en Progressiv Web App (PWA), som er endnu bedre til at cache indholdet på telefonen.
Hvis du har en hjemmeside som ofte besøges af de samme brugere igen og igen, og især hvis disse brugere bruger de samme sider igen og igen, er dette plugin et must have i min bog.

Jetpack

Jetpack er et stort plugin. Det kan UTROLIGT meget!

I forhold til at gøre WordPress hurtigere, er der dog kun en enkelt funktionalitet jeg bruger;  Site accelerator. Site accelerator består af to komponenter, et der håndterer billeder, og et der håndterer de statiske filer så som javascript & CSS som hyppigst bruges i WordPress regi.

Det at Jetpack tilbyder at hente alle dine billeder over til dem, og sørge for at de bliver leveret så hurtigt som muligt til brugeren, betyder at din hjemmesides server ikke skal stå for at finde og sende billederne til brugerne. Min erfaring er at dette gør en kæmpe forskel.

Jeg bruger ikke længere Jetpack til dette, da det viste sig at et korrekt konfigureret Cloudflare løste disse problematikker markant bedre end Jetpack, samtidig med at det resulterede i mindre Javascript til frontenden / brugere + potentielt bedre SEO da billede-URLs nu er fra mit eget domæne og ikke fra Jetpacks domæne.

Redirection & håndtering af 404 fejl

Noget der også kan gøre WordPress langsomt, er hvis dine brugere bliver videresendt / redirected fra side til side. Der kan være mange grunde til at dette sker, både tilsigtede og utilsigtede. Endvidere kan brugerne forsøge at tilgå ressourcer som ikke findes, sker dette vil de blive mødt af en 404 fejl. Dette kan være en viderestilling som ikke virker, og det kan være billeder som af den ene eller anden grund, ikke længere findes på hjemmesiden.

Et plugin jeg er blevet rigtigt glad for når jeg skal lede efter og håndtere disse fejl, er pluginnet Redirection. Herunder ser du et eksempel på et billede som jeg stadig linker til et sted, men som ikke længere findes i min uploads mappe på serveren.

Redirects – 404s

Håndtering af disse redirects kan hjælpe med at gøre WordPress hurtigere, da browseren så ikke skal håndtere og vente på ressourcer som ikke findes.

Offsite cache – Cloudflare

Du har fået lavet en lokal cache på din server med W3, dine scripts og stylesheets er komprimeret og er samlet i én fil for hver type. Dine billeder har fået lazy load. Generelt har du gjort hvad du umiddelbart tænker du kan for at optimere din hjemmeside.

Men vent! Der er mere du kan gøre for at gøre WordPress hurtigere. Men nu begynder vi at bevæge os ind på den mere tekniske del af optimeringerne.

Når brugerne besøger din hjemmeside, er det dit webhotel som skal levere disse data. I langt de fleste tilfælde, er denne server langsom, fordi du (ligesom mig) har sparet på serveren til din hjemmeside. Derfor kunne det da være lækkert hvis vi kunne få en super hurtig webserver til at agere cache for vores hjemmeside. Og netop dette kan Cloudflare hjælpe os med. De er blandt andet kendt for at have verdens hurtigste DNS.

At få sat Cloudflare op som caching server er desværre så nemt som bare at downloade et plugin og trykke “aktiver”, her skal der lidt mere til da det er et mere teknisk setup. Vi skal nemlig have fortal dine besøgendes browser at den ikke skal lede efter din hjemmeside på din webserver, men i stedet skal lede efter den hos Cloudflare.

Heldigvis har Cloudflare selv lavet en guide til hvordan du får sat Cloudflare op for din hjemmeside, så jeg vil lade dem forklare den tekniske del, og i stedet vil jeg vise jer nogle før og efter billeder for min hjemmesides forside.

Mobil – før Cloudflare

Læg især mærke til billederne under tallene. Her er det tydeligt at vi nu allerede fra starten har menuen, topbaren & overskriften af artiklen klar. Vi får også ret hurtigt vist et billede og den vigtigste tekst så brugeren kan komme igang med at læse indholdet.

Mobil – Efter Cloudflare

På stationære & bærbare computere er resultatet et helt andet. Her er der snart ikke meget at komme efter længere.

Desktop / bærbar efter CloudFlare

Såfremt du ønsker at bruge Cloudflare kan det varmt anbefales at bruge Cloudflare pluginnet. Det kan sørge for at din off-location cache bliver purged hver gang du laver ændringer til dit layout. Dertil den har en fin handy knap til at sætte de mest normale indstillinger op for Cloudflare når man bruger WordPress.

Jeg kan på det varmeste anbefale at du får lavet de følgende “Page Rules” i Cloudflare. Formålet med disse regler er følgende:

1. Undgå al caching på dine preview sider. Dette er de sider du får vist når du bruger forhåndsvisningen for dine indlæg.
2. Fjernelse af hård cache (cache everything) på wp-admin delen af WordPress, men samtidig bibeholde caching af det statiske indhold du har i wp-content (fx dine billeder)
3. “Cache everything” = hård cache / “fang alt” for resten af dit site. Alting bliver gemt her, også dynamisk indhold, hvilket også inkluderer søgeresultater på din side, widgets i din sidebar, og kommentarer. Dette er en ret stor hammer, og synes du den rammer for hårdt kan du med fordel ændre “Cache Everything” til “Standard”.

Cloudflare PageRules

Her rammer vi den tekniske del. Følgende vil kræve at du kan håndtere at navigere rundt på en FTP server, og at du ved hvordan du håndterer at tilføje nye PHP funktioner til dit site.

Til EWWW har jeg tilføjet disse to overrides i wp-config.php. Disse to overrides sørger for at mine originale uploads holdes så originale som muligt. Derfor beholder jeg metadata / EXIF data på disse billeder, samt skipper billederne hvis der køres en lozzy optimering af billederne.

define( 'EWWW_IMAGE_OPTIMIZER_METADATA_SKIP_FULL', true );
define( 'EWWW_IMAGE_OPTIMIZER_LOSSY_SKIP_FULL', true );

// Lock Image Quality
add_filter( 'jpeg_quality', function($arg){return 90;} );
add_filter( 'wp_editor_set_quality', function($arg){return 90;} );

// change thumbnail size
function jetpackchange_image_size ( $thumbnail_size ) {
    $thumbnail_size['width'] = 240;
    $thumbnail_size['height'] = 137;
    return $thumbnail_size;
}
add_filter( 'jetpack_relatedposts_filter_thumbnail_size', 'jetpackchange_image_size' );

/* Replace the default WordPress jQuery script */
function squazz_modify_jquery() {
    wp_deregister_script('jquery');
    if(wp_is_mobile()) {
        wp_enqueue_script('jquery', 'https://code.jquery.com/jquery-3.4.1.min.js', array(), null, true);
    } else {
        wp_enqueue_script('jquery', 'https://code.jquery.com/jquery-3.4.1.min.js', array(), null, true);         
    }
}
add_action('wp_enqueue_scripts', 'squazz_modify_jquery');

// https://stackoverflow.com/questions/44827134/wordpress-script-with-integrity-and-crossorigin
add_filter( 'script_loader_tag', 'add_attribs_to_scripts', 10, 3 );
function add_attribs_to_scripts( $tag, $handle, $src ) {
    // The handles of the enqueued scripts we want to defer
    $async_scripts = array(
        'jquery-migrate',
        'sharethis',
    );
    $defer_scripts = array( 
        'contact-form-7',
        'jquery-ui',
        'jquery-form',
        'wpdm-bootstrap',
        'frontjs',
        'jquery-choosen',
        'fancybox',
        'jquery-colorbox',  
        'search'
    );        
    $jquery = array(
        'jquery'
    );

    if ( in_array( $handle, $defer_scripts ) ) {
        return '<script src="' . $src . '" defer="defer" type="text/javascript"></script>' . "\n";
    }
    if ( in_array( $handle, $async_scripts ) ) {
        return '<script src="' . $src . '" async="async" type="text/javascript"></script>' . "\n";
    }
    if ( in_array( $handle, $jquery ) ) {
        return '<script src="' . $src . '" defer integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous" type="text/javascript"></script>' . "\n";
    }
    return $tag;
}

Mange af de løsninger jeg ser til at løse lignende problematikker, gør det ved at definere en semikolon (eller lignende) separeret liste på et enkelt key i app.config. Det er en fin løsning, og den kan bruges, men det er ikke en særligt pæn løsning. Den stiller også lidt flere krav til de steder hvor den definerede liste skal bruges.

I dette tilfælde ønsker jeg at oprette en velkomst widget som har brug for at vide hvilke muligheder den har for at sige “hej” til brugeren.

Eksempel på den XML kode vi ender med at kunne indsætte i app.config

<?xml version="1.0" encoding="utf-8" />
<configuration>
 <widgets>
  <greetingWidget>
   <add greeting="Hej" />
   <add greeting="Goddag" />
   <add greeting="Hello" />
   ...
   <add greeting="Konnichiwa" />
   <add greeting="Namaskaar" />
  </greetingWidget>
 </widgets>
</configuration>

Først starter jeg med at oprette det egentlige greeting-element

Det er vigtigt at vi får nedarvet fra ConfigurationElement da vi bruger den programmatiske tilgang til at implementere vores ConfigurationElementCollection senere.

public interface IGreeting
{
    string Greeting { get; set; }
}


public class GreetingElement : ConfigurationElement, IGreeting
{
    [ConfigurationProperty("greeting", IsRequired = true)]
    public string Greeting
    {
        get { return (string)this["greeting"]; }
        set { this["greeting"] = value; }
    }
}

Derefter opretter jeg min samling som skal håndtere de forskellige hilsner.

public class GreetingElementsCollection : System.Configuration.ConfigurationElementCollection
{
    public List<IGreeting> All { 
        get { return this.Cast<IGreeting>().ToList(); }
    }

    public GreetingElement this[int index]
    {
        get
        {
            return base.BaseGet(index) as GreetingElement;
        }
        set
        {
            if (base.BaseGet(index) != null)
            {
                base.BaseRemoveAt(index);
            }
            this.BaseAdd(index, value);
        }
    }

    protected override ConfigurationElement CreateNewElement()
    {
        return new GreetingElement();
    }

    protected override object GetElementKey(ConfigurationElement element)
    {
        return ((GreetingElement)element).Greeting;
    }
}

Vi har også brug for en greetingWidget property så vores app.config forstår den nyoprettede samling

public class Widgets : System.Configuration.ConfigurationSection
{
    public static Widgets Widget => ConfigurationManager.GetSection("greetingWidget") as Widgets;

    [ConfigurationProperty("greetingWidget", IsRequired = true)]
    public GreetingElementsCollection GreetingWidget
    {
        get { return (GreetingElementsCollection)this["greetingWidget"]; }
        set { this["greetingWidget"] = value; }
    }
}

Når vi skal have fat i data fra vores config gør vi det således

List<GreetingElement> greetings = Widgets.Widget.GreetingWidget.All;

The Events Calendar er et lækkert plugin når man har en masse events man hurtigt vil have oprettet og fremstillet på en flot måde. Desværre løb jeg ind i at en klient ønskede at få ændret en label med værdien “Organizer” til at få værdien “Coordinator”.

Jeg kunne have valgt at redigere labels direkte i pluginnets kode. Men så ville jeg enten være låst til den nuværende version af pluginnet fremover, eller også ville jeg skulle huske at opdatere mine egne rettelser hver gang. Alternativt kunne jeg også have brugt et oversættelsesprogram som WPML, som ville kunne oversætte den enkelte streng. Men at hente et oversættelses plugin ned, bare for at ændre et par labels, virker som noget af et overkill.

I stedet endte jeg med at hægte mig på The Events Calendar’s filtre, og overskrive disse. I den nedenstående kode ændrer jeg først organizer labellen til at være Coordinator. Dernæst obfuskerer jeg mailadressen og gør den klikbar.

// Edit Organizer Label Singular & Plural
add_filter('tribe_organizer_label_singular', 'tribe_organizer_label_singular_edit');
   function tribe_organizer_label_singular_edit() {
   return __( 'Coordinator', 'tribe-events-calendar' );
}
add_filter('tribe_organizer_label_plural', 'tribe_organizer_label_plural_edit');
   function tribe_organizer_label_plural_edit() {
   return __( 'Coordinators', 'tribe-events-calendar' );
}
// Make Organizer Label clickable
$mail = tribe_get_organizer_email();
add_filter('tribe_get_organizer_email', 'tribe_get_organizer_email_edit');
function tribe_get_organizer_email_edit($mail) {
   $output = mailto($mail);
   return $output;
}

Om det er grundet marketing så Ninja Forms kan få solgt deres “Front-End Posting” plugin skal jeg ikke kunne sige (men jeg mistænker dem for det). Men som det ser ud i øjeblikket er det kun administratorer der har adgang til at oprette og redigere Ninja Forms i WordPress’ backend. Et problem, da jeg ikke ønsker at alle mine brugere, som skal kunne oprette forms, skal være administratorer.

Da jeg ledte efter en måde hvorpå man kunne ændre hvilke brugere der havde adgang til hvad i deres plugin, fandt jeg ud af at det i skrivende stund kun er muligt ved at hægte sig på filtrene i WordPress. Så det måtte jeg jo gøre.

I mit tilfælde ønskede jeg at editors og admins kunne oprette og vedligeholde forms. Skal jeg ramme begge, skal jeg finde en egenskab som disse to roller har til fælles. “edit_others_posts” er en sådan egenskab som kun Editors og Admins deler. Det er derfor en fin egenskab at sortere efter. Se evt. Capability vs. Role table for andre egenskaber at sorter efter.

Min endelige løsning blev de følgende linjers kode. Disse filtre tillader mine editors at oprette nye forms. Dertil har jeg tilføjet tilladelser til nogle af de undermenuer vi i vores tilfælde havde brug for at editors havde adgang til.

function squazz_change_ninja_forms_capabilities_filter( ) {
   return 'edit_others_posts';
}
add_filter( 'ninja_forms_admin_menu_capabilities', 'squazz_change_ninja_forms_capabilities_filter' ); // Show Ninja Forms menu
add_filter( 'ninja_forms_admin_add_new_capabilities', 'squazz_change_ninja_forms_capabilities_filter' ); // Show "Add New" submenu
add_filter( 'ninja_forms_admin_all_forms_capabilities', 'squazz_change_ninja_forms_capabilities_filter' ); // Show "All Forms" submenu
add_filter( 'ninja_forms_admin_submissions_capabilities', 'squazz_change_ninja_forms_capabilities_filter' ); // Show "Submissions" submenu
add_filter( 'ninja_forms_admin_import_export_capabilities', 'squazz_change_ninja_forms_capabilities_filter' ); // Show "Import / Export" submenu

Det hele kan laves til et plugin. I så fald skal vores funktion omskrives lidt:

function squazz_change_ninja_forms_capabilities_filter( $capabilities ) {
   $capabilities = 'edit_others_posts';
   return $capabilities;
}

Filtrene skal da omskrives på følgende måde:

add_filter( 'ninja_forms_admin_menu_capabilities', 'squazz_change_ninja_forms_capabilities_filter' ); // Show Ninja Forms menu

Tjek Writing a Plugin hvis du ikke har helt styr på hvordan du laver et plugin.

Nedenstående kode er i store dele taget fra Zack Perdue‘s fine blogpost “3 Clever Ways To Protect Your Email From Spammers“, men jeg har rettet koden lidt til da jeg fik nogle fejl med koden hvis ikke funktionerne blev fodret med en mailadresse.

/*
 * Obfuscate emails / use with "echo mailto($email)"
 */
function obfuscate($string) {
   $safe = '';
   foreach (str_split($string) as $letter) {
      switch (rand(1, 3)) {
         // HTML entity code
         case 1:
         $safe .= '&#'.ord($letter).';';
         break;
         // Hex character code
         case 2:
         $safe .= '&#x'.dechex(ord($letter)).';';
         break;
         // Raw (no) encoding
         case 3:
         $safe .= $letter;
      }
   }
   return $safe;
}

function email($email) {
   // Make sure the at sign is always obfuscated
   return str_replace('@', '@', obfuscate($email));
}

function mailto($email, $title = NULL) {
   // Obfuscate email address
   if($email) {
      $email = email($email);
      if ($title === NULL) {
         // Use the email address as the title
         $title = $email;
      }
      return '<a href="&#109;&#097;&#105;&#108;&#116;&#111;&#058;'.$email.'">'.$title.'</a>';
      } else {
      return '';
   }
}

Ovenstående implementation bruger jeg flittigt i kombination med WordPress Plugins der ikke håndterer dette af sig selv. Dette er fx tilfældet med “The Events Calendar”.

Når jeg udvikler temaer til WordPress, forsøger jeg altid så vidt muligt at gøre temaet responsivt. Derfor skar det mig også i hjertet da jeg opdagede hvor låst NextGen Gallerys styles var. Det er ikke meget kode der skal til for at gøre det meste responsivt dog, hvilket den kommende CSS vil vise.

/*
 * CSS Name: Responsive NextGen Styles
 * Description: NextGEN Gallery Responsive Stylesheet
 * Author: Late Night Productions / Squazz
 * Version: 1.1
 */

.ngg-galleryoverview {
   display: flex !important;
   flex-wrap: wrap;
}
.ngg-album-compact,
.ngg-gallery-thumbnail-box {
   width: 98%;
   padding:0 1% 5px 1% !important;
   margin: 0 !important;
}
.ngg-album-compactbox {
   line-height: 1;
}
.ngg-album-compactbox .Thumb,
.ngg-gallery-thumbnail img {
   width: 100%;
   height: auto;
   margin: 0 !important;
   padding: 0 !important;
}
.ngg-album-compact h4 .ngg-album-desc,
.ngg-gallery-thumbnail {
   height: auto !important;
   width: 100% !important;
}
.ngg-album-compact p {
   line-height: 1;
}
.slideshowlink {
 width: 100%;
}
/* iPhone / Droid – Landscape */
@media screen and (min-width: 480px) {
   .ngg-album-compact,
   .ngg-gallery-thumbnail-box {
      width: 48%;
   }
}
/* Small Tablets – 640px wide */
@media screen and (min-width: 640px) {
   .ngg-album-compact,
   .ngg-gallery-thumbnail-box {
      width: 31%;
   }
}

Husk at loade disse styles afhængigt af NextGens styles. Både fordi det er god practice, og fordi det er nødvendigt grundet den måde NextGen har skrevet deres styles fra start. Indsæt følgende kode i functions.php (og ret til så det passer til din opbygning af kode)

// NextGen gallery fix
function NextGen_styles_fix() {
   wp_enqueue_style( 'NextGen-Responsive', get_stylesheet_directory_uri() . '/styles/nggallery.css', array('nextgen_basic_thumbnails_style'), '1.1' );
}
add_action( 'wp_enqueue_scripts', 'NextGen_styles_fix' );

Der er dog nogle problemer med dette setup. Grundet at NextGen er så fastlåst i sine styles fra start af, har udvikleren også valgt at køre med meget små thumbnails. Med ovenstående styles strækker vi disse styles ret meget, og thumbnails vil komme til at se forfærdelige ud nu. Det er derfor vigtigt at vi sikrer os at vores thumbnails er store nok til worst-cases. I mit tilfælde var det 450px i bredden (Det er næsten 3x den størrelse NextGen bruger som standard).

Vi kan ændre de generelle indstillinger for thumbnails under “Gallery Settings”, hvor vi i hver af de faner vi bliver præsenteret for vælger “Override thumbnail settings” og indtaster de værdier der passer til vores tema.

Da NextGen Gallery er bygget op som den er, er det ikke nok at ændre den generelle thumbnail værdi for gamle albums. Denne værdi skal ændres for samtlige albums, hvilket kan være en del albums hvis man er en aktiv fotograf. Men det er arbejdet værd i det lange løb.

jQuerys Accordion er utroligt let at bruge, alt hvad man behøver at gøre er at indsætte et par links i bunden af ens website (JavaScript bør altid ende i bunden af dit site). I Wordpres er det endnu nemmere, her tilføjer vi blot den følgende kode til vores functions.php fil.

function enqueued_scripts() {
   if ( !is_admin() ) {
      wp_enqueue_script('jquery-ui-accordion');
   }
}
add_action( 'wp_enqueue_scripts', 'enqueued_scripts' );

For at styre hvordan vores accordion skal fungere, opretter jeg filen accordion.js med følgende indhold:

jQuery(document).ready(function($) {
   $( "#accordion" ).accordion({
      heightStyle: "content",
      collapsible: true,
      active: false
   });
});

Og tilføjer den til wordpress på følgende måde:

function enqueued_scripts() {
   if ( !is_admin() ) {
      wp_enqueue_script('jquery-ui-accordion');
      wp_enqueue_script(
         'custom-accordion',
         get_stylesheet_directory_uri() . '/js/accordion.js',
         array('jquery')
      );
   }
}
add_action( 'wp_enqueue_scripts', 'enqueued_scripts' );

Slutteligt skal vi have opdateret vores Q&A så den udnytter jQuery’s Accordion. Dette gøres i tekst-editoren for din WordPress side:

<div id="accordion">
   <h3>Section 1</h3>
   <div> Mauris mauris ante, blandit et, ultrices a,...</div>
   <h3>Section 2</h3>
   <div> Sed non urna. Donec et ante. Phasellus eu ligula...</div>
</div>

Så er vi faktisk færdige, men accordion kan hurtigt gå hen og blive uoverskueligt, især når man er en mobilbruger. I vores tilfælde, ønskede vi at have det således at når man klikkede på en ny overskrift for at åbne den, lukkede den tidligere fane sig automatisk sammen. Dette fungerede fantastisk på desktop computere, men på mobile enheder blev det hurtigt rodet. Man endte med at scrolle frem og tilbage for at kunne læse indholdet af vores Q&A.

For at løse dette problem vendte jeg snuden mod StackOverflow. Som så ofte før, viste det sig at der var andre der havde haft samme problem som jeg. Her fandt jeg frem til denne løsning, som virkede præcist som jeg ønskede den skulle:

activate: function( event, ui ) {
   if(!$.isEmptyObject(ui.newHeader.offset())) {
      $('html:not(:animated), body:not(:animated)').animate({ scrollTop: ui.newHeader.offset().top }, 'slow');
   }
}

Efter en opdatering af accordion.js med denne kode ender vi slutteligt ud med dette

jQuery(document).ready(function($) {
   $( "#accordion" ).accordion({
      heightStyle: "content",
      collapsible: true,
      active: false,
      activate: function( event, ui ) {
         if(!$.isEmptyObject(ui.newHeader.offset())) {
            $('html:not(:animated), body:not(:animated)').animate({ scrollTop: ui.newHeader.offset().top }, 'slow');
         }
      }
   });
});

Hvis man ikke ønsker at siden automatisk skal flytte fokus til toppen af overskriften når man er på en desktop computer, kan man tjekke hvorvidt brugeren er på en mobil eller stationær enhed. Der er mange måder at gøre dette på. Min personlige favorit er at bruge så simpelt JavaScript som muligt, både fordi simpel kode er nemmest at læse, og fordi man så ikke skal huske at importere en masse biblioteker. Denne følgende kode (fundet på StackOverflow) kan bruges til at tjekke om din bruger er på en mobil platform:

if( /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent) ) {
   // some code..
}

En løsning var at oprette en side, og så importere denne side på forsiden via min forbedrede side inkludering. Dette er ikke en optimal løsning. Det ville betyde at skribenten på Musalaha så både skal:

1. Uploade nyhedsbrevet
2. Indsætte det på siden med vores nyhedsbreve
3. Huske at opdatere siden indeholdende det seneste nyhedsbrev

I stedet ønskede vi at automatisere denne proces.  Det gælder trods alt om at give skribenterne så få muligheder for at lave fejl som muligt

Efter at have søgt vidt og bredt efter et plugin, der kunne hjælpe mig med opgaven, endte jeg hos Stray Bits hvor Chris Cummings havde siddet med samme problematik. Min løsning er baseret meget på hans arbejde, men dog med nogle modifikationer for at kunne bruge koden mere bredt i fremtiden. Der er trods alt ingen grund til at låse sig selv fast fra begyndelsen.

function squazz_get_PDF($targetword, $limit = '-1') {
   // Setup what we are searching for
   $args = array(
      'post_type' => 'attachment',
      'post_mime_type' => 'application/pdf',
      'numberposts' => -1,
      'post_status' => null,
      'post_parent' => null,
      'orderby' => 'post_date',
      'order' => 'DESC'
   );
 
   // Get the initial results
   $attachments = get_posts($args);
   // If there are results, sort them
   if ($attachments) {
      $i = 1;
      foreach ($attachments as $post) {
         // Get the post title 
         $title = $post->post_title;
         // Only show results matching our keyword
         if (stripos($title,$targetword) !== false) {
            $files[$i]['ID'] = $post->ID;
            $files[$i]['title'] = $title;
            ...
            if($i == $limit) { break; }
            ++$i;
         }
      }
   } else {
      _e('Nothing to see here', 'SquazzFunctions')
   }
   return $files;
}

Med vores funktion kan vi nu vælge hvilket nøgleord vi vil søge efter, og hvor mange resultater vi ønsker at få.

Med ovenstående løsning fik jeg hvad jeg ønskede, næsten i hvert fald. Funktionen søger efter PDF filer hvis titel indeholder vores keyword. I vores tilfælde skulle vi kun bruge ét dokument, det seneste, som er på engelsk. Og netop her opstår problematikken: “… på engelsk“.

Arbejdsrutinen omkring upload af vores nyhedsbreve er som oftest, at det første nyhedsbrev vi uploader, er det engelske nyhedsbrev. Herefter kommer så det tyske og derefter det franske. Hvilket også betyder at jeg i første forsøg fik præsenteret det franske nyhedsbrev da jeg kørte min funktion. Én løsning er at fortælle alle skribenterne at de skal uploade det engelske nyhedsbrev til sidst, men hele grunden til at vi lavede denne funktion var jo at vi ønskede at minimere mængden af ting vore skribenter skulle huske på. Hvem ved, måske kommer der i fremtiden andre processer, eller flere sprog til.

Det vores funktion har brug for, er en opgradering. Ud over at vælge hvad vi vil søge efter, og hvor mange resultater vi ønsker at modtage, vil vi også kunne vælge hvilke ting vi ikke ønsker at få med i resultaterne. Dette viste sig at være nemmere sagt end gjort.

Heldigvis har vi på Musalaha en arbejdsrutine hvor nyhedsbreve navngives “newsletter-LANGUAGE–YEAR“. Dette er vigtig information, da vi så “bare” skal fortælle vores mini PDF-søgemaskine hvilke ting vi ikke ønsker at blive præsenteret for.

PHP tilbyder os finde strenge ved hjælpe af strpos(), men desværre tilbyder PHP os ikke at søge efter et array af strenge i samme streng. Heldigvis er der andre der har haft dette problem, og som så mange gange før kunne StackOwerflow hjælpe mig videre med en super god løsning. For at skabe overblik har vi koden herunder:

function strposa($haystack, $needle, $offset=0) {
   if(!is_array($needle)) $needle = array($needle);
   foreach($needle as $query) {
      // stop on first true result
      if(strpos($haystack, $query, $offset) !== false) return true; 
   }
   return false;
}

Note: strpos() er case-sensitive, brug stripos() hvis du leder efter en case-insensitive løsning.

Med min nye funktion, som kan søge efter flere keywords i en streng, har jeg nu det perfekte våben i kampen mod uønskede fraser i titlen på vores nyhedsbrev. Vi tilføjer et nyt parameter til vores funktion og nogle få linjer i koden af funktionen. Og så er vi faktisk klar til at frasortere alle de elementer vi ikke ønsker at se.

function squazz_get_PDF($targetword, $limit = '-1', $remove = array()) {
   ...
   if ($attachments) {
      ...
         if (stripos($title,$targetword) !== false) {
            if(!strposa($title,$remove)) {
               ...
            }
         }
      }
   }
   ...
}

Den endelige funktion kan ses herunder i sin fulde form:

function squazz_get_PDF($targetword, $limit = '-1', $remove = array()) {
   // Setup what we are searching for
   $args = array(
      'post_type' => 'attachment',
      'post_mime_type' => 'application/pdf',
      'numberposts' => -1,
      'post_status' => null,
      'post_parent' => null,
      'orderby' => 'post_date',
      'order' => 'DESC'
   );
 
   // Get the initial results
   $attachments = get_posts($args);
   // If there are results, sort them
   if ($attachments) {
      $i = 1;
      foreach ($attachments as $post) {
         // Get the post title 
         $title = $post->post_title;
         // Only show results matching our keyword
         if (stripos($title,$targetword) !== false) {
            if(!strposa($title,$remove)) {
               $files[$i]['ID'] = $post->ID;
               $files[$i]['title'] = $title;
               ...
               if($i == $limit) { break; }
               ++$i;
            }
         }
      }
   } else {
      _e('Nothing to see here', 'SquazzFunctions')
   }
   return $files;
}