adrian

@wbmnfktr - I am not sure about that fix. When I add that and I click the Do not consent, the banner keeps appearing on page reload. Does that not happen for you?

Thanks for narrowing it down to that option. It looks like it doesn't work in combination with the Allow Users to Manage option. If you uncheck that one, then the AutoAccept seems to work fine. It would be great if you could confirm that at your end, but I think I will make it so it's not possible to select both of these - it will be one or the other.

@Robin S - good call on the change of hook - thanks.

Maybe a typo, but you are missing the period in the $selector .= so that you are concatenating the check_access onto the selector.

Start by removing the $selector check stuff so that it just appends the , check_access=0 bit and once it's working build back up to protect other instances of Pages::find

I put this in my ready.php file: // hack to overcome this: https://github.com/processwire/processwire-issues/issues/550 $this->addHookBefore('Pages::find', function(HookEvent $event) { $selector = $event->arguments(0); if(is_string($selector) && strpos($selector, 'template=user') !== false && strpos($selector, 'name|first_name|last_name%=') !== false) { $selector .= ', check_access=0'; } $event->arguments(0, $selector); }); You'll need to adjust to suit the needs of your selector, but this is how I got around it and make it work for non-superusers. Sorry I forgot about this above. Definitely worth a read through that github issue as well: https://github.com/processwire/processwire-issues/issues/550

Not sure if this helps, but this works for me:

Hey @Macrura - just wanted to let you know that I just started using this module and it's very handy. I don't have enough pages to bother with creating an import script, so copy paste is the way to go and this has made things much quicker. Thanks!

Sorry guys, in a rush but perhaps including "check_access=0" in the selector for the page field will do the trick here. I might be totally off track and it might be a bug, but worth a shot.

Thanks for the feedback @cstevensjr - glad to hear it has served you well, although I must point out that Pete was the one who did all the initial work with this module - I just picked up the torch and added a bunch of new features. I'll wait to hear back from @tires about how he is storing tags and we'll go from there.

I think I would actually go hooking into field rendering rather than page so that you can target this to just RTE textarea fields, or whatever you are using to store this iframe stuff in the first place. Actually, on that note, I think I would go with a textformatter module to handle the iframe rather than allowing it to be entered into an RTE (assuming that is what you are actually doing - maybe you're not?).

Yes of course - sorry it didn't occur to me to mention this - it's a good reminder for everyone who may read this in the future though. Here's a screenshot to show it in action. 1) Make sure the Network tab is open before you start the image upload 2) Clear the existing entries to make the image upload script easier to find 3) Upload image 4) Select the image upload script 5) Check the Response tab - sometimes the error will be here, but if not, proceed to step 6 6) If nothing there, go to the Console tab and click on the VM: link from the error. 7) Notice that "test" is being output before the json response

Glad you found it, but now I want to know why all of a sudden you are getting the response back. Did you do something different to get this to show up. or are you getting it some other way?

Have you tried Tracy in Strict mode? You can toggle it on from the Panel Selector. Also, just to confirm that you have the "Disable Cache" option checked in the dev toolbar?

Just use Tracy's Module Disabler panel - easy to do them all at once and then re-enable. But to clarify, is there any content in the "Response" section?

Probably safer with paths() so you get the full disk path paths()->templates

Best of luck with this Kongondo. I haven't yet had a need for Padloper, but I am excited to see it has a healthy future because I am sure it will be useful for me at some point down the road.

Sorry I am a little confused - by the same error, do you mean the "unexpected token", or do you mean the same content in the Response? Unexpected token errors typically mean that html is being returned instead of JSON, so you just need to figure out what HTML is in the response and find the source of it. In the example I linked to it was because the session had expired and PW was returning the login prompt, but HTML in the reponse could be from many other issues as well.

Have you looked at browser dev tools Network Tab - Response section? Does this help:

@ryan Another thought - I quite like using @wumbo's FieldtypeAssistedURL (https://processwire.com/talk/topic/10530-module-fieldtypeassistedurl/) - or more accurately, my fork of it: https://github.com/adrianbj/processwire-fieldtype-assisted-url/commits/master which adds support for storing local pages as ID, not URL. I would hate to have to choose between your new URL field as this one. I wonder if you'd consider adding the functionality of the assisted url field to your new one?

This should be doable, but I guess the problem may be how the tags field stores these. Are you using page reference field for tags, or a select options field, or some other approach? In implementing this I'd want to make sure it worked in as many scenarios as possible. Although I am not really sure if this module gets much use at all - it seems pretty quiet around here and personally I have never had a use for it (even though I helped extend it quite a bit since Pete's initial development).

@Ivan Gretsky - I have implemented everything I think you will need. I have posted about it over here: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=172482 so let's continue the discussion there - thanks!

More enhancements to help support @Ivan Gretsky's needs. These settings (via config.php/config-dev.php or the module config settings): $config->tracy = array( 'enabled' => true, 'guestForceDevelopmentLocal' => true, 'frontendPanels' => array('mailInterceptor','processwireInfo','requestInfo','processwireLogs','tracyLogs','debugMode','console','panelSelector'), 'backendPanels' => array('mailInterceptor','processwireInfo','requestInfo','processwireLogs','tracyLogs','debugMode','console','panelSelector'), 'nonToggleablePanels' => array('mailInterceptor', 'tracyToggler'), 'panelSelectorTracyTogglerButton' => false ); results in the following: 1) Tracy is enabled 2) Tracy is in development mode (ie debug bar on) even when logged out on localhost / dev machine 3) Mail Interceptor is enabled and can't be toggled off (notice that the checkbox is greyed out) 4) Tracy Toggler panel is disabled and can't be toggled off (notice that the checkbox is greyed out) 5) Tracy Disable/Enable (toggler) button in the Panel Selector is removed

@Ivan Gretsky - any thoughts on my last message? Is this something that would be helpful for you or are you going to take a different approach?

I think the only way to send different content from the email to different fields is using the delimiters options. Have you tried to achieve what you want with that? Or am I missing the point? I don't think I really understand the "hash" idea you are talking about.