Custom Logging with Laravel and Monolog

Aug. 8, 2017, 12:34 p.m.

Laravel comes with Monolog which it uses to log application exceptions and such. The need arose recently to log other information to text files, specifically searches performed by users. I tried logging this to the database but the table grew very quickly and performance suffered as a result. 

So I decided to log to text files, which I can then process when reporting is needed. It would be relatively easy to use PHP file operations to open and append to a text file, but I decided to try to stick to using Monolog. Most of the information I was able to find online about how to do this involved overwriting Laravel's Logging Configuration classes to allow different types of data to be written to different log files, but it seemed like an awful lot of code to do something that should be relatively simple. After more searching I found a method that uses 4 lines of code and works perfectly:

$logPath = [path to log file]
$orderLog = new Logger('searches');
$orderLog->pushHandler(new StreamHandler($logPath), Logger::INFO);
$orderLog->info('Search : ', $data);

By including the date in the $logPath as part of the file name I can automatically rotate the logs and write to whatever location I choose to. The $data variable needs to be an array and is encoded to JSON and written to the log. The parameter passed into the new Logger() is the channel written to the log. 

The only thing I have not yet been able to customize is the Priority - in this case "Info." For my purposes this isn't really necessary and could be ommitted, but having it doesn't have any downsides so I don't know if it's worth the trouble of figuring out how to remove it. 


Labels: coding , laravel

No comments

PHP Traits

June 27, 2017, 9:21 a.m.

Over the last few weeks I have become enamored of using traits in PHP. Whereas I previously would put functions that need to be reused into either my Models or into helper functions, I have now started to make traits with these functions in them. For my Laravel application I created a directory app/Http/Traits where I keep my traits.

I started doing this when I began to optimize my code, trying to remove redundant code and remove unneccesary weight from my models. Using PHPStorm's very useful ability to find duplicated code I searched for blocks of 10 lines or more that were reused and moved those into traits. As I continued to do this I started to realize other benefits of using traits - mainly that it provides a way to simplify things. If the same action is taken in different controller or different parts of the application by using a Trait if I decide to change it I only have to change the code in one place rather than tracking down every place in the code that needs to be changed.


Labels: coding , laravel , php2

No comments

Updating Laravel Mail Config at Runtime

June 1, 2017, 9:34 a.m.

For the project I am working on we want to have multiple SMTP configurations in the database, which can be chosen at runtime. It's very easy to update the mail config using the config() helper, but for some reason that did not change the SMTP settings used to actually send the mail. I did a lot of research and found some answers for older versions of Laravel that did not work with 5.4.

Eventually I was able to find how to accomplish this from this post on It seems that the mailer instance is created with the app, so updating the config won't change the properties of it which have already been set. To do that you need to use the following code:


$transport = \Swift_SmtpTransport::newInstance($host, $port);
// set encryption
if (isset($encryption)) $transport->setEncryption($encryption);
// set username and password
if (isset($username))

// set new swift mailer
Mail::setSwiftMailer(new \Swift_Mailer($transport));
// set from name and address
if (is_array($from) && isset($from['address']))
    Mail::alwaysFrom($from['address'], $from['name']);

If you execute this after you have updated the config it will create a new instance of swift_mailer with the update mail config. Once that is done you can just send the mails and it will use the proper SMTP server.

Labels: coding , laravel

No comments

Googlebot wreaking havoc

May 30, 2017, 8:51 a.m.

This morning I wake up to emails saying that our Mailgun account has been disabled due to high volumes of email and high volumes of bounces. The logs indicate that way more emails have been sent than we had visitors. Emails are only sent as the result of a user clicking a link on the site, so I have no idea how this is possible.

After a few hours of investigation, it turns out Googlebot was crawling our site and kept following links and buttons that send emails. To prevent this from happening again I took a couple different precautions:

  • Added rel="nofollow" to the links and buttons in question.
  • Changed any link that generates an email from a GET to a POST
  • Added meta robots tags to the pages in question with "nofollow"

Hopefully that will prevent this sort of thing from happening again.

Labels: coding

No comments