Ben @ Team Tangible

Hmm, I just tested this and it seems that if you create a loop and add query parameters that aren’t related to sorting, the sticky parameter seems to work as expected:

<Loop type=post sticky=true>

But if you add any query parameters that sort/order the loop, that sorting takes precedence and the sticky posts end up tossed back into the middle of the posts.

<Loop type=post orderby=date sticky=true>

Do you have query parameters on your loop that are sorting the loop in some way?

In general, the developers design things to mimic core WordPress functionality as closely as possible to keep things as efficient as possible, so this might be one of those cases but I’ll confirm whether this is the intended/necessary behavior for this feature. In the short term, if you need to sort your loop based on something and also show sticky posts at the top, it should theoretically be possible to stack two loops, the first where you set sticky=only and the second where you set sticky=false. A bit more verbose, but I assume that should achieve what you’re looking for while also still being able to sort your loop based on some other factors. It might even be possible to compact these two loops to avoid needing to repeat your inner content multiple times with something like:

<Set query=post_loop_1 type=post orderby=date sticky=only>
<Set query=post_loop_2 type=post orderby=date sticky=false>

<Loop times=2>
  <Loop query="post_loop_{Get loop=count}">
    Your inner loop content...
  </Loop>
</Loop>

Obviously a little bit more markup than might be ideal, but then you also have a lot more control over how each query works.

I’ll let you know what I hear back from the devs about whether this behavior of ignoring the sticky parameter on sorted loops was intentional or necessary.

Hi @birous, I’m happy to report that the latest version of the plugin includes the new sticky query parameter that allows you to work with sticky posts in the Loop tag more easily than before. It works a little differently than how I’d suggested earlier, so in the end, it accepts three possible values:

• sticky=true puts sticky posts at the beginning of the loop (sounds like this is what you’re after)
• sticky=false excludes sticky posts from the loop altogether
• sticky=only loops through only sticky posts and ignores non-sticky posts

If the sticky query parameter isn’t set, the loop simply ignores whether a post is sticky or not and loops through all posts as usual.

Let me know if you have any other questions or issues!

@theshae this blog post might help explain why Loops & Logic opted not to use shortcodes as the foundation of its language. And here’s another FAQ article that goes over a lot of the questions that CCS users have about transitioning to L&L. I hope that’s helpful!

Hi again @birous, I just heard back from the dev team and it seems that not only was the ignore_sticky_posts attribute initially designed in a fairly limited way (it apparently only works when is_home() is true, which would be pretty rare), but they also noted that having this be a boolean attribute (true/false) is unnecessarily limiting.

To fix the issue and improve the usefulness of that feature, the team is going to deprecate the ignore_sticky_posts attribute and add a new attribute, sticky. This attribute could be set to one of four values: default would show all posts as normal, first would show sticky posts before the other items in the loop, only would loop through only the sticky posts, and hidden would hide sticky posts, only looping through non-sticky posts. It sounds like when this is released, sticky=only or sticky=default would achieve what you’re trying to do.

I’ll confirm when this makes its way into the released version, but I figured I’d follow up here so that you can keep an eye on the changelog for this feature being added.

Hi @birous, I’m glad to hear that you’re enjoying the plugin overall! I just tested this on my end and I’m getting the opposite behavior: whether I set ignore_sticky_posts to true or false, it always seems to be displaying my sticky post. This sounds like a bug, so I’ll report it to the dev team and have someone follow up here when it’s resolved.

A couple more ideas to try:

• The docs mention that ACF text fields “can be displayed simply with the?Field?tag.” Have you tried writing the attribute as href="{Field edit_post_link}" instead of href="{Field acf_text=edit_post_link}" ?
• If you just write <Field edit_post_link /> in your template my itself, does that display the contents of your ACF field? If not, are you sure you’re using the right field name?
• If neither of those work, I just noticed when I look at the list of fields available inside a post loop (which is also all the fields that are available when you’re on a post, even a custom post) there’s a edit_url field. Does it work if you use href="{Field edit_url}" instead?

Hi @airtasker6, as far as I can tell, it looks like you have the right idea with all the dynamic tags in your template. So you seem to be on the right track! The documentation might not mention how to put that specific field in that specific attribute, but luckily the syntax is the same no matter which attribute you want to work with. If you’re putting a tag inside and attribute, just swap <> for {}, exactly as you’ve done. All you need to look up in the docs is which tag/field you should use to display the data you want. You seem to have been successful at that.

Looking at your markup, I’m noticing that your opening a tag has a slash in it, as if it was a closed tag. In other words, you’ve written <a />link text</a> when you probably meant to write <a>link text</a>. If you get rid of that slash, does that fix your issue?

By the way, just for future reference, you might get better support by posting on the L&L forum. It’s a much more active community and there are more people visiting it, so you’re quite likely to get a response from someone experienced with the particular issue you’re facing.

Hi @chrisrixxo, I just realized that I forgot to follow up here with an update, but I’m noticing that version 3.1.1 of the plugin that was released on December 30 included this in the changelog: “Template post types: Support any database table prefix including wp_” so I believe this should now be resolved. Not sure if this thread was marked as resolved previously as a result of this release, but I figured I’d follow up here in case you missed the release. Let me know if you notice any other issues ??

Hi @gauravtiwari, thanks for bringing this up. It looks like this doesn’t affect all OL/UL lists, but specifically those added by the Gutenberg list block. It also only appears to impact things in the editor, not the front end. I’ve reported this to the devs and I’ll follow up here with updates and to let you know when this has been addressed.

There are indeed! There’s a pro version of Loops & Logic in the works that will add a few additional powerful features including native integrations for third-party plugins that don’t use the WP posts table (like WooCommerce, LearnDash, and several others that are in development), the ability to write and modify data on the database instead of just reading it, and the ability to save and manage your templates in the cloud. If you want to sign up for notifications about when the pro version launches, you can enter your email at loopsandlogic.com.

Hi @lightwebwss, good question. Our team hasn’t had the chance to test to what degree Loops & Logic works with data from every plugin out there, but it works with any plugin that stores data in the wp_posts table. If BuddyBoss uses the standard WP tables and isn’t storing its data in another custom table, you should be able to access data about those groups.

As far as making a carousel, on top of being able to work with HTML and JS right inside your L&L template, there’s also a Slider tag that might help you make a custom carousel pretty easily.

By the way, you might have better luck asking this type of question on the Loops & Logic forum. There are a lot more people that browse that forum so you’d be more likely to find someone who has experience with L&L and specific third-party plugins.

Hi @mvishal71, great question! Loops & Logic works using the core WordPress structure of post types and custom fields. So for the most part, you can work with L&L the same way if you’re working with core fields, custom ACF fields, or post types and fields created with another plugin. We can’t ensure that every other plugin developer designs their plugins to work the “WordPress way” and we haven’t tested L&L with ACPT, but if they haven’t done anything that goes against normal WordPress functionality, then you can just work with ACPT the same way you’d work with any other post type or field in L&L. So for example, let’s say you’ve created a post type called my_acpt_post_type and you’ve got a custom field called my_acpt_custom_field, you should be able to write something like this to loop through that field on all your posts:

<Loop type=my_acpt_post_type>
  <Field my_acpt_custom_field />
</Loop>

This is exactly how you’d work with any other custom post type and field in L&L, so there’s nothing ACPT-specific here. Personally, I’d recommend working with ACF if you can since the only benefit I can see that ACPT offers is built-in templating, but I don’t think there’s anything you could do with their templating tools that you can’t already do better with L&L. To get an idea of how to work with L&L, I’d recommend going through the getting started guide in the docs if you’re not sure where to start. I won’t be able to offer more specific guidance on how to work with ACPT since we don’t officially support that plugin, but hopefully, the documentation gives you a good foundation.

I should also mention that if you need help in the future, there’s a Loops & Logic forum that has a much more active community with people of varied skill sets, so you’ll probably have better luck getting support there compared to this WordPress forum.

Hi @sterndata, thanks for the information, I wasn’t aware of that policy/recommendation and I’ll do my best to adhere to that moving forward. Thanks for your efforts in keeping this forum safe for everyone!

You’re welcome ??

I just realized I made a small mistake in my earlier comment and I don’t seem to be able to edit that post anymore. It should say that the template tag is “used to render/nest templates inside other templates.” Although I guess the language is flexible enough that you could probably also nest a template inside a tag attribute, but that’s not commonly how it’s used. You might find this forum thread to be an interesting discussion about the workflow possibilities that open up when you nest templates inside one another.

Hi @signale, glad you got this sorted! To clarify about the Template tag, it’s used to render/nest templates inside other tags. So you could create a template and then reuse it in several other templates, reducing the amount of markup you need to rewrite and making it easier to manage your templates. You can also pass variables to the nested template as shown in the docs linked above.

By the way, you might want to try posting on our own Loops & Logic forum next time since it’s a bit more of an active community and there are people with a wide range of skillsets on there. Don’t hesitate to ask away if you have any other questions!