What changes here, if any, will require re-baking posts with hashtags in them?
Will any required re-baking happen automatically based on enabling this, or will there be an explicit migration step to rebake?
The discussion revolves around rebaking posts to apply new autocomplete hashtag styling in Discourse. mcdanlj initially asks whether enabling the feature triggers automatic rebaking or requires a manual migration. MarcP shares that they manually rebaked all posts via Rails, while mcdanlj expresses concern about unnecessary rebaking of unaffected posts. Ed_S warns that rebaking may harm older posts, citing potential issues. mcwumbly confirms no built-in selective rebake feature exists yet. mcdanlj and pfaffman propose a SQL-based solution targeting posts with class="hashtag" in cooked content, which mcdanlj successfully tests. sam suggests updating baked_version to trigger background rebaking without image reprocessing. martin agrees to implement a rake task for self-hosters, later merged as hashtags:mark_old_format_for_rebake martin. Jonathan5 requests usage instructions, answered by mcdanlj with CLI steps. pfaffman notes that manually editing and saving posts or using the wrench icon to rebuild HTML also works, which Jonathan5 confirms as a safer alternative. The thread also briefly touches on future plans for colored category links, deemed complex and not immediate mcwumbly.
What changes here, if any, will require re-baking posts with hashtags in them?
Will any required re-baking happen automatically based on enabling this, or will there be an explicit migration step to rebake?
After enabling the feature I just ran rebake all posts through rails.
I have a lot of posts, the vast majority of which won’t need to be touched. I was kind of hoping there would be a rebake-only-affected-posts ability, either explicit or implicit.
Rebaking can even harm older posts, it seems:
How to avoid potential issues when rebaking all posts?
This feature is fresh out of the oven. There isn’t any built in ability to rebake all posts that have category/tag mentions included with it at this time. Will keep an ear to the ground here for what folks feel is necessary there and/or what solutions people come up with in the meantime.
Is there a pattern perhaps we could use to rebake all posts except the ones with an embed/onebox?
What we want to rebake is all posts for which the cooked representation matches class="hashtag", as far as I can tell.
I don’t think that rebake_match will help here because it matches the raw text, and there is no option for matching against cooked text in the existing rails tasks. So this will, I think, require actual coding, either in the rails console or in a new task.
Something like
Post.where("cooked like '%class=\"hashtag\"%'").each do |p| p.rebake! end
Something very like that! I just successfully tested exactly that on my staging site.
I was thinking about the delay option for the posts:rebake_match but probably it doesn’t matter.
It is of course insisting on re-processing all the images on the affected posts, which is unnecessary, so an automated fix just for this might reasonably avoid that, but in the meantime there is a way forward.
I might want to do this by reverse ordering and adding a delay if a site has a lot of affected posts.
@mcwumbly Now that 3.0 was announced with this as a headline feature, what would you think about a migration that only fixed up the text without reprocessing images, or alternatively that lets you rebake only the affected posts with a delay so it doesn’t clog queues with image re-processing?
@martin can you share a few thoughts here on how you might approach this problem?
In short, I think what people want ideally is something like:
And maybe also:
You can already do something like that.
Post.where("cooked like '%class=\"hashtag\"%'").update_all(baked_version: 0)
It will then churn through stuff in the scheduled jobs in the background.
I do anticipate us upping our baked_version some time in the next year.
I will make a rake task to do what @sam suggests above that self-hosters can run.
I don’t think this is necessary, since we’ve now made this the default for new sites, and soonish will remove the option altogether. If people want to try it out they could enable the setting, rebake a couple of posts manually in the UI, then if they don’t like it turn the setting back off and rebake the same posts.
Though, there won’t be any choice soon.
Do you know if the colored category links idea is still considered?
It is, but we think this is larger in scope than it appears on the surface and there are still a number of design details to work through first so it won’t happen immediately.
Cool, sounds good!
I just merged a rake task for this:
https://github.com/discourse/discourse/pull/19876
bundle exec rake hashtags:mark_old_format_for_rebake
Could you please provide a full idiot’s guide to using that command?
Is there any way to of changing individual posts as a user (eg editing/saving with a minor edit)?
Thanks.
This is the usual pattern for rake tasks:
cd /var/discourse
./launcher enter app
bundle exec rake hashtags:mark_old_format_for_rebake
That should work. If your staff you can click the wrench and rebuild html
That worked fine, thank you. For my purposes it seemed lower risk than trying the rake task.