bernhard

Im on mobile so I can't do a mock-up but I vote for a text based solution like matjazp mentioned and I would put the tabs above the dump. Just like the tabs in processpageedit. They would be code for the mouse and would not mess up alignments on the left or right. I don't want any automatic additional info. As Adrian said the need is always different and the solution is just one extra dump away. Please save your time Adrian thanks for all your great work! Still waiting for a donation button

That was my suggestion: But I guess that's more effort than just implementing a new method dumpVerbose() with different settings. Let's wait for adrian to wake up - good morning btw

I don't care about how we call it, but I care about what it shows and dumping/debugging/infoing a page object that is then labelled as array is simply not what I understand as good/correct dumping/debugging/infoing. PS: actually I even do care a little about how we call it dump() is already some kind of standard. we have dump() and bardump() and it's called exactly like this in the nette docs. It's a better alternative for var_dump() and well... that also "dumps" variables. We already have firelog() and log() so I see no need for introducing another one (for me d() and dv() would be a similar thing and mean about the same just with different options. dump() and dumpVerbose() => tracy bar, log() => file, firelog() => dev console).

At first glance I liked the array-approach, but thinking about it a little bit more I think it is not a good idea to modify the type of the originally dumped object. It should really output the correct type. Also @szabesz suggestion would be a wrong output for my understanding. Having one d() call output two dumps on the other hand can also be misleading. IMHO the best solution (and I guess also the simplest one) would be to have d() output the debuginfo version and dv() = dumpVerbose() output the verbose info with debugInfo = off. I don't think that a config setting is necessary or any better. I think it's even more confusing and one more thing to keep in your mind. Another setup and you might end up in another output. Not the best option. d() and dv() would just be one thing to remember across all setups and it would produce a consistent output always and everywhere. EDIT: Another option I could think of would be something like this, having a toggle in the label section showing/hiding one or the other but outputting only one visible object for one single dump and also showing correct variable types: The label, eg d($page, 'my custom label'); could also be shown right beside the toggles

yep, one theme is absolutely fine for me. looks great already!

I've also had such an issue several times but no time so far to check out the reason

If you only need a simple map you can still integrate it as simple iframe (example https://www.hrdiamonds.com/kontakt/ ) Openstreetmap has been a very good and reliable solution for several years. Sometimes their data is even better than google's. It's also a great project for collaboration in case of desasters where everybody can help to digitalize the current situation. There are also lots of different tile providers based on openstreetmap data having customized renderings, like https://www.opencyclemap.org/ Leaflet on the other hand is a very good JavaScript library to DISPLAY this data. Another one is OpenLayers (really powerful but not so light-weight). Lots of options Didn't know about here.com, thx @zoeck

Little offtopic and self-promotion here, but you should definitely give RockGrid a try. It's such a great way to list all kinds of content, style it properly, add additional functionality. In the example below you get instant filtering, properly formatted currencies, referenced pages and some hover-action-icons that open that page in a panel or open the PDF invoice directly. The pagetree is great for websites, but it's definitely not for other more complex content management applications So true (y)

Added support for joining multiple finders. You can even join finders on columns of previously joined finders In this example I'm joining projects (finder1) and their related clients (single page reference field of project) and then I join the referral contact of the project's client based on the "camefrom" id of finder2:

not sure how that should look like exactly but it sounds good to me

Thank you. Actually I came up with a somewhat different idea. I had to debug something yesterday and needed ['debugInfo' => false] several times. In fact I need it that often that I can even remember it by heart My Idea: What if we had a bdv() method instead of bdb, meaning barDumpVerbose() that has a limit of 9999 AND debuginfo set to false?

thanks - already using it and i like it!

why not learn from existing solution? https://modules.processwire.com/modules/inputfield-urlchecker/

found another strange behaviour while testing my new RandomPageName module: The string should actually have a length of 4 (not 5), the "minDigits" setting of 2 would also be true for "8y4k" so the final "x" is unnecessary (wrong) imho...

glad you find it useful. please use caution until this issue is solved (maybe you find some time to help me debugging/testing?):