kaxigt.com

Vi är många som formligen älskar att dyka ned under huven på WordPress och rota runt – i vardagligt tal kallas vi för WordPress Developers (WordPressutvecklare). Att dissekera koder, skriva om, eller att utveckla nya variationer, är för oss ett stort intresse. Vid sidan av detta bygger vi också gärna olika teman som vi sedan designar efter förmåga.

Under huven på WordPress är därför tänkt att vara en serie med tips om hur man kan bygga, utveckla och testa WordPress. Intentionen är att kunna presentera tips med förklaringar i varje artikel.

Vi ska naturligtvis titta på front end, det vill säga själva byggandet och hur man kan implementera olika koder – men vi ska även smyga lite back end genom att kika närmare på hur man kan lägga till funktioner till själva WordPress ramverk.

Med andra ord öppna upp huven på WordPress. Jag rekommenderar er att ta back-up på filerna innan ni sätter igång och ändrar i dem.

Sätta WordPress i ”DEBUG-läge”

När man utvecklar WordPress, i synnerhet back end eller plugin, men också när man bygger teman, menar jag att det är ett måste att sätta WordPress i DEBUG-läge eftersom det underlättar att se var ett kodningsfel kan finnas.

Förenklat innebär DEBUG att man systematisk tar bort/skriver om de buggar (programmeringsfel) som finns/uppstår så de försvinner.

Till hjälp ändrar man en kodsnutt i filen wp-config.php. Det är samma fil som du har angett dina lösenord till databasen i. För att möjliggöra DEBUG behöver du alltså öppna din wp-config.php och leta dig fram till denna rad:

define('WP_DEBUG', false);

Som standard är den alltid ställd till ’false’. Ändra den till ’true’.

define('WP_DEBUG', true);

Nu kan vi stanna här och sätta igång om vi vill, men om du utvecklar ett plugin – visst vore det bra att logga felen som du åtgärdar?

Vi vill ju kunna arbeta utan att störas av att hela tiden se alla felmeddelande på sidan (som faktiskt kan bli rätt så irriterande i längden), således ska vi ytterligare lägga till några kodsnuttar som dels loggar buggarna och dels förhindrar WP att visa dessa felmeddelanden.

Under föregående kod lägger vi därför till följande koder:

// WordPress ska logga allt till /wp-content/debug.log file
define('WP_DEBUG_LOG', true);

// Ta bort PHP 'display_errors' variabler
define('WP_DEBUG_DISPLAY', false);

// Göm felen från att visas on-screen
@ini_set('display_errors', 0);

Man kan också snygga till det genom att skriva ihop alla koder, de ska fortfarande placeras under raden som definierar dina databasnamn. Glöm inte heller att ändra ordet ”development_user” till ditt eget development database user name.

@ini_set('display_errors',0);
if( 'development_user' === DB_USER ){
  define('WP_DEBUG',         true);  // Turn debugging ON
  define('WP_DEBUG_DISPLAY', false); // Turn forced display OFF
  define('WP_DEBUG_LOG',     true);  // Turn logging to wp-content/debug.log ON
}

Vad du än valde så är det nu bara att köra igång men kom ihåg att samtidigt hålla koll på debug.log så du ser vad det är du gör.

Väljer du däremot att enbart ställa WP_DEBUG till ’true’ kommer alla felmeddelanden att synas. Det kan då vara bra att veta att de felmeddelanden som ligger ovanför WordPress ”on-screen” brukar oftast vara programmeringsfel i dina plugin.

De fel som kan finnas i själva WordPress kommer att finnas ”on-screen” i WordPress. Jag rekommenderar er också att använda pluginet Theme Check eftersom det kontrollerar om ditt tema är ”up-to-date” med senaste versionen av WordPress.

SCRIPT_DEBUG

WordPress minimerar och konkatenerar (sammanslår strängar, ex sol + stråle = solstråle) JavaScript och CSS i Admin så om du funderar på modifiera de Javascript eller den CSS som redan finns inbyggt i WordPress kan det vara bra att veta att WordPress har något som kallas för “development” scripts.

För javascript är det dev.js och för CSS dev.css. Innan du kan använda dessa behöver du sätta SCRIPT_DEBUG till ’true’.

define( 'SCRIPT_DEBUG', true );

När du är klar med din DEBUG, eller delar av den, ändrar du bara tillbaka till värdet ’false’ igen. Piece of cake!

WordPress hooks, actions och filters

Det händer rätt ofta att vi vill förändra eller lägga till något utöver det som redan finns ”inbyggt som standardfunktioner” i WordPress – det är då vi använder hooks, actions, och filters. För att kunna modifiera dessa använder vi oss av filen functions.php, med det tar vi klivet över tröskeln till att närma oss back-endprogrammering.

När man skriver in funktioner som förändrar, agerar, lägger till, eller filtrerar är det att liknas vid plugin. Skillnaden ligger i att här skriver vi in koderna direkt i functions.php istället för att installera dem externt till WordPress. Benämningen på detta är WordPress API (Application Programming Interface) och hooks är således koderna som utvecklarna använder.

Vad är då hooks?

Hooks är speciella koder som tillåter plugin, eller mer koderna i dessa, att ”haka på” WordPress egna hård-koder. De är koder som kallar på olika funktioner vid olika tillfällen och på så vis försätter ett ”plugin” (i detta fall en funktion i funktions.php) i rörelse.

Det finns två olika sorts hooks:

1. Actions är hooks som WordPress ”core” sätter igång vid specifika tidpunkter under det att de utförs, eller när en specifik händelse uppstår. Man kan specificera så att en eller fler av dess funktioner i PHP blir utförda vid dessa tidpunkter genom att använda Action API. Det kan vara att publicera en post eller att byta tema.
2. Filters är hooks som WordPress igångsätter för att modifiera texter av varierande slag innan de läggs till i databasen eller blir sända till webbläsarens skärm. Man kan specificera så att en eller fler av dess funktioner i PHP modifierar olika specifika textformer vid dessa tidpunkter genom Filter API.

Actions triggas igång av specifika händelser som tar plats i WordPress medan filter verkar på redan existerande innehåll och är funktioner genom vilka WordPress låter sin data passera. Det innebär följande:

1. ett filters funktion måste acceptera en variabel som parameter, och…
2. ett filters funktion måste returnera resultatets innehåll efter att alla funktioner har utförts

När man har definierat en funktion ska den ”registreras” till WordPress och det gör man genom att kalla på den genom add_action(). Se koden nedanför.

add_action ( 'hook_name', 'your_function_name', [priority], [accepted_args] );

Samma sak gäller filters genom att kalla på funktionen genom add_filter() . Se koden nedanför.

add_filter ( 'hook_name', 'your_filter', [priority], [accepted_args] );

Visa post thumbnail i din rss feed (filter)

function diw_post_thumbnail_feeds($content) {
	global $post;
	if(has_post_thumbnail($post->ID)) {
		$content = '

’ . $content; } return $content; } add_filter(’the_excerpt_rss’, ’diw_post_thumbnail_feeds’); add_filter(’the_content_feed’, ’diw_post_thumbnail_feeds’);

Här är en lista över alla WordPress Hooks.

Här avslutas första avsnittet i serien Under huven på WordPress. Jag hoppas att det inspirerade intresset att fördjupa er i WordPress underbara värld. Lycka till!