prev/next post navigation should only use published posts

[mhoennig]

When including post.previousPost/nextPost in a template, these use also draft posts, not just published posts, like in this pref-next-post.ftl:

<ul class="actions pagination">
  	
  		<#if (post.previousContent)??> 
        <li><a href="${content.rootpath}${post.previousContent.noExtensionUri!post.previousContent.uri}" 
                class="button big previous">${content.previousContent.title}</a></li>
         </#if>
       <#if (post.nextContent)??> 
        <li><a href="${content.rootpath}${post.nextContent.noExtensionUri!post.nextContent.uri}" 
                class="button big next">${content.nextContent.title}</a></li>
        </#if>
	
</ul>

Not only are those links to drafts broken, but it also reveals the topics one is working on, and with a little URL tweaking, even reveals the contents.

Even though in templates, there is published_posts next to just posts, I think it would make more sense if the default was accessing only the published articles.

Given this, the fix is pretty easy, just add and status='published' to the WHERE clause in `ContentStore.STATEMENT_GET_UNDRENDERED_CONTENT? . It seems there are no explicit tests at all for these SQL-statements so far? Is this deliberate? If I change this, no test fails.

I wanted to try the guidelines for pull-requests, but unfortunatly the link to the developer mailing list seems to be dead.

[mhoennig]

It seems the fix is not that easy, because this query is also used to render the draft-posts itself :-( I just saw the old files from earlier runs.

[jonbullock]

Apologies for just getting round to replying to this.

I think I'm following what you're saying. It would appear that the logic in DocumentsRenderer that picks what is next/previous needs a filter for draft content. As if you add the filter to ContentStore the draft content itself is no longer output. Am I correct?

[jonbullock]

And I've just noticed your PR relating to this #652 🤦