Query infinite load more button disabled when frontend rendering turned on

General
1

Description:
When I turn on frontend rendering on a query, almost all configuration options for the “Infinite Load More” Panel disappear – I’m only left with the option to choose between “Button” and “Scroll”. Setting “Load More” to “Scroll” and scrolling the page on the frontend correctly fetches and displays new posts.

With frontend rendering turned on, I would expect the Infinite Load More panel to work exactly the same as with FR turned off. Concretely: switching the “Load More” property to “Button” should preserve all further properties (especially “Button ID”). And on the frontend the Load more button I defined should load new posts on click. With FR turned on the button does not do anything.

Step-by-step reproduction instructions:

  1. Open the Post Editor/Site Editor
  2. Add a Query block
  3. Add a query template block
  4. Add some content inside the query template block
  5. Add a button
  6. Activate infinite load more on the query
  7. Set the the button’s ID as the Button ID in the infinite load more panel
  8. Check on the frontend, everything works fine (on button click new posts are loaded)
  9. Turn on frontend rendering
  10. Notice that almost all properties are gone from the Infinite Load more panel
  11. Check on the frontend, button ceases to work (on button click nothing happens)

Screenshots, screen recording, code snippet

Screenshot 2024-09-23 at 19.54.58
Screenshot 2024-09-23 at 19.54.58544×760 18.4 KB

Environment info

  • WordPress version: 6.6.2
  • Cwicly Plugin version: 1.4.1.8
1 Like
2

Update on this issue:

Tried this out on a new browser with completely wiped cache and all other site data. Problem persists. Also updated to cwicly 1.4.4 and the problem persists.

Has anybody encountered a similar bug? Is there anything else I can try on my end? I also tested this on a completely fresh wordpress install with both cwicly 1.4.1.8 and 1.4.4, but no luck.

Is the infinite load more button not supposed to work with frontend rendering turned on or is this really a bug?

Cheers
Marc

3

We haven’t needed to use this feature so can’t say for sure but on the face of it it looks like a bug. @Louis will be able to determine one way or another.

4

Interesting, from your omnipresence here in the forum and your allround knowledge about cwicly I thought you and your team would’ve used virtually every feature cwicly has to offer :smiley:

But alright, I’ll wait and see how Louis evaluates the situation.

For additional context, one more things I tried, but didn’t work:

I noticed that enabling frontend rendering removes the HTML property data-ccquerybutton from the query div on the frontend and instead adds the property data-cc-il (which I assume stands for “infinite load”). I then looked at the script cc-query-infinite.min.js, which I understand controls the load more functionality. There I saw the following code snippet:

const t = document.querySelectorAll("[data-ccquerybutton]");
    t.length && t.forEach(function(e) {
        queryInfiniteButton(e.id, e.dataset.queryid, e.dataset.ccquerybutton, e.dataset.ccinfinityhistory, e.dataset.ccinfinityhistorytitle, e.firstElementChild, e.dataset.ccinherit)
    })

This indicates to me that only the queries which have the data-ccquerybutton attribute get targeted. Therefore, I manually added the property to the query inside the cwicly editor and set its value as the ID of the button that should load more posts. Unfortunately, this did not work.

As you can see, I’m also fine with workarounds if the bug cannot be fixed right away, but I haven’t yet found a way to break through. So if @Louis or anyone has an idea, I’d greatly appreciate it :slight_smile:

Cheers
Marc

1 Like
5

Heh, well, probably most features, but Cwicly does have a lot of them and we are still finding more gems even now. :mag_right:

From your investigation I am guessing that this is an asynchronous issue. Effectively for this to work, there would need to be a mutation listener on the query template wrapper that re-runs the querySelectorAll every time new data is loaded in. I don’t have time to look in depth at the moment, but this is my best guess.

6

Hello @marc,

Since Frontend Rendering works a bit differently currently, the button will have to be placed within the Query block.
From there, instead of specifying the ID within the settings, you can add an Action to the block through the link settings: Load More Items

Hope that helps.

1 Like
7

Thanks for your input @Louis and @StrangeTech , much appreciated!

Ohhhh, alright, didn’t realise there was also a “Load More Items” Link Action, thanks for the tip! I’ll try it out once I’m near my installatiom again and let you know if that worked :slight_smile:

8

@Louis adding the Action “Load More Items” to the button worked flawlessly, thanks! I still don’t quite know if what I’m experiencing is a bug or not. If not, feel free to move this thread to General :slight_smile:

And do I understand you correctly that you’re planning a rework of the frontend rendering functionality?

1 Like
9

Hello @marc,

Thanks for confirming that.

Indeed, not a bug since the overall function when Frontend Rendering is active is a little different.
With the rework that is planned, these differences should be removed.

2 Likes
10

Sorry for reopening this thread, but during the pre-launch beta phase I’m getting an unexpected amount of feedback from users who tell me that they don’t see any posts on the page. So it seems like for some users the posts don’t load at all.

I’ve tried to reproduce this issue on multiple devices, browsers and operating systems, but I haven’t been able to. My test users tell me that this issue does not always happen, only sometimes when they visit the website. So maybe I haven’t had the right timing to witness the issue in action. But still, the issue is happening on a core part of the website, so I cannot afford to leave it to chance.

Has anyone received similar feedback on pages that were using frontend rendering with (or without) infinite load more?

11

Several times in the past, after modifying some filters for a Query that has Front End Rendering on, the loading skeleton was displayed but no posts loaded.

After re-editing the page, this was immediately resolved and everything worked.

We have several sites that have been running filtered queries for years without any issue, so I don’t think this is a general issue with Front End Rendering.

If it is not an issue with infinite load more, then it is likely there is something specific about the site and/or the query or filter configuration that is the distinguishing factor. Alternatively it could be as simple as a connection issue or something in the user’s browser.

It may be worthwhile seeing if there are any consistent similarities between the users who have reported this, such as the browser or browser settings/extensions they use.

Another potential path is, if you share your query/filter config, someone may be able to identify anything that could potentially impact the loading.

2 Likes
12

Thanks for the quick reply @StrangeTech !

Looks like I’m making progress: after re-editing some other blocks on the page, posts are visible to more users.

Unfortunately, there seems to be a cap on the number of posts displayed on the frontend. Even though I have 69 posts registered, only 50 are displayed on the frontend. Inside the cwicly editor all 69 posts are displayed. I set the “Posts per Page” field inside the query builder to 100. Only when I disable frontend rendering do all 69 posts appear on the frontend.

Does frontend rendering cap the number of posts to 50 on the frontend? If yes, is there any way increase that cap? Or is it not advisable to that for performance reasons?

13

Update:

Looking at the AJAX request in the browser developer console I noticed that the postsPerPage parameter was in fact being capped to 50. Defining any number below 50 was reflected on the frontend no problem.

I tried many different approaches to override query parameters with no luck, so I dug deeper in the cwicly plugin code looking for any clue.

Inside the file class-main-query-api.php I found the following snippet:

case 'posts_per_page':
	$max_pages = apply_filters( 'cc_wp_query_max_posts_per_page', 50 );
	if ( $value <= 0 || $value > $max_pages ) {
		$query_args[ $key ] = $max_pages;

		break;
	}
	$query_args[ $key ] = $value;

I then defined the following code snippet targeting the same WP filter:

add_filter( 'cc_wp_query_max_posts_per_page', function( $max_posts ) {
    return 100; 
});

I’m sure there’s a good reason to cap the posts per page to 50, so if there’s a better solution do let me know :slight_smile: For now I’ll be rolling with it.

1 Like