linos
/
mobilizon-mirror
3
3
Fork 0
Code Issues 13 Pull Requests Projects Releases 1 Wiki Activity
Labels Milestones
New Issue

Add Gutenberg Block and Shortcode #2

Open
opened 11 months ago by linos · 16 comments
linos commented 11 months ago
Owner

Give the user the possibility to add events everywhere via Gutenberg Blocks and shortcodes.

Maybe use code from https://codeberg.org/linos/mobilizon-block

This may also make the archive page of the custom post type optional.

Give the user the possibility to add events everywhere via Gutenberg Blocks and shortcodes. Maybe use code from https://codeberg.org/linos/mobilizon-block This may also make the archive page of the custom post type optional.
linos added this to the 1.1 milestone 11 months ago
linos added the
enhancement
contribution welcome
 labels 11 months ago
rolf commented 6 months ago

Yes please (+1) ...

Yes please (+1) ...
linos commented 6 months ago
Poster
Owner

@rolf which one you think is more important?

@rolf which one you think is more important?
rolf commented 6 months ago

Hi @linos I was actually needing a widget but either of these solutions would do the trick. Ofcourse a block would be better going forward but a shortcode would ensure compatibility with sites running on older WP, ClassicWP, with the Classic Editor plugin or any other pagebuilder out there...

Hi @linos I was actually needing a widget but either of these solutions would do the trick. Ofcourse a block would be better going forward but a shortcode would ensure compatibility with sites running on older WP, ClassicWP, with the Classic Editor plugin or any other pagebuilder out there...
linos commented 6 months ago
Poster
Owner

@rolf Could you try using the Plugin "Ultimate Addons for Gutenberg". And then for example add the block "Post Grid".

Select post-type "mobilizon-mirror" and then adjust it to your design needs.

The following will not work, but I think, that these problems could be easily fixed:

  • The posts date is the date where the event was created or last updated not the date of the event
  • You can't sort the event based on their date

But aside from that it should work? Please give feedback, as implementing this would be easy and quick.

@rolf Could you try using the Plugin "Ultimate Addons for Gutenberg". And then for example add the block "Post Grid". Select post-type "mobilizon-mirror" and then adjust it to your design needs. The following will not work, but I think, that these problems could be easily fixed: - The posts date is the date where the event was created or last updated not the date of the event - You can't sort the event based on their date But aside from that it should work? Please give feedback, as implementing this would be easy and quick.
rolf commented 6 months ago

I have tried Shortcodes Ultimate which also includes a "Post list" comparable to what UAG offers (without the nice interface but still similar result) and indeed the post date shown is obviously the publication date not the event date.

At this point, I'm using https://github.com/wordpress-connector-for-mobilizon/connector-mobilizon for a widget (it also includes a shortcode) together with Mobilizon Mirror for the event pages themselves.

I have tried Shortcodes Ultimate which also includes a "Post list" comparable to what UAG offers (without the nice interface but still similar result) and indeed the post date shown is obviously the publication date not the event date. At this point, I'm using https://github.com/wordpress-connector-for-mobilizon/connector-mobilizon for a widget (it also includes a shortcode) together with Mobilizon Mirror for the event pages themselves.
linos commented 5 months ago
Poster
Owner

I currently can't decide between options, which both work.

  1. Still using the WordPress post_date field as the equivalent of the Mobilizon insertedAt field and using a meta key named beginsOn in Wordpress for storing Mobilizons beginsOn value for the event (this is what the plugin currently does). When a query is done in the front-end we can then use hooks to modify the query to sort by our beginsOn meta value and replace the post_date with the beginsOn meta value, so that most likely we display what we want as our "date".

  2. Using WordPress post_date value for storing the event start time (Mobilizons beginsOn value). We could the just keep Mobilizons updatedAt in the WordPress key post_modified and use this one for syncing/updating the events.

Pros and cons

The second version is faster, because wordpress allows to query to certain post_date ranges directly and sort them very efficiently. In the first version the query is much more complex, because a meta value is queried and used for sorting (all meta values are stored in a single json like string - at least to the best of my knowledge).

The second version seems like a hack to me - misusing the post_date value, I am just afraid that there might be drawbacks I currently can't think of.

Looking for advice. Help wanted.

### I currently can't decide between options, which both work. 1. Still using the WordPress `post_date` field as the equivalent of the Mobilizon `insertedAt` field and using a meta key named `beginsOn` in Wordpress for storing Mobilizons `beginsOn` value for the event (this is what the plugin currently does). When a query is done in the front-end we can then use hooks to modify the query to sort by our beginsOn meta value and replace the `post_date` with the `beginsOn` meta value, so that most likely we display what we want as our "date". 2. Using WordPress `post_date` value for storing the event start time (Mobilizons `beginsOn` value). We could the just keep Mobilizons `updatedAt` in the WordPress key `post_modified` and use this one for syncing/updating the events. ### Pros and cons The second version is faster, because wordpress allows to query to certain post_date ranges directly and sort them very efficiently. In the first version the query is much more complex, because a meta value is queried and used for sorting (all meta values are stored in a single json like string - at least to the best of my knowledge). The second version seems like a hack to me - misusing the `post_date` value, I am just afraid that there might be drawbacks I currently can't think of. Looking for advice. Help wanted.
emo commented 5 months ago

one issue you made was about "integrate event organizer plugin" perhaps you can decide how to handle between the two options in view of this?

one issue you made was about "integrate event organizer plugin" perhaps you can decide how to handle between the two options in view of this?
linos commented 5 months ago
Poster
Owner

The event organizer plugins I checked all use a meta_key for that and this is most likely the way to go, also as pointed out here https://fosstodon.org/@MediaFormat/107662976279500950!

The event organizer plugins I checked all use a meta_key for that and this is most likely the way to go, also as pointed out here https://fosstodon.org/@MediaFormat/107662976279500950!
rolf commented 5 months ago

The second version seems like a hack to me - misusing the post_date value, I am just afraid that there might be drawbacks I currently can't think of.

I agree. One drawback would be that WordPress tends to see posts with a post date in the future (which would be the case with planned events) as posts that are pending publication. When giving a post a furure post date, the post will not be shown on the front end anymore untill that date arrives.

On meta value and replace the post_date with the beginsOn meta value, so that most likely we display what we want as our "date".

Even when replacing the true post date with a future date on runtime, might cause unexpected results... When other filters or plugins are involved, things could get funky whith unexpected post dates.

Storing the event start and end dates/times as meta values is the way to go. But it then needs a custom query to get only future events and show them in correct order (based on meta data) with the correct event date.

Or...

"integrate event organizer plugin"

... that is not a bad idea either. But you'd have to transform this plugin to an extension of an existing (popular and well maintained) event plugin. Which in itself can be an advantage or disadvantage... Any particular event plugin in mind?

> The second version seems like a hack to me - misusing the post_date value, I am just afraid that there might be drawbacks I currently can't think of. I agree. One drawback would be that WordPress tends to see posts with a post date in the future (which would be the case with planned events) as posts that are pending publication. When giving a post a furure post date, the post will not be shown on the front end anymore untill that date arrives. > On meta value and replace the post_date with the beginsOn meta value, so that most likely we display what we want as our "date". Even when replacing the true post date with a future date on runtime, might cause unexpected results... When other filters or plugins are involved, things could get funky whith unexpected post dates. Storing the event start and end dates/times as meta values is the way to go. But it then needs a custom query to get only future events and show them in correct order (based on meta data) with the correct event date. Or... > "integrate event organizer plugin" ... that is not a bad idea either. But you'd have to transform this plugin to an extension of an existing (popular and well maintained) event plugin. Which in itself can be an advantage or disadvantage... Any particular event plugin in mind?
linos commented 5 months ago
Poster
Owner

Even when replacing the true post date with a future date on runtime, might cause unexpected results... When other filters or plugins are involved, things could get funky whith unexpected post dates.

@rolf This is tricky indeed, but I think it won't be a big problem, since I would only hook when some date which belogs to a post_type mobilizon_event is displayed in the front-end. Couldn't think of a collission yet.

Storing the event start and end dates/times as meta values is the way to go. But it then needs a custom query to get only future events and show them in correct order (based on meta data) with the correct event date.

I intend to speed this up by using a transient which stores the events in the right order.

Any particular event plugin in mind?

Not really. But maybe start with the most popular ones. Is there any popular event plugin which is totally free and libre and has none of this "buy the pro version" stuff going on?

But serving an exclusive Block might also have advantages, especially for usability. Two possibilites:

  1. I am curious if WordPress 5.9 introduces some new blocks which could be forked to display the events.
  2. Otherwise I think I am going to stick with https://github.com/brainstormforce/ultimate-addons-for-gutenberg/tree/master/src/blocks/post/post-grid
> Even when replacing the true post date with a future date on runtime, might cause unexpected results... When other filters or plugins are involved, things could get funky whith unexpected post dates. @rolf This is tricky indeed, but I think it won't be a big problem, since I would only hook when some date which belogs to a post_type `mobilizon_event` is displayed in the front-end. Couldn't think of a collission yet. > Storing the event start and end dates/times as meta values is the way to go. But it then needs a custom query to get only future events and show them in correct order (based on meta data) with the correct event date. I intend to speed this up by using a transient which stores the events in the right order. > Any particular event plugin in mind? Not really. But maybe start with the most popular ones. Is there any popular event plugin which is totally free and libre and has none of this "buy the pro version" stuff going on? ### But serving an exclusive Block might also have advantages, especially for usability. Two possibilites: 1. I am curious if WordPress 5.9 introduces some new blocks which could be forked to display the events. 2. Otherwise I think I am going to stick with https://github.com/brainstormforce/ultimate-addons-for-gutenberg/tree/master/src/blocks/post/post-grid
rolf commented 5 months ago

I am curious if WordPress 5.9 introduces some new blocks which could be forked to display the events.

I'll have a quick look and let you know :)

> I am curious if WordPress 5.9 introduces some new blocks which could be forked to display the events. I'll have a quick look and let you know :)
rolf commented 5 months ago

Ok, with WordPress 5.9 there will be the new Query Loop block available. It works with custom post types and also Mobilizon Mirror events: https://dev.status301.com/mobilizon/

Note:

  • this block is not always available for the sidebar or footer (depends on theme compatibility)
  • it does not allow querying post meta

Also note (unrelated to this topic) that the Mobilizon events page and single events generate two "Derpecated" notices and do not use the desired template (because it is not there anymore) in Twenty Twenty-Two.

Ok, with WordPress 5.9 there will be the new Query Loop block available. It works with custom post types and also Mobilizon Mirror events: https://dev.status301.com/mobilizon/ Note: - this block is not always available for the sidebar or footer (depends on theme compatibility) - it does not allow querying post meta Also note (unrelated to this topic) that the Mobilizon events page and single events generate two "Derpecated" notices and do not use the desired template (because it is not there anymore) in Twenty Twenty-Two.
linos commented 5 months ago
Poster
Owner

@rolf The WordPress (Version 5.9) internal Query Loop Block also doesn't allow for filtering for a specific post type. And it is not giving good configuration options. Rather 4 templates what is shown an what is not, thats it.

@rolf The WordPress (Version 5.9) internal Query Loop Block also doesn't allow for filtering for a specific post type. And it is not giving good configuration options. Rather 4 templates what is shown an what is not, thats it.
linos commented 5 months ago
Poster
Owner

@rolf Would you mind testing the latest commits together with the https://wordpress.org/plugins/ultimate-addons-for-gutenberg/ post-grid block for example?

@emo If you are interested you might as well.

@rolf Would you mind testing the latest commits together with the https://wordpress.org/plugins/ultimate-addons-for-gutenberg/ post-grid block for example? @emo If you are interested you might as well.
emo commented 5 months ago

i do some tests. raster of mobilizon events and a field for mobilizon groups works. but not chosable which group to display.
i can filter by taxonomie tags but that isnt ideal, as workaround ok.
optical drawbacks is too early to talk?

i do some tests. raster of mobilizon events and a field for mobilizon groups works. but not chosable which group to display. i can filter by taxonomie tags but that isnt ideal, as workaround ok. optical drawbacks is too early to talk?
linos commented 5 months ago
Poster
Owner

i do some tests. raster of mobilizon events and a field for mobilizon groups works. but not chosable which group to display.
i can filter by taxonomie tags but that isnt ideal, as workaround ok.
optical drawbacks is too early to talk?

The taxonomy term mobilizon_group are the groups, the normal tags are handled differently. WordPress distinguishes between taxonimies and tags. Taxonomies are more complex: they can have parents and children, tags can not. The standard build-in taxonomy is category. But WordPress allows for adding custom taxonomies. Therefore I added mobilizon_group. This way it gets saved which group a event belongs to.

It seems like forking the block from ultimate-gutenberg-addons and only displaying the stuff one needs for an event list and adding appropiate sytle to it is the way to go. The usability with ultimate-gutenberg-addons post-grid block is indeed not good, as there are to many settings for the average user.

Optical drawbacks usually depend on your theme at this stage. I like the idea that the events are thisplayed in WordPress like they were native there.

I am about to rewrite the logic for single event pages though and allowing to choose between the design in version 1.0.1 (+some quirks fixed), and a different one, where there is no new page template, instead only the content of the post is modified to contain the meta information in the beginning and the end. See #3.

> i do some tests. raster of mobilizon events and a field for mobilizon groups works. but not chosable which group to display. > i can filter by taxonomie tags but that isnt ideal, as workaround ok. > optical drawbacks is too early to talk? The taxonomy term `mobilizon_group` are the groups, the normal tags are handled differently. WordPress distinguishes between taxonimies and tags. Taxonomies are more complex: they can have parents and children, tags can not. The standard build-in taxonomy is `category`. But WordPress allows for adding custom taxonomies. Therefore I added `mobilizon_group`. This way it gets saved which group a event belongs to. It seems like forking the block from ultimate-gutenberg-addons and only displaying the stuff one needs for an event list and adding appropiate sytle to it is the way to go. The usability with ultimate-gutenberg-addons post-grid block is indeed not good, as there are to many settings for the average user. Optical drawbacks usually depend on your theme at this stage. I like the idea that the events are thisplayed in WordPress like they were native there. I am about to rewrite the logic for single event pages though and allowing to choose between the design in version 1.0.1 (+some quirks fixed), and a different one, where there is no new page template, instead only the content of the post is modified to contain the meta information in the beginning and the end. See #3.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
Labels
Apply labels
Clear labels
bug
Something is not working contribution welcome
Contributions are very welcome, get started here duplicate
This issue or pull request already exists enhancement
New feature help wanted
Need some help invalid
Something is wrong question
More information is needed upstream
Related to an upstream repository, already reported there wontfix
This won't be fixed
No Label bug contribution welcome duplicate enhancement help wanted invalid question upstream wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
1.1
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch '%!s(MISSING)'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes