adrian

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.

Ok, I think I understand your scenario now - you are trying to batch add pages on a remote server but the images are in a local path on your computer? If that's correct, then this won't work - you'll need to move the images to the server and adjust the paths but that should be a pretty simple search / replace in your text editor. For example, search for /Users/xxuser/Desktop/201124_Website/binary/ and replace with something like /var/www/site/assets/tempimages/ (or wherever you decide to FTP them to).

Hi @sww, I just checked with an image at a local path and it worked fine, but I think the issue might be the "file://" at the beginning. Does it work if you remove that?

The other thing you can do is check for a Tracey Bluescreen exception html file in /site/assets/logs/tracy/ - hopefully that exception would have been logged there and it will show the full stack trace.

@LAPS - the other thing to try is to enable PW debug mode (if it's not already). I have a feeling that with Tracy disabled and debug enabled, you'll probably see that error again. I don't know where the error is coming from, but I don't think it's Tracy - Tracy is likely just reporting it whereas otherwise it's going hidden and therefore not affecting the download.

What about the strict mode option?

Ok, sorry - I missed that. If you are running php 7.2+ it might be worth updating to the latest version of Tracy, although I don't really expect it will help. I am running out of ideas here, but perhaps you could try putting Tracy into strict mode to see if it provides a full stack trace of the error.

Ok, so what version are you using?

Change 2.8.x to 2.7.x

@LAPS - the error originates here: https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/core/WireHooks.php#L520 I just checked out that other post - I don't think it's an issue with Tracy, but I'd appreciate it if you could try disabling all panels in the panel selector and see it that makes a difference. If it does, can you narrow things down to a particular panel for me? I'm also curious if it might be related to the latest Tracy core update. Could you try forcing 2.7.x by modifying this line: https://github.com/adrianbj/TracyDebugger/blob/94047302d6ffe3e933ee7d8eaf9514c192f2c50d/TracyDebugger.module.php#L333 so that it loads 2.7.x - be sure to hard reload the browser to flush the cache. Let me know if either of those help.

Ok, I get it now, but it is pretty confusingly worded - either that, or I am just a bit slow ? Anyway, it's easy enough to add, but do you think the icon should be displayed for all users, or just superusers? Also, which icon - the issue is that the key and lock icons are already used in the page tree for other indicators. The other question I have is whether to use the ProcessPageListRender::getPageLabel hook and add the icon as a "PageListStatusIcon" like the lock, exclamation icons are added by the core (at the end of the title in grey), or using the Page::getIcon hook which adds to the front of the page title and the icon is pink. I think the "PageListStatusIcon" option is more correct and looks nicer, but it means that it will be broken on sites that use that ProcessPageListRender::getPageLabel hook to modify the page titles - something I do on a few sites. Of course the other option would be if this wasn't included as part of the module, but rather those who want it can add it themselves with one of those hooks like this: $this->wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $p = $event->arguments[0]; if($p->protected) { $event->return = $p->title . "<i class='PageListStatusIcon fa fa-fw fa-key'></i>"; } }); OR $this->wire()->addHookAfter('Page::getIcon', function(HookEvent $event) { $page = $event->object; if($page->protected) { $event->return = 'key'; } });

Well it sounds like that is a useful thing for it to alert you to ? - if you take a look at the RepeaterMatrixPage.php file, you'll see that the render() method isn't hookable. Perhaps You are probably looking for InputfieldRepeaterMatrix::render

Hi @SwimToWin - I am not seeing any issues with the page tree not showing, but maybe I am not understanding the scenario correctly. Any chance you could post screenshots showing the settings you have and the issue where the page tree isn't visible?