Imported tag pages are named after the tag's ident, not its title

Search first

• I searched and no similar issues were found

What Happened?

Importing a :graph-human EDN export creates every user tag page with :block/name derived from the tag's :db/ident instead of from its title. Because a user tag's ident carries a random suffix, the imported tag page is named e.g. sometag-x7ab12cd, while the same tag created in the app is named sometag. :block/title is correct in both cases.

Observed values from a real graph (tag titles warning and cite):

No merging or graph manipulation is involved: exporting one graph and importing that file into a new graph is enough.

Effect I observed in the imported graph: blocks whose text holds an inline tag reference (stored as #[[<uuid>]]) displayed the raw UUID instead of the tag name, and rendered normally again once the tag pages were given the correct :block/name. I am not claiming the name is the only cause of that rendering symptom — I have also seen raw-UUID tags in a graph whose tag pages have correct names — but the imported names are wrong on their own.

Reproduce the Bug

1. In a DB graph, create a tag #SomeTag in the app, and use it inline in a block ("some text #SomeTag").
2. Export the graph:
   logseq graph export --graph <graph> --type edn --file /tmp/g.edn --edn-options '{:export-type :graph-human :graph-options {:include-timestamps? true}}'
3. Import it into a new graph:
   logseq graph import --graph <new-graph> --type edn --input /tmp/g.edn
4. Compare the tag page in both graphs:
   logseq query --graph <graph> --query '[:find [(pull ?c [:db/ident :block/name :block/title]) ...] :where [?c :block/tags :logseq.class/Tag] [?c :block/title "SomeTag"]]'
   and the same query with --graph <new-graph>.

The source graph reports :block/name "sometag"; the imported graph reports :block/name "sometag-<ident suffix>".

Expected Behavior

An imported tag page is named after its title, exactly as the app names a tag it creates, so that a tag page imported from EDN is indistinguishable from the same tag created in the app.

Screenshots

Browser, Desktop or Mobile Platform Information

macOS 26.6.2 (25G83), arm64. Desktop app 2.0.1 — local build of 6bf8fe772f (built 2026-09-16), CLI logseq --version → Revision: 6bf8fe7-dirty.

Additional Context

Investigation (at 6bf8fe772f; the same code is on current master)

• Where: deps/db/src/logseq/db/sqlite/build.cljs:469-487 — build-classes-tx builds the class with
  {:block/name (common-util/page-name-sanity-lc (name class-name)) :block/title (name class-name) …},
  where class-name is the key of the :classes map in the export, i.e. the qualified ident :user.class/SomeTag-x7ab12cd.
• Why it fails (confirmed by the repro above): the export's class definition is merged after that map, and it contains :block/title but no :block/name, so the title is corrected and the ident-derived name survives.
• Properties are not affected: build-properties-tx passes :title to sqlite-util/build-new-property (deps/db/src/logseq/db/sqlite/build.cljs:295-298, deps/db/src/logseq/db/sqlite/util.cljs:59-78), which derives :block/name from that title. Imported property pages have correct names.
• Workaround (confirmed): add :block/name to each entry of :classes in the EDN before importing; the merge order means the definition's value wins.
• Related: #958 is a different problem (an import error when a tag was already created by a page import), not the page name.

Are you willing to submit a PR? If you know how to fix the bug.

Not planning to, but happy to test a fix.

Start at deps/db/src/logseq/db/sqlite/build.cljs:469-487, especially build-classes-tx, and reproduce the issue with the documented logseq graph export and import commands. Compare :block/name and :block/title using the provided logseq query; done means an imported user tag page has a name matching its title, without changing imported property behavior.