adrian

@pwfans - I always disable BCE for pages that have too many children for the edit mode to handle. I don't really think the edit mode makes much sense with that many pages anyway so I don't think pagination will help. If you need to batch edit that many child pages you probably need to write a script via the API (Tracy Console panel or AdminActions perhaps?) to make the changes.

There is also https://processwire.com/store/pro-dev-tools/user-activity/ so given that, I don't see anything like it ending up in the core.

@ryan - what about a dedicated "Skins" section - maybe within the modules directory. Perhaps the requirement for adding a skin to the directory would be to link to a Github repo with the admin.less and also an admin.png file which could be used on the skin's page in the directory. Ideally I think it would be nice if it was possible to view all skin screenshots via a gallery of thumbnails to make it easy to browse visually.

@Tom - I think the field=title within the quotes selector, vs having the list of fields in a separate quoted group is optional either way. The "array_values" is needed because the text tags needs the array to be indexed numerically starting at zero, rather than the page IDs which findRaw() returns.

@Pete - I'd like to second this - is it an easy fix to show the full message in the email? Thanks!

@fruid - I'll admit the database vs in-memory can be somewhat confusing in PW in terms of what selectors are support for one but not the other. This definitely needs improvement and better documentation, but I don't think that is really relevant in this case. Once you assign an array of pages to a variable and then do a find on that, you are using an in-memory selector - you're not querying the database anymore. This means if you are loading so many results that you need to paginate, then you're losing some of the benefits of pagination. This is not PW specific or even PHP specific. Regarding the two subsections - are you grouping results into these subsections? It's hard for me to advise on that without having an example of exactly what you are trying to do.

I can confirm that @matjazp's example works. The thing is though that this still means that you are loading all pages into memory and then paginating. This doesn't seem like a good idea in general - is there a reason you can't limit the find() to the results you want and just use my example which only loads the required pages for each page/view - much more efficient and scalable. What is the actual set of pages you are trying to query? Have you tried to build a selector that can get what you want with one find operation?

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?