» » WordPress: Schrijf uw eigen plugin, Deel 3

WordPress: Schrijf uw eigen plugin, Deel 3

Geplaatst in: Programmeren, Techniek, Web | 3

WordPress: Een Kunst Database Plugin, Deel 3

In het vorige deel van deze serie hebben we gezien hoe we super eenvoudig een plugin kunnen maken. We hebben uitgelegd hoe de heading in het eerste plugin bestand een rol speelt en hoe hooks in de plugin het gedrag van WordPress kunnen aanpassen.

In deel 3 zullen we een stukje administrative GUI maken en de database structuur van de plugin aanmaken wanneer de plugin geactiveerd word. As always, the WordPress Codex has some great information which we will apply to our own plugin.

De Kunst Database zal zowel setup informatie als data beheren. Dit is een belangrijk onderscheid. Setup informatie word typisch bijgehouden in de WordPress opties, terwijl data die door de plugin word beheerd in z’n eigen database tabel gaat. We zullen dus een tabel moeten aanmaken en de opties voor de plugin bijhouden in de reeds bestaande WordPress tabellen.

Installatie Functie

We beginnen met het coden van een installatie functie. Deze installatie functie is verantwoordelijk voor het aanmaken van de data tabel wanneer de plugin word geactiveerd. We zullen tevens een functie aanmaken die deze tabel netjes opruimt als de plugin word verwijderd. Als de plugin word gedeactiveerd zullen we de tabel eenvoudigweg laten bestaan zodat door deactivatie niet mogelijk veel data weggegooid word.

/**
 * This function creates the data table for the plugin in the WordPress
 * database. It gets called only once on activation of the plugin.
 */

global $kdb_db_version;
$kdb_db_version = "1.0";

function kdb_install () {
    global $wpdb;

    $maintable_name = $wpdb->prefix . "kdbdata";
    $artisttable_name = $wpdb->prefix . "kdb_artists";
    $materialtable_name = $wpdb->prefix . "kdb_materials";
    $charset_collate = $wpdb->get_charset_collate();

    $mainsql = "CREATE TABLE $maintable_name (
        id mediumint(9) NOT NULL AUTO_INCREMENT,
        time_added datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
        time_updated datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
        name tinytext NOT NULL,
        text text NOT NULL,
        artist_id mediumint(9) NOT NULL,
        material_id mediumint(9) NOT NULL,
        year_painted mediumint(4) NOT NULL,
        url varchar(255) DEFAULT '' NOT NULL,
        PRIMARY KEY (id),
        FOREIGN KEY(artist_id) REFERENCES $artisttable_name(id),
        FOREIGN KEY(material_id) REFERENCES $materialtable_name(id)
    ) $charset_collate;";

    $artistsql = "CREATE TABLE $artisttable_name (
        id mediumint(9) NOT NULL AUTO_INCREMENT,
        time_added datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
        time_updated datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
        artist_name varchar(255) DEFAULT '' NOT NULL,
        artist_description text NOT NULL,
        PRIMARY KEY (id)
    ) $charset_collate;";

    $materialsql = "CREATE TABLE $materialtable_name (
        id mediumint(9) NOT NULL AUTO_INCREMENT,
        time_added datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
        time_updated datetime DEFAULT '0000-00-00 00:00:00' NOT NULL,
        name tinytext NOT NULL,
        text text NOT NULL,
        material_name VARCHAR(255) DEFAULT '' NOT NULL,
        PRIMARY KEY (id)
    ) $charset_collate;";

    $wpdb->query($materialsql);
    $wpdb->query($artistsql);
    $wpdb->query($mainsql);

    add_option('kdb_db_version', $kdb_db_version);
}

Zoals u kunt zien duiken we nu echt in de code en we wijken tevens al direct af van de Codex instructies omtrent de dbDelta functie. We hebben hier belangrijke redenen voor, de WordPress dbDelta() functie ondersteunt namelijk geen FOREIGN KEY constructs. Als, slechts, medior DBA heb ik meerdere discussies hierover gelezen en om eerlijk te zijn is de redenatie om dit niet te ondersteunen in dbDelta nogal belachelijk. Het klopt, FOREIGN KEY zou dbDelta ingewikkelder maken, een stuk ingewikkelder. Echter, de argumenten die ik heb gevonden doen mij veel denken aan een ‘jaren 80 cowboy mentaliteit’ waarbij “MySQL niet een ‘echte’ relationele database is en queries toch volledig in de code zitten waardoor we er volledige controle over hebben, bla bla bla’. De data tabellen die door de Kunst Database plugin worden gepopuleerd zullen echter tevens door andere bronnen gevuld of gelezen worden. Hierdoor is het belangrijk om een schema te maken wat referentiele integriteit heeft en welk genormaliseerd is teneinde wildgroei en duplicatie van data te voorkomen.

Activeren

Nu we de installatie functie hebben geschreven dienen we ervoor te zorgen dat de functie aangeroepen word met behulp van de register_activation_hook functie:

register_activation_hook(__FILE__, 'kdb_install');

Nadat we de plugin code hebben opgeslagen kunnen we als test proberen de plugin te activeren:

 

Plugin Geactiveerd
Plugin Geactiveerd

Nadat we de plugin geactiveerd hebben willen we natuurlijk graag controleren of de tabellen ook werkelijk zijn aangemaakt. We kunnen dit eenvoudig doen door verbinding te maken met de WordPress database.

Debuggen

Code Bug
Code Bug

Na het activeren van onze plugin verwachten we 3 tabellen te zien in de WordPress database:

  • wp_kdbdata
  • wp_kdb_materials
  • wp_kdb_artists

Geen van deze tabellen bestaat echter na het activeren van onze plugin. Dit is waar het door iedere programmeur gevreesde en toch zo deel-uitmakend van hun baan begint: het debuggen.

We hopen echter als 3DN een levendige site te creëeren waarbij mensen participeren dus we gaan de bug hier op dit moment nog niet verklappen. Ziet u de bug? Post dan uw eigen oplossing in de comments! Wanneer we voldoende animo hiervoor krijgen zullen we overwegen een klein prijsje ter beschikking te stellen. We zijn benieuwd!

Samenvatting

Hoewel de WordPress Codex een uitmuntend stukje documentatie is dient u altijd uw verstand te blijven gebruiken en niet klakkeloos de instructies overnemen. In de meeste gevallen is het prima en zelfs beter om de dbUpdate functie te gebruiken. In ons geval waar we de Kunst Database ook vanuit andere applicaties wensen te gebruiken is het echter van belang om het schema te normaliseren. Aangezien we verwachten dat de Kunst Database behoorlijk groot kan worden omdat we tevens een automatische koppeling aan de Europeana Database willen implementeren is de normalisatie en referentiele integriteit van een overstijgend belang.

Dit artikel is grotendeels junior nivo. We gaan nu nog steeds vrij langzaam maar hebben het tempo wat opgevoerd ten opzichte van Deel 1 en Deel 2 van deze serie. Word het u nu al wat te moeilijk maar heeft u wel behoefte aan een custom plugin? U kunt natuurlijk altijd 3DN inhuren. Wij zijn ons business model aan het veranderen waardoor het inhuren van een ZZP’er ook voor u erg aantrekkelijk en betaalbaar kan worden.

Related

WordPress: Schrijf uw eigen plugin, Deel 2 WordPress: Een Kunst Database, Deel 2 In het vorige deel van deze serie hebben we wat functionele eisen beschreven van onze plugin:Interactie m...
Een Product Bouwen: Systool Product Al jarenlang bouwt 3DN vele scriptjes, programma's en diensten, hulpmiddeltjes die ons in onze rol van freelancer goed van pas komen wanneer ...
WordPress: Schrijf uw eigen plugin WordPress Plugins: Een Kunst Database, Deel 1 Rechtlijnig DenkenEén van onze huidige projecten is het bouwen van een online Kunst winkel, 'Knipo...
Apache en HTTP/2 HTTP/2: Introductie HTTP/2 is een grote sprong vooruit van HTTP/1.0. HTTP/2 is afgeleid van het vroegere experimentele SPDY protocol. Het SPDY protoc...

3 Responses

  1. Fred Leeflang
    | Beantwoorden

    WordPress heeft een mechanisme ingebouwd om wat debugging te loggen, zie https://codex.wordpress.org/Debugging_in_WordPress

    Wij hebben deze functie normaal gesproken aanstaan op onze productie site, hetgeen niet aanbevolen word door WordPress. In latere instantie zullen we hiervoor een WordPress staging omgeving opzetten, echter dat is momenteel nog niet het geval.

    Hint: De WordPress debug.log verklapt NIETS waarom onze database tabellen niet gecreeerd worden.

  2. admin
    | Beantwoorden

    Wij hebben inmiddels het probleem geanalyseerd en opgelost. U ook? We geven u tot morgen de tijd om dit puzzeltje op te lossen. Als niemand het heeft opgelost zullen we de oplossing posten. Het is, net zoals het nivo van dit artikel, een eenvoudig probleem.

    Later zullen we meer uitdagende problemen posten.

  3. admin
    | Beantwoorden

    Helaas heeft niemand het foutje kunnen vinden;

    – We draaien bij 3DN WordPress multisite. Dit betekent dat meer sites door een server worden afgehandeld. WordPress voegt intern een cijfer toe aan de $wpdb->prefix waardoor de tabellen niet wp_kdbdata etc. heten maar in ons geval wp_9_kdbartists

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *