Open tn3rb opened 3 years ago
Block Name | Description / Value Displayed | Options |
---|---|---|
Event Name | EE_Event::name() |
style? |
Event Description | EE_Event::description() |
style? |
Event Categories | EE_Event::get_all_event_categories() |
style? |
Event URL | EE_Event::get_permalink() |
link vs button style? |
Event Author | EE_Event::wp_user() |
avatar? link? style? |
Event Phone # | EE_Event::phone() |
style? |
Members Only? | display banner if event is members only EE_Event::member_only() |
style? |
Event Sold Out? | display banner if event is sold out EE_Event::is_sold_out() |
style? |
Event Postponed? | display banner if event is postponed EE_Event::is_postponed() |
style? |
Event Cancelled? | display banner if event is cancelled EE_Event::is_cancelled() |
style? |
Block Name | Description / Value Displayed | Options |
---|---|---|
Date Name | EE_Datetime::name() |
style? |
Date Description | EE_Datetime::description() |
style? |
Dates List | EE_Event::datetimes() |
sort:(chronological, custom order); show expired; style? |
Next Upcoming Date | EE_Event::datetimes(queryArgs) |
style? |
Start Date | EE_Datetime::start_date() |
show time? format? style? |
End Date | EE_Datetime::end_date() |
show time? format? style? |
Date Range | EE_Datetime::date_range() |
show time? format? style? |
Date Sold Out? | display banner if date is sold out EE_Datetime::sold_out() |
style? |
Block Name | Description / Value Displayed | Options |
---|---|---|
Tickets List | EE_Event::tickets() |
available only? specific dates? specific tickets? style? |
Available Tickets | # of tickets left for sale | specific dates? specific tickets? style? |
Ticket Sold Out? | display banner if ticket is sold out EE_Ticket::available() |
style? |
Get Tickets Button | link to reg page? link to external reg page? | Ticket ID? style? |
Buy Tickets Button | choose ticket qty & go to checkout | Ticket ID? style? |
Buy Ticket Bundle | preset ticket qty & go to checkout | Ticket ID? Quantity? style? |
Block Name | Description / Value Displayed | Options |
---|---|---|
Venue Name | EE_Venue::name() |
style? |
Venue Description | EE_Venue::description() |
style? |
Venue Categories | EE_Venue::get_all_event_categories() |
style? |
Venue Author | EE_Venue::wp_user() |
avatar? link? style? |
Venue Phone # | EE_Venue::phone() |
style? |
Venue URL | EE_Venue::venue_url() |
link vs button style? |
Virtual Phone # | EE_Venue::virtual_phone() |
style? |
Virtual URL | EE_Venue::virtual_url() |
link vs button style? |
Venue Full Address | EEH_Address::format() |
type:('inline', 'multiline')? style? |
Venue Address | EE_Venue::address() + EE_Venue::address2() |
style? |
Venue City | EE_Venue::city() |
style? |
Venue State | EE_Venue::state() |
format(abbreviation, full)? style? |
Venue Country | EE_Venue::country() |
format(abbreviation, full)? style? |
Venue Zip Code | EE_Venue::zip() |
style? |
Venue Capacity | EE_Venue::capacity() |
style? |
Venue Map | EE_Venue::google_map_link() |
style? |
Venue Events List | EE_Venue::events() |
upcoming only? style? |
Then once we have created a bunch of super simple blocks like the above we can either:
work on much more complex blocks like:
Ticket Selector: maybe multiple ticket selector blocks like the ones listed above so that users have more options available for how they want their tickets presented but without having ALL of that complexity jammed into one block.
Events Lists: same idea, instead of one complex event list block with a ton of controls, create completely separate blocks so that the complexity of each block can be reduced. This can essentially replace some of our template add-ons like:
eea-events-table-template
eea-calendar-table-template
eea-category-accordian-template
eea-events-grid-view-template
so because of that, we may want to release these as some kind of "Advanced Gutenberg Layouts" add-on
OR
+1 to Block patterns. I do like the granularity of the individual blocks, but that's going to irritate and tire people out if they have to add each element all the time. We should come up with some smart patterns that make it easy for people to publish something they like. For example: free events (no prices), buy tickets (editable buttons that say "buy now" instead of "register now"), etc.
Also if we can make the text elements of the blocks editable, that'll help with translation issues.
Another event list element might be the ability to search the events by keyword.
Another event list element might be the ability to search for events by location.
Another event list element might be to just use a dropdown or icon to change the layout from a calendar to a month list, to a week list, to a day list, to photo (grid) view, to a map view, etc.
but that's going to irritate and tire people out if they have to add each element all the time
reusable blocks might come handy here
https://github.com/WordPress/gutenberg/tree/master/packages/reusable-blocks
@garthkoyle
I do like the granularity of the individual blocks, but that's going to irritate and tire people out if they have to add each element all the time.
right. totally agree. this would just be as a start, primarily to help "developers" (strongly emphasized finger quotes) working on custom designs for infrequent, but big events like a yearly conference.
We should come up with some smart patterns that make it easy for people to publish something they like.
also totally agree. The more complicated blocks will however require more work to create and therefore take more time before they can be released. It should be relatively easy to pump out a bunch of simple blocks like I have listed above, which will at least give people something to work with while we work on more complex stuff.
For example: free events (no prices), buy tickets (editable buttons that say "buy now" instead of "register now"), etc.
Ya for complex blocks like the Ticket Selector or Event List, I do NOT want to go the route of trying to build one block that does everything, and am going to push for breaking things up based on their usage and/or functionality. So for example, with the ticket selector we can have different types like:
standard vanilla ticket selector: ie: what we have now
"Buy Now" buttons for individual tickets or ticket bundles (already listed above in table)
RSVP / free ticket selector: for events that do not require payment to reserve space
"Dude! Where's my Ticket Selector?": ie: max registrations per txn = 1
Date Picker ticket selector: uses calendar to select dates for tickets
Search Box ticket selector: text field (+ other options?) for searching available tickets that meet the search criteria
Now that said, it might still be best to have only ONE actual ticket selector block, but then have the very first configuration option be a way to select one of the above types, and THEN only display additional config options as needed for that specific type of ticket selector.
Also if we can make the text elements of the blocks editable, that'll help with translation issues.
Great idea and much easier to implement with React and Blocks.
Another event list element might be the ability to search the events by keyword. Another event list element might be the ability to search for events by location. Another event list element might be to just use a dropdown or icon to change the layout from a calendar to a month list, to a week list, to a day list, to photo (grid) view, to a map view, etc.
More great ideas. I'll be using this Issue to create additional smaller issues for spawning actual PRs so we can revisit all of these ideas later in specific smaller issues.
@nicolad
reusable blocks might come handy here
hmmm... just from looking at that repo it's not really clear what the purpose of those are... do they allow you to combine a bunch of simpler blocks to create a more complex block? If so, then ya that would definitely by useful for this.
hmmm... just from looking at that repo it's not really clear what the purpose of those are... do they allow you to combine a bunch of simpler blocks to create a more complex block? If so, then ya that would definitely by useful for this.
here is what it does:
ya ok, we'll have to see if those can be preconfigured from within a plugin, although my gut feeling is no considering that WP is also adding block patterns, which essentially does the same thing:
We need to begin building out our Gutenberg Block Library
This should begin with a bunch of extremely simple blocks that just display a single basic entity detail such as:
these blocks should be dynamic so that any changes made to the above fields will instantly be reflected in posts that utilize these blocks (as opposed to having the block save the values at the time of post editing to the post data, which requires the post to be updated in order to capture the new changes)