Page disappears, when containing meta-file without related file

[owzim]

Description

1. quickly boot up a kirby startekit:

git clone git@github.com:getkirby/starterkit.git lost-pages
cd lost-pages
composer install
php -S localhost:3001 kirby/router.php

2. navigate to http://localhost:3001/panel/site see about us page being displayed as expected

3. delete an image without deleting the meta file rm content/3_about/table.jpg see the page disappeared

the page also disappears when references somewhere else, it's actual page (http://localhost:3001/about) in the frontend is empty

BUT:

This scenario was not caused by manual deletion of the file but during regular use of the panel. It is unclear how it happened, but kirby itself caused the problem.

Nevertheless, the page should not be invisible by the whole system just because a file is missing.

Your setup

Kirby Version 4.0.3

[distantnative]

If the actual file is missing, Kirby has no means to know which textfile is the actual content file and which one the leftover meta file. So this is expected and we won't be able to fix it - competing content files (so more than one without a matching actual file) will cause troubles. E.g. the other content is used and the other content file now determines a totally different template.

during regular use of the panel. It is unclear how it happened, but kirby itself caused the problem.

We will need more information on this. If it indeed was caused by Panel usage alone, this would be a bug indeed. But without more information I am afraid we won't be able to replicate the problem and, if needed, to fix it.

[distantnative]

If you have any additional information how to replicate this via Panel usage, please let us know and I will open the issue again. Closing it for now.

[owzim]

@distantnative

It happened again ...

We have two clients which by their day-to-day use of the system every now and then stumble upon the issue, that a metafile is left without the actual file being there and then interpreted by kirby as a template-name/content file. We cannot reproduce the issue, it happens occasionally (maybe by some race condition or interrupted processes) and it generates unnecessary support and I fail to rationalize the reasoning behind it to the client:

A meta file is left dangling due to some unknown circumstances, and then kirby interprets it as the content file of the page, so any template filtering or field config is out of the window.

what? that seems horribly unstable

And I agree. The determination if a text file in a folder is a file-metafile or a page content file seems like it's not properly designed.

In my opinion, there are at least two options to determine the text-file-type in a more stable manner:

1. by template name

Kirby knows about the available templates, via the templates folder

• templates/
  • event.php
  • default.php
  • album.php

so if in a page folder, there is a text file with any one of those template name, it's the content file

• some-page/
  • event.de.txt
  • some-missing-file.png.de.txt

2. by determining if the plain name contains a dot, hence an extension

• some-page/
  • event.de.txt
  • some-missing-file.png.de.txt

remove the option('content.extension') and language suffix:

• some-missing-file.png <- contains a dot an an extension, so it's a meta file
• event <- contains, no dot and no extension, it's the content file

maybe there are more or even better ways, but everything is better than just taking whatever text file without an accompanying page file comes first.

[owzim]

@distantnative It happened again and again in many occasions. Hard to debug. Most likely to do with multiple users accessing pages in the panel. Perhaps related: https://github.com/getkirby/kirby/issues/6724

To prevent anymore reputation loss of kirby within our company and towards our clients we have this patch on all our kirby projects in our composer.json for the getkirby/cms package:

diff --git a/src/Filesystem/Dir.php b/src/Filesystem/Dir.php
index b51b80b..165a7f0 100644
--- a/src/Filesystem/Dir.php
+++ b/src/Filesystem/Dir.php
@@ -318,6 +318,11 @@ class Dir
                continue;
            }

+           // has a dot, so it's most likely a meta file
+           if (strpos($name, '.') !== false) {
+               continue;
+           }
+
            // it's most likely the template
            $inventory['template'] = $contentName;
        }

This kind of data loss is really damaging :frowning_face:

[distantnative]

@owzim Sorry we missed your previous reply from 2 months ago.

Since this isn't reported so far by any other customer, could you please share more details about your setup: config, plugins etc. - maybe the root of the issue is hiding there somewhere.

Regarding your suggestions:

1. We would need to check the performance implications here. This could be a problem.
2. It's not uncommon for developers to also use dots in their template names. This would be a huge breaking change for them.