Macrura

@adrian, in order for dynamic domain to work, all of the domains have to be registered/validated in Mailgun. So for most uses the dynamic domain is not necessary. It shouldn't have been checked by default, if it was, i'll have to figure out how to make it not so. This would only be useful for sites where you have identities that are sending from multiple domains; So for example if someone had a few forms, and one of the forms needed to have the sender email be a different domain than was entered in the form settings. If you are in fact sending from a verified domain, and the mails are not being sent, can you check the mailgun log to see what the error code is? Also, i should point out what happens if you don't use the dynamic domains, the emails will still go through, but will all be logged under the domain entered in the settings. The dynmaic domain just allows that config property, which is used for the CURL, to be changed on a per-message basis, setting the value of the api domain to the sender's domain (extracted from their email address). This files the messages under the correct domain logs in the Mailgun interface. If it is not working, one possibility is that the code to extract the domain is not 100% working for all email address formats.

It should totally work, but i think you need to rename your assets, remove the Pro and then it will work, also remove the PPLP from the Activate for process.

i incorporated those elements, so those are in the module now; Should be tested by someone though, eu region on the forked version. https://github.com/outflux3/WireMailMailgun/blob/master/WireMailMailgunConfig.php#L18-L27 https://github.com/outflux3/WireMailMailgun/blob/master/WireMailMailgun.module#L197-L205

After further testing, it turned out that the dynamic domain is in fact necessary as i had requested it to be made to the original module author in 6/2016 (https://github.com/plauclair/WireMailMailgun/issues/7#issuecomment-228608931) The reason is that the messages won't be filed into the correct Mailgun logs unless the CURL domain is set correctly, therefore if you ever want to send from multiple domains from an PW site, the current version of this module won't work when you are not able to override that (such as messages sent by FormBuilder). I guess that maybe it could be achieved with a hook, but that would be too technical for most users; and people may be using this module and wondering why their messages are going in the wrong logs, or the from email is randomly being changed to postmaster@domain.com (happens when there is a mismatch between the sender domain and the CURL domain). New version supports the option now...

@mel47 right, there are some shortcomings to the module; it is sort of a construction kit module, and those lines were put in and sometimes i do comment those on some sites, i was too lazy to setup permissions or config settings for that stuff; This module probably needs some work, bit i may not be able to get to it for some weeks or months. In the meantime, I tried to come up with a better system for managing documentation that could be usable on a much larger scale, and it is somewhat backwards compatible with this one, in the sense that the ProcessDocumentation gives you a lot more options; It doesn't do the accordion view; but it does have granular permissions for the help docs, and supports PDF export for any document, which is very helpful in the case that there is long documentation and the user wants to read it offline.

Wow, yeah i didn't know $mail was a global variable... I updated the readme a bit; i think a lot if people might be overriding the global mail, because using the examples on this; So we should show both versions; they both seem to work the same. I commented out the public send();

I also re-read this thread and found out why i had to do the custom method to get the sender domain; However, the module does have the ability to change the sending domain on the fly, but it was not working at all when i posted the comment below; this could take some testing to figure out if the added method is necessary, or will be fixed once the send method observes all of the overrides. Just tested and it is working now, and i'm able to override the sending domain upon instantiation of the mail, therefore the mods i posted above are not necessary; The new version I forked on GH only has the 1 change, which is the commenting out of the send alias. ----- this is the fork: https://github.com/outflux3/WireMailMailgun and i guess once all of the changes are made and it is tested, we could try and see about getting this one switched on the modules directory. For @adrian's dilemma, i think the easiest thing would be to have a setting in the module config that when clicked causes the module to not include the public send() method; so the config value is checked and then we include that method from an external file, unless there is a better way. So anyone upgrading would keep the same functionality as before, but can elect to check the box to "remove the public send() " or something like that.

Sure, i don't see any reason I couldn't maintain the module; I think it is basically stable and we'd just need to all contribute our changes, test it and then it should be good to go... I'll try and get that setup soon..

I also have made some simple customizations to this module that I feel are worth putting into the official version, and for at least 1 site that run this on, these changes are critical for the module to work. If anyone were to take it over, I could submit a pull request, or describe the change/requirement and let the maintainer implement in their interpretation of best practice. for one, you might notice that this module's config provides a field for the 'Domain Name'. However, in my case, the 'from' email may use different domains. My Mailgun account has many domains configured. So instead of the $options array item called CURLOPT_URL using the module's entered domain name, i need it to use the domain from the $mail instance's from/sender. To this end i created a method getDomainName() as follows: private function getDomainName() { return substr(strrchr($this->mail['from'], "@"), 1); } then replace the CURLOPT_URL with CURLOPT_URL => "{$this->apiUrl}" . $this->getDomainName() . "/messages", I guess for this module to be flexible enough going forward, there may need to be an additional setting, where you either enter a domain name in the module config, or you tell the module to 'auto' populate the domain name from the sender domain.

I'm attempting to upgrade a site from 2.7.x to 3x, and one of the modules that i'm upgrading also is Tracy. One major issue that anyone doing this upgrade will encounter is the legacy setting for coreBranch – if that is set on your initial install, then it will be stuck in 'stable' and cause require_once failed to open stream errors on tracy-stable/src.tracy.php; the 2 ways to fix this are to either first just completely uninstall Tracy before upgrading, or to manually change that value in the database.

just read the core, it doesn't take that long and you learn a LOT

I usually use Settings Factory, it handles most situations and lets you have links in your admin menu to the settings. Most sites I build have a centralized Media Library, so i never need to deal with images in settings, e.g. if i needed to have a logo or some other image for a setting, i would make it a page reference to the media library.

that's great to hear – you may be one of the only sites on the internet using the Cassette UI..

yah, i havn't been able to get the reels to work, it's something about the reel mask and the canvas that isn't translating... could take some serious js troubleshooting to fix that..

ok that's a bug, you can either uncheck the default skin in the module config, or upgrade to the latest version (110), which fixes that. Also note that the newest version would be injecting the JS var into the header so you wouldn't need to hardcode that; also you shouldn't need any extra css, as the module should just work with this version...

you'd need to do this in your options: [smplayer tag=cryplant type=cassette cassette=ma-r90]

for some reason the 2nd one has the wrong class name, it looks like the classname is added 2x - this is what your api version classname looks like: ma-r90ma-r90 but it should only be ma-r90

well you're probably not doing delayed output, so that code won't output anything; you'd need to echo if you are doing direct output, like echo $sm2->player($track, $options);

right - as i pointed out, the error is because the $sm2 variable is not the instance of the module. player() on null means that $sm2 is null. You said this in your init $sm2 = $modules->get('TextformatterSoundmanager'); You either lost the variable between your init and the template, or you are in a different namespace; whatever the case, you can easily solve it by just re-referencing the module right before the code; just repeat that code before the other code; none of the other items you mentioned would affect anything, field name,

the api access to the cassette ui is working for me; you just need to make sure you supply the options, because there is no way to default to the cassette for the player, because it only supports 1 audio file per page..

it means for example if you were linking from a page to a form and what that page reference, you'd echo the url like <a href="<?=$pages->get(9999)->url?>?pageref=<?=$page->id?>">Register Now</a>

not sure, it sounds like $sm2 is not the module instance; you'd need to use Tracy Debugger to bd($sm2) at that point and see if it is actually the module; I will test your code also to see if i can troubleshoot that issue; are you passing any options to the player, or are you setting the default player as the cassette, in the module config?

you have some rules messing up the player; make sure the player CSS is loaded after your site css; The controls shouldn't appear until you hover over the cassette. Problem 1) #content p, #content ul, #content ol, #content table { margin: 1em 0 1.5em 0; } Problem 2) #content ul li { margin: 0 0 0 3em; display: list-item; list-style: none; } problem 3) #content a { color: #f00076; } once those are solved you should have it looking like this: for the other issue, you should check to make sure that the variable $sound is not getting overwritten somewhere; for safety you should probably call it $sm2 instead of sound;

i don't see the CSS file - cassette-tape-ui.css in your header; if you have Tracy, can you try debugging what is inside $config->styles? on my local machine it all works; alternately you can hardcode the reference to the css file on that page, like this: <link rel="stylesheet" href="/site/modules/TextformatterSoundmanager/soundmanager2/cassette-tape/css/cassette-tape-ui.css">

so are you doing this? ) In order for the module to output the necessary styles and scripts, you need to echo the $config->styles and $config->scripts arrays into your site's header/footer. Here is an example: // In Header foreach($config->styles as $style) echo "<link rel='stylesheet' type='text/css' href='{$style}' />\n"; // In Footer foreach($config->scripts as $script) echo "<script type='text/javascript' src='{$script}'></script>\n"; I don't see the cassette css file anywhere on the page; the styles for any given player need to be either hardcoded style link references on the page, or you have to use $config scripts & styles in order for each/any of the players CSS and JS files to load;