adrian

Would anyone be interested in having an option to make bd() and d() calls output two versions - one with debugInfo on and one with it off? I am finding that I often want both because sometimes the debugInfo version is useless, but then sometimes it contains really useful info not available without it, eg @horst's new image info: https://github.com/processwire/processwire/pull/117 Any thoughts on this?

Just to follow up on this - if you still feel like converting it to pure JS, I'd been keen to maintain that new version. I don't have the need or motivation to do it right now, but I can imagine that I may want it in the not too distant future. It doesn't sound like the Drupal version will end up being converted, but at this point in the development of the module, I think that's ok. If it receives any new killer features I'd be happy to port them over myself. Let me know if you're still on board. Thanks!

Sure thing - just added to the latest version. I know you know this already, but just a reminder for others that you can also do: d($page, [6]); to control the exact depth of the array/object being dumped.

Can you please post some screenshots of your config so we can check things?

Thank you - I have committed that change and updated the module's directory.

@wbmnfktr and @iank - would you please try reverting to the version currently on Github and then replace that line with: var method = $.fn.jquery.replace(/\.(\d)/g,".0$1").replace(/\.0(\d{2})/g,".$1") > "1.6" ? 'prop' : 'attr'; and let me know if that works as expected. Thanks!

As you know (because you have been kindly testing it via PM), the new version now has an extra Submit button just below the customPHP code field to make it easier to quickly save and test multiple iterations of the code.

Looking at that check, it's pretty clear that it ignores the main version of jQuery, eg 1, 2 or 3 and just looks for the point version being greater than .6 so it's pretty useless really.

What jQuery version are you guys running? I have been testing with 2.1.1

"method" is being defined at the top of that file: // older versions of jQuery need to use the `attr` method to modify node properties, newer versions use `prop` var method = parseInt(jQuery.fn.jquery.split('.')[1], 10) > 6 ? 'prop' : 'attr'; It seems like jQuery 1.6 was where prop vs attr changed and that is what they are trying to deal with by using this, but maybe it's not working as expected?

Hi @iank - that's strange. It looks like this for me: There is some JS to uncheck the other checkbox here: https://github.com/adrianbj/CookieManagementBanner/blob/8a1cafe555221c9de03299d1ffdd9dafd8fe4d63/assets/js/CookieManagementBanner.js#L180-L183 I don't really know why the original Drupal version of this took this approach over simple radio buttons, but it seems to work as expected here. I think it's a jQuery version issue. In one of the recent commits, "on" was changed to "bind" to support older versions of jQuery. I wonder if that's the problem you are seeing? Could you try changing that "bind" to "on" and see if it works for you?

I am not sure there is much I can do about this - those triangles are how Markdown generates the output for <details><summary> tags. If you have any ideas on an alternate approach, let me know though. Regardless, I think the key things is that Ryan (and other PW Issues regulars) will get to know this output and how it works.

Ok, now the tables render correctly with Github's MD parser. Take a look and let me know if you have any suggestions.

Except I didn't check the output in Github - I was using another Markdown editor which was rendering the tables correctly, but Github isn't - working on fixing it now.

Agreed, that does look nice. I have committed a new version with the following changes. Now we just need to get people using it more regularly ? Each section is structured as a table and with the Server Details not collapsed. The plain text version is basically the same, just with section titles added for clarity. SERVER DETAILS ProcessWire: 3.0.108 PHP: 7.2.6 Webserver: Apache/2.4.33 (Unix) MySQL: 8.0.11 SERVER SETTINGS allow_url_fopen: 1 max_execution_time: 120 (changeable) max_input_nesting_level: 64 max_input_time: 60 max_input_vars: 1000 memory_limit: 128M post_max_size: 8M upload_max_filesize: 50M xdebug: xdebug.max_nesting_level: GD: bundled (2.1.0 compatible) GIF: 1 JPG: 1 PNG: 1 EXIF Support: 1 FreeType: 1 Imagick Extension: MODULE DETAILS AdminOnSteroids: 1.9.8 BatchChildEditor: 1.8.12 BreadcrumbDropdowns: 0.1.0 CookieManagementBanner: 0.2.1 FieldtypeStreetAddress: 0.5.1 FormBuilder: 0.3.4 InputfieldFormBuilderFile: 0.0.2 InputfieldStreetAddress: 0.5.1 JquerySelectize: 1.0.4 MarkupSEO: 0.8.7 MarkupSitemap: 0.4.1 ModuleReleaseNotes: 0.10.7 ModuleSettingsImportExport: 0.2.9 PageRenameOptions: 1.0.4 ProcessAdminActions: 0.6.12 ProcessChildrenCsvExport: 1.7.0 ProcessFormBuilder: 0.3.4 ProcessWireUpgrade: 0.0.7 ProcessWireUpgradeCheck: 0.0.7 RestrictTabView: 1.1.3 TextformatterTagParser: 2.2.0 TracyDebugger: 4.10.25

I think that makes most sense. Just like this or do you think that a table layout would help with clarity?

Check out the latest version - I think it works pretty nicely! Happy to implement, but not sure the best interface - are you thinking about maybe splitting the the button into two: 1) Copy Simple for Github 2) Copy Detailed for Github Or do you have other ideas?

Glad you found the "Version's List" functionality - pretty handy isn't it ? Let me know if you think of any other info that should be added to it. Sorry about the code saving bug - hope you didn't lose too much! It is fixed in the latest commit.

Hi Steve, Thanks for the suggestion. I have added it to the just released version. Please let me know if you have any issues with it. PS - I am curious what you are using this panel for - I haven't had much feedback on it thus far.

Apologies - you are indeed correct. I can't imagine why it would actually have been changed - not sure why you'd need uppercase chars in a field name, but the description of what is allowed certainly has changed. https://github.com/ryancramerdesign/ProcessWire/blob/a210ba0b5ea67e56fef8a27a620bcfa6f96ca0b8/wire/modules/Process/ProcessField/ProcessField.module#L949 https://github.com/processwire/processwire/blob/48fe0769a4eb3d0f5b4732fd01b4b4ed8262d952/wire/modules/Process/ProcessField/ProcessField.module#L1196

I think it has always said this: "Use only ASCII letters (a-z A-Z), numbers (0-9) or underscores." I think it's likely we've just always assumed lowercase only because names suggest lowercase vs labels/titles which is where you expect difference cases, spaces, special chars etc.

Thanks @Robin S for picking that up and figuring out what the problem was. I have committed a new version which fixes the issue (the same version you tested via PM).

Thanks - I went looking for that flowchart but couldn't manage to find it.

I don't know much about this, but what about doing it via JS instead of PHP so that it works more seamlessly with PW's approach which is to slugify in realtime with JS. It would also mean automatic integration with the PageRenameOptions module. Here is some stuff on doing this with JS: https://ourcodeworld.com/articles/read/255/creating-url-slugs-properly-in-javascript-including-transliteration-for-utf-8 On a side note - I guess this doesn't work for your needs, but don't forget that you can change the character replacements by editing the settings for the core InputfieldPageName module.

I should also add that you can also do: so $roles does contain all the roles, it just doesn't return an array that can be dumped by default, which is different to $templates and $fields - this seems like a bit of an API inconsistency to me. Also to note, you can do: