adrian

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:

Hi Ivan, Not currently, but it would be a very simple addition for Tracy to support $config->tracyFrontendPanels and $config->tracyBackendPanels arrays that if defined would override the selected panels from the module's config settings. Is this what you are looking for here?

Sorry, yes you're right about $user, but it doesn't work for the other examples I listed, eg:

One thing I would like to see is editUrl work properly for users, roles, permissions, templates, and fields. Currently the first 3 kind of work, but they take you to page/edit/?id= instead of /access/users/edit/?id= etc.

Some great examples here already and these are probably the best approach, but just another alternative (in case it's useful) is to use a Profields Table field - this way you can easily define a new string to translate as a new row in the table.

I think it should work everywhere. I just tested a bootstrapped page: <?php require './index.php'; $mail = \ProcessWire\wireMail(); $mail->to('test@gmail.com', 'Test User'); $mail->from = 'me@gmail.com'; $mail->subject('Test'); $mail->body('Blah blah'); $numSent = $mail->send(); and Tracy captured it just fine: The one key thing I would do is ensure that Mail Interceptor is enabled in the config settings, rather than via Sticky in the Panel Selector so that it can't be disabled accidentally. I would also check the "Force Guest users into Development mode on localhost" option so that even if you're not logged in, Tracy will be active and intercepting an emails. Also, for your own peace of mind, I would suggest checking everything with your email address as the only TO/CC/BCC until you are convinced that Tracy is working as expected. I find it invaluable when testing all sorts of emails.

Thanks - now I understand all the rationale here. My approach is to simply permanently turn on the Mail Interceptor panel in Tracy - it logs calls to send emails rather than sending them. And when you want to test send to yourself instead of the actual recipients, it can handle that as well. Just another option if you think it would be ok in your workflow.

I don't think I know this version. Would you mind linking to it please.

Perhaps you can just grab a copy of leaflet.js and serve it up locally. Then you can edit it to replace those http calls with https

That replacement needs to be inside the foreach. You probably also want to replace with " " instead of ""

Thanks @Soma - so far that looks to be working as expected.

Looks like there are lots of other issues along the same lines. So far I have also come across trying to set the "twitter_params" option. It is not sticking because this line: $params = $this->get($item . "_params"); needs to be: $params = $this->options[$item . "_params"]; but there are lots of other instances like this as well that I think need changing. Thanks again.

Hey @Soma - I just noticed a bug with overriding options. This is my $options array: $options = array( "theme" => "templates/social_themes/ms2s", "outer_wrapper_tag" => "span", "item_wrapper_tag" => "span style='float:left' ", "text" => $page->share_email_text, "char_limit" => 9999 ); However, the char_limit isn't being respected. The problem is these lines: https://github.com/somatonic/MarkupSocialShareButtons/blob/7b25cf4098a23ab79ea423082ecd200bc7a06590/MarkupSocialShareButtons.module#L381 https://github.com/somatonic/MarkupSocialShareButtons/blob/7b25cf4098a23ab79ea423082ecd200bc7a06590/MarkupSocialShareButtons.module#L402 $this->char_limit and $this->char_limit_sypnosis need to be $this->options['char_limit'] and $this->options['char_limit_synopsis'] respectively. Thanks!

Totally OT, but is there any reason this module loads 0.7.3 of leaflet when they are up to 1.3.4?

I don't use this module so maybe not the best person to respond, but it looks like it should load the https version. It was changed to this in this commit: https://github.com/madebymats/FieldtypeLeafletMapMarker/commit/eb0c1e703a0b3eb5bc6c00aaee44eb59a6d22dfe#diff-b979b991c53396a5160add7bfa0c8dcb

No guarantees, but from what I can tell about those changes, I don't think it should affect this module. If you find anything though please let me know and I'll attempt to fix it ASAP.

I don't know - you tell me ? I just took a very quick look and the basic functionality seems ok. Could you point me to what you are having issues with?

I have refactored a few things this morning. 1) On the module config settings page, if you have the Only display for EU visitors setting checked, the check for their status happens on every page load (session is ignored). This does not affect the frontend - users here will still only be checked once per session. 2) There is a new "Clear Local Storage" option to reset stored banner settings so that it's easier to test changes to the banner.

Ok, to help make it easy for you guys to test the vanilla JS version that @tpr put together, I have included a new toggle. It defaults to the jQuery one for now so you can upgrade to this new version without breaking anything. Everything appears to work fine, but I would like the folks that use the module together with Google Tag Manager to test that everything is firing as expected. Once I have some confirmation I will remove the jQuery version and this setting and also ask @tpr for a PR so he gets the Github credit for this. Thanks for helping to test.

Just had a small world experience. I have been emailing with Ueli at https://www.whatwedo.ch/ who are the folks who operate the https://ip.nf/ IP to country API service. He just mentioned that they are partners with https://novu.ch/ (built with PW) and that they use ProcessWire a lot. So anyway, he is keen to support this module and to make sure their service will be able to keep up with any requests made by it to their service ?

Just committed a significant upgrade. The IP to country lookup now has three services it can use - all of which support IPV6. You can specify the order and remove some if you like. They will be used in order and in case one fails, it will move onto the next one. You can now specify an IP address in the config settings to test. Note that saving the module config settings will remove the "FromEU" session variable so the result will be fresh each time. Also, because all of these three services can automatically detect the user's IP address, I am no longer supplying it via the API call (unless you are using the test option), which means that tests from your localhost dev environment will actually work properly. I have also included Tracy bd() calls that return more information. Obviously this will only show if you have Tracy installed, but it tells you which service was used, the results from it, and then the call to the other service to check if the country is in the EU, as well as the result of this test: true/false.