lektor / lektor-atom

Lektor Atom plugin.
30 stars 13 forks source link

Feed pages are auto-pruned #10

Closed freakboy3742 closed 3 years ago

freakboy3742 commented 7 years ago

Using Lektor 2.3, feeds are correctly generated - but then immediately pruned by the lektor build process. It is necessary to use the --no-prune option to get a working feed output.

An example project demonstrating the problem can be found in the pybee/pybee.github.io repository.

goanpeca commented 6 years ago

I think I have seen this happen before. Need to double check. It definitely happens on the pybee site.

eigengrau commented 6 years ago

I ran into this after enabling the alternatives system within Lektor. I also noticed that this does not trigger for all feeds, but only those associated with pages that exist only for the primary alternative (so, contents.lr exists, but contents+en.lr does not.

eljoest commented 6 years ago

I'm seeing the same problem with active alternatives. The feeds that are based on a page without translation get pruned. This happens even for the primary alternative, if there's no "(Overlaid)" content (in my case the primary is de, secondary is en. If there's no contents+de.lr the primary feed gets pruned. If there's no contents+en.lr the secondary feed gets pruned).

mantuko commented 3 years ago

I'm on Lektor 3.2 and my feeds still geht auto pruned.

dwt commented 3 years ago

I'm pretty sure the problem behind this behaviour is that the feed can't / doesn't depend on any file in the lektor source code besides the project file and thus the build system thinks the file is obsolete.

See

I'd like to tackle this, but I'm not entirely sure what the right way to go about this is. Ideas welcome.