Filter out or remove link from draft articles in tagged lists

Feature Upgrade · Articles & templates · Created by Ononomad
closed
tagged-list
Have a method to either filter out, or differentiate in some way, tagged articles in lists when they are in draft.   A few options:
  1. Just filter them out of the generated list altogether
  2. Display their title without a hyperlink
  3. add a css tag to them so authors can treat them as they wish through CSS.
  I tend to favour 2 or 3, as it could be a good indicator of 'what is to come' without visitors accidentally getting to the multipass page.  

What functionality is missing? What is unsatisfying with the current situation?

When tagged articles are displayed in tagged lists, it includes articles which are in draft state, but no indication that they are not viewable until after clicking the link, which results in multipass screen. Currently, for worlds with lots of tagged articles, or stubs that have been organised using a tagged system, it can be pretty time-consuming to track down and untag everything.  

How does this feature request address the current situation?

We could add tags to articles as we create them, and when they get published at any time in future, they still get included in relevant lists. For options 2 and 3, we could show the direction and ideas of where the world is heading without causing un-needed multipass experiences.  

What are other uses for this feature request?

If option 3 added, authors could add custom css to highlight them or treat them differently in some way.

The Team's Response

Thanks for the suggestion! This is actually a bug; draft articles shouldn't appear in tagged lists. The bug report is currently under investigation and you can follow its progress here: https://www.worldanvil.com/udan-tracker/495936eb-be0c-4658-86f8-69fdd913983e/view
Current score

16/300 Votes · +4500 points

Votes Cast

  • +100

    by Tecknaragnes
    on 2024-06-25 13:01
  • +300

    by lolmatter
    on 2024-06-25 04:48
  • +300

    by ecl1psed
    on 2024-06-25 03:59
  • +300

    by DMFW
    on 2024-06-24 10:11
    I don't have strong opinions about the specific solution (between options 2 & 3, or even others) but I do like the idea of being able to deliver a smoother experience for visitors where it's clear that links are intentionally unavailable (or not shown) without a distracting "no access" page that takes a reader out of the world. It's nicer if they don't see what appear to be error pages, even if they aren't really errors as such.
  • +100

    by Demongrey
    on 2024-06-23 20:55
  • +300

    by kaixabu
    on 2024-06-23 17:08
  • +300

    by Tillerz
    on 2024-06-23 15:49
  • +300

    by Secere Laetes
    on 2024-06-23 15:14
  • +300

    by Chrispy_0
    on 2024-06-23 14:37
    I actively avoid creating/linking large numbers of draft articles for this reason. I HATE seeing the multipass page on other people's worlds so I imagine they would hate seeing it on mine too.   Also, I agree with Kittymonster. Adding tag CSS classes is a good idea too and solves the problem beyond just fixing tagged lists.
  • +300

    by denversg1
    on 2024-06-23 10:24
  • +300

    by Kittymonster
    on 2024-06-23 08:04
    I would love for article links to get tag css classes similar to article blocks for this reason. On article blocks I add a little lock icon on drafts, and it'd be lovely for be able to show that icon on regular links to drafts too.
  • +300

    by DesNordlund
    on 2024-06-23 07:17
    I'd love to be able to put the link there without resulting in an unuseable link for my viewers. At the same time I prefer to be able to add a link to a draft. So if they can't be filtered for a viewer, could it link to a page saying it is not a published article yet?
  • +300

    by HunterChristmas1247
    on 2024-06-23 02:11
  • +300

    by JoellaKay
    on 2024-06-23 01:00
  • +300

    by Those2Nerds
    on 2024-06-23 00:06
    The trick is having an option that works for both list and block views. Option 2 works better for list view, and 3 works better for blocks. Option 1 works for all of them, which might ultimately be easiest to implement.
  • +100

    by TheDoctor292
    on 2024-06-22 23:35
  • +300

    by Ononomad
    on 2024-06-22 23:32