Over the years, our blogs were not managed correctly and grew to over 30 separate blogs. We are now condensing using the API. I just wanted to go through my strategy here to get some feedback if this is the best way to do it. We are also, revamping topics.
We have already exported a list of all blogs and have decided which blog they are being moved to and the new topics.
So basically I am going to create a script that goes down the list of posts and updates the content_group_id and the topics_id fields to the new values.
This should work fine right? I use the topics and blog apis to get the id’s of the new blogs and topics and then just call the blog post api for each post and update the 2 fields.
Of course this does not affect the url or redirects. What is the best way to go about this? I thought i’d be able to create mass redirects from one blog to another but not all posts under each blog are moving to the same new blog.
If I change the slug, will this create a redirect? I don’t really want to create over a thousand redirects in the system. We are not against having the old addresses all redirect to the blog home page if this is the only way.
So moving a blog by just providing a new content group ID in the put method works. And the url is updated automatically.
The one issue which seems like a bug is that when you go into the settings of that blog post where you can change the url, it is different than the url that shows up on the post info page before you hit edit. That page has the correct working new link… but when you hit edit and go to settings, the slug section sometimes shows the blog url and the slug instead of just the slug and other odd issues with that part of the settings.
It seems like a bug as it didn’t match the actual working link. Is there any one I can show this to to see if it can be looked into by the devs?
There’s not really enough detail to give you a 100% answer here, but I can give you a general outline of how I would think about this. It will end up being a somewhat complicated process, but it seems like you’re off in the right direction.
I would think about this migration process as a series of ‘maps’, where you’ll need to map each parent blog, post, author, and topic data to the proper corresponding asset in the aggregated new world.
In terms of creating posts, assuming you’re using the ‘Create a blog post’ endpoint: http://developers.hubspot.com/docs/methods/blogv2/post_blog_posts, then, by POSTing to the endpoint described there, and changing the content-group-id, would create a blog post in a new blog with the same data that you got from another post. I would inspect the body of each post and ensure that the data you GET for each post will map to the expected JSON of a new post.
Just changing the slug won’t create a redirect, because you’re creating an entirely new asset that has no correlation to the original. Each ‘create blog post’ is creating a new post that doesn’t correspond to the ‘old’ post. Each content-group-id is essentially its own ‘namespace’.
When you create a new post, it will take the blog root URL of the particular blog that you’re creating it under. So, for original article /blog1/article1 , when you create a new post under a new blog, the root would be /blog2/new-post-title. If you create the new posts and have the URLs, if you match the subdirectory of the article post, so that the new URL becomes /blog2/article1, you can create a pattern-match URL in the COS URL Mapping tool (https://knowledge.hubspot.com/articles/kcs_article/cos-general/how-do-i-set-up-a-flexible-pattern-ur...) which would allow you to map all of /blog1/:name-of-article to /blog2/:name-of-article
You’ll also want to think about creating and ‘associating’ the blog comments (which has its own set of methods for getting and creating posts).
I was not thinking of using the Create a blog post endpoint at all. I am thinking of more of a move than a destroy and create. Am I not able to just change the group id in each post so that it moves to the new group/blog instead of creating new posts?
.png "HubSpot Employee"){kind=icon}
