Wp-discourse-shortcodes plugin

I couldn’t find any API calls in any of the Discourse logs. :woman_shrugging: However, the good news is I think we might have solved it.

The original shortcode was using source="top" and some other parameters, so I slowly stripped the shortcode down until it was only using default settings by omission. I was under the impression that only source="latest" made use of a webhook per the language of the checkbox in the WP admin settings, but we enabled a webhook for latest topics (and additionally restricted the trigger to only the categories we wanted to show) and then when I added back in the parent category, the shortcode started respecting the category restrictions! :tada: (It didn’t respect the category restriction with source="latest" either until I enabled the webhook, despite clearing the cached HTML through the WP admin page, and other sources of caching we have for the site.)

After seeing the desired results using the webhook + source="latest", I changed the source back to “top” and then added the original parameters back in bit by bit. So far it has kept respecting the category restriction. I left the webhook enabled.

If the webhook is what is helping (still, and not just something that served as a reset of sorts), I suggest changing the wording of the WP admin page from “Use a Discourse Webhook to refresh the ‘latest’ topic list” to “Use a Discourse Webhook to refresh the [discourse_topics] list” (or something else to make it clear it doesn’t matter which source you’re using in the topics list, the webhook is likely to be the cure-all elixir we are looking for). :joy:

This is a great plugin. Two feature questions:

  1. Is it possible to display images within the posts, as with the embed script using template=“complete”?..

  2. Is it possible to swap out usernames for real names?

Thank you kindly

Also a bug with nested categories not displaying. Only topics within a primary category shows up.
See ex below: General but no General >> News and Events

and again with tiles and all other shortcode attributes removed…

Hey Ryan, neither topic image previews or names are features of the plugin, however you can use these filters to apply your own formatting and to possibly add those elements in.

To override the HTML output entirely use these two filters (i.e. the add_filter equivalents)

// Return false to use your own formatting
apply_filters( 'wpds_use_plugin_topiclist_formatting', true );

// Return your own HTML output from the discourse_topics data
apply_filters( 'wpds_after_topiclist_formatting', $output, $discourse_topics, $args );

Or add additional elements into the existing HTML

apply_filters( 'wpds_topiclist_above_header', $output, $topic, $category, $poster_avatar_url, $args );
apply_filters( 'wpds_topiclist_above_footer', $output, $topic, $category, $poster_avatar_url, $args );
apply_filters( 'wpds_topiclist_avatar', $avatar_image, esc_url_raw( $poster_avatar_url ) );
apply_filters( 'wpds_topiclist_below_footer', $output, $topic, $category, $args );

Sorry do you mean the topic from a nested category is displaying, but not its category badge?

1 Like

Many thanks, Angus. That is helpful.

Correct. If a topic resides in a nested category the badge will not display… the screenshot below shows the missing badge. This is a topic within the General >> News and Events nested category. If I were to change the category of the topic to the parent ‘General’ category, the badge would display as the second topic below…

1 Like

Thanks for clarifying Ryan, I’ll take a look at that issue next week and get back to you.

1 Like

Thanks. FWIW, I added a “real name” attribute to replace usernames and posted my changes within this repo… I’m pretty new to git so I apologize it didn’t follow the proper commit channels, but the changes are there if ever helpful to anyone else…

2 Likes

The big issue with this plugin still is the inabillity to include/exclude by category. In a private membership based forum you either see all the categories or you get none, which means there’s no way to exclude staff topics from being shown to the wider member base.

However, it seems like an easy workaround could be commenting out the ajax request and relying exclusively on the webhook. We have triggers setup to exclude the staff category in the webhook…

And this works to temporarily block new staff discussions until the ajax call is eventually made.

So maybe just comment out the ajax call?..

Am I overlooking something that would make this approach inadvisable?

1 Like