2

How do I create an entries loop that will pull content even if the entry in the loop is not set to Live?

e.g., I have a Matrix so a user can select entries to feature in a slider. They want the slider to feature entries even if the entry itself is currently hidden/unpublished.

{% for caseStudy in entry.featuredCaseStudies %}
    <div class="slide">
        <div class="text">
            {% if caseStudy.status == 'live' %}<a href="{{ caseStudy.url }}">{% endif %}
                <img src="{{ caseStudy.caseStudy.first().clientLogo.first().getUrl('caseStudyTumbnail') }}" alt="" />
            {% if caseStudy.status == 'live' %}</a>{% endif %}
        </div><!-- .text -->
    </div><!-- .slide -->
{% endfor %}

This works only in as much as the anchor is only output if the linked entry is live. But I can't get it to spit out the image; presumably because the entry isn't live.

2

Short answer

Change this line:

{% for caseStudy in entry.featuredCaseStudies %}

to:

{% for caseStudy in entry.featuredCaseStudies.status(null) %}

Long answer

If “featuredCaseStudies” is an Entries field, then typing entry.featuredCaseStudies will give you an ElementCriteriaModel object, configured to return all of the entries related to entry via that “featuredCaseStudies” field (using the relatedTo param). Just like the ElementCriteriaModel object you get when typing craft.entries, you’re free to chain in additional parameters after entry.featuredCaseStudies.

By default, entry-targetting ElementCriteriaModel objects will only return “live” entries – entries that are enabled, and whose Post Date is in the past, and whose Expiry Date is either not set or set in the future. You can alter that behavior using entries’ status criteria param. Setting it to null tells Craft to not factor entries’ statuses into the query whatsoever, which is what you’re looking for here.

4
  • Ah, I see! My problem was I was trying to go through a Matrix to do this (featuredCaseStudies was a Matrix, which had a block type that was Entries). This didn't work for that arragement, but I realised I could switch it to a plain Entries field rather than having to have a Matrix in this case. Thanks! Oct 2 '15 at 8:07
  • Ah gotcha - and now caseStudy.caseStudy.first() makes more sense; caseStudy.caseStudy was the Entries field; not entry.featuredCaseStudies. Was there any reason you did this with a Matrix field and sub-Entries field, rather than just a simple Entries field? (It looks like you had status and url fields on your Matrix blocks as well? Were those actually necessary or would it have been better to grab the actual case study entries’ statuses and URLs rather than duplicating that data in your Matrix field?) Oct 2 '15 at 15:00
  • 1
    Reason I ask is because you can get it to work either way - you just would need to add that .status(null) param to the actual Entries field reference (caseStudy.caseStudy.status(null) rather than to entry.featuredCaseStudies. Oct 2 '15 at 15:01
  • In this case no, I'd just got stuck in a Matrix mindset, but I can see it being useful in a Matrix in future projects. Thanks for the info :) Oct 5 '15 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.