Filteren op custom taxonomie niet mogelijk met Query Loop-blok

[rvdsteege]

We hadden bedacht om de reviews op bijvoorbeeld de pagina van een product te gaan tonen m.b.v. het Query Loop-blok. Om de reviews voor dat specifieke product op te vragen (waarvan de post ID in de meta van reviews wordt bewaard als _pronamic_review_product_id), loop ik eigenlijk tegen een beperking van het Query Loop-blok aan. De filters zijn namelijk beperkt (categorie, tags, auteur, zoekwoord):

Ik heb het nu zo gemaakt dat de standaard taxonomie voor categorieën wordt gebruikt (slug = product post ID, naam = product post titel), maar mooier zou zijn als we een custom taxonomie kunnen gebruiken of de waarde uit de meta. Dat is echter (nog) niet mogelijk, blijkt ook uit een open issue in WordPress/gutenberg:

#34977 Query Loop: Add custom taxonomies to the Filters options

[remcotolsma]

Ik ben binnen https://github.com/pronamic/leadlegends ook bezig geweest met het Query Loop-blok. Ik kwam in ieder geval de function build_query_vars_from_query_block( $block, $page ) functie tegen:

https://github.com/WordPress/WordPress/blob/adee0cbf6b0fb5535bf7c562ccf23ad4dda09419/wp-includes/blocks.php#L1067-L1155

https://github.com/WordPress/WordPress/blob/ebca9841e81c3d3b1cea8d9583898a40cdf9b677/wp-includes/blocks/post-template.php#L8-L37

Misschien kunnen we de block context wil aanpassen?

add_filter( 'render_block_context', function( $context, $parsed_block ) {
	if ( ! array_key_exists( 'blockName', $parsed_block ) ) {
		return $context;
	}

	if ( 'core/query' !== $parsed_block['blockName'] ) {
		return $context;
	}

	if ( ! array_key_exists( 'postType', $context ) ) {
		return $context;
	}

	if ( 'pronamic_review' !== $context['postType'] ) {
		return $context;
	}

	// Ok, we hebben een query block die reviews wil tonen, en nu?

	var_dump( $parsed_block );
	var_dump( $context );

	return $context;
}, 10, 2 );

Misschien iets doen a la:

$context['query']['search'] = 'pronamic-reviews-for-post:' . $context['postId'];

Beetje a la de 'advanced search syntax' van bijvoorbeeld GitHub:
https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests

[remcotolsma]

Bedenk me nu dat je dan natuurlijk dit ook gewoon in het block kunt opgeven:

Dit moet dan in combinatie met een pre_get_posts filter die de 'advanced search syntax' parsed:

https://github.com/WordPress/WordPress/blob/39bff93b6b274a873158a362725b1338ab1400e5/wp-includes/class-wp-query.php#L1793-L1804

Weet niet of dit the way to go is, het is een wild ideetje 🤓

[remcotolsma]

Via Slack hadden we dit nog ook nog even kort besproken:

Remco

Ja, bedacht me vanochtend nog dat het ook gewoon met categorieën zou kunnen… dat een beheerder gewoon handmatig een categorie aanmaakt en er voor zorgt dat een product en de bijbehorende reviews in dezelfde categorie worden gezet…
misschien niet perfect, maar misschien ook wel werkbaar

Reüel

Lijkt me niet heel handig als je 100'en reviews per dag binnenkrijgt (:wink:) en nadeel van die categorieën is ook dat ze op andere plekken kunnen opduiken hè. Dus bijvoorbeeld bij een blog/nieuws ofzo, dat is eigenlijk waar die standaard categorieën meestal voor gebruikt worden.

Remco

Klant zal wel niet zo snel 100'en reviews per dag binnenkrijgen, moeten de reviews ook niet al handmatig gepubliceerd worden? Is misschien ook beetje afhankelijk van hoeveel producten en dus categorieën zijn. Maar ben het eens dat het niet perfect is, maar misschien is het voor nu wel een simpele oplossing.

Ik zie dat in da3b8c6 wel automatisch [pronamic_review_object_post_id=%d] wordt toegevoegd.

Ik heb toch wel een beetje mijn twijfels bij deze implementatie, het is voor beheerders denk ik niet duidelijk dat dit onderwater gebeurd. Als je nu op een productpagina ook bijvoorbeeld wel alle reviews wilt laten zijn dan kan dat ook niet? Ik zou het voor nu gewoon op basis van categorieën doen. Zodra we deze plugin breder in gebruik hebben zien we dan wel of er behoefte is aan een dergelijke functionaliteit. We kunnen dan ook overwegen of we voor de [pronamic_review_object_post_id=%d] notatie gaan, of bijvoorbeeld review-for:%s. De search-operator:value notatie is misschien wel gebruiksvriendelijker en gebruikelijker?

• https://support.google.com/mail/answer/7190
• https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests

[LeoOosterloo]

@rvdsteege laten we voor nu wel gebruik maken van de standaard categorieën om reviews te kunnen filteren met de query loop. Dat is nu de kortste klap en dan kunnen we dat ook mooi testen op de site van Veenstra.

[rvdsteege]

Ik zie dat in da3b8c6 wel automatisch [pronamic_review_object_post_id=%d] wordt toegevoegd.

Ja klopt, sorry 😇 Ik was erg blij het gebruik van de categorieën te kunnen wegwerken:

1. om vervuiling/misbruik van categorieën te voorkomen;
2. het is niet toekomstbestendig, omdat het niet in templates in een block theme gebruikt kan worden;
3. bij gebruik van bijvoorbeeld de Gravity Forms Advanced Post Creation add-on wordt het lastiger met categorieën, omdat je dan ook altijd nog de juiste categorie zou moeten meegeven via het formulier (dat lijkt mij foutgevoelig en niet fraai; helemaal als het überhaupt overbodig is).

Meer controle over welke reviews er getoond worden is inderdaad wel fijn, in plaats van automatisch te filteren. Daarom is het filter in 6489c23 optioneel gemaakt. Het zoekfilter pronamic-reviews-for: gevolgd door de post ID van het gereviewde kan dan indien gewenst ingesteld worden in de zoekwoorden van het Query Loop-blok. Dit is m.i. overzichtelijker/duidelijker/eenvoudiger dan categorieën gebruiken (de naamgeving van het filter kan uiteraard nog wel gewijzigd worden, indien gewenst).

In een single block template is het voor de reviews van de huidige post ook mogelijk om pronamic-reviews-for:self te gebruiken (daarin kun je de juiste categorie niet instellen in het Query Loop-blok, omdat de categorie dan per post zou verschillen). Als je het filter nu op deze manier gebruikt, wordt het alleen op de frontend toegepast en helaas niet in de editor (doordat de post ID van het item dat je aan het bewerken bent onbekend is, tijdens het opvragen van de posts voor het Query Loop-blok in de editor).

[...] moeten de reviews ook niet al handmatig gepubliceerd worden.

Niet perse, ik begreep dat dat ook al wel automatisch gebeurt als klanten daar toestemming voor hebben gegeven. Een categorie zou dan dus al wel goed ingesteld moeten zijn.

[remcotolsma]

1. om vervuiling/misbruik van categorieën te voorkomen;

Ik zie het gebruik van categorieën niet per se als vervuiling/misbruik. Kan voor klanten ook een mooie manier zijn om alle content (en dus ook reviews) te bundelen in een categorie.

2. het is niet toekomstbestendig, omdat het niet in templates in een block theme gebruikt kan worden;

Hoe bedoel je dit?

3. bij gebruik van bijvoorbeeld de Gravity Forms Advanced Post Creation add-on wordt het lastiger met categorieën, omdat je dan ook altijd nog de juiste categorie zou moeten meegeven via het formulier (dat lijkt mij foutgevoelig en niet fraai; helemaal als het überhaupt overbodig is).

Dat kan een aandachtspunt zijn, weet niet of de betreffende klant de reviews altijd handmatig wil publiceren. Op https://www.gravityforms.com/add-ons/advanced-post-creation/ is wel het volgende te lezen:

• Assign Posts to Taxonomies – Assign terms from any of the taxonomies registered to your selected post type, including tags and categories.

Ik zie in https://github.com/pronamic/wp-pronamic-reviews-ratings/blob/develop/src/GravityForms.php ook logica voor het aanmaken van een post. In hoeverre dan "Gravity Forms Advanced Post Creation Add-On" nog een rol speelt of kan spelen heb ik nog niet kunnen bekijken. Is misschien ook nog wel een vraagstuk waar we naar kunnen kijken. Gaan we aanmaken van de post review regelen met "Gravity Forms Advanced Post Creation Add-On" of met een eigen implementatie. Of is dat al geen vraagstuk meer?

Het zoekfilter pronamic-reviews-for: gevolgd door de post ID van het gereviewde kan dan indien gewenst ingesteld worden in de zoekwoorden van het Query Loop-blok.

Ik neig wel zoals @LeoOosterloo ook noemde om het voor nu met categorieën te doen. Als we wel deze weg inslaan vraag ik me nog wel af of pronamic-reviews-for:123 wel de beste keuze is. Misschien is pronamic-reviews-for:slug nog wel iets gebruiksvriendelijker. Een pronamic-reviews-for:self is dan misschien ook niet nodig, dan kan de slug van de huidige post/pagina ingevoerd worden i.p.v. self.

Niet perse, ik begreep dat dat ook al wel automatisch gebeurt als klanten daar toestemming voor hebben gegeven. Een categorie zou dan dus al wel goed ingesteld moeten zijn.

Als ik kijk op https://www.veenstradejong.nl/wp-admin/admin.php?page=gf_edit_forms&view=settings&subview=gravityformsadvancedpostcreation&id=9&fid=1 dan wordt voor elke inzending een concept klaar gezet.

[rvdsteege]

Op de werkvloer besproken en inmiddels opgelost met twee 'zoekfilters' in a10a9f5 :

• pronamic-reviews-for-post
• pronamic-reviews-for-post-id:%d

Daarnaast komt er in WordPress ook ondersteuning voor custom taxonomies in het Query Loop block:

• https://make.wordpress.org/core/2022/02/03/whats-new-in-gutenberg-12-5-february-2nd/#query-loop-custom-taxonomies-filtering-and-more