### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 20, 2017, 2:41pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/4 "2017-06-20T14:41:27Z")
> [@blake](#):
>
> Are you not able to look up the topic\_id in the the wordpress post\_meta data?
I’m trying to match a list of updated Discourse topics to their corresponding WordPress posts. It’s being done at a regular interval in a cron job, so I’m trying to make it as efficient as possible. I’m especially concerned about multisite WordPress installations with an unknown number of subsites. In that case, it seems important to tie up as little time as possible in processing the cron job. On WordPress, finding a post by the value of a meta-key can be done, but it’s not efficient.
I only added the topic\_id as post metadata a couple of weeks ago. For posts created before that time, it’s not available. So on the WordPress end there’s no advantage of using the topic\_id metadata over using a new wp\_id that’s added as a property to Discourse topics.
If you do add it, the field doesn’t need to be `wp_id`. It could be something like `external_post_id` .
---
### Author:  [@blake](https://meta.discourse.org/u/blake)
#### Post date: [June 20, 2017, 3:52pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/5 "2017-06-20T15:52:01Z")
> [@simon](#):
>
> On WordPress, finding a post by the value of a meta-key can be done, but it’s not efficient.
Is `WP_Query` not efficient? (I’m not a WP expert, so just curious)
>
[This post](https://kinsta.com/blog/wp-query/) might help speed things up
I’m leaning toward not adding an `external_post_id` because I feel like keeping track of the topic\_id which the api returns should be the responsibility of the integrator not Discourse. In order to make looking up a topic by `external_post_id` efficient in Discourse we would also have to index the column in the db table and create/modify an api endpoint to allow for searching by that param.
> [@simon](#):
>
> So on the WordPress end there’s no advantage of using the topic\_id metadata over using a new wp\_id that’s added as a property to Discourse topics.
If there is no advantage to using one or the other right now, I’m going to push you do use the topic\_id in the metadata. I guess I’m having a hard time seeing the downside if you are already tracking the topic\_id that you couldn’t just hit the [/t/{id}.json endpoint](http://docs.discourse.org/#tag/Topics%2Fpaths%2F~1t~1%7Bid%7D.json%2Fget) and get the title and the posts\_count?
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 20, 2017, 4:35pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/6 "2017-06-20T16:35:10Z")
Sure, I can make it work without it. I’ll remove the `wp-id` parameter from the data the plugin sends to Discourse when a topic is published through WordPress.
My use case wasn’t wanting to query Discourse for topics by the `external_topic_id`. I’m querying a Discourse route that I’ve added through a plugin for topics that have been updated over a given period of time. That data is being used to update the comment counts for all the posts on a site, and to indicate which posts need to sync their comment content with Discourse.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [June 20, 2017, 6:21pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/7 "2017-06-20T18:21:15Z")
> [@blake](#):
>
> If there is no advantage to using one or the other right now, I’m going to push you do use the topic\_id in the metadata. I guess I’m having a hard time seeing the downside if you are already tracking the topic\_id that you couldn’t just hit the /t/{id}.json endpoint and get the title and the posts\_count?
Even better with the real `topic_id` you can listen to webhooks, and be way more efficient than regular API calls to data that didn’t change.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 20, 2017, 7:36pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/8 "2017-06-20T19:36:50Z")
I like the idea of using a webhook. It was my initial approach to doing this. The biggest problem with using a webhook with a WordPress multisite installation is that it doesn’t return any data that will allow the updated Discourse topic to be matched with the correct WordPress subsite. For each webhook request, the postmeta table of each WordPress subsite will have to be searched to try to match the topic with a post. For a network with 100 subsites, this could become quite inefficient.
I’m going to give this some more thought and see if there’s a way to make it work.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 20, 2017, 8:06pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/9 "2017-06-20T20:06:51Z")
> [@blake](#):
>
> I guess I’m having a hard time seeing the downside if you are already tracking the topic\_id that you couldn’t just hit the /t/{id}.json endpoint and get the title and the posts\_count?
This is basically how the plugin is functioning now. What I’m trying to do is keep the comment numbers and content up to date while making as few API calls to Discourse as possible.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 21, 2017, 4:19am UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/10 "2017-06-21T04:19:30Z")
A post\_event webhook will work for syncing content if the post’s `topic.topic_embed.embed_url` is returned with the webhook. On a WordPress multisite setup, the webhook only needs to be sent to the main site on the network. If the topic was published from a subsite, the subsite can be found from the `embed_url`.
Does using a webhook for this seem safe?
Would it be possible to return the `embed_url` with a post\_event webhook? For testing, I just added this to the `post_serializer`.
```plaintext
def embed_url
if object.topic && object.topic.topic_embed
object.topic.topic_embed.embed_url
end
end
```
If this can’t be done, querying a Discourse route that’s added through a plugin to get a list of updated topics also works well. On the WordPress end, the two ways of doing it use mostly the same code.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 21, 2017, 2:55pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/11 "2017-06-21T14:55:12Z")
I should probably change the title of this topic 🙂 What I’m looking for is the best way to improve the plugin’s performance that will work in both a normal WordPress installation and a multisite installation.
If using a webhook for keeping data synced between Discourse and WordPress is a good approach, the reason for wanting to have the `embed_url` returned with the post\_event webhook, instead of storing that data on the WordPress end, is that the only way I can see of storing the data on WordPress is to create a new database table. That would be quite simple, but I’m trying to conform to the WordPress VIP coding standards. The hope is that the plugin can eventually be used on sites hosted by [wordpress.com](http://wordpress.com). The WordPress VIP coding standards do not allow creating or altering the WordPress database tables: [https://vip.wordpress.com/documentation/vip/code-review-what-we-look-for/#database-alteration](https://vip.wordpress.com/documentation/vip/code-review-what-we-look-for/#database-alteration)
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [June 22, 2017, 10:15pm UTC](https://meta.discourse.org/t/adding-the-wp-id-parameter-to-topics-created-through-wordpress/64630/12 "2017-06-22T22:15:07Z")
I ended up creating a topic\_id/blog\_id database table. It’s only added when a single Discourse forum is associated with multiple WordPress sites, so it should be ok.