Problem/Motivation
The Commerce Product Availability module exposes availability information for Drupal Commerce products and variations.
However, when site builders want to output this information in Schema.org JSON‑LD Offer markup, there is currently no token support for:
- availability
- deliveryLeadTime
- shippingDetails
This prevents easy integration with JSON‑LD generators (e.g., Metatag, custom preprocessors, or theme templates) and requires custom code to expose these values.
Providing tokens would allow site builders to output Offer‑related structured data without writing custom PHP.
Steps to reproduce
Need these tokens for Metatags
Proposed resolution
Add a Token type for Commerce Product Availability and expose the following tokens:
Token Description Example
- [commerce_product:current_variation:commerce_product_availability:schemaorg_availability] Returns the Schema.org availability URL https://schema.org/InStock
- [commerce_product:current_variation:commerce_product_availability:schemaorg_delivery_lead_time] Returns ISO 8601 duration or textual lead time P3D
- [[commerce_product:current_variation:commerce_product_availability:schemaorg_shipping_details] Returns shippingDetails JSON fragment or structured array { "shippingRate": ... }
- Add token definitions for the Offer properties.
- Map the module’s internal availability data to Schema.org URLs (e.g., InStock, OutOfStock, PreOrder).
- Provide values for delivery lead time and shipping details if configured.
- Add automated tests for token output.
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork commerce_product_availability-3591534
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
anybodyAttached you can find some crappy AI code which uses non-existing classes, but it should show the expected token outcome. Unsure what is usable and what is not. Simply should not be used for anything than demonstrating the idea behind ;)
Comment #4
anybodyComment #5
anybodyComment #6
anybodyComment #7
anybodyLet's do a quick fresh implementation by time :)
Comment #9
grevil commented@anybody, there is no "TokenTypeInterface" can we not simply define the tokens like in the already existing module file "CommerceProductAvailabilityTokenHooks"?
Comment #10
anybodyI know, see #3. It's just about the outcome.
Comment #11
grevil commentedComment #14
grevil commentedAlright, I still need to properly test this.
Especially the
part. Let me go through this with xdebug tommorow.
Comment #15
anybodyYes this is indeed wrong. Instead of providing a general global token, this token should only be available on commerce_product_variation entities!
So I guess will be something like (pseudocode)
Guess there are existing examples how to add further tokens on the entity level. Then we'll also always have the
$variationgiven, no need for a fallback.Comment #16
anybodyPS: The final token will then look like this:
[commerce_product:current_variation:commerce_product_availability:schemaorg_availability](for a product - most typical)[commerce_product_variation:commerce_product_availability:schemaorg_availability](for a product variation - less typical but one step shorter)Logic is always the same: The tokens act on the commerce_product_variation entity level!
Sorry my requirement specification was too general and buggy. Shit in, shit out... Updated it accordingly.
Comment #19
grevil commentedPlease review, the implementation with the computed property works even better!
Comment #20
anybodyLGTM, thx!!
Comment #22
anybodyComment #24
anybodyWorks like a charm! :)