I’m yet to thoroughly test but upgrading EE to 7.3.12 appears to fix the issue on the front end, just adding here for clarity.

Hi Brian

We are still unable to resolve this. I cannot find any reference to the block_display_field() method in our codebase nor can I find any mention of it within our database. This issue occurred following upgrading EE from version 7.2.11 -> 7.3.12 and also updating bloqs from 5.0.7 -> 5.0.11.

We are able to view/edit/save entries that do not contain any Bloqs, please let me know anything I can provide to assist with solving this.

Thanks,

Hi Brian,

I also just noticed when checking the bloq that field above belonged too I can’t view/edit the it in the CMS along with all the other bloqs, stack trace below for the error:

Call to undefined method grid_display_settings()
ee/ExpressionEngine/Service/Template/Variables/ModifiableTrait.php:37

Stack Trace: Please include when reporting this error
#0 [internal function]: EE_Fieldtype->__call('grid_display_se...', Array)
#1 user/addons/bloqs/Controller/FieldTypeWrapper.php(324): call_user_func_array(Array, Array)
#2 user/addons/bloqs/Controller/FieldTypeWrapper.php(407): BoldMinded\Bloqs\Controller\FieldTypeWrapper->callGridOnly('grid_display_se...', Array)
#3 user/addons/bloqs/mcp.bloqs.php(1033): BoldMinded\Bloqs\Controller\FieldTypeWrapper->displaySettings(Array)
#4 user/addons/bloqs/mcp.bloqs.php(957): Bloqs_mcp->getAtomDefinitionSettingsForm(Object(BoldMinded\Bloqs\Model\AtomDefinition), 'text')
#5 user/addons/bloqs/mcp.bloqs.php(906): Bloqs_mcp->getAtomDefinitionView(Object(BoldMinded\Bloqs\Model\AtomDefinition), NULL, Array)
#6 user/addons/bloqs/mcp.bloqs.php(541): Bloqs_mcp->getAtomDefinitionsView(Object(BoldMinded\Bloqs\Model\BlockDefinition), Array)
#7 [internal function]: Bloqs_mcp->blockDefinition()
#8 ee/ExpressionEngine/Controller/Addons/Addons.php(1590): call_user_func_array(Array, Array)
#9 ee/ExpressionEngine/Controller/Addons/Addons.php(866): ExpressionEngine\Controller\Addons\Addons->getModuleSettings('bloqs', 'blockDefinition', Array)
#10 [internal function]: ExpressionEngine\Controller\Addons\Addons->settings('bloqs', 'block-definitio...')
#11 ee/ExpressionEngine/Core/Core.php(268): call_user_func_array(Array, Array)
#12 ee/ExpressionEngine/Core/Core.php(124): ExpressionEngine\Core\Core->runController(Array)
#13 ee/ExpressionEngine/Boot/boot.php(184): ExpressionEngine\Core\Core->run(Object(ExpressionEngine\Core\Request))
#14 admin.php(139): require_once('...')
#14 admin.php(139): require_once('...')

Hi Brian,

I’ve tried a fresh copy of expression engine, bloqs and then copied across all of our remaining addons (Structure, Publisher Lite, Wyvern) along with our project setup and templates and also a backed up version of the database prior to the issue and unfortunately the issue still persists. This is probably about as close as I can get with a fresh install. The problem is that we have a site with over 400 entries and around 50 bloqs, if data migration in expression engine was easy then I’d be happy to go with a fresh install but as you can imagine recreating a site like that manually would take a very long time (time isn’t something we have unfortunately).

It feels like somewhere along the way the database might have become corrupted in some form - if that’s the case could you possibly advise on anything for us to try?

In relation to your final questions, no we don’t have any fields named the same as bloqs and we don’t use any grid columns on the site at all.

Thanks,

Hi Brian,

We reverted back to what’s on our live installation currently to try and work forwards from there which is running EE version 7.2.11 and Bloqs 5.0.7. For reference our master template contains Template partials, not embeds - which I should have mentioned before. When I strip it down to it’s absolute barebones of what’s required, this consists of a “row_block” with a nested test block “bloq_test_new”, in order to replicate how our layout typically operates. Our master template looks like this:

{exp:channel:entries channel="default_layout" {gv_disable} {gv_cache}}

{default_group}
{row_block}
<div class="row">
    {bloqs:children}
    {bloq_test_new_template}
</div>
{/row_block}
{/default_group}

{/exp:channel:entries}

The partial that’s referenced “bloq_test_new_template” looks like this:

{bloq_test_new}
<div data-block-name="bloq_test_new">
    {title}
</div>
{/bloq_test_new}

The output of the page in this situation is:

<div class="row">
    
<!--Attempting to render a block from entry #429, but the template tag pair is missing. Add {bloq_test_new}{/bloq_test_new} to your layouts/_html-wrapper template to correct this error.-->

    test
<div data-block-name="bloq_test_new">
    Testing Title
</div>
{/bloq_test_new}
</div>

Notable takeaways from the above:

• I’m not sure where the “test” text is coming from.
• I’m also not sure why the closing bloq tag “{/bloq_test_new}” is returning.
• Despite it rendering it appears there was an issue as the comment suggests.

Thanks again for your help.

Sorry I forgot to add as well, that removing any reference of “block_” and “grid_” from these methods being called in the FieldTypeWrapper.php file fixes my issues in the CMS, this is why I’m asking the above in my last reply.

Hi Brian,

Apologies I think you’ve misunderstood the above. I understand the origins of where they are being called from, my question is where do these methods exist at? Specifically these 4:

“block_display_settings” “block_validate_settings” “grid_display_settings” “grid_validate_settings”

Thanks,

Hi Brian,

So this appears to be where my issue lies, as creating a new bloq appears to require the use of those 4 methods listed above. This only occurred when I upgraded EE to the latest version from 7.2.11. If I am to modify FieldTypeWrapper.php to remove the prepending of “block_” and “grid_” when these methods are called and we just use the default versions of “display_settings” and “validate_settings” then the error goes away. So for example:

I alter the following lines in FieldTypeWrapper.php at Line 292:

} else if (is_callable(array($ft, 'block_' . $methodName))) {
            $result = call_user_func_array(array($ft, 'block_' . $methodName), $args);
        } else if (is_callable(array($ft, 'grid_' . $methodName))) {
            $result = call_user_func_array(array($ft, 'grid_' . $methodName), $args);

And replace it with:

} else if (is_callable(array($ft, 'block_' . $methodName))) {
            $result = call_user_func_array(array($ft, '' . $methodName), $args);
        } else if (is_callable(array($ft, 'grid_' . $methodName))) {
            $result = call_user_func_array(array($ft, '' . $methodName), $args);

And then also modify FieldTypeWrapper.php line 400 for displaySettings():

public function displaySettings($data)
    {
        $method_to_call = is_callable(array($this->_fieldtype, 'grid_display_settings'))
            ? 'grid_display_settings'
            : 'display_settings';

        return $this->callGridOnly($method_to_call, array($data));
    }

And change this too (removing $method_to_call and hardcoding “validate_settings” instead):

public function displaySettings($data)
    {
        $method_to_call = is_callable(array($this->_fieldtype, 'grid_display_settings'))
            ? 'grid_display_settings'
            : 'display_settings';

        return $this->callGridOnly('display_settings', array($data));
    }

And then finally amending FieldTypeWrapper.php Line 413 for validateSettings():

public function validateSettings($data)
    {
        return $this->callGridOnly('grid_validate_settings', array($data));
    }

And changing this to remove grid_ in the call too:

public function validateSettings($data)
    {
        return $this->callGridOnly('validate_settings', array($data));
    }

All these changes above to this file appear to fix my issue. Would it be possible to get an understanding how these will impact the bloqs addon moving forward and if this helps on your end in debugging this?

Thanks,

Hi Brian,

Apologies I will come back to you on all of the above - I’m just rather busy right now and want to collate everything for you properly so we can work this out, I should be able to fire something back on all your above points in the next few hours.

Thanks,