Hot answers tagged

7

Turn devMode on https://craftcms.com/support/dev-mode If you want the errors to log regardless of devMode or not, pass in true as the third parameter, e.g.: Craft::log("There was an error", LogLevel::Info, true); https://straightupcraft.com/articles/how-do-i-log-errors-warnings-and-info-in-my-plugins-to-a-craft-log-file


5

By default a full stack trace will only be assembled and logged if an exception is thrown (which is what you're looking at in your 2nd example) mainly for performance reasons - cycling through the backtrace and assembling all of that info is a relatively expensive operation. Standard calls to MyPlugin::log or Craft::log will get a partial backtrace added to ...


4

A few things to keep in mind. LogLevel::Infois only going to be logged when devMode is enabled, so any overhead from excessive logging won't be an issue in production. Excessive logging will consume extra memory because all logging information on a given request is stored in memory and flushed to disk at the end of the request, but overall I imaging that ...


4

Not currently, but I agree it's kind of annoying. I thought maybe you could pull it off with a plugin since Yii does have an onException event, but there wouldn't be a way to disable logging of 404's without some code changes on our end. I've added it to our 3.0 list to add a config setting to disable logging of 404's though.


4

Based on the official documentation the log files are under /storage/logs and look for the web.log file especially. If you don't find anything check your webserver logs.


3

As someone who theoretically might inherit your site one day... and also as future-you trying to diagnose a problem... please don't try to limit what Craft logs. If you want a quicker way to look for critical problems, check out the Yii2 Debug Toolbar as discussed here Profiling your Website with Craft CMS 3’s Debug Toolbar You can use it to very quickly and ...


3

So what I do is I just redirect anything requesting a WordPress-ish thing to WordPress.com (that's what they are looking for, after all...). You can see how to do that here if you're using Nginx: https://github.com/nystudio107/nginx-craft/blob/master/sites-available/somedomain.com.conf#L67


3

If you're doing it from a custom bootstrap script, you'd need to do something like this for plugin logging to work: $craft = require '../craft/app/bootstrap.php'; craft()->plugins->loadPlugins(); MyPlugin::log('My Message', LogLevel::Error); craft()->end();


2

You should be able to do that with something like this: Craft::getLogger()->flush();


2

Off the top of my head, I don't think it's going to be possible, at least in the context of outputting it from a Twig variable. That info comes from Yii's CProfileLogRoute class, which Craft extends at etc\logging\ProfileLogRoute. But with all of Yii's logging, that stuff doesn't get flushed to disk (for FileLogRoute) or to the browser's console (for ...


2

If you want a log item to appear regardless of whether devMode is enabled, you can pass true as the third argument to the log() method. Is this accurate? Yes. Logs will only get flushed to disk is a proper craft()->end() occurs, firing the onEndRequest event. So if you're doing something in your plugin like calling PHP's exit() directly or there is some ...


2

If you want to view the logs in the control panel in Craft 3, like was possible in Craft 2, then you will need to use this plugin: Logs


2

This will be a similar answer as here: Craft 3 large log file sizes Basically Craft goes with Yii's default FileTarget settings, which is 5 log files of 10MB each before they start rotating out. Those are individual limits for both web.log and console.log files. If you want to change those behaviors you'll need to modify those properties via a config/app....


2

Put the force parameter to true MyPlugin::log("Errors:\n\n" . print_r($fieldsData, true), LogLevel::Error, true); Custom Log in Craft


2

Those should not be logged in web.log when running Craft 3.x, but rather in the web404s.log -- assuming you don't have devMode on (which it shouldn't be on for production...) Vide: Zen and the Art of Craft CMS Log File Reading Also should you really want to customize things, it's not hard to do with Craft CMS, check out: Creating a Custom Logger for Craft ...


2

As someone who theoretically might inherit your site one day... and also as future-you trying to diagnose a problem... please don't try to limit what Craft logs. If you want a quicker way to look for critical problems, check out the Yii2 Debug Toolbar as discussed here Profiling your Website with Craft CMS 3’s Debug Toolbar You can use it to very quickly and ...


1

Finally solved this issue by digging a lot in code: The whole (unnecessary?) information is logged inside yii framework yii\log\Target: method collect(...): if (($context = $this->getContextMessage()) !== '') { $this->messages[] = [$context, Logger::LEVEL_INFO, 'application', YII_BEGIN_TIME, [], 0]; } When inspecting the getContextMessage() closer ...


1

As Oli commented, those will only be logged if devMode is enabled, which should never be the case in production. Outside of that, Craft does have a sensitiveKeywords propery in the Security class: https://github.com/craftcms/cms/blob/develop/src/services/Security.php#L29 that defaults to these keywords: https://github.com/craftcms/cms/blob/develop/src/...


1

This is what we ended up using. <?php return [ 'components' => [ 'log' => [ 'targets' => [ [ 'class' => PsrTarget::class, 'logger' => $logger, 'levels' => [YiiLogger::LEVEL_ERROR], '...


1

First, full disclosure here, the company I work for is a customer of Fort Rabbit. The secrets.json approach is something I think that strikes the balance between flexibility and security for really sensitive keys like API, OAuth, Amazon S3 and other sensitive secrets. dotenv is great, but having these in plain text is a risk, which I think you are mindful of....


1

Even so this thread is old, maybe my answer can help someone: Cleanup Craft Logs Basically it's possible via app.php to remove all unnecessary logs such as all the $_GET, $_POST, $_SERVER variables and all the SQL being logged. The main point you need is to configure in app.php the log component. The entry 'logVars' will get rid of all the $_SERVER values ...


1

We were having the same issue. Our logs were getting so dense with SQL statements that it was hard to find our errors. And for the most part, seeing Craft's internal SQL would not help us debug the problem. What we've found is we can use the onelogger plugin. After installing it, we just needed to add a file called onelogger.php to our config file. This ...


1

We've done the redirect route in Andrew's answer before and while it keeps some script kiddies out, it can also cause less "savvy" ones to think you actually have a valid WP installation and continue to hit you as well, which doesn't really solve the issue. nginx is so efficient that we were using a few MBps in our outgoing bandwidth just to redirect a ...


1

There is a plugin that redirects all of Craft log output to stderr that works on Heroku and Fortrabbit. https://github.com/ostark/craft-stderr-logger


1

I'm only 80% confident in this answer, but I'm pretty sure that runtime PHP ini_set calls won't work with nginx running with FastCGI (which is what Craft uses to change the error_log path. Try setting that path directly in your /etc/php5/fpm/php.ini file.


1

This was a bug in Craft that's been fixed for the next (post 2.4.2696) release. Once that release is out, devMode output will be written to the craft/storage/runtime/logs files just like a normal web request would with devMode enabled.


1

Currently not without hacking the core files. It's on our list to make log routing more configurable for Craft 3, though.


Only top voted, non community-wiki answers of a minimum length are eligible