During application development sending test emails can usually be a pain, even when using a modern frmaework like the excellent Laravel 4. During development it is very desirable to debug emails without actually sending them.There are a few options I’ve come across:
- Use Laravel 4’s Mail pretend feature. Simply set the configuration key “pretend” to true in app/config/mail.php. Laravel will now not send emails, instead write the content of each email to the application log
- Manually change the “to” email to your own so emails are delivered to your favourite email client – again, messy if sending lots of emails and if you ever made a mistake
- Print out the email data directly to the screen, but don’t send the actual email – the worst solution in my opinion
Options 2 and 3 are particularly fraught with issues. For instance, assume the application was to send out 1000 member renewal reminders and during development the route that sends out the emails was hit. Very soon, we’d have some very real (and confused, annoyed etc.) customers contacting you – disaster!
Continue reading Mailcatcher & Laravel 4 – Sending Development Emails
SSH, or Secure Shell is something any web developer will have come across. Personally, every single website I deploy involves SSH where I’ll upload and extract a single compressed archive. This is simply good practice and most importantly, much faster than normal FTP. There are a plethora of further benefits in having SSH access – I won’t go into these here though. However, as common a feature as SSH access is, gaining SSH Access on a Heart Internet hosting account surprisingly, turns out to be pretty darn hard to get.
Continue reading SSH Access & Heart Internet, oh my …
Sometimes, you have small experiences that really make you appreciate your chosen web host. They leave you glad you spent the time doing your homework, testing out their support, features and generally ensuring everything is easy as possible with them. If it isn’t easy, then your job will be made all that much harder, unnecessarily.
I experienced such a feeling last week with a client who wanted to use their own web hosting. I had updated a small website to include a blog and gallery, both updateable by the client. This wouldn’t usually be an issue at all if using my own hosting – simply upload the files, add in my custom htaccess file for some mod rewriting goodness and away we go.
However, the host in question was 1and1.co.uk. Now, I’ve read some absolute horror stories about this company in the past – all such experiences seem very typical of a very large company, with their support teams based offshore.
So, back onto uploading the updated site in question. I had expressed initial concerns about the clients current 1and1 hosting package, noting that they’d most likely need to upgrade with 1and1, even though they were on an intermediate hosting package entitled the “1and1 Standard package”. I had also personally been forced to use their support about a year ago, which was hard work to say the least. Moving forward, I carried on and uploaded the site to 1and1’s servers and then visited site. Instant internal server error 500. Straight away I knew this was the hosting as I had previously given the client a link to a staging area on my preferred web host, that worked flawlessly. I’m aware 1and1 have some restrictive hosting on their basic packages (which seems to be inherant of such a large company, with thousands of customers in my experience), so I immediately headed towards to the .htaccess file (it’s essentially a variation of the HTML5 Bolierplate template with some of my own magic included, nothing out of the ordinary though) and renamed the htaccess file. Whallah – the site loaded, thus isolating the issue straight away. Great, I can inform 1and1 and find out what htaccess directives are allowed, it should be a run of the mill support request for any support department.
Continue reading Appreciating Your Chosen Web Host
After spending a whole 2 hours of my life trying to get Apache mod-rewrite rules working with XAMPP on a local computer, I thought I’d share my results as I seemingly tried everything. The problem, I have a simple mod-rewrite rule in my htaccess file. When I upload this to my online web host everything is fine – the working htaccess file for my online host:
RewriteRule amnesia/resetpass(.*) recover-password.php$1 [PT]
So typing in
www.domain.com/amnesia/resetpass does a simple re-write to
www.domain.com/recover-password.php, without the user ever knowing. All is fine. However, when I treid to get this seemingly simple rule to work with XAMPP I ran into problems, getting 404 and 500 responses from the server – obviously quite a pain as this essentially means I can’t test the site using my own web server (E.g. localhost). The site hosted from my computer via the normal setup E.g. xampp/htdocs/mysite. I’ll jump straight to the solution and then explain exactly what things were changed – the working htaccess file is below:
RewriteRule amnesia/resetpass(.*) recover-password.php$1 [PT]
Firstly, the extra line that uses the
+FollowSymLinks directive was added. To explain this I’ll quote straught from the Apache documentation:
To enable the rewriting engine for per-directory configuration files, you need to set “
RewriteEngine On” in these files and “
Options FollowSymLinks” must be enabled. If your administrator has disabled override of
FollowSymLinks for a user’s directory, then you cannot use the rewriting engine. This restriction is needed for security reasons.
The re-write base has been changed to the relative path of the website directory. To finish up, open the http.conf file (the default settings for XAMPP, that get overwritten with you .htaccess file rules on a directory basis), located by default at C:\xampp\apache\conf\http.conf. Find all occurances of
AllowOverride None and change it to
AllowOverride All. After restarting XAMPP everythign should work. In a nutshell changing the AllowOverride directive in the http.conf file decalres which directives in .htaccess files can override directives from httpd.conf, this is discussed in more dept over here, but basically by having this directive set to None, you’re stopping individual htaccess files from working locally.