Add permalink history for taxon on friendly-id

[JustShah]

[WIP] Open Questions

This PR aligns URL handling of taxons with products.

Open questions:

• The slugs of taxons are currently called permalinks (which they aren't), should they be renamed to slug (in backend and DB) creating also a migration

Related Issues, PRs and Discussions

• [Meta Issue][SEO] old slugs are not redirected correctly #6093
• Add condition to handle redirects for taxon permalink solidus_starter_frontend#415

Summary

This PR introduces FriendlyId to the Taxon model to store the history of permalinks (slugs) and provides a more flexible approach to handling slugs for taxons.

Changes:

• Taxon Model:

  • Added FriendlyId to the Taxon model, enabling it to generate and store slug history.
  • The before_save callback is used to set the permalink instead of before_create and before_update, allowing for better slug management.
  • Introduced a custom method for should_generate_new_friendly_id? to control when a new friendly ID should be generated, specifically when the permalink changes.
  • Added a custom normalize_friendly_id method to adjust how slugs are generated, especially for nested taxons, ensuring proper formatting of the slug.

• Test:

  • Added a test to ensure that the history of permalinks is correctly stored when a taxon's permalink is updated. The test verifies that both the initial and updated slugs are retained in the history.

Motivation

This update enhances the management of taxon slugs by allowing historical tracking of slugs. This is particularly useful for SEO purposes and for maintaining accessibility of the resource if URLs change over time.

Note

The starter frontend PR is dependent for this change starter frontend PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.68%. Comparing base (dfe87ae) to head (5618cc6).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6100   +/-   ##
=======================================
  Coverage   88.67%   88.68%           
=======================================
  Files         829      829           
  Lines       17995    18004    +9     
=======================================
+ Hits        15957    15966    +9     
  Misses       2038     2038           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fthobe]

@shahmayur001 i think there's a drop in cov across the project, we probably need to refine testing here.

[fthobe]

@shahmayur001 as a consequence of this change, do we need to write logic to redirect {id} and {historyslug} as we did on products?

[fthobe]

@tvdeyen as bespoken history for Taxon slugs as well

[JustShah]

@shahmayur001 as a consequence of this change, do we need to write logic to redirect {id} and {historyslug} as we did on products?

@fthobe Yes, we already included that changes in starter frontend PR.

[tvdeyen]

I explained it many times before and still I need to comment on every single PR of yours.

Please use your (often very good PR descriptions) as commit description(s). It is not even more work for you, because GitHub actually uses the git commit message to create the PR description in single commit PRs like this.

So, please always use the commit description for explaining why a change has been made. Even for multi commit PRs. The PR description is only helpful for users of the GH UI, while commit messages are used every where else (in your code editor, in third party git clients, the git log in your terminal, during rebase, etc.). It should always be the single source of truth and not the GitHub GUI). This has been discussed in the developer community all over the globe for decades now and should have been inherited by every single developer finally. I am a bit frustrated that I have to repeat this every, single time.

So, please - again - rewrite your commit message so that it includes the content of your - actually very good - PR description.

I hope that I do not have to write the same comment on your PRs over and over again.

Thanks.

[JustShah]

I explained it many times before and still I need to comment on every single PR of yours.

Please use your (often very good PR descriptions) as commit description(s). It is not even more work for you, because GitHub actually uses the git commit message to create the PR description in single commit PRs like this.

So, please always use the commit description for explaining why a change has been made. Even for multi commit PRs. The PR description is only helpful for users of the GH UI, while commit messages are used every where else (in your code editor, in third party git clients, the git log in your terminal, during rebase, etc.). It should always be the single source of truth and not the GitHub GUI). This has been discussed in the developer community all over the globe for decades now and should have been inherited by every single developer finally. I am a bit frustrated that I have to repeat this every, single time.

So, please - again - rewrite your commit message so that it includes the content of your - actually very good - PR description.

I hope that I do not have to write the same comment on your PRs over and over again.

Thanks.

Thank you for the feedback. I was planning to update the commit message after addressing the comments but I completely agree with your point. Moving forward, I will ensure that commit includes the description. I appreciate your patience.

[tvdeyen]

Thank you for the feedback. I was planning to update the commit message after addressing the comments but I completely agree with your point. Moving forward, I will ensure that commit includes the description. I appreciate your patience.

Thanks for your understanding. I actually is very helpful to have all the information beforehand in order to be able to review the PR in the first place.

[fthobe]

@tvdeyen thank you

[fthobe]

@tvdeyen there was a question on top of the PR, could you please answer to that so that we know what to do there. I understand that this is a breaking change, but I feel like it should be tackled sooner or later as current naming conventions between products and taxons regarding URLs are confusing.

[tvdeyen]

We can do that, but is it worth the effort?

Because this is would we would have to do

1. Introduce the new column
2. Deprecate the old column
3. Write data into both columns
4. Stop writing the data into the old column
5. Drop old column

All that over the period of at least one major version. I am not sure if this is really worth it. What is the reasoning behind this? Just because or is there a technical issue that this solves?

[fthobe]

We can do that, but is it worth the effort?

Because this is would we would have to do

1. Introduce the new column
2. Deprecate the old column
3. Write data into both columns
4. Stop writing the data into the old column
5. Drop old column

All that over the period of at least one major version. I am not sure if this is really worth it. What is the reasoning behind this? Just because or is there a technical issue that this solves?

In this case absolutely only bringing naming in line between resources. I wouldn't die on that hill. Taxon rendered is taxon rendered no matter the name. We could start by writing into both columns though and I mean that as suggestion not by any means as something that needs to be done now.

[tvdeyen]

Same here. I don't think it's worth it. Thanks for elaborating