🚀 Feature Request: Allow to define a Query offset for Archive Posts and Loop Grid

[ipagani]

Prerequisites

• I have searched for similar features requests in both open and closed tickets and cannot find a duplicate.
• The feature is still missing in the latest stable version of Elementor ( Elementor Pro )

What problem is your feature request going to solve? Please describe.

When designing archive pages, I want to be able to use offset in order to create a custom mixed-column layout. For instance, where the most recent post within a category is in 1 column, then I can use offset for another post widget to create two columns for the rest of the posts, essentially allowing me to highlight the most recent post.

I've seen some themes have this built in as an option, and some 3rd party plug-ins that either allow you to highlight the first post within an archive using a single design widget, or use offset to get that effect (and more customization) using multiple widgets.

Currently offset does not exist in the archive post widget, and it disappears as an option if you use the current query option within the standard posts widget, effectively making this design style impossible within dynamic taxonomy designs.

I've searched far and wide and have fiddled with elementor for months to try and do this - I've concluded it's not possible.

Describe the solution you'd like

I would love for this to be built into Elementor or pro natively so I don't have to install an entire plug-in or theme for this one function.

Describe alternatives you've considered

The only "work around" is creating a standard page for each category instead of using the category archive. Understandably this is a ton of manual work for larger sites and ultimately, users can still end up in an archive via search or breadcrumbs and see a completely different design / result.

Preferably I would love to see this just built into one or both of the post widget types offered by elementor

Additional context

No response

[nicholaszein]

Hello, @ipagani!

Thank you for contributing with your ideas! 🙏

This functionality is already available in Elementor Pro Posts, Products, and Loop Grid widgets. When setting up your query all you need to do is to go to the Exclude tab in the Query Group settings and define your offset. Please check the documentation for more information:
https://elementor.com/help/posts-widget-pro/#:~:text=Offset%3A%20Use%20this%20setting%20to%20skip%20over%20posts%20(e.g.%20%E2%80%9C2%E2%80%9D%20to%20skip%20over%202%20posts).

However, this is not possible in WordPress archive templates due to how archive queries (Current Query) are built. This would require Elementor to modify the current query and could cause conflicts with other plugins, your theme, and WordPress itself.

This is why Elementor has the Custom Query Filter feature, so you can make the changes yourself knowing that it will work with your WordPress installation.

Currently, we have no plans to add this feature due to the complexity and limitations it imposes as explained above. We will, of course, keep this suggestion in mind and consider adding it if there is significant demand in the future.

Please feel free to contact us again with other feature suggestions. 😉

Best regards

[danieliser]

@nicholaszein - Why would you need to change the query, simply don't render the first X offset posts when looping over them. It would effectively work exactly the same on the front end without any need to mess with query overloading.

Pretty frustrating not being able to do dynamic inserts on archive or blog index due to this limitation.

There is definitely a simple solution here being overlooked.

[nicholaszein]

@danieliser this is a WordPress limitation, not Elementor's. We cannot account for every case scenario out there when it comes to the main query.

[danieliser]

@nicholaszein Hmm, in my mind modifying the query as a methodology here is not a possibility due to core limits, correct.

BUT, you could simply add conditional breaks in the loop that renders the module, breaking after showing X posts, or skipping Y posts at the beginning.

Overly simplified of course, but the following would safely work without worrying about WP core.

foreach ( $posts as $post ) {
    $i++

    if ( $i > $X ) {
        break;
     }
     
     if ( $i < $Y ) {
         continue;
     } 
     
     // Render post.
};

Obviously I can see this could lead to possible confusion with other query types, so make it only functional & optional for Current Query.

Your teams call ultimately, but this would be a simple enough fix if you can limit side effect exposure.

[nicholaszein]

@danieliser The Current Query is an abstract query source. Meaning it fetches whatever is queried for that archive. We can't know for sure what is being queried. Themes, plugins, and even custom codes may be modifying this. If we try to modify it further, it would simply create a whole bunch of possibilities for conflicts.

The correct way to deal with this type of very specific case is to use pre_get_posts(), or modify the WP_Query entirely.

This should be something that each individual should do. We can't possibly consider every single case scenario. So I understand your suggestion, however, this is highly unlikely to happen. It's a can of worms that is simply too complicated to control.

In the future our position might change, but for now, this is highly unlikely. I hope you can understand.

[danieliser]

@nicholaszein I think you missed my point. I'm suggesting something completely different, not to modify the query at all. Just modify the loop that renders it.

No matter where you pull the query from you can easily choose in PHP to render or not to render any given iterabile in the loop.

So NO, don't modify the main query, that will have side effects.

But you can just not render the first X, or last Y. You don't have to modify anything about the query, just don't render the appropriate items.

Obvious you already have made your choice, all good. Appreciate the time just the same.

[nicholaszein]

@danieliser yes, I understood your point. Apologies for not being clear enough.

Changing the rendering is an interesting idea, however, we did test multiple ways of doing this, including using pre_get_posts() (just as an example), and the results were less than desirable in many aspects, the most important being performance. There is also something that we are always really careful, which is user experience. By giving this option, regardless of how we do it, means adding yet another layer of complication that can lead to user error. And troubleshooting this is really difficult. People make mistakes when they don't understand what they are doing, and given the possibility of querying already modified queries, there is another layer of complication. Let's say for example a query order is ascending. Now we have to make sure to account for that, otherwise we might skip the wrong posts.

Ideally we need to find the sweet spot between usability, options, and ease of use. This means making hard decisions, such as how far we can go with features.

As an advanced user, I would love to have all the options at the tip of my fingers, so to avoid wasting time making custom code. But I understand that less advanced users would have difficulty in making things work because of the complexity at hand. Most of the time, we don't need such specific requirements, and if they are needed, there is always a way to code.

I know this is not what you are expecting to hear, and I understand (and am grateful for) your point of view. For now, this is something that probably won't be possible to achieve. Maybe in the future we can revisit this.