Entries that truly cannot be rendered on the web

SoniEx2 commented 4 months ago

Expected Behavior

We would like to have entries that do not get rendered on the web, for use as bonus/exclusive entries for atom feed subscribers.

Current Behavior

Some themes/templates currently use regular entries with special metadata to produce external links in a category's sidebar. This mechanism doesn't seem entirely suitable for bonus/exclusive entries, as we don't want them to be linkable.

Possible Solution

(hmm...)

Steps to Reproduce (for bugs)

N/A

Context

While we don't need them to be truly unbrowsable (after all, they'd show up in the atom feed, you could just view it in the atom feed), our goal is to encourage creatures to use the atom feed. For all we care, someone could even make an URI to the exclusive entry - so long as it points to the atom feed. They can link the feed, they can link the entry in the feed, but they shouldn't be able to link the entry on the web.

fluffy-critter commented 4 months ago

Publ doesn't really differentiate templates based on whether they're "web" or not, since it's all just HTTP in the end anyway.

I think the path forward for a feature like this would be to have a header like Allowed-Templates and/or Blocked-Templates or the like, so for example if you only wanted an item to appear in your Atom feed you'd say:

Allowed-Templates: feed

or if you just didn't want it to appear in, say, your web-based index but did want it in other things (e.g. a permalink page) you'd do:

Blocked-Templates: index

Perhaps it could be given a rule parser similar to Auth, e.g.

Templates: entry !index

In any case, in order to implement this feature, changes would need to be made in a bunch of places, and there might need to be a decent amount of rearchitecting. For example,

view and search need to know what template it's now presenting for (and this information needs to come through Template.render
entry needs something like Entry.show_for_template which would consult the allowlist/blocklist
rendering.render_entry and rendering.render_category similarly need to provide the template name to the underlying render function, and render_entry needs to also raise an appropriate error if the template in question isn't allowed for the entry

Basically this would be an enormously complex change and while your use case is valid it's not something I care enough to support. I'm willing to accept a reasonably-well-considered pull request but I am not going to be doing this work myself.

fluffy-critter commented 4 months ago

Oh also Entry.link should be aware of templates as well and refuse to generate a link to a template type that it doesn't support. That gets super complicated, though, like what should the output be if one isn't supported? That also complicates the templates that rely on it.

All that said, you can already sort of do this with the existing template system. Give an entry a type of feed-only and then restrict your web-based HTML view queries to all have entry_type_not='feed-only' and you're, like, 80% of the way there. In the Atom feed you could also do something like:

{% if entry.type != 'feed-only' %}
<link rel="alternate" type="text/html" href="{{entry.link}}" />
{% endif %}

It does require more maintenance on the side of your templates, though, and it's up to you to decide how to handle someone attempting to load the entry page directly.

PlaidWeb / Publ