adrian

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.

I would have multiple uses for this type of URL field for sure! At the moment I use @teppo's unreleased ProcessLinkChecker, which is awesome. I think the key thing would be that in addition to returning an empty value I think it also needs a way to log and also report (maybe via email or other options) broken links so that we don't need to monitor its findings.

I see your point for sure. I guess I thought it was more about ensuring the default panels on the local install vs a live one. If you're migrating a database between the two, Tracy settings could get mixed up easily, but by using the config.php file you can more easily keep track of these. You could even use PW's built-in config-dev.php file to ensure that locally the mailInterceptor is loaded, but not on the live server. I think if we need to prevent some panels from being adjusted via the debug bar's Panel Selector, then this needs to be a new config setting where you can select all the panels that you want excluded from the Panel Selector interface. This list of panels could of course be set in the config settings, or it could also be done via: $config->tracy = array( 'nonToggleablePanels' => array('mailInterceptor') ) What do you think about this option - this would make it very difficult to accidentally remove the Mail Interceptor panel. I think perhaps it would also be worth adding a few extra settings to config-dev.php so it looks like this: $config->tracy = array( 'enabled' => true, 'guestForceDevelopmentLocal' => true, 'frontendPanels' => array ("mailInterceptor","processwireInfo","requestInfo","processwireLogs","tracyLogs","methodsInfo","debugMode","console","panelSelector"), 'nonToggleablePanels' => array("mailInterceptor", "tracyToggler") ); This setup would ensure that Tracy is always enabled, the Mail Interceptor panel is on and can't be toggled off, and the Tracy Toggler panel/button can't be enabled. The only remaining way to disable Tracy would be via the Disable Tracy button on the Panel Selector, but I would add an option to remove this as well. @Ivan Gretsky - is this the sort of functionality you would need to feel comfortable with this approach? The other consideration in all this is the load order of modules by PW. The hook that intercepts emails from being sent is in Tracy's init() method, but I suppose if you have another module sends an email in init(), rather than ready(), then it's possible it could be sent before Tracy intercepts it, but that like a highly unlikely situation.

The most recent version includes @Robin S's suggestion for "Expand/Collapse All" functionality. Both Robin and @tpr have helped significantly with testing of this feature - thank you both. Also new in this version is the ability to override any module config settings using: $config->tracy = array() You can read more about this and why it was introduced here:

Hi @horst - sorry was just posting when this came through. The changes I just committed allow overriding of the module's config settings. They don't prevent changes from being made via the panel selector so I guess you could potentially uncheck the Mail Interceptor panel and do a once/sticky but I think that should be the expected behavior. Do you think this is ok, or do you think we need an option to prevent overriding of certain panels?

Ok, I have added the ability for Tracy to respect any settings added to the $config->tracy array, eg: $config->tracy = array( 'guestForceDevelopmentLocal' => true, 'frontendPanels' => array("mailInterceptor","processwireInfo","requestInfo","processwireLogs","tracyLogs","methodsInfo","debugMode","console","panelSelector","tracyToggler") ); This ensures that Tracy is always loaded and the mailInterceptor panel is always loaded on the frontend. You may also want to include it in a backendPanels array as well if that is an issue with your setup. To get settings for $config->tracy, I would recommend installing: http://modules.processwire.com/modules/module-settings-import-export/ so you can grab them like this: