Hey @franticape,
We apologize for the delay but this is tricky and is actually beyond the scope of our theme support as it involves Toolset which is a third party plugin.
We’ll answer your concern for the last time as it took significant time investigating this. If our answer still doesn’t solve the problem, please subscribe to our One Total Care so we can check this issue deeply.
Below is our final answer.
Given your current Condition:
{{dc:date:generic date="@{{dc:post:meta key="wpcf-fecha-webinar"}}" format="Ymd"}} after {{global.date({"format":"Ymd"})}}
There are two critical flaws in this specific condition syntax, plus the ongoing Looper Sorting issue:
1. Flaw #1: Broken Double-Quote Nesting (Syntax Error)
Look closely at the nested dynamic content tag:
date="@{{dc:post:meta key="wpcf-fecha-webinar"}}"
2. Flaw #2: Strict after Operator Excludes Today’s Events
-
The issue: The customer is using the strict
after operator (>).
-
The math on an event happening today:
- Formatted Webinar Date:
20260910
- Formatted Today:
20260910
- Condition evaluation:
20260910 after 20260910 $\rightarrow$ FALSE (Today is not strictly after Today).
-
The consequence: Any webinar scheduled for today immediately fails this condition. It gets excluded from the “Upcoming Webinars” section and ends up grouped with past events!
-
The Fix: Change the condition operator from
after to is or after (or >=).
3. The Sorting & compare=EXISTS Issue (Re-cap)
-
ASC Sorting: In
ASC order, posts missing wpcf-fecha-webinar in wp_postmeta (or posts with empty values "") sort first (0 / NULL). They fill up the looper limit, fail the element condition, and result in nothing being displayed on screen.
-
Why
compare=EXISTS gave 1 result: In Toolset/Types, postmeta rows are only written to the database when a field is explicitly filled out and saved. If only 1 post had been saved with a date populated, EXISTS correctly returns only 1 post. The customer likely updated/saved the other event posts later, which is why “things started working correctly” on their own.
How to Diagnose in Pro (Cornerstone)
Here is how you can step-by-step diagnose and prove these issues inside Pro:
Diagnostic Step 1: Check Dynamic Content Resolution (On-Screen Text Test)
Place a temporary Text Element inside the Looper Consumer to verify if tags resolve or fail due to syntax errors:
1. Raw Meta: "{{dc:post:meta key='wpcf-fecha-webinar'}}"
2. Generic Date: "{{dc:date:generic date="@{{dc:post:meta key='wpcf-fecha-webinar'}}" format="Ymd"}}"
3. Today's Date: "{{global.date({"format":"Ymd"})}}"
-
If #2 shows today’s date (
20260910) even though the meta timestamp is different: The nested DC tag failed to parse (check quotes).
-
If #2 and #3 match (
20260910 vs 20260910): You have confirmed why the after operator evaluates to FALSE for today’s events.
Diagnostic Step 2: Looper Output vs. Condition Visibility Check
To confirm if missing items are hidden by the condition or excluded by the query:
- Add a temporary status line inside the looper consumer:
Item {{dc:looper:index}} of {{dc:looper:count}} | Post ID: {{dc:post:id}}
-
Disable the Element Condition on the container.
- If all 5 items display
Item 1 of 5 through Item 5 of 5, the Looper Provider (Query) is working fine, and the Condition was hiding the elements.
- If only 1 item displays, the Looper Provider (Query) itself is only returning 1 item from the database.
Diagnostic Step 3: Verify Meta Key Presence in Database
If compare=EXISTS returns fewer posts than expected:
- Go to the WP Admin post editor for the missing events.
- Ensure the date field actually has a value selected and click Update. (WordPress/Toolset will not create a
wp_postmeta database entry until the post is explicitly saved with data).
- Alternatively, check using Query Monitor:
- Open Query Monitor on the page.
- View Database Queries $\rightarrow$ filter by
wp_postmeta.
- Inspect the SQL
WHERE clause to see which meta keys WP is filtering by.