Hot answers tagged

4

Unfortunately, the AJAX call to getAuthTimeout is hard coded to fire every 60 seconds. In other words, if you're looking for a config value, there isn't one – might be worth a feature request? For a quickfix/hack, you can create a custom plugin and add the following to its init method: craft()->templates->includeJs('(function () { Craft....


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.


3

I can think of a couple things why this is happening: 1) Custom code doing a save operation. If you're hooking into onSaveEntry for example, Craft also lets other plugins have a chance at calling their own save code as well. So when you do a saveEntry (or other element), Craft is going to repeat that call when you do it from your own code, basically putting ...


3

okay, guess I got it. as soon as I kick the Preparse Field-plugin, everything works smooth. but i guess it's not the plugin that causes the trouble, it's the way craft is writing its logs for deprecated code? another solution: RTFM.. in Preparse Field-plugin: activate "Disable all Preparse field columns on all element indices".


3

What you want is this: // Returns how many seconds are left in the current user session. // (int) The seconds left in the session, or -1 if their session // will expire when their HTTP session ends. craft()->userSession->getAuthTimeout() You can then combine this with a Javascript setTimeout when the page loads so you can trigger whatever messages ...


2

This should no longer be an issue in the next (post 2.3.2461) release of Craft.


2

The first thing I would try is to "Disable" every single one of your plugins. If that solves the problem, go through and re-"Enable" each one of them until you have pinpointed which plugin is causing the problem. If that doesn't help at all, the next thing I'd do is to open up the Craft logs, and see if anything suspicious is in there... /craft/storage/...


2

Updated using composer update craftcms/cms


2

Create a commerce.php config file in your config folder and set the cartCookieDuration to a time interval. The default is 3 months. <?php return [ 'cartCookieDuration' => 'P3M', 'purgeInactiveCarts' => true, 'purgeInactiveCartsDuration' => 'P3M', ];


1

Fixed this by adding return [ 'modules' => [ 'my-module' => \modules\Module::class, ], 'components' => [ 'queue' => [ 'ttr' => 3600, ], ], ]; to config/app.php.


1

Here is the answer, thanks to @Brandon Kelly: ./craft migrate/up --track=craft


1

The console command you are looking for is: ./craft migrate/all


1

You can use this article to help debug 504 Gateway Timeout errors that can be common when updating Craft, because those tend to be longer running operations: https://craftcms.com/support/504-gateway-timed-out-error Your solution works because PHP timeouts from the command line are generally much more forgiving that PHP timeouts from a web browser. Craft 3 ...


1

This is likely due to the item going out of stock while they were away from the cart, then when they went to pay, the item had to be removed from the cart, but they should have seen an error message when they tried to pay: Something changed with the order before payment, please review your order and submit payment again. The secondary issue is allowing ...


1

An equivalent for this code fragment in Craft 3 would be: $view = Craft::$app->getView(); $js = /** @lang JavaScript */ <<< EOT (function () { Craft.AuthManager.checkInterval = 600; // Ten minutes }()); EOT; $view->registerJs($js, $view::POS_READY); For reference: /** * Registers a JS code ...


1

I wanted to do something similar to this, but ran into the problem that if they were on another tab taking actions, they could extend the timeout, which would render the original set timeout to no longer be correct. To account for that, I created a controller in one of my plugins which would get the timeout for the user, and return that. public function ...


1

If running Webmin, check the Website Options under Server Configuration and set Maximum PHP script run time to unlimited or a largar value. This is what finally did the trick but updating /etc/apache2/mods-available/fcgid.conf with the following values may have also played a role. FcgidConnectTimeout 600 FcgidIOTimeout 600 IPCCommTimeout 600 After these ...


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