adrian

Thank you @bernhard and @ryan This is really brilliant and exactly the type of skinning ability that I think we've been missing!

Can you try this bare-bones example: $pager = $modules->get('MarkupPagerNav'); $items = $pages->find("id>0, limit=10"); // replace id>0 with your selector echo "<ul>" . $items->each("<li>{title}</li>") . "</ul>"; echo $pager->render($items); // render the pagination navigation This works perfectly for me - each page has 10 results and each page starts where the last one stopped. If that doesn't work, and you have pagination enabled for the template where you add this code, then I have no idea :)

Do you need to specify the start? As you can see here: https://processwire.com/api/ref/markup-pager-nav/ everything is automatically handled when you load MarkupPagerNav and use its render() method. No need to specify the start. Does that not work for you?

My apologies @fruid - I read this thread quickly and saw you comment about a custom paginated array and assumed that meant you were building up an array of pages rather than letting the pagination API handle querying the DB automatically. Sorry, I was in a rush and didn't fully grasp things. Good luck getting things sorted. I don't have time to dive deeper into this, but I guess I don't understand why you need to use the setStart() etc methods. I just build my selector and add a "limit=x" to it and that's it - everything else is automatic, but obviously I am not understanding your needs properly.

Have you read any of the linked posts from this thread:

Sorry, but I don't really think this is an accurate statement - I am running Tracy on many sites and it doesn't break pagination in Lister or in frontend templates on any of them. As discussed, I think there is something else going on with your setup and that JS error you are seeing that is contributing.

There have been two changes to the Tracy Logs panel since 2019. This first one resulted in an "Uncaught SyntaxError: Unexpected end of input" error for Zeka, and the second one fixed that. I couldn't ever reproduce it though and don't really understand why he was seeing the error - my guess is maybe something to do with the way I am caching the results for the logs panel and maybe some DB encoding / escaping issues? https://github.com/adrianbj/TracyDebugger/commit/98fae74bcdb5e993d20f9fda37133c7979f39698#diff-6da6812cc20e34e30fb779775ef23d7cf2b15469ac373d4109480dd3c231c787 https://github.com/adrianbj/TracyDebugger/commit/81f3b427defabeb218b7a089432fe2e8c36be93c#diff-6da6812cc20e34e30fb779775ef23d7cf2b15469ac373d4109480dd3c231c787

I still don't think it's an issue with Tracy, but rather because of the weird way the core Tracy files are loaded it's causing the error to have more impacts. I think if you solve the error, Tracy won't impact the Upgrades module or Lister pagination anymore.

@Kiwi Chris - does that JS error remain when Tracy is disabled? Anything useful here: https://stackoverflow.com/questions/55979921/error-request-object-that-has-already-been-used ?

Thanks @Robin S - I tested with all panels activated before posting my last comment, so I don't think it's a panel issue, although of course there are a lot of extra panel settings, so maybe there is something turned on for @Kiwi Chris that I don't have on. @Kiwi Chris - can you try with the minimal set of panels to see if that helps?

Sorry @Kiwi Chris - I haven't experienced either of these issues on any of my sites. The upgrades module now requires clicking the refresh button to show available updates - an annoying change IMO, but Tracy doesn't affect anything here. As for the Lister Pro pagination, I have no idea what might be causing that. Can you please test on a different site and see if you can reproduce the problem and if not maybe see if there might be something else contributing?

Yes, you can set all of Tracy's settings as $config options. For exporting settings, use: https://processwire.com/modules/module-settings-import-export/ This post explains it all: https://processwire.com/talk/topic/5693-new-module-type-wiremail/?do=findComment&comment=172428

Thanks for your work on this @Pete One thing I noticed is pink on dark grey doesn't really work, eg: Otherwise, looks great!

I did my test with a multiple images field (max: 0) just like in your screenshot. It might be helpful if you could test on another template / repeater field setup with support for multiple images and see if you can narrow it down. If you've got a setup that doesn't work, I am sure others will come across this at some point as well.

Sorry @Rostik RODE - I am at a bit of a loss - still can't reproduce. Any chance you could share a login to the site so I can test? Are there any other modules / hooks that might be interfering with image naming? or anything else you can think of?

Thanks @Rostik RODE - I just tested those settings and can't reproduce the issue you are seeing. Any chance the title field for the page somehow isn't set when the image is uploaded? Usually this is unlikely because title is required and the first thing that is set when creating a new page, but that it really the only reason I can think of for the upload-tmp suffix being added - it's there so that the module knows that file needs to be renamed later, once that field value is available.

Did it work fully with older versions of the module? The problem is not actually repeater specific - the upload-tmp suffix is because the naming rule you defined relies on a field that isn't populated at the point when the image is uploaded. Obviously this happens in most situations with repeaters, but it will also happen with regular pages in that situation. Can you share your settings like PWAddict did?

Sorry if this is a silly / obvious thing, but please note that setting the page name for the admin to xyzzy doesn't also set the admin/superuser's name to xyzzy as well. Did you explicitly set it to xyzzy as well?

The reason is because ListerPro uses the saveField() when only field in the row is changed. If you edit two fields, then the rename will work because ListerPro then uses save() - you can see this starting on line 631 of the main ListerPro module file. It should be possible to make CUN work with this by adding a new hook to Pages::saveField. I have this working but I think I need to test more for other possible side effects. If you'd like to help test, you can place: $this->addHookBefore('Pages::saveField', $this, 'customRenameUploads'); after this line: https://github.com/adrianbj/CustomUploadNames/blob/67b1d42aef4c23be92684420f0d282c0c4a9a8d4/ProcessCustomUploadNames.module.php#L101 Let me know how it goes for you.

Thanks @PWaddict - that helped a lot. Should hopefully be fixed in the latest version.

@PWaddict - I have been trying to reproduce the issue with repeaters but can't so far. I have a feeling the duplicate image issue might not exist in 1.3.1 so I want to work on the repeater issue first and see if that fixes everything for you. Can you please provide all the repeater field settings, the image field settings, and the CUN settings. There must be some combination I am not trying.

Hi @videokid - sorry about that - it was some PHP 7 specific syntax in the newish ConvertFieldsToMultiLanguage action. Should be fixed in the latest version.

@digitex - I think this idea is really needed - can you add to PW requests GH repo please?

Hi @Falk - would you mind adding a note to that github issue (https://github.com/processwire/processwire-issues/issues/1335) so that Ryan knows it's not just me?

Was this just in a repeater scenario? I have been using the latest version extensively without any problems (and it solves lots of other issues), so I am assuming this is repeater specific? I'll try to take a look shortly. Sorry, I haven't had much time for module maintenance lately.