adrian

Thanks ? It's a decent start, but I am kinda hoping for some contributions from the community for improving it. It's all available in the docs folder (markdown files) in the repo and anyone can edit and submit PRs. I think a nice Tips & Tricks section would be beneficial, as would improvements to the rest of the docs.

TracyDebugger's Console Panel - https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console

That should work just fine:

PHP is not properly running on the server. If it's a fully managed server I suggest to submit a ticket to get them to fix it. It could be that the apache handler for php files is not configured, but there could be other issues as well.

I know lots of us enjoy using them and I think it would be a worthwhile addition to Migrator. I bet it would be much quicker to extend Migrator than to look for other options ? Maybe at some point in the future I'll find some time to look at adding it. It supports all the other ProFields, so it makes sense to include it as well.

You can also just use: $this->wire('page') $this->wire('mail') etc inside the hook function.

HI @Karinne Cyphers - glad you narrowed it down to the Repeater Matrix field. The Migrator module was built before that fieldtype existed and I haven't had time to add support for it. It already works for standard repeater fields though, so it might not be a huge amount of work to implement Repeater Matrix, but unfortunately I don't really have the time at the moment. If you have the time / skills, perhaps you could take a look and provide a PR?

Yes - as an example: drwxr-xr-x 9 ajones staff 288 Aug 6 09:36 wire Since you playing around this panel and given your experience the Diagnostics module, I wonder if you have any thought about the Status and Notes that are being returned? Also, have you looked at the Filesystem Files option?

Hi Steve - thanks for finding and debugging this! Testing here on MacOS and it doesn't make any difference for me. Both versions return: but if your version works for you, then it makes sense to replace it. I have changed locally and I'll commit with the next version sometime soon.

Hi @Karinne Cyphers - it's hard to debug that error because I don't know where it is originating from. If you could install TracyDebugger you should get a full stack trace of the error so you can point me to the line in the Migrator module that is the origin of this. I expect it is a fieldtype I haven't tested with, but won't know for sure until you can track this down for me.

Yeah, without a template.php file ProcessWire doesn't know how you want the admin template rendered - what fields do you want to output where and in what structure and with what CSS. Remember that PW doesn't output anything on the frontend by default - which is why it's so flexible rather than fighting against the system.

Hey - sorry about the delay on this. I have looked at your PR and it looks like a useful addition. I am just wondering though - what about if we rather not use the array approach like you have there. I don't really have a preference, although I think moving forward, I'll probably go with this approach: https://github.com/adrianbj/CookieManagementBanner/blob/master/CookieManagementBanner.config.php but at the moment, most of my modules work like this: $f = $this->wire('modules')->get("InputfieldCheckbox"); $f->attr('name', 'enabled'); $f->label = __('Enable Tracy Debugger', __FILE__); $f->description = __('Uncheck to completely disable all Tracy Debugger features.', __FILE__); $f->columnWidth = 50; $f->attr('checked', $data['enabled'] == '1' ? 'checked' : '' ); $fieldset->add($f); Do you think we need a config setting to determine which style is output?

I think the most likely situation is that you haven't created any template files to match the templates of the imported pages. If you are importing a WP blog, then you need something like blogs.php and blog.php in your /site/templates/ folder. You can create these manually yourself, or you could use the blog module http://modules.processwire.com/modules/process-blog/ depending on your needs.

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.