adrian

Hi @ryan - it's been a great year for the PW core - thanks for all your hard work as always and very glad to hear that pro module sales are doing so well for you! In addition to the requests repo that @Robin S mentioned, there is also of course the https://processwire.com/talk/forum/5-wishlist-roadmap/ thread. I actually think it would be best to start with the issues repo and once those are all fixed, then move onto those two requests lists. Lots of user input has gone into those lists and I'd hate to see that effort ignored or pushed aside in favor of new suggestions. I have lots of new suggestions / ideas, but I think they should wait so your efforts can focus on outstanding issues first - does that make sense?

Brilliant - thank you!

Hi @teppo - Happy New Year. I wonder what you think about removing the "by " prefix from the username. I have a lot of users on one particular site and I often want to find a user by making use of the browser's autoselection when you start typing when a select field is focused. It still works as is, but it means I need to type: "by ajones" instead of just "ajones". Thanks for considering. Actually, on a related note, it would be nice to be able to limit the shown users to certain roles, or at least those that have admin page-edit permissions.

@ryan - looks like the presence of a support button is not dependent on there actually being a thread for a module, eg: https://processwire.com/modules/login-register/

Sorry I guess I am not understanding what you want to do. That module triggers module upgrades in one step and you could certainly call that code from anywhere.

This should help you get going: https://gist.github.com/joyrexus/7307312 Things like prevAll() will need to be done with a loop. Googling things like "prevAll in vanillajs" will provide you with examples.

@Sascha Nos - not sure your overall goal here, but take a look at: https://processwire.com/talk/topic/8410-module-toolkit/ which adds a batch upgrade button to Ryan's PW Upgrade module. Maybe you don't want to use it that way, but perhaps you can extract the code you need. Let me know if you need any help deciphering it - it's a bit of a mess ?

Sorry @ryan - I think maybe I wasn't clear - the "list position" I was referring to, is the position of the combo field in the ordered list of fields within the template settings. Once you have separately configured the position of all combo subfields, it doesn't matter where you put the combo field in the template field list. It's not a big problem - just an observation. Thanks again for making this possible!

Thanks @Robin S and @ryan - this makes Combo an entirely new beast - so much more powerful and flexible - thank you both for your persistence and openness to making this work. I do agree with Robin that the way the ordering is configured is not ideal - it could be very time consuming for example if you have a combo field with lots of subfields and you need to insert in images field right in the middle. I do agree with Robin though that it's definitely confusing looking at the order of fields in the template settings now, especially in the scenario where you have custom placed all of the combo's subfields. You have this combo field in the list is a position that really has no relevance anymore. BTW, I really like the fact that if you use the new Custom Form Placement option for every subfield, it completely removes the label/fieldset container of the combo field which I think is often a key part to giving this the flexibility it needs to be useful in a wider variety of use cases.

Hi @Dennis Spohr - thanks for testing all that. Would you mind posting a issue on Github so that @ryan can track this. Please include a link to this thread.

Perhaps it's worth trying the new: $pages->parents()->rebuildAll(); https://github.com/processwire/processwire/blob/d3b1ab2983108a0410f7c66997f0478e7f3e02e6/wire/core/PagesParents.php#L580 Obviously a DB backup before doing this is essential, or do it on a dev copy of the site.

What version of PW are you running? In 3.0.156 there were a bunch of changes related to page parents: I am wondering if these changes might help, or if you are already running this (or later version), if it was faster before?

I guess my thought is that there would be an option to automatically select/add them all to the template, but then because they would be listed as separate "fields" in the orderable ASM select, you could intersperse them with other fields as needed. I also don't think it would necessarily be a bad thing to be able to exclude some subfields on some templates, but I don't think this is particularly high on my wishlist.

Is it only slow when changing the parent to trash, or slow in general? Instead of that approach to trashing pages, have you tried: $page->trash(); https://processwire.com/api/ref/page/trash/

@Robin S - what about being able to select a subfields like you can with Lister Pro for Page Reference fields etc. Do you think this sort of interface would work to allow for interspersing image etc fields in between Combo subfields effectively? I realize there are some technical issue for Ryan to overcome, but I think this interface might work to allow the arrangement flexibility as we are envisioning.

@ryan - After logging in, you end up at: https://processwire.com/modules/login/login but on this page, the module search input is missing so you need to navigate to: https://processwire.com/modules to be able to access it. I think this is a bug. Thanks.

This will count the number of published pages (not under Admin or Trash). Is this what you need? $pages->count('has_parent!=2,has_parent!=7,status!=unpublished');

Thanks Ryan, My worry about the stated goal of Profields is the desire to reduce the number of required fields - I am not saying that Combo doesn't do an excellent job of this - clearly it does. My concern is why we want to reduce the number of fields - for me, the only reason really is performance. I don't mind giving up simplicity of managing fields for the added flexibility, which is why I don't personally like Textareas. That doesn't mean I don't think Combo isn't awesome - it clearly is - it's just a matter of being careful about when / why you decide to use it. I am really just wanting this discussion to help us all think through the tradeoffs of our decisions now we have this extra tool. I think the key take away that I am getting is that Combo is something to consider when: 1) Fields always belong together in the editor 2) You will always (or almost always) use them all together when rendering on the frontend 3) You are certain you won't ever want to include non-supported subfields (like images) 4) The Combo field contains enough subfields that the performance (DB query) is significantly greater than going with separate fields I am sure that the Combo field can provide more performance - I haven't ever actually questioned that - the key thing for me though is making sure I don't choose it in an effort to have more performance, only to find out that later on there are new requirements that mean that I have to move everything to separate fields - I can already see the need for a new action for AdminActions for automatically separating a Combo field into separate fields and moving all the data to those new fields. Regarding talking about Textareas and Combo together - I think that's because in a couple of key ways they are very similar: 1) They only appear as one field in the system 2) They only use one DB table 3) They are lumped together in the page editor as what looks like a fieldset 4) They are the two main Profields that are designed to reduce the number of fields in the system I understand that otherwise they are very different. Anyway, I do hope this conversation has helped everyone a little and not come across as critical in any way - sorry if I am too brash sometimes - it comes with my Aussie heritage I guess ?

Sorry Ryan if any of our comments came across as criticism of Combo - I do think it has the potential to be very useful and I completely understand why the subfields can't actually be visually separated. What worries me I guess is the stated goal of Profields: "ProFields are an powerful group of ProcessWire field types (with custom inputs) that enable you to manage more data with fewer fields. This saves you time, reduces overhead, and makes development more efficient and even more fun." I guess I am wondering why I'd actually want to have fewer fields (how much less overhead is there actually) - in reality I don't re-use fields that often because of the issues of not having a self-documenting name when calling a field via the API. Yes, title, body, images, etc are fine, but after that it ends up seeming contrived to have a name that is both generic enough and yet semantic enough to not be confusing. Obviously text_1, text_2 is not very useful, but anything more specific is sometimes just as confusing if you are going to re-use for different purposes. Yes, it's a balancing act and I don't have any complaints - I make a decision one way or the other and move on. But, we have these Profields (just talking about Textareas and Combo) to do something that perhaps isn't that beneficial in very many cases. In your address example - how much of a performance advantage will it actually have? What if I also need first_name and last_name fields outside of the address combo field - now I start wondering whether I want a combo address field that includes these, or I want an address field that is just location info, with the first/last name fields separate, or do I just go with all separate fields for ultimate flexibility. We are spoiled for choices in PW, but sometimes I just wonder if too many choices can lead to confusion. Honestly, if there was no performance advantage to the Combo field approach, I wouldn't ever consider using it because of the reduced flexibility - I don't have any logistical issues with managing lots of regular PW fields - it's very easy and extremely flexible. Again, I know we are all very appreciative of all the options you have made available - it's incredible really, just perhaps a little overwhelming trying to balance flexibility with the unknown performance advantages / disadvantages. Finally, I think I mentioned this when you first announced Combo - an example of when I would use it is where I have used a Table field, but restricted it to one row - in this case, I wanted easy SQL querying of scientific metadata that was several fields per page. It will be brilliant for this use cases like this and can't wait to use it for these sorts of things, but I am going to resist the urge to use it for any "normal content" fields. Thanks again for all your hard work.

I just wanted to add some more thoughts to @Robin S and @Pete's comments. Flexibility is the key thing here. Imagine setting everything up for a template using a combo field, only to discover you need an image (or other unsupported fieldtype) in the middle of the combo's subfields. This is particularly important once the site has content - all of a sudden it becomes a nightmare to fix. This is one of the reasons I haven't ever used the Textareas Profield and I can see being just as wary about using the combo field for the same reason - you just never know how requirements will change over time. Being able to quickly tweak the content types and layouts in templates is why PW is so awesome in the first place.

Huge thumbs up from me too @Robin S

Hi @jploch - not sure why, but as you can see, /TracyDebugger/tracy-2.8.x/src/Tracy/Bar/assets/loader.phtml has this code: strpos(false, '?') but the line in that file (https://github.com/adrianbj/TracyDebugger/blob/637e9cf6b9e3d37037fa282d65e34940fc539e97/tracy-2.8.x/src/Tracy/Bar/assets/loader.phtml#L17) is: $baseUrl .= strpos($baseUrl, '?') === false ? '?' : '&'; Would please mind taking a look and seeing what exactly you have there. If $baseUrl is false, perhaps there is an issue with the $baseUrl = $_SERVER['REQUEST_URI'] ?? ''; line above returning false, instead of an empty string. What is your local dev setup and versions of things? I don't really understand why updating to the latest version of Tracy would change anything, because that bit of code has been like that for a while.

Yes of course - sorry, I forgot you added that already. My natural instinct these days is go to the Breadcrumbs first in most cases which is why it's always so weird when they're not available - going to be great having these available for templates, fields, and some of these others in the future. Thanks again!

Thanks @Robin S - fantastic as always. I wonder if I can ask a little favour and have it support languages as well? And while you're at it, is there any reason not to also support Setup > Logs and have you thought about Access > Users / Roles / Permissions? I think these would also be useful if you can't see any downsides.

They'll be copied to the page's assets/files/xxxx folder. It will be up to you to manually remove them from your temp folder.