mirror of
https://gh.wpcy.net/https://github.com/discourse/discourse.git
synced 2026-06-19 00:48:08 +08:00
Previously, the Community sidebar section, its 12 default URLs, and the links binding them were inserted across four migrations (`20230411032053_insert_community_to_sidebar_sections.rb`, `20241025045928_add_invites_link_to_sidebar.rb`, `20250626090725_add_my_messages_link_to_sidebar.rb`, `20250721043317_add_filter_link_to_sidebar.rb`), mixing schema and data and re-running data inserts every time a new link was added. This change moves the rows to `db/fixtures/700_sidebar.rb`, gated by a hidden `sidebar_seeded` site setting so admin customizations (renamed links, reordering, even destroying the public Community section via `sidebar_sections_controller#destroy`) survive subsequent `db:seed` runs. The fixture iterates `SidebarUrl::COMMUNITY_SECTION_LINKS` so adding a future link is a one-line model change plus a re-seed. The four existing migrations are gated on `Migration::Helpers.new_site?` so they continue to upgrade existing sites past the point the link didn't yet exist, but no-op on fresh installs (where the fixture is the source of truth). A companion `20260513105516_mark_existing_sites_sidebar_seeded.rb` flips the flag for existing sites so the seed bails immediately on the upgrade deploy. Extracted from https://github.com/discourse/discourse/pull/39788.
17 lines
460 B
Ruby
Vendored
17 lines
460 B
Ruby
Vendored
# frozen_string_literal: true
|
|
|
|
class MarkExistingSitesSidebarSeeded < ActiveRecord::Migration[8.0]
|
|
def up
|
|
return if Migration::Helpers.new_site?
|
|
|
|
execute(<<~SQL)
|
|
INSERT INTO site_settings (name, data_type, value, created_at, updated_at)
|
|
VALUES ('sidebar_seeded', 5, 't', NOW(), NOW())
|
|
ON CONFLICT (name) DO UPDATE SET value = 't', updated_at = NOW()
|
|
SQL
|
|
end
|
|
|
|
def down
|
|
raise ActiveRecord::IrreversibleMigration
|
|
end
|
|
end
|