kirby icon indicating copy to clipboard operation
kirby copied to clipboard

Pages position changeable even sortable disabled in sections

Open afbora opened this issue 3 years ago • 10 comments

Describe the bug
Pages position changeable even sortable disabled in sections: sortable: false

To Reproduce
Steps to reproduce the behavior:

  1. Go to any sections
  2. Disable sortable with sortable: false option
  3. Click "Change Status" (listed pages) in same section
  4. Change position and save

Expected behavior
shouldn't be able to change the position when sortable disabled.

Screenshots

Kirby Version
3.4.4

afbora avatar Oct 18 '20 17:10 afbora

Looking at this, I think it actually shouldn't be the section which defines whether pages are sortable or not. But the blueprint of the page itself.

distantnative avatar Oct 19 '20 15:10 distantnative

Yes, even if sortable is disabled in the section, the page position can be updated in the page detail. So a page blueprint based setting as you said seems to solve the issue 👍

afbora avatar Oct 19 '20 16:10 afbora

I agree. We need to move more of those page-specific settings into the page blueprint instead of sections. This will make sections a lot less complicated and weird.

bastianallgeier avatar Oct 20 '20 07:10 bastianallgeier

What would happen in the following edge-case:

Let's say you have a page that allows children with two different templates. Template A has sorting enabled, template B has sorting disabled in its own blueprint.

How should a pages section that contains pages with templates A and B behave? Just allow sorting of the pages with template A? Don't allow sorting at all once one of the pages isn't sortable?

To be honest I'd say this is pretty unsolvable with our section setup in v3.

lukasbestle avatar Oct 20 '20 18:10 lukasbestle

Reference to the related Nolt idea: https://kirby.nolt.io/149

lukasbestle avatar Oct 20 '20 18:10 lukasbestle

In addition, the position of a page is related to its status: https://github.com/getkirby/kirby/issues/1969#issuecomment-687178587

afbora avatar Oct 20 '20 19:10 afbora

@lukasbestle but don't we have that situation already if e.g. blueprint A has num: date while blueprint B has num: default?

distantnative avatar Oct 20 '20 19:10 distantnative

Yep, it's pretty difficult to get this right in the UI, but I think at least it could be correct in the backend.

Let's say we mix sorting numbers and sorting permissions and there was a page structure like this:

- parent
  - 1_child-a
    - template-a.txt
  - 2_child-b
    - template-a.txt
  - 20201001_child-c
    - template-b.txt
  - 20201002_child-d
    - template-b.txt
  - child-e
    - template-c.txt

With the following blueprint setups

# /site/blueprints/pages/template-a.txt
num: default
# /site/blueprints/pages/template-b.txt
num: date
# /site/blueprints/pages/template-c.txt
sortable: false

Template A

All pages with template-a get sorted the normal way. The sorting number is always formed by the index. All pages with templates that have different num settings should be ignored by creating that index. I.e. pages with template-b or template-c are not counted

Template B

All pages with template-b get sorted by date. They completely ignore their indexed position. Sorting in the frontend is disabled for them anyway.

Template C

All pages with template-c cannot be sorted in the frontend and in the backend. They will be sorted alphabetically. They will never get a sorting number unless it has been manually added in the file system. We cannot solve this edge case though.

For the frontend, we would be able to disable sorting individually for each page. We already do this based on the num setting and an additional sortable: false setting could be used as well.

Do you see other cases that I'm missing here?

bastianallgeier avatar Oct 21 '20 07:10 bastianallgeier

@bastianallgeier Sounds good!

lukasbestle avatar Oct 25 '20 12:10 lukasbestle

This issue has been automatically marked as stale because it has not had recent activity. This is for us to prioritize issues that are still relevant to our community. It will be closed if no further activity occurs within the next 14 days. If this issue is still relevant to you, please leave a comment.

stale[bot] avatar Aug 10 '22 10:08 stale[bot]