Promote a block to a page and relink accordingly

Feedback Feature Requests
1

There are some old threads that have requested something similar, and the working solution at the time seems to have been using a plugin. This is not really viable for anyone using the db version. A more robust solution would make me feel less anxious about data loss.

Being able to convert an existing block to a “page” and relink all the backlinks (even in properties) would make life a lot easier. The way Logseq is designed, there are certain advantages to pages, such as having them displayed in the left sidebar’s history or having their title displayed in the right sidebar, etc. Nevertheless, working directly in the journal is intuitive and facilitates rapid capture. Being able to convert blocks to pages and relink them would make Logseq much more versatile than it already is, and it would better accommodate a wider variety of workflow possibilities.

Thanks!

2

I would actually consider this a Bug and not a Feature request, since this is the way it should work by default

3

I see what you mean, but as far as I can tell, the facility for doing this is not implemented (so it is not a dysfunctional feature).

4

Hi, I’m a fresh user of Logseq DB but there seems to be a feature that does exactly that.

In this doc it says that simply applying the #Page tag to a block converts it into a page. I’ve tried that and it seems to work.

5

Thank you for sharing that! I didn’t realize that document existed, or had forgotten about it. It didn’t even occur to me to try adding the #Page tag to a block to convert it.

Based on my experiments and what the docs explain, the behavior differs from what I would have expected to happen. Blocks converted to a page get added to the “Library” and are namespaced under their parent node. I think I had imagined it working the way it would in a flat-file idiom, where a new page would be created and the original node and its references would get re-linked to it.

So, technically this feature does already exist in some form. Is it worth keeping it open for the sake of discussing alternative functionality?

6

You’re right, the parent seems to get moved to Library. I hadn’t noticed that.

But I’ve tried with a second-level block made into a page and that seems not to happen.

I don’t know what to make of this.

7

Neither do I. Having fiddled with it some more, I don’t really get how pages can be effectively used. Their design seems to imply a certain way of using them (such as leveraging the library), but they don’t seem to have any clear advantage over block nodes other than having some special facilities in the UI—such as being able to create them on the fly, showing up in the recents list, having their text as a “title” in the right sidebar and being displayed as a heading in “page view”, etc. It seems that in the DB version, the “page” idiom and its relevant features have been kept to help facilitate migration and also to allow people to work in a folder/file paradigm.

I think this feature could still be useful to people working that way, but I think for anyone just dropping blocks straight into the journal, feature parity with pages would be a good improvement (such as being able to see visited blocks in the recents list, having their text be the “title” displayed when pinned to the right sidebar, etc.)

1 Like
8

I agree with you.

I think the change to the new version could have come with a unification of the concepts of block and page into that of simply a node (blocks are nodes within a node and pages are nodes without a parent).

And no “Library” page. And no special status of journal nodes.

I think Tana (that works and feels very similar to Logseq DB) did it this way, although it’s got the ambiguous “Library” page too and some other oddities.