Are Folders Still Virtual Paths or First-Class Objects?

[identitydocs]

I'm trying to better understand how page hierarchy works in Wiki.js v3.

From the Wiki.js documentation, my understanding has historically been that folders are inferred from page paths rather than existing as actual folder objects. For example, a page could exist at /en/example/directory/page without requiring explicit creation of /en, /en/example, or /en/example/directory.

I also found an older discussion where @NGPixel stated: "folders don't technically exist"

However, in v3 I see references to folder trees, destination folders when saving pages, and page tree entries with properties such as isFolder, which makes me wonder whether the underlying model has changed or whether these are still abstractions over path-based content. #8237 && #8241

Could someone clarify:

• Are folders in v3 still virtual/inferred from page paths?
• Is a path such as /en/example/directory considered a real object if no page exists there?
• If a page exists at /en/example/directory, does that page become the logical landing page for everything beneath it?
• What exactly does isFolder represent in v3?
• Has the hierarchy model fundamentally changed from v2, or is it largely the same concept with a different UI?

[Drako01]

The old v2 explanation should not be carried over unchanged to v3. In the published 3.3.0
implementation, folders have persisted entries of their own.

The tree model has createFolder,
getFolderById and folder move/rename operations. Creating a folder inserts a row with
type: 'folder', its own ID, title and metadata. Ancestor folders can be created automatically when
a path needs them, which differs from folders existing only as inferred strings.

A page and a folder can occupy the same logical path. The browse response deliberately merges them
into one entry with independent flags:

• isPage: there is a page at that address.
• isFolder: there is a folder to browse beneath that address.
• Both can be true.

Consequently, a folder can exist without a page at its path. A page placed at that path can provide
landing-page content, but it does not become the folder record or replace the separate hierarchy
entry. Merely writing an arbitrary URL does not create either object.

The tree API exposes these folder
operations directly. For v3 documentation, use docs.js.wiki, whose homepage
identifies it as the official 3.x documentation; the linked docs.requarks.io guide describes the
earlier model.

This is based on the tagged 3.3.0 source, not a test against your instance.

[NGPixel]

v3 has real folders and are no longer inferred from page paths. They behave like a real file system in that sense.

The only thing that is still true in v3 is that a page with the same path name as a folder is the landing page for that path.

[identitydocs]

Thank you for this simple and declarative response. Will importing from v2 with a Git backend cause any issues where those inferences once existed?

[NGPixel]

Folders will be created automatically to match.

[identitydocs]

Incredible. Thank you!