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?
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:
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.