Taxonomieën (WordPress): verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Regel 290: Regel 290:
 
== Attribuut-taxonomieën ==
 
== Attribuut-taxonomieën ==
  
−
''Attributes'' zijn een bijzondere variant van ''Categorieën''.
+
Zie [[Attribuut-taxonomieën (WooCommerce)]]
−
 
 
−
=== Database-model ===
 
−
 
 
−
Tabel <code>wp_woocommerce_attribute_taxonomies</code> bevat alleen beschrijvingen van de taxonomieën. Da's ca. hetzelfde als de 'hoofd-taxons'. Voorbeeld:
 
−
 
 
−
<pre>
 
−
SELECT * FROM kbo3.wp_woocommerce_attribute_taxonomies;
 
−
 
 
−
 
 
−
attribute_id  attribute_name      attribute_label    attribute_type  attribute_orderby  attribute_public
 
−
------------  --------------      -----------------  --------------  -----------------  ----------------
 
−
5       breedte            Breedte       text         name_num     1
 
−
6       diepte           Diepte       text         name_num     1
 
−
7       lengte           Lengte       text         name_num     1
 
−
8       automatische_stop  Automatische stop  text         name             1
 
−
</pre>
 
−
 
 
−
* Subtaxons verschijnen gewoon in <code>wp_terms</code>. Dat maakt het gemakkelijk om met subtaxons te werken, want het werkt hetzelfde als voor gewone categorieën.
 
−
* Tabel <code>wp_term_taxonomy</code> verbindt taxons met taxonomieën. Hier kun je zien dat WooCommerce 'onder water' losse taxonomieën defineert voor alle attributen. Je herkent ze aan de prefix <code>pa_</code>. Merk op dat <code>parent=0</code>: Er wordt niet gebruik gemaakt van hierarchie! Ook niet zo vreemd, omdat je bij attributen max. twee lagen hebt. Voorbeeld:
 
−
 
 
−
<pre>
 
−
SELECT * FROM kbo3.wp_term_taxonomy where taxonomy like "pa_%";
 
−
 
 
−
term_taxonomy_id  term_id  taxonomy    description    parent  count
 
−
----------------  -------  ----------  -------------  ------  -----
 
−
110                110      pa_breedte  Breedte-taxon  0        0
 
−
</pre>
 
−
 
 
−
=== Velden ===
 
−
 
 
−
Dit zijn de velden die ik zoal tegenkom. Ze zijn inconsistent en niet-intuïtief
 
−
 
 
−
''' Name - attribute_name '''
 
−
 
 
−
Shown on the front-end
 
−
 
 
−
''' Slug - attribute_label '''
 
−
 
 
−
Max. 28 karakters.
 
−
 
 
−
''' attribute_type '''
 
−
 
 
−
Het soort control dat gebruikt wordt als interface??? Bv.:
 
−
 
 
−
* <code>select</code> - Beperkt aantal keuzes, zoals een lookup-tabel of voor Boolese waarden
 
−
* <code>text</code> - Tekstveld, lijkt me.
 
−
 
 
−
''' Enable Archives'''
 
−
 
 
−
Dus dat je een 'taxon-pagina' hebt. Altijd doen. Voor Attributes-taxonomieën kun je helaas geen afbeelding of tekst toevoegen (itt. gewone Categorieën) [https://premium.wpmudev.org/forums/topic/enable-archives-option-in-woocommerce]
 
−
 
 
−
''' Custom ordering - attribute_orderby '''
 
−
 
 
−
Niet zo spannend:
 
−
 
 
−
* <code>menu_order</code>
 
−
* <code>name</code>
 
−
* etc.
 
−
 
 
−
''' attribute_public '''
 
−
 
 
−
Taxonomieën worden binnen een WordPress-site veelvuldig gebruikt voor interne aangelegenheden. Bv. om vertalingen bij te houden. Vandaar dat je er voor kunt kiezen om attribuut-taxonomieën verborgen te houden voor gebruikers.
 
−
 
 
−
=== Hoofdtaxon toevoegen ===
 
−
 
 
−
Nieuwe hoofdtaxons toevoegen, doe je mbv. <code>wp_insert_term</code>. Aangezien ''Attributes'' een speciaal geval is van een ''categorie'', zou je verwachten dat dit werkt. Maar dat doet het niet. Gelukkig kun je dit op een meer low-level fixen mbv. <code>$wpdb</code>. Daar gebruik ik deze functies voor, die ik plaats in <code>functions.php</code> van de betreffende sites. Geïnspireerd op [https://wordpress.stackexchange.com/questions/244335/creating-custom-woocommerce-attribute-taxonomies-from-a-plugin]:
 
−
 
 
−
<pre>
 
−
function dvb_add_attribute_taxonomy($attribute)
 
−
{
 
−
    # Add a WooCommerce Attribute-taxonomy
 
−
    #######################################################################################################
 
−
    #
 
−
    # * Somehow, the usual function register_taxonomy doesn't work for WooCommerce Attributes, hence the
 
−
    #  lower-level approach in this function
 
−
    # * Based on the example https://wordpress.stackexchange.com/questions/244335/creating-custom-woocommerce-attribute-taxonomies-from-a-plugin
 
−
    # * Jeroen Strompf, De Vliegende Brigade - April 2019
 
−
    # * To be included in functions.php where appropriate
 
−
 
 
−
 
 
−
    #######################################################################################################
 
−
    # Get acces to $wpdb class
 
−
    #######################################################################################################
 
−
    #
 
−
    global $wpdb;
 
−
 
 
−
 
 
−
    #######################################################################################################
 
−
    # Verify input
 
−
    #######################################################################################################
 
−
    #
 
−
    if (empty($attribute['attribute_type'])) { $attribute['attribute_type'] = 'text';}
 
−
    if (empty($attribute['attribute_orderby'])) { $attribute['attribute_orderby'] = 'menu_order';}
 
−
    if (empty($attribute['attribute_public'])) { $attribute['attribute_public'] = 0;}
 
−
    if (empty( $attribute['attribute_name'] ) || empty( $attribute['attribute_label'] ) )
 
−
    {
 
−
            return new WP_Error( 'error', __( 'Attribute name and/and slug is missing.', 'woocommerce' ) );
 
−
    }
 
−
    elseif ( ( $valid_attribute_name = dvb_check_attribute_name( $attribute['attribute_name'] ) ) && is_wp_error( $valid_attribute_name ) )
 
−
    {
 
−
            return $valid_attribute_name;
 
−
    }
 
−
    elseif ( taxonomy_exists( wc_attribute_taxonomy_name( $attribute['attribute_name'] ) ) )
 
−
    {
 
−
            return new WP_Error( 'error', sprintf( __( 'Slug "%s" already in use', 'woocommerce' ), sanitize_title( $attribute['attribute_name'] ) ) );
 
−
    }
 
−
 
 
−
 
 
−
    #######################################################################################################
 
−
    # Insert into WordPress
 
−
    #######################################################################################################
 
−
    #
 
−
    $wpdb->insert( $wpdb->prefix . 'woocommerce_attribute_taxonomies', $attribute );
 
−
 
 
−
    do_action( 'woocommerce_attribute_added', $wpdb->insert_id, $attribute );
 
−
 
 
−
    flush_rewrite_rules();
 
−
    delete_transient( 'wc_attribute_taxonomies' );
 
−
 
 
−
    return true;
 
−
};
 
−
 
 
−
function dvb_check_attribute_name( $attribute_name )
 
−
{
 
−
    # Check if a given attribute name is valid
 
−
    #######################################################################################################
 
−
    #
 
−
    # * Based on the example https://wordpress.stackexchange.com/questions/244335/creating-custom-woocommerce-attribute-taxonomies-from-a-plugin
 
−
    # * Jeroen Strompf, De Vliegende Brigade - April 2019
 
−
    # * To be included in functions.php where appropriate
 
−
 
 
−
    if ( strlen( $attribute_name ) >= 28 )
 
−
    {
 
−
return new WP_Error( 'error', sprintf( __( 'Slug "%s" is longer than 28 characters)', 'woocommerce' ), sanitize_title( $attribute_name ) ) );
 
−
    }
 
−
    elseif ( wc_check_if_attribute_name_is_reserved( $attribute_name ) )
 
−
    {
 
−
return new WP_Error( 'error', sprintf( __( 'Slug "%s" is not allowed because it is a reserved term.', 'woocommerce' ), sanitize_title( $attribute_name ) ) );
 
−
    }
 
−
    return true;
 
−
};
 
−
</pre>
 
−
 
 
−
Voorbeeld van een aanroep:
 
−
 
 
−
<pre>
 
−
<?php
 
−
 
 
−
###############################################################
 
−
# Call require_once
 
−
###############################################################
 
−
#
 
−
# Functions "dvb_add_attribute_taxonomy" and
 
−
# "dvb_check_attribute_name" have been included in functions.php.
 
−
# They become available through this "require_once" command
 
−
#
 
−
require_once("/home/strompf/www/kbo3.dvb/wp-load.php");
 
−
 
 
−
 
 
−
###############################################################
 
−
# Define new attribute-taxonomy
 
−
###############################################################
 
−
#
 
−
$attribute_definition = array
 
−
(
 
−
'attribute_name' => 'attribute-naam (2)',
 
−
'attribute_label' => 'attribute-plakker (2)',
 
−
'attribute_type' => 'text',
 
−
'attribute_orderby' => 'menu_order',
 
−
'attribute_public' => false
 
−
);
 
−
 
 
−
 
 
−
###############################################################
 
−
# Create this new attribute-taxonomy
 
−
###############################################################
 
−
#
 
−
dvb_add_attribute_taxonomy($attribute_definition);
 
−
</pre>
 
−
 
 
−
=== Subtaxons toevoegen ===
 
−
 
 
−
* ''Attribuut-taxonomieën'' zijn niet-hiërarchisch, en zitten iets anders in elkaar dan product_cat-taxonomieën:
 
−
* Subtaxons toevoegen, gaat op dezelfde manier als voor product_cat-taxonomieën, met één verschil: De naam van de taxonomie, is de naam, voorafgegaan door <code>pa_</code>.
 
−
 
 
−
Voorbeeld uit een SQL-script, waarbij <code>pa_breedte</code> de betreffende taxonomie is:
 
−
 
 
−
<pre>
 
−
# Create table
 
−
##############
 
−
#
 
−
create table dim1_taxons_tmp
 
−
select distinct
 
−
dim1,
 
−
    concat
 
−
    (
 
−
"wp_insert_term('",
 
−
        replace(dim1, ".", ","),"'",
 
−
        ", 'pa_breedte',",
 
−
        " array('description' => 'Alle koolborstels met een breedte van ",replace(dim1, ".", ",")," mm',",
 
−
        " 'parent' => 0, 'slug' => 'breedte-",replace(dim1, "," ,""),"' ));"
 
−
    ) as dim1_php
 
−
from root_tmp;
 
−
</pre>
 
−
 
 
−
Je weet de 'pa-naam' pas met zekerheid, nadat er subtaxons zijn aangemaakt. Dan vind je 'm terug met zoiets als dit (in SQL):
 
−
 
 
−
<pre>
 
−
SELECT distinct taxonomy FROM kbo3.wp_term_taxonomy;
 
−
</pre>
 
−
 
 
−
Mochten er nog geen taxons zijn toegevoegd:
 
−
 
 
−
* Voeg er eentje handmatig toe, om het te testen
 
−
* Gebruik je gezond verstand om uit te vogelen wat de naam zou zijn.
 
−
 
 
−
Nog één voorbeeld:
 
−
 
 
−
<pre>
 
−
<?php
 
−
require_once("/var/www/kbo3.dvb/wp-load.php");
 
−
 
 
−
wp_insert_term
 
−
(
 
−
'Met automatische stop' ,
 
−
'pa_automatische_stop',
 
−
array
 
−
(
 
−
'description' => 'Alle koolborstels met automatische stop',
 
−
'parent' => 0,
 
−
'slug' => 'met-automatische-stop'
 
−
)
 
−
);
 
−
 
 
−
wp_insert_term
 
−
(
 
−
'Zonder automatische stop' ,
 
−
'pa_automatische_stop',
 
−
array
 
−
(
 
−
'description' => 'Alle koolborstels zonder automatische stop',
 
−
'parent' => 0,
 
−
'slug' => 'zonder-automatische-stop'
 
−
)
 
−
);
 
−
</pre>
 
  
 
== Categorieën verwijderen ==
 
== Categorieën verwijderen ==

Versie van 17 mei 2019 18:40

Onder Products vind je maar liefst drie taxonomieën: Categories, Tags en Attributes (kenmerken)

WordPress biedt verschillende manieren om gegevens zoals posts en producten te ontsluiten via taxonomieën. Dit artikel gaat vooral over de Categories-functionaliteit, inclusief WooCommerce Attributes, omdat dat een specifiek geval is van Categories. Dit artikel focust daarnaast op automatisering rondom taxonomieën.

Inleiding

Een taxonomie is een gestructureerde manier om informatie te ordenen. WordPress heeft hier meerdere systemen voor:

Terminologie

  • Taxonomie is de algemene term voor systemen om data te ordenen (of zoiets). Vaak gebruik ik het ook als synoniem voor Categorieën
  • Categories is een specifieke WordPress-functionaliteit, waarmee je zowel platte als hiërarchische taxonomieën kunt vormen. Ik vind de naam niet handig
  • Taxon is de benaming voor een term of label waarmee je objecten ordent. Meervoud schijnt taxa te zijn, maar taxons vind ik prettiger
  • Taxon-namen: Een bekend taxonomisch systeem (dat niets met WordPress te maken heeft), is de taxonomie van Linnaeus (Linnaean taxonomy). Hierbij hebben taxons hun eigen naam. Zoogdieren is daar een voorbeeld van. Ik merk dat ik het niet handig vind om te denken in namen-van-taxons
  • Elementen zijn de objecten die bij een taxon horen.

Meerdere taxonomische systemen

WordPress kent verschillende taxonomische systemen:

Categorieën

Het meest algemene taxonomische systeem van WordPress, heet Categorieën. Deze functionaliteit wordt op diverse plekken binnen een WordPress-site toegepast. Soms op een manier die zichtbaar is voor gebruikers, en soms op manieren die niet zichtbaar zijn. Al deze Categorie-instanties, zijn gescheiden van elkaar. Je hebt dus bv. een Categorie-taxonomie voor posts en een aparte Categorie-taxonomie voor producten.

Voorbeeld van de Categorie-taxonomieën van een site-in-aanbouw. category is hierbij de Categorie-taxonomie voor posts: 

SELECT distinct taxonomy FROM rt_tmp.wp_term_taxonomy;

category
language
nav_menu
post_translations
product_cat
product_tag
product_type
product_visibility
term_language
term_translations

product_cat

Product_cat is geen eigen taxonomisch systeem, maar een Categorie-taxonomie, toegepast op WooCommerce-producten. Voorbeeld: 

SELECT distinct taxonomy FROM kbo3.wp_term_taxonomy;

category
nav_menu
pa_dimensie-1
product_cat
product_type
product_visibility

Hierbij is product_cat de Categorie-taxonomie voor products. Vandaar dat ik dit vaak product_cat noem.

Predefined Attributes

WooCommerce kent naast Categorieën, een taxonomisch systeem dat 'Attributes oftewel Kenmerken heet. Onder water is dit gewoon een Categorie-taxonomie, met wat toeters, bellen, maar ook met enkele beperkingen. Deze WooCommerce Attributen komen in twee smaken:

  • Predefined attributes
  • Custom attributes.

De predefined attributes lijken in grote lijnen sterk op Categorieën. Het voorbeeld van de site van hierboven: 

SELECT distinct taxonomy FROM kbo3.wp_term_taxonomy;

category
nav_menu
pa_dimensie-1
product_cat
product_type
product_visibility

Hierbij is pa_dimensie-1 een attribute. Hier kun je zien dat dat een bijzonder geval is van een Categorie-taxonomie. Verder heegt dit attribute de naam Dimensie-1. Blijkbaar voegt WooCommerce daar de prefix pa_ (product attribute?) aan toe.

Custom Attributes

De WooCommerce Custom Attributes zijn kenmerken die je ad-hoc, dus per product kunt defineren. Waarom je dit zou doen? Waarschijnlijk omdat het gewoon prettig werken is, dat je on the fly je datamodel kunt vaststellen, ipv. vantevoren. En omdat er altijd wel gekke producten bij zitten, die niet in het systeem passen.

Voorbeeld van WooCommerce Custom product attributes

Tags

Als laatste kent WooCommerce een systeem voor tags. Bv. om een folkstonomy te bouwen. Nog niet mee gewerkt.

Custom fields

Het hoort niet thuis in dit rijtje, maar toch behandel ik het hier, omdat ik anders in de war raak: custom fields (maatwerk-velden) zijn heel handig, maar hebben niets met taxonomieën te maken. Ze dienen een heel ander doel: Informatie omtrent een product op een gestructureerde manier aanbieden. Toevallig kan diezelfde informatie soms ook geschikt zijn voor een taxonomie, maar dan nog moet je de informatie twee keer incorporeren in de site: Eén keer als custom field, en één keer via een taxonomisch systeem (product_cat of attributes, lijkt me).

Vergelijking tussen deze systemen

Attributes vs. categorieën vs. tags

Producten - Categorieën
producten - Attributen
producten - Tags - Tot op heden nog niet gebruikt (april 2019)
Ah, dit is de truuk tav. attributen (kenmerken): Het gaat om aspecten die inherent aan het product zijn. Ze komen ook terug op de productpagina's en (hopelijk) ook bij importeren

Intuïtief/ergonomisch

Dit voorbeeld benadert het verschil tussen attributes en categorieen als volgt aan de hand van een voorbeeld van het kopen van een spijkerbroek bij (in mijn geval) C&A:

  • Categorieen: Herenkleding >> Vrije tijd >> Spijkerbroeken
  • Attributes: merk, maat, stijl, etc.

Klinkt intuïtief/ergonomisch, maar is het relevant? Als ik alles met categorieën kan, waarom dan überhaupt attributen gebruiken? Het heeft namelijk een paar stomme beperkingen (zie verderop)

Inhoudelijke verschillen

Aspect Categorieën Attributen
Archief-pagina's Een 'archief-pagina oftewel (taxon-pagina) is hetzelfde als een taxon. Je kunt tekst en één afbeelding toevoegen Alleen ruimte voor tekst
Hiërarchie Geen probleem Kunnen nooit hiërarchisch zijn. Je kunt meerdere hoofdtaxons defineren (bv. lengte, breedte & hoogte) en per hoofdtaxon meerdere taxons defineren. Maar geen additionele lagen
Taxons Archief-pagina's en taxons zijn hetzelfde. Dus ruimte voor tekst en één afbeelding Alleen ruimte voor tekst

Conclusies

Ik houd het spijkerbroek-voorbeeld aan:

  • Attributes gebruik ik voor eigenschappen van het betreffende product
  • Categorieen gebruik ik voor het zoeken/ontsluiten van het betreffende product

Categorieën - Details

Taalspecifiek

Taxons zijn taal-specifiek. Als je bv. een Duits produc.t probeert toe te voegen aan een Nederlandstalige categorie, wordt er een kopie gemaakt van die categorie in het Duits (automatisch gekoppeld aan de NL-categorie!), en dat product wordt daar toegevoegd

Taxonpagina (archives page)

  • Elke categorie-taxon heeft z'n eigen pagina. Dus z'n eigen Archives page. Standaard kun je een afbeelding en description-tekst per taxon toevoegen. Het hangt van het thema af of het getoond wordt - Altijd doen!
  • WooCommerce Attribuut-taxons hebben echter niet zo'n eigen pagina.

Database-model

Dit hoofdstuk is incompleet. Daarnaast blijkt kennis van het achterliggende database-model van weinig belang te zijn, als je werkt via de gebruikelijk API's.

De vier tabellen die een rol spelen rondom Categorie-taxonomieën. Merk op dat WordPress bijna nooit relaties defineert tussen tabellen
Categorie-taxonomieën: De drie belangrijkste tabellen + hun relatie [1]

wp_options

Tabel wp_options bevat algemene informatie over taxonomieën, bv. bij welk type objecten ze horen: Blijkbaar mag een taxonomie met maar één klasse van objecten geassociëerd zijn.

wp_terms

Tabel wp_terms bevat alle taxons, voor alle taxonomieën, voor alle talen. Welke taxon je ook zoekt: Het staat altijd in deze tabel.

Voorbeeld van de inhoud.pll staat vermoedelijk voor Polylang. Ik weet alleen niet waar die taxons voor zijn
Ander voorbeeld. De taxons 10 mm en 20 mm hebben betrekking op de attribute Dimensie-1 (zie eerder voorbeeld)

wp_term_taxonomy

Vermoedelijk is dit de centrale tabel rondom taxonomieën, en niet wp_terms - Deze laatste is vrij doods. Tabel wp_term_taxonomy geeft aan bij welke taxonomie een taxon hoort, verschaft additionele informatie, en regelt nog een paar dingen. Velden:

  1. term_taxonomy_id - Primaire sleutel
  2. term_id - Taxon waar dit record betrekking op heeft
  3. taxonomy - Naam van de taxonomie waar deze taxon deel van uitmaakt
  4. description - Aanvullende informatie. Denk daarbij aan serialised data voor niet-publieke taxons
  5. parent - Parenteel-taxon (is dat Nederlands?). Niet-hierarchische taxonomie? Dan waarde 0
  6. count - Aantal elementen (denk ik - Nu niet al te belangrijk).
Voorbeeld van de inhoud van tabel wp_term_taxonomy

wp_term_relationships

  • Tabel wp_term_relationships is een tussentabel waardoor het mogelijk is om meerdere objecten te koppelen met meerdere taxons en vice versa. Ik geloof dat je altijd een tussentabel nodig hebt als je een veel-op-veel-relatie wilt hebben
  • Ik heb de indruk dat deze tabel een samengestelde primaire sleutel heeft: object_id+term_taxonomy_id.

wp_termmeta

  • Tabel wp_termmate bevat aanvullende taxon-gerelateerde info
  • Alsof deze tabel een "extra'tje" is, voor data die niet gemakkelijk in wp_terms_taxonomy past (bv. binaire data, dus data met een entiteit- en een waardeveld)
  • Voorbeeld: De afbeelding en description voor een taxonpagina, vind je als twee losse records in deze tabel.

product_cat

Verplaatst naar Product cat-taxonomieën (WordPress). Alles wat nog hier staat, zijn dingen die nog niet af zijn.

product_cat - Taxons & producten associëren

Mbv. wp_set_object_terms kun je eenvoudig taxons en producten met elkaar associëren. In dit voorbeeld wordt een WooCommerce-product met ID 0901 (klopt dat wel? Het zou toch gewoon een integer moeten zijn, dus zonder voorloopnul?) gekoppeld aan taxon Bosch uit de taxonomie product_cat: 

wp_set_object_terms("0901", "Bosch", "product_cat");

en hier hetzelfde, maar dan ahv. de term_id (niet geverifiëerd) - Handig als namen niet uniek zijn (slugs zijn trouwens altijd uniek): 

wp_set_object_terms("0901", 104, "product_cat");

Het brengt echter twee issues met zich mee:

$object_id achterhalen

De truuk is waarschijnlijk, om vanuit het dwh in de db van de site te koekeloeren, en zodoende de object-ID's te achterhalen. Fluitje van een cent.

Voorbeeld: Alle producten associëren met een fabrikant

De volgende stap: Hoe zorg ik dat alle producten die een element zijn van taxon Bosch, als zodanig geassociëerd worden?

DWH-SQL-code: 

#
# Connect all relevant products with taxon "Bosch"
######################################################################################################
#

######################################################################################################
# Create php code
######################################################################################################
#
drop table if exists tmp;

create table tmp 
select distinct sku
from brush_tool_asein_201808 
where tool_brand like "Bosch"
order by sku;

call add_column_unless_exists("tmp", "exec", "text");

update tmp
set exec = concat
(
	"wp_set_object_terms(",
	char(34), sku, char(34),
	", ", char(34), "Bosch", char(34),
	", ", char(34), "product_cat", char(34), ");"
);

select * from tmp;


######################################################################################################
# Export code
######################################################################################################
#
call export_save_php("taxonomy_terms", "tmp", "exec", "/home/strompf/www/kbo3.dvb");

Een deel van het resulterende script: 

<?php
require_once("/home/strompf/www/kbo3.dvb/wp-load.php");
wp_set_object_terms("0100", "Bosch", "product_cat");
wp_set_object_terms("0101", "Bosch", "product_cat");
wp_set_object_terms("0102", "Bosch", "product_cat");
wp_set_object_terms("0103", "Bosch", "product_cat");
wp_set_object_terms("0104", "Bosch", "product_cat");
wp_set_object_terms("0105", "Bosch", "product_cat");
wp_set_object_terms("0107", "Bosch", "product_cat");
wp_set_object_terms("0108", "Bosch", "product_cat");

Dit bestand uitvoeren met let op -f: 

php -f ./05-taxonomy_terms-20190413-1627

Leuke extra: De local working directory hoeft niet te worden aangepast! Dankzij het require_once-commando, wordt het script automatisch uitgevoerd binnen de juiste WordPress-site.

Attribuut-taxonomieën

Zie Attribuut-taxonomieën (WooCommerce)

Categorieën verwijderen

Nog niet gelukt. Zie PHP-API » get_categories

Zie ook

Bronnen

Algemeen

Attributes

Overgenomen van "https://wiki.devliegendebrigade.nl/index.php?title=Taxonomieën_(WordPress)&oldid=18083"