Onboarding improvements

[aerosol]

Changes

Migration will be extracted to a separate PR once the review is conducted.

This PR aims to make the onboarding (and related flows, such as e.g. domain change) more helpful and visually consistent. The main functional change is the "customize installation" screen, where site type is determined early (WordPress/GTM/manual) and installation instructions are provided according to that inspection result.

For manual and GTM installations, users can build the script snippet by selecting tracker extensions they're interested it (some of which will have side effects - e.g. including the "file downloads" extension will automatically create a relevant goal).

As a consequence, the snippet window has been removed from general settings section (snippet may not be relevant at all, in case of WP installations) and replaced by 2-step flow allowing users to "review their installations". Similarly, the snippet window became no longer relevant during domain change.

By the way the following changes were also made:

• focus.html layout has been removed, the distinction leads to unnecessary maintenance
• site verification is no longer optional, VERIFICATION_ENABLED variable has been deprecated, it no longer has any effect. For self-hosted installations, verification will simply fail by default, unless browserless stack is set up. Instructions on how to do that for CE can be provided later on
• minor visual rearrangements according to the new designs

Docs: major changes pending

Tests

• [x] Automated tests have been added
• [ ] This PR does not require tests

Changelog

• [x] Entry has been added to changelog
• [ ] This PR does not make a user-facing change

Documentation

• [ ] Docs have been updated
• [ ] This change does not need a documentation update

Dark mode

• [x] The UI has been tested both in dark and light mode
• [ ] This PR does not change the UI

[github-actions[bot]]

Preview environment👷🏼‍♀️🏗️
PR-4459

[aerosol]

Data migration for CE is failing: https://github.com/plausible/analytics/actions/runs/10612221725/job/29413425673?pr=4459

This is because Plausible.DataMigration.SiteImports relies on Site schema that gets migrated later on. How should we proceed in such case? cc @zoldar @ruslandoga

[ruslandoga]

~~I'll need to take a closer look, but I wonder if https://github.com/plausible/analytics/pull/4466 would fix this?~~

[ruslandoga]

Ah, the issue seems a bit different. I think the fix here would be to not use Ecto schemas in data migrations and instead rely on "raw" selects.

That is, instead of doing this

Plausible.Site |> ... |> Repo.all()

we can do this in code that runs in migrations

"sites" |> select([s], map(s, [...necessary fields for the migration...])) |> Repo.all()

[aerosol]

hmm how about:

diff --git a/lib/plausible/data_migration/site_imports.ex b/lib/plausible/data_migration/site_imports.ex
index 8aaa03f3e..749fbeaa2 100644
--- a/lib/plausible/data_migration/site_imports.ex
+++ b/lib/plausible/data_migration/site_imports.ex
@@ -29,6 +29,7 @@ defmodule Plausible.DataMigration.SiteImports do
     sites_with_only_legacy_import =
       from(s in Site,
         as: :site,
+        select: %{id: s.id, imported_data: s.imported_data},
         where:
           not is_nil(s.imported_data) and fragment("?->>'status'", s.imported_data) == "ok" and
             not exists(site_import_query)

the test at Plausible.DataMigration.SiteImportsTest runs fine.

[ruslandoga]

For self-hosted installations, verification will simply fail by default, unless browserless stack is set up. Instructions on how to do that for CE can be provided later on

Ah, I see. I hope this won't cause too much confusion / questions on the forum :)