Jump to content

New module type: WireMail


ryan

Recommended Posts

9 hours ago, Ivan Gretsky said:

One more offtop question here, @adrian. Is it possible to set Tracy mail interceptor option programmatically as part of environment config?

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?

 

  • Like 2
Link to comment
Share on other sites

1 hour ago, adrian said:

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. 

What about this: The config setting should not override the fronten selection, but should make the named ones stay visible (unhideable). ? Or is it that what you allready have in mind? Thinking that someone enables per frontend a panel, that is not within the config setting.

  • Like 1
Link to comment
Share on other sites

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:

image.thumb.png.d0c1c961bd6e22c535795bc02495c283.png

  • Like 2
Link to comment
Share on other sites

4 minutes ago, horst said:

What about this: The config setting should not override the fronten selection, but should make the named ones stay visible (unhideable). ? Or is it that what you allready have in mind? Thinking that someone enables per frontend a panel, that is not within the config setting.

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?

  • Like 1
Link to comment
Share on other sites

7 minutes ago, adrian said:

Do you think this is ok, or do you think we need an option to prevent overriding of certain panels

This is how I understood @Ivan Gretsky but I may be wrong. Regardless of this, it depends on how many devs work on one site. If I'm the only one, I mostly know what I'm doing. ?

  • Like 2
  • Haha 1
Link to comment
Share on other sites

48 minutes ago, horst said:

This is how I understood @Ivan Gretsky but I may be wrong. Regardless of this, it depends on how many devs work on one site. If I'm the only one, I mostly know what I'm doing. ?

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.

  • Like 4
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...