For the past few months, I have worked on and off providing some basic maintenance on a site built using Laravel’s PHP Framework. Up until this week, I didn’t have to get too deep into the functionality of the site and most changes were CSS related or other design fixes. However, this week I had to do some work with creating some addition views/routes/models, templating, and a few other tasks, so had to get my hands dirty and learn a bit about how it works and I think I like it.

This isn’t my first time working with Laravel products, I’ve developed two User Frosting sites and as a result have a decent amount of experience using Laravel’s Eloquent ORM, which I’ve found to work well and be comparable to other similar products, like Zend or WordPress’s Database implementation, although(at least in regards to Zend) much simplier to work with. It even integrates with Mssql with only a few minor issues.

Based on these two experiences, the ORM and PHP Framework, I have to say that I really like their products and could definitely see myself using it for new projects where I don’t need all the functionality of WordPress, but also don’t want to start from scratch on the build. Like userfrosting, I can see it as providing a pretty great starting point for a lot of smaller projects. Obviously, it is a bit on the technical side, so isn’t a drop-in replacement for WordPress for people looking to build their own site without much technical experience, but it really is pretty great to work with and isn’t overly complicated. I think when I have some free time, getting a basic template setup, so that I can use it starting point for new sites, would be a good use of time.


As I’m sure you are aware, the April 27th deadline to switch off of Mandrill(or upgrade to a paid Mailchimp + Mandrill account) is approaching quickly. I’ve been using Mandrill for projects for some time now and overall have really liked the service. Its Magento/Mailchmip integration is really cool and painless and for the most part, deliverability has been fairly good.

However, back in February, Mandrill pivoted and announced that they were redoing their system to require all Mandrill accounts to have a paid Mailchimp account going forward. They gave users a rather short notice to either start paying for a Mailchimp and Mandrill account or switch to a different service.

I completely understand needing to charge for a service and would of probably been fine paying a monthly fee to use Mandrill(especially for its Magento integration,) forcing all my clients that are using it into a paid mailchimp account, especially when many use other services like iContact/Constant Contact/etc, didn’t sit right with me.

The Mandrill Pivot

Prior to February, Mandrill was billed as an:

Email delivery API from MailChimp

Mandrill is a reliable, scalable, and secure delivery API for transactional emails from websites and applications. It’s ideal for sending data-driven transactional emails, including targeted e-commerce and personalized one-to-one messages.

And, this is how I used it…as a way of ensuring better email deliverability than you can get using a random hosts sendmail functionality. However, the pivot resulted in the following new description:

Transactional Email for MailChimp

Mandrill is a transactional email API for MailChimp users. It’s reliable, powerful, and ideal for sending data-driven emails, including targeted e-commerce and personalized one-to-one messages.

So, as Mandrill was moving away from their initial use-case, I decided to also move away from it. Of all the people who I have using Mandrill, only one decided to stay with it and we may revisit that this week given how well Mailgun seems to work. In this case, the client actually used Mailchimp w/paid account already, so it wasn’t a big jump to also pay for Mandrill.

Transitioning to Mailgun

I suppose as a glutton for pain, I moved to yet another third-party service, this time choosing Mailgun, which was acquired by Rackspace several years ago. My reasoning for not wanting to roll my own transactional service, use the server’s sendmail tool, or just use SMTP on one of my email servers is mainly due to deliverability and, to a lesser extent, tracking/logging of clicks, opens, messages, etc. Of course, this could backfire if/when Rackspace decides to shut this down, but hopefully they will just eliminate the free version and convert it’s user’s to paid if that happens…not do a complete pivot like Mailchimp.

Overall, the transition has been painless and I actually like the web interface a lot more than Mandrill. It has a sane way to search the logs, SMTP responses and error codes are reported in a better and easier to understand fashion, and setup was easier. It feels like a much more mature web-interface.

Similarly, the PHP api was very easy to get working and I switched out all my Mandrill send mail functions to use Mailgun in no time at all. If anything, it is a bit simpler than Mandrill’s api. A couple of my sites were also using a WordPress SMTP plugin to send wordpress emails and switching those over to Mailgun’s SMTP offering was also painless.

First impressions of the service, website, and api are that it is a much better product than Mandrill. I’ll reiterate my hope that if it ever gets to the point that offering it as a free service doesn’t work out, Mailgun does a sane pivot to paid accounts, I would happily pay at this time.

Mailgun vs Mandrill Deliverability

I have not had any issues yet, although don’t have that much data. I will revisit this post in the coming months once I have been using it for longer and have more data to play with.

I imagine it can not be any worse than Mandrill, which sometimes silently failed, reported mails as sent that were not, and didn’t always properly report SMTP codes.


If you use an Adblocker, like Ublock or Adblock, and have tried to visit Newegg’s website this weekend, you might not of had much luck. In fact, you might not be able to use their website at all, resulting in more of a Cyber Monday Fail rather than the intended Cyber Monday Sale.

As it stands, visiting redirects you to a static email landing page with a bunch of buttons enticing you to save money and check out their Cyber Monday Deals. Unfortunately, clicking those buttons just open a new window that redirects you back to the landing page, effectively breaking their website.

I discovered the issue when I was looking to buy a motherboard for a client, which according to another site, they had the best deal on right now. When I couldn’t get past the landing page, I hopped on twitter to see if anyone else was unable to get on NewEgg’s website and got a bit of an LOL.

This issue has kept NewEgg’s Twitter employee(s) quite busy today, as they have been tweeting and responding to tweets all day telling people to disable adblock, clear their cookies, use Internet Explorer, and that their web team is working to fix the issue. Some twitter users are also reporting issues in the Android app and on mobile devices, along with still being unable to access the site correctly after clearing cookies and disabling their adblock.

So, this probably hasn’t been a great day for Newegg and I would imagine this probably had a not-insignificant impact on their Cyber Monday sales. Any site that caters to tech users most likely has a higher than average number of users who use an advertisement blocker. So, if your website is completely broken for ad block users, you will probably have a bad time.

I think it also provides a nice lesson for web-developers too…make sure your website still works when someone blocks your tracking pixel :)

Update 12/01/2015 – Newegg’s website is working again. The rather tiny(268 member) subreddit /r/newegg blew up yesterday due to the issue as well. According to a several posters, there where other issues with their website, mainly shopping cart issues, that prevented people from buying things even after disabling adblock.

See below for some of the Twitter Carnage:


With the start of IE9, browser testing got a whole lot easier. While it still has some annoying warts and limitations, it is way better than IE8 was and doesn’t even compare to the nightmare that was IE6 and before. Now with IE11+, Microsoft has stepped up their game and is more in-line with browsers like Firefox and Webkit Browsers(Chrome/Safari/Etc.)

Back a few years ago, dropping support for IE 8 gained steam, despite the fact that for people still using XP, IE8 was the latest version of Internet Explorer you could get. Google may have been the forerunner on this, as they dropped IE8 support in 2012 for their Apps, but other companies/devs were already limiting support by then as well. Since then, both due to dwindling numbers and better alternatives, many new devs don’t even test it anymore and the web simply don’t work well for those running it.

Apparently, Microsoft Devs don’t either.

While preforming a clean install of Windows 7, I decided to checkout a few pages in it and came across the Windows 10 page. The below screenshots are from the new Windows 10 Upgrade Page and as you can see, it wasn’t cross browser tested in IE8.


After turning on Compatibility Mode, I got the below. It actually worked better, although I got a script error that slowed the browser to a crawl.

IE 8 After Turning on Compatability Mode

Just to be on the safe side, I fired up my IE8 XP Virtual Machine, which has all the XP Internet Explorer Updates, as to be fair the windows 7 machine hadn’t had any updates yet. As you can see, it looks similar, just with certificate errors.

ie 8 xp

So, it seems that Microsoft doesn’t care too much about cross browser testing in Internet Explorer 8 anymore, which I suppose is good as it is another nail in the coffin. Of course, I can’t help but think that given they are the ones that spawned this demon on us, the least they could do is continue putting some man hours towards it.

Personally, while I don’t spend time making sure everything looks identical in IE8, I do at least check it and typically make the page largely readable. Does it matter? Probably not, as if you are still running Internet Explorer 8, the web is probably a horribly broken place, but basic IE8 support is something I include in most cases.

Recently, an old client contacted me because emails were not being sent from their Godaddy hosted wordpress site. A quick look at the folders in their webroot made it clear that the site had been hacked and most likely the emails not working was a side-effect of godaddy noticing and blocking their email function.

After a bit of investigation, it looked like the most likely avenue was from the CherryFramework, which is a bootstrap wordpress theme/plugin framework. A bit more digging and I discovered a recently patched vulnerability in cherry-plugin/admin/import-export/upload.php

The entire contents of the vulnerable file is below:

	if(strtolower($_SERVER['REQUEST_METHOD']) != 'post'){
		exit_status('Error! Wrong HTTP method!');
		$upload_dir = isset($_REQUEST['upload_dir']) ? $_REQUEST['upload_dir'] : $upload_dir ;
		$file_name =basename($_FILES['file']['name']);
		$upload_file = $upload_dir.$file_name;
		$result = move_uploaded_file($_FILES['file']['tmp_name'], $upload_file);

As you can see from the above, which is the first version uploaded to git, the ONLY checking this file does is whether or not you are sending it some files to upload and telling it where to send it. So, it conveniently lets you upload any file to any directory on the webserver. Similarly, their download-content.php file also let you download arbitrary files from the webserver, with 0 checks in place to prevent abuse. You can see a screenshot of the github repository here.

This was fixed in later versions of CherryFramework and shows that the developer better understands wordpress now, as they not only implement a nonce and checks the logged in user’s capabilities by calling current_user_can, but also adds the code to an ajax action rather than just a malware installer like it was before.

Without casting too many stones, as no-one is perfect least of all me, I just can’t understand how something like this could get written, if not intentionally(which is entirely possible.)

Everyone makes mistakes and it is easy to miss something that can be abused…mistakes happen, get fixed, and we move on. But, something like that or SQL queries written with 0 thought to injection blow my mind.

After cleaning up a recent WordPress hack, I believe there is another Revolution Slider vulnerability making the rounds. If you are using an old version of Revoltion slider, you should update immediately or disable the plugin.

From what I can tell, it affects two Themepunch plugins, Revslider and Showbiz Pro. According to a proof-of-concept exploit posted this month, versions 3.0.95 and before of Revslider, as well as versions 1.7.1 and before of Showbiz Pro are vulnerable.

The issue allows for unauthenticated ajax calls sent /wp-admin/admin-ajax.php to trigger Revolution Slider’s onAjaxAction function, which in turn can be used to delete slides, import/export slides, and update the plugin(among other tasks.) In the case of the site I cleaned up, they used it to trigger an update to the plugin, which uploaded a remote shell to the site.

From looking around, this vulnerability appears to have been posted relatively recently on several sites and is currently being exploited.

The Vulnerability

This is part of revslider_admin.php. In affected versions, the below gets called, which adds wp_ajax and wp_ajax_nopriv callbacks for the onAjaxAction function.

Since there is no check on whether the user is actually logged in or allowed to make changes to the plugin, it is possible to(among other things) upload files to the server.


self::addActionAjax("ajax_action", "onAjaxAction");

This in turn calls the addActionAjax function, which creates the wp_ajax and wp_ajax_nopriv callbacks.


protected static function addActionAjax($ajaxAction,$eventFunction){
	self::addAction('wp_ajax_'.self::$dir_plugin."_".$ajaxAction, $eventFunction);
	self::addAction('wp_ajax_nopriv_'.self::$dir_plugin."_".$ajaxAction, $eventFunction);

As a result of this, the revslider_ajax_action action gets added, allowing for unprivileged updates. This is not terribly surprising as, at least in early versions of Revolution Slider, security and a deep understanding of wordpress do not seem to have been a concern.

Working Example

The following is a working example. On a vulnerable site, the following will print an ajax response similar to: {“success”:false,”message”:”wrong ajax action: asdf “}.

If you see something to the effect of {“success”:false,”message”:”Wrong request”}, you are probably not vulnerable, but should still verify you are running the most recent version, as there are several known vulnerabilities at this point!

<form method='post' action='/wp-admin/admin-ajax.php'>
<input type='hidden' name='data' value='asdf' />
<input type='hidden' name='client_action' value='asdf' />
<input type='hidden' name='action' value='revslider_ajax_action' />
<input type='submit' />

The reason you see this response is because the switch is called and since asdf is not a recognized action, it triggers the default: self::ajaxResponseError(“wrong ajax action: $action “);

Affected Versions

As stated above, this does not appear to impact newer versions 3.0.95 of revolution slider, as well as versions 1.7.1 and below of Showbiz Pro.

In a newer version I checked, Themepunch appears to have added a nonce called revslider_actions and check that the nonce is present in onAjaxAction prior to actually executing the ajax calls.

Temporary Fix

If you are using an old version of revolution slider, you should update immediately and/or disable the plugin.

As stated before, since this plugin is often included with themes and is a premium plugin, updating it presents several difficulties and is something that a non-tech website owner might not even know they need to do. I feel this leaves something to be desired.

The below should be a quick way to stop the attack.

**Note that the below will only allow people with the privilege to install plugins to work with Revslider’s Ajax calls. You may want to adjust what permission you allow.


public static function onAjaxAction(){

if(!function_exists('current_user_can') || !current_user_can('install_plugins')){

Given that there have been two very serious vulnerabilities reported in the past few months, I would strongly encourage you to upgrade the plugin to the latest version and/or use a different plugin!

While viewing Softlayer’s Website today, I noticed something rather amusing…they are using Amazon’s Cloudfront to deliver at least one script on their homepage.

Softlayer is a hosting company, which does a lot of dedicated hosting. However, especially since being acquired by IBM, they have been heavily promoting the cloud side of their business. So, it is sort of funny that they are using their biggest competitors service on the homepage of their website to serve up javascript, rather then their own Cloudlayer or other infrastructure.

Of course, you should use what works, works well, and is easy, which in many cases is an offering by Amazon AWS. However, if your goal is to ‘to Accelerate Adoption of Cloud Computing in the Enterprise,’ you should probably keep your hosting in-house as much as possible and not showcase the reliability and reach of your competitor.

As an aside, this reminds of a similar situation a few years ago when Dreamhost was having some major downtime. I noticed that the Dreamhost status blog was always up, despite probably getting crazy traffic from all of their customers, while their shared hosting hosting infrastructure was seeming to crumble. I checked and saw they were using Linode to power their status blog, still do. That ended up being a good recommendation, as I switched to Linode shortly after that and have been overall happy with them ;)