Pierre-Luc

Just made a v0.4 release and a new support thread over at https://processwire.com/talk/topic/12667-wiremail-mailgun/. I would really appreciate someone testing this on 3.0 and report how it's working, I don't have much time to test this out right now.

v0.4 release Small update with improvements on the addAttachment() method and an added validateEmail() method, using Mailgun's email validation service. https://github.com/plauclair/WireMailMailgun/releases/tag/0.4

Support thread for WireMail Mailgun. For bug reports, please use the bug tracker on GitHub. https://github.com/plauclair/WireMailMailgun

For those interested, I've released a new prerelease and dropped the PHP 5.5.0 requirement. I've also added a few features and will be creating a forum thread soon.

This might not be of any help but is it any different if you run the Vagrant box off VMWare ? I have a Win box right now at the office and it's a pain. I just end up carrying my MacBook Pro most of the time!

According to his screenshot both requests are XHR (XMLHttpRequest), so it should be seeing them as such. I assume you're doing your call with jQuery? Do you have any proxy between the browser and the server like CloudFlare that might interfere with it?

They look pretty good too and that announcement is really interesting from a business perspective. Sparkpost was among a few others I was investigating, but felt like the sudden change in pricing could as well be reversed and 100K free forever felt a bit too good to be true. The thing that really annoyed me from Mandrill was the fact that they pulled the rug beneath our feet in a really painful way, and that commitment from Sparkpost is very welcome. I will probably also implement their API, based on the code from the Mailgun module. It's slightly more complex but not by a big margin. Choice is good. Sending through the API is so much faster, SMTP just kills servers on large volumes!

For those interested in the Mailgun module, just letting you know it's ready to use. I'd appreciate you guys giving me a hand in testing things, let me know if you encounter weird encoding errors (it's been tested with Litmus and should be ok but you never know) or anything else. The only thing that you should know is that there is a requirement for PHP >5.5 only if you use the attachment functionality, as the cURL functions I'm using for files (CURLFiles class vs @) requires it, though that will be fixed in a newer version by the end of the week. Please file reports on the repo tracker, not on the forums, it's going to be much easier tracking things this way.

Next time you get this error, do "service mysql status" on the server terminal and see that it says.

It's highly dependent on the server, if you're unsure, check with your sysadmin. On some systems, the user:group settings will also have big impact, on some not so much. Also in site/config.php, make sure your default permissions are correct, once you find the right settings. If your images are too big for the amount of memory you have available, the resize might die through the process.

It will unless the permissions are broken and it's not reading/writing correctly.

MySQL "gone away" often happens when you hit your memory cap (ram and swap combined), mysql will crash, that can happen when you are being crawled which appears to be the case. Do you have caching enabled on your pages? 1200s queries are not normal, I would make sure all your files permissions are ok first then investigate further. It seems to me like you are resizing/rendering a lot of stuff on the fly and maxing out your cpu allowance.

And now have a 0.2 that implements everything from the basic wireMail() plus a few goodies.

Sneak peek : https://github.com/plauclair/WireMailMailgun I've started implementing Mailgun. It's mostly working except for some stuff. Look at the tags for 0.1 prerelease.

I'm kinda worried on this one, it feels like a bad move. This will be hell to move the dozens of client accounts I have on this..

Raising this from the dead, but setLanguageValue() and getLanguageValue() are pretty useful for those kind of things. From code/Page.php * Methods added by LanguageSupport.module (not installed by default) * ------------------------------------------------------------------ * @method Page setLanguageValue($language, $fieldName, $value) Set value for field in language (requires LanguageSupport module). $language may be ID, language name or Language object. * @method Page getLanguageValue($language, $fieldName) Get value for field in language (requires LanguageSupport module). $language may be ID, language name or Language object. *

It sure can be, look at philo/laravel-blade (30K downs) or duncan3dc/blade (26K downs). But there are (quite a few) requirements to run those packages though, and if you're ok dealing with external dependencies that might go without a head dev anytime, suit yourself. Not that I think Laravel is going to die anytime soon, but those projects — not so sure. I've been burned enough times on forks to have learned that lesson. I'd rather stick with twig/twig (14.6M downs) which has literally no dependencies, though personally I'm more of a "PHP's already a good at templating and I don't want to learn yet another template engine syntax" kind of guy, though I see how they are nice to use in their "native" environment, where their value seems higher to me. /r

This is my experience as well. A lightweight JS call to an external file was the best solution in most of these cases.

There are a few "standalone" packages on Packagist.org but they all have a few Illuminate components requirements, which themselves have a few too. Looks like Blade is only really intended to be called from within Laravel itself..

Quick question horst, haven't had time to play with it yet but what are/will be storage options? SQLite is nice but from a distributed standpoint isn't it a bit limited ? Wouldn't MySQL be a better option? (Don't know if you support it yet, on my phone right now so limited ability to look at it)

Try updating your CKE to latest if PW isn't there already. It's as simple as downloading the full package and replacing what's in /core/

My pleasure. If you find typos or unclear translations, please file a bug report. That's the best way to help.

Right, all the magic getters do have a (negligible imo) impact on performance but it's to be expected in a CMS.. there's always a cost to flexibility and convenience. Can't say I've really ever had performance problems with PW itself though. I'd be interested to see a comparison between the same calls between PHP7 and 5.6 though.

Sorry for raising this from the dead, but I've recently used it and it's absolutely marvelous. It will stay put on production servers unless you call it explicitly through the browser plugin, and it will profile anything you throw at it, PW, WP, frameworks, etc. Compared to xdebug, it's litterally miles ahead in my opinion. This is a must have.