What rebake is required for the new autocomplete styling?

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?

1 Like

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.

3 Likes

Rebaking can even harm older posts, it seems:
How to avoid potential issues when rebaking all posts?

2 Likes

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.

3 Likes

Is there a pattern perhaps we could use to rebake all posts except the ones with an embed/onebox?

4 Likes

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.

2 Likes

Something like

 Post.where("cooked like '%class=\"hashtag\"%'").each do |p| p.rebake! end
6 Likes

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.

1 Like

@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?

3 Likes

@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:

  • when I turn on the new hashtag feature, I want a way to update the style of all my old hashtags to match, without otherwise changing the contents of existing posts

And maybe also:

  • when I turn it off, I want an easy way to do the opposite.
3 Likes

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.

5 Likes

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.

4 Likes

Do you know if the colored category links idea is still considered?

1 Like

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!

4 Likes

I just merged a rake task for this:

bundle exec rake hashtags:mark_old_format_for_rebake

6 Likes