-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Events: Use a showcase like approach for the events list/archive #1124
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This WFM 👍🏻
Note: the filters are not being applied to the results set yet.
This was the part that didn't feel great to me, since it's shoehorning arbitrary data from the wporg_events
table into a WP_Query
flow. The opposite approach in WordPress/wporg-mu-plugins#523 has it's own set of problems, though, so I think this PR is at least as good, and probably better.
public_html/wp-content/themes/wporg-events-2023/src/event-list/index.php
Outdated
Show resolved
Hide resolved
public_html/wp-content/themes/wporg-events-2023/templates/page-upcoming.html
Show resolved
Hide resolved
Try using a php block that queries. Example query filtering. add block build script. Add the patterns Hook in another filter. Rename template. Some minor updates. Add the month filter
I merged in the Past Events template in 9cc0b23 |
Opened up a PR for adjusting the time block: |
@@ -46,7 +46,7 @@ | |||
<!-- wp:column {"width":"33.33%","fontSize":"medium","fontFamily":"eb-garamond"} --> | |||
<div class="wp-block-column has-eb-garamond-font-family has-medium-font-size" style="flex-basis:33.33%"><!-- wp:group {"style":{"border":{"radius":"2px","width":"1px"},"spacing":{"padding":{"left":"var:preset|spacing|30","top":"var:preset|spacing|20","bottom":"var:preset|spacing|20"}}},"borderColor":"light-grey-1","layout":{"type":"constrained"}} --> | |||
<div class="wp-block-group has-border-color has-light-grey-1-border-color" style="border-width:1px;border-radius:2px;padding-top:var(--wp--preset--spacing--20);padding-bottom:var(--wp--preset--spacing--20);padding-left:var(--wp--preset--spacing--30)"><!-- wp:paragraph {"style":{"layout":{"selfStretch":"fit","flexSize":null},"elements":{"link":{"color":{"text":"var:preset|color|charcoal-0"}}}},"textColor":"charcoal-0","fontSize":"heading-6"} --> | |||
<p class="has-charcoal-0-color has-text-color has-link-color has-heading-6-font-size">540,537 members</p> | |||
<p class="has-charcoal-0-color has-text-color has-link-color has-heading-6-font-size">540,537 attendees</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it'd be accurate to change this. That number is the # of meetup.com group members (plus WordCamp attendees, but that doesn't affect it significantly), and the number of attendees is likely to be significantly different.
If we really want to say attendees, we could try to estimate the # based on RSVPs, but I don't think it'd be accurate enough to publish. IMO members is the most accurate/meaningful stat we can use here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that context. I was going off the designs. I'll provide that feedback and switch it back to members today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO members is the most accurate/meaningful stat we can use here.
I definitely see what you mean. I'm just unsure if "members", despite being accurate, is the right term to use. It does have hints of exclusivity and seems directly tied to Meetup.com's terminology, not necessarily WordPress's. When "members" are talked about in WP ways, I've typically seen it explicitly contextualized as "community members"... which is too long (as usual 😅).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So summing up the problem, if we use "attendees", we will be underrepresenting the actual number of attendees.
I also find members
to be an inclusive term. What about just people
?
Simple is as simple does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
people
is accurate and simple, for sure. Also feels too generic/passive. (and what of all the pet contributors? 😎)
I'd suggest one of the following (for now), with my preference being 1:
participants
: technically accurate, the bar for participation can be fluid, i.e., as low as just becoming a member on Meetup.com or as high as attending and contributing at a WordCamp.contributors
: perhaps not entirely inclusive/accurate, but directly related to the project and also used elsewhere on the page already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 that's a good point, we definitely don't want it to feel exclusionary. I like participants
, thanks for thinking of that!
I think the problem with attendees
is more that it _over_represents the number of attendees, since so many people join a meetup group, and even RSVP to an event, but don't actually show up. IMO accuracy is the most important factor, and it'd be better to err on the side of too low than too high. My concern is that inflating stats, even unintentionally, would erode trust.
I'll go ahead and update it to participants
since we're coming up on the deadline to launch, but I'm happy to continue discussing it if y'all would like to iterate on that, or make any changes.
public_html/wp-content/themes/wporg-events-2023/src/event-list/index.php
Outdated
Show resolved
Hide resolved
$events = get_events( $attributes['events'], 0, 0, $facets ); | ||
|
||
// Get all the filters that are currently applied. | ||
$filtered_events = array_slice( filter_events( $events ), 0, 10); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is cutting the list off at 10, but we only want that for the homepage. Maybe the block should accept a limit
attribute that defaults to 50
or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, good idea. I was thinking about the grouping as well. Should we pass in a groupyByMonth
property? Feels too specific.
Alternatively, we can pass a "heading" property to this list block and create a wrapper block where we use the query results to loop and output multiple instances of the event list block. I'll look at that today.
<div class="wp-block-group alignwide" | ||
style="padding-right:var(--wp--preset--spacing--edge-space);padding-bottom:var(--wp--preset--spacing--50);padding-left:var(--wp--preset--spacing--edge-space)"> | ||
|
||
<!-- wp:pattern {"slug":"wporg-events-2023/event-list-filters-archive"} /--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't exist in the repo, do you have it locally? Or should this be event-list-filters
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here as #1124 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, I was on late last night. Fuzzy brain. Forgot to add it to git.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it still need to be added? I just worked around it in 303e77f, but I'm not sure if that matched what you have locally
<div class="wp-block-group"><!-- wp:search {"showLabel":false,"placeholder":"Search events...","width":100,"widthUnit":"%","buttonText":"Search","buttonPosition":"button-inside","buttonUseIcon":true,"className":"is-style-secondary-search-control"} /--></div> | ||
<!-- /wp:group --> | ||
|
||
<!-- wp:template-part {"slug":"event-filters"} /--> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this either, do you have it locally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added it in 303e77f so I can work on it today, but free free to change that if you had something else in mind
e36afed
to
0de639a
Compare
This is a draft PR exploring the use of components from https://github.com/wordpress/wporg-showcase-2022 to build out the "All Events" page. This is a Work in Progress.
Why I think this is the best approach
What's not perfect here yet
Current
Note: the filters are not being applied to the results set yet.