Not Working With Pagination

I haven’t run into that problem on standard WP themes or on other paginated custom loops. It’s interesting – though I’m sorry for the inconvenience!

Three main points that are unclear to me:

1. When you say the fallback featured image isn’t getting applied, do you mean all images you expect the plug-in to provide, or do you mean something more specific? Does that mean that regular category images and regular featured images work fine?

2. Is your theme a custom installation or something available from the WordPress free theme repository? Have you tried switching to Twenty Seventeen or one of the other annual themes, just to be sure everything else is OK?

3. When you say “custom page where [you are] calling the loop,” could you be more specific about where the page comes from or how it’s generated?

Is your site accessible on-line? Anyway, solving this might take getting more deeply into the specifics of your installation… I’d really like to figure out what’s going on, but it may not be an instant fix.

• This reply was modified 7 years, 8 months ago by CK MacLeod.
• This reply was modified 7 years, 8 months ago by CK MacLeod.

It may very well be an issue with the theme; I’m leaning towards that, but wanted to know if you had run into this before. I will be testing a free theme on a stage environment. If I could get an email from you, I would send you a link of the live site.

1 -> the fallback feature image isn’t getting applied to all posts; unless I set the page/template/settings to display all posts. Meaning:
Lets say I’ve got 30 articles for example. The wp-settings are to only show ten at a time; thus causing pagination. The fallback feature image gets applied to page one. The fallback featured image does not get applied to pages 2 or 3; regardless of pagination ‘style.’

2 -> The theme is not on the free theme repository.
It can be found: https://themeforest.net/item/jupiter-multipurpose-responsive-theme/5177775
An example of the ‘default’ loop for it is here: https://demos.artbees.net/jupiter5/blog/blog-modern-full-width/
I will be testing theme twenty seventeen on a stage environment soon and will post results here.
If I get your email – I will give you a link to the live site

3 -> I’ve customized the blog loop templates to read-in the images size; then calculate if the image is landscape vs portrait view; and then alter the output accordingly. The template files for the ‘archive/category’ pages use the templates; and so does any call to a blog loop. Its working as expected.

Also your plugin is working as I would have expected, with the exception that any paginated pages/post loops to get the ‘fix’

I tried on a development site – same plugins and articles – to use a free theme Twenty Seventeen; and your plugin does seems to work as expected; all posts missing a featured image get the fallback image.

Any ideas on how to call your plugin from the theme upon pagination; because something is occurring with the Jupiter theme that is not calling your plugin when a new page from the posts are listed.

Or maybe what hook are using to call your ‘actions’ so maybe I could move to one my theme hooks?

I think the problem is clear. It has actually given me some interesting new ideas for further development of the plug-in, but I’m not sure how long it will be until I can solve your particular problem using it with this theme.

It seems that the Jupiter theme uses an Ajax-enabled “load more” form of “pagination,” as opposed to WordPress standard PHP-based pagination. I’m guessing, though I can’t say for sure without looking at the code, that the load more script goes looking for the featured images in a sense both before and after the plug-in does or can. In other words the PHP engine re-creates the page on every reload, and the filter it uses arrives at is proper moment in the sequence as computed. The Ajax function avoids the new page reload, and goes right to the database to extract its images.

I see no reason, in theory, that CFIX, or an expanded version of it, couldn’t do that or something like it, essentially re-producing the same logic from the PHP script – but that would be… a project: no doubt a worthy and educational one, but I still haven’t even gotten around to publishing the new upgraded version of CFIX.

I do think there might be an easier way around that – by ensuring that when Ajax or anyone else comes knocking there is always somebody home, and the tools I’m now envisioning might produce some alternative benefits for some users – but I’m going to have to look into the matter further. If my initial experiments go shockingly well, I might have something sooner than you would think or than I can currently promise.

I think in the meantime I’ll have to add a warning to the next update of CFIX about what it can’t do at this time: insert itself into Ajax calls.

To answer your question on hooks, and in order to illustrated the issue further, the main plugin function relies on the get_{$meta_type}_metadata filter from the get_metadata() function in includes/meta.php. So, it’s called when get_metadata() is called. In essence, I’d say, Ajax calls of the ‘load-more’ type use their own “get_metadata” functions.

If you wish to discuss the matter more you can always contact me via my site contact form, and you can always find my blog via my WordPress profile. Also, all of my plugins include contact info and links to plug-in support and documentation, also at my site, on their settings pages.

I’m thinking I’ll mark this thread resolved, as I think the matter is probably settled as far as the plug-in at this stage is concerned, but I’ll wait for you to confirm (or decline to object…).

I concur, as far as the plugin goes, the problem is resolved.

Concerning Jupiter:
data-page-attribute[#] is main container;
the pagination using onClicks to alter the page-attribute; and yes I agree must be pulling the specific posts from database again; because your plugin adds the fallback image to first page; I click page 2; posts appear but no fallback image; I click page 1, and even though they had fallback images they no longer do. Suggestion what you are saying, page is not re-loaded, just new data via Ajax.

I’ll most likely hard cord something into the templates now; but I was trying to save time : P lol.

I’m playing around with the templates right now to achieve the fallback image in a another manner – similar to my portrait vs landscape issue with it.

If I have more time at a later date; I will attempt/play around with what you are talking about as well; maybe save someone else time at some point. But for now, I must trudge on to other tasks as well.

Thank you for your time and effort

• This reply was modified 7 years, 8 months ago by goodyis. Reason: marked as resolved

So… I got it to work on the stage environment.
I first got it working in the same fashion that your plugin had it working; just inserting a fallback image for those posts that didn’t have a featured image; but – like your plugin – it only worked on the first page.

But clicking on page 2, and having the slow load feature set; both gave the same result, no fallback image.

After I stepped away from it; the ‘light-bulb’ went on.
We already figured ajax was being used, and more then likely as such probably just loading in the data again. After looking at the data-attributes generated and realizing that

Because AJAX is already used in WordPress’ back end, it has been basically implemented for you.

I just needed to FIND where Jupiter was calling wp_ajax() on post loops.
ended up finding /framework/helpers/load-more.php

After some variable dumping and console.log push(s) I found the problem.

The templates I had been editing and making changes to; were not the templates that were being called. Each time a new page was selected; a new wp_query was called, accounting for existing data-attributes (to skip those posts).
Then the themes ‘shortcode’ mk_blog is called with some global attributes and some of the existing attributes; but not all. The shortcode was calling the default loop style, not the one I had created.

So I just had to redeclare the $atts['style'] to my new style.
Because here is the shortcode/view call: mk_get_shortcode_view($atts['shortcode_name'], 'loop-styles/' . $atts['style'], true, $atts);

Sounds like quite a brainstorm, but it’s hard to follow without seeing the code you’re adjusting. I’d especially enjoy looking at it on the off chance that it could be adapted as a more general solution incorporated in some way into the plug-in itself or its documentation: In either case I’d give you full credit for it, of course!

I’m speculating here without yet understanding what you’ve done, but it might conceivably provide a basis for an alternative implementation of the plug-in – IF it scales.

On the last note, I wonder if you’ve noticed any significant performance difference, as I could imagine it going either way or having little overall effect at all. For performance reasons and also for particular applications I also still like the alternative solution to your problem (and others) of producing an option to assign thumbnails en masse (but by category, tag, etc.) to posts that don’t have them or that have corrupted ones.

That might be especially useful for the next version of the plug-in, which includes the option to create taxonomic and global groups of images for the logic to select from among semi-randomly. (It’s currently in use at my site without any such pre-assignment feature, and has needed some housekeeping adjustments, additional re-coding, and testing for a good while now.) I wonder how it would work in its present form with your solution.

• This reply was modified 7 years, 8 months ago by CK MacLeod.