All add-ons currently require PHP 7.4 or greater.

On July 4th 2024 PHP 8.2 will be the new minimum requirement for all add-ons. Expect any add-on released after that date to require 8.2 or greater. Some releases may not immediately take advantage of 8.x specific features in PHP, which means you might, be able to continue using new releases in PHP 7.4, however, if you experience an error the first thing you should do is update to PHP 8.2 then create a support ticket if the error persists.

Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from, be sure to visit to add the license to your account here on

Ticket: Logging as an On/Off setting in bloqs

Status Resolved
Add-on / Version Bloqs 4.10.2
EE Version 5

Paul Larson

Nov 30, 2021

Friendly request: I’d like to submit to a future feature list,  error logging as an On/Off setting.

We ran into a situation on a high-traffic site where 1,000 bloqs warnings were being written to the EE dev log every minute, eventually reaching 2.5 million rows and bringing down the web server.

I’m not saying the logging isn’t important, but the cadence of the logging (again, due to traffic) created a high-pressure situation where we had to manage truncating the database table _while_ figuring out our offending bloq template/tags (which is still in-process).

Many modules have on/off logging, such as Detour, Snaptcha, CartThrob (image below),

My two cents!


BoldMinded (Brian)

I’m going to have to think about this because I’m not sure I entirely agree. The logging has actually expedited, or entirely prevented support issues because they’re pointing out legitimate issues that should be addressed. I think a better solution is to only log the error if the current user can login to the control panel, e.g. a developer working on the site. There is already an instance in Bloqs where I do this, but this particular instance you point out does not have the same condition. I’ll add it to the next release. For now if you want to make the change wrap the logging lines in the conditional:

Starting at line 670 of TagController.php

private function handleEmptySections(TagOutputBlockContext $context, array $sections = [], $useChildrenTag = false): array
        // Probably trying to render a block that does not have a tag pair in the template.
        if (empty($sections)) {
            $message = sprintf(lang('bloqs_missing_tag_pair'),

            if (App::userData('can_access_cp')) {

            // We have a missing block tag pair.
            // Create a blank tag pair so we can output a message in the proper location in the DOM.
            $sections[] = $this->_createSectionTagPair($context->getShortname(), '<!--' . $message . '-->', $useChildrenTag);

        return $sections;

Aasun Eble

I definitely agree with having an option to disable. Similar to dev logging on a site while troubleshooting an issue.. There are times when I want it on, and to intentionally use the resources that it requires. But, there are high-volume sites where extra logging is not a good fit. (Working on one now). So, I also want the ability to disable logging.


BoldMinded (Brian)

The issues being logged are not simple notices, like “made a query to the database” or “instantiated a class” - they are legitimate issues that should be addressed, therefore I’m not going to add a sweeping disable toggle, especially if it yields more support tickets. I made the change above for the next release so it’ll only log if the user is logged in and can actually see the logs in the CP.


BoldMinded (Brian)

I appreciate the feedback, but as mentioned in the previous comment I won’t be adding any global disable option. I found another instance of where it was logging for any user, so I wrapped it in the same conditional as above. So the next release should greatly reduce the log count, but still keep relevant logs.

Login to reply