In the thread template the next.url and previous.url tmpl_vars are always defined wether a next or previous thread exist or not. This is because the existence of a next or previous thread is not checked when the url's are generated.

I thought this might be intended behaviour, but the Default Submission template indicates otherwise. It contains tmpl_if checks to see if next.url and previous url are defined.

    <tmpl_if previous.url>
        <a href="<tmpl_var previous.url>" class="controlLink"><tmpl_var previous.label></a>
    </tmpl_if>   

    <tmpl_if next.url>
        <a href="<tmpl_var next.url>" class="controlLink"><tmpl_var next.label></a>               
    </tmpl_if>    

 This will be fixed in 7.3.16

Wouldn't the performance penalty be a lot smaller if checking for a previous or next thread would be done without instanciating Thread assets? That isn't really necessary when ?func=previousThread is used instead of a direct url.

I did see that you go back to the main listing when there's no previous or next thread, which is a good feature. But it would still be nice if you could leave a link to the next or previous url out of a template by checking if a next or previous url actually exists. The <tmpl_if previous.url> in the Default Submission template does imply that this should be possible.

By the way, DBell and colink mentioned that macro's like PageTitle  return inaccurate information when www_nextThread or www_previousThread are used. I didn't look at this myself but i'm pretty sure your last change reintroduced this problem. Colink also added notes in Thread.pm that www_previousThread and www_nextThread are depracated, which is not the case anymore.

Yung