Dashboard Single Pages in v9+ elementManager error

[goldfox]

Hi there,

I’m upgrading a Concrete5 site (previously v8.3.2) to ConcreteCMS (v9.1.1). The upgrade has worked almost flawlessly, but I’m unable to access the Dashboard Single Pages from Packages developed pre v9. It throws an error:

Call to a member function get() on null

for the line:

$_breadcrumb = $this->elementManager->get($this->getBreadcrumbElement(), [
            'breadcrumb' => $breadcrumb
        ]);

in file: siteroot/updates/concrete-cms-9.1.1-remote-updater/concrete/src/Page/Controller/DashboardPageController.php

So for some reason elementManager is null for $this when running through the on_before_render() function. I have tried adding ElementManager to the controllers (use Concrete\Core\Filesystem\ElementManager;) but it’s still throwing the error and I don’t know where to start trying to fix it.

Hope someone can help.

[jessicadunbar]

@goldfox Are you able to post your website configuration from Environment Information in your Concrete Dashboard?

[goldfox]

Hi Jes,

Thanks for replying. The env info is this:

Concrete Version

Core Version - 9.1.1
Version Installed - 9.1.1
Database Version - 20220516191423

Database Information

Version: 5.7.38-log
SQL Mode:

Concrete Packages

Custom Package #1 (0.1), Custom Package #2 (1.1.2), Custom Package #3 (0.9.1), ExchangeCore reCAPTCHA (1.1.1), Insert Video (0.9), Custom Package #4 (0.1)

Concrete Overrides

Concrete Cache Settings

Block Cache - Off
Overrides Cache - Off
Full Page Caching - Off
Full Page Cache Lifetime - Every 30 minutes.

Server Software

Apache

Server API

cgi-fcgi

PHP Version

7.4.30

PHP Extensions

bcmath, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dba, dom, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imap, intl, json, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, Reflection, session, shmop, SimpleXML, soap, sodium, SPL, sqlite3, standard, tidy, tokenizer, xml, xmlreader, xmlwriter, xsl, zip, zlib

PHP Settings

max_execution_time - 50000
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - -1
max_input_vars - 5000
memory_limit - -1
post_max_size - 64M
upload_max_filesize - 64M
mbstring.regex_retry_limit - 1000000
mbstring.regex_stack_limit - 100000
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - no value
session.gc_maxlifetime - 7200
soap.wsdl_cache_limit - 5
unserialize_max_depth - 4096

[goldfox]

@jessicadunbar Thanks for replying. Not sure if I needed to tag you for you to see that I’d replied? I haven’t used the forum here in a few years and it all seems new to me, sorry. I’ve posted the env info above. Any ideas?

[jessicadunbar]

Thank you so much, I’ll pass this up to Engineering.

[pvernaglia]

I’ve been fixing the null errors with an if statement, try this, it might work

if($this->getBreadcrumbElement(){
$_breadcrumb = $this->elementManager->get($this->getBreadcrumbElement(), [
‘breadcrumb’ => $breadcrumb
]);
}

[Doki]

Seconding this. We’re in the process of upgrading from 8.5.7 to 9.1.1 and are encountering this exact bug (which is just one among an enormous amount of other issues – almost everything custom is broken in 9.1.1 and thus we have to recode just about every single page, controller, block and package).

Of these issues, this issue seems to crop up the most – our custom dashboard pages all fail specifically because of this bug. Because the issue backtracing goes completely through core code, I cannot currently identify a local fix, so I’ll try the above kludge until an official fix is in.

Just writing to make sure people know this isn’t an isolated issue but a widespread one.

[Steff]

We just ran into the same problem. But even with the idea from @pvernaglia we could not get around. As we actually do not need breadcrumbs on this page, we just uncommented the whole part

[Myq]

I’ve tried poking around at this issue a few times, but I’m still unable to reproduce the issue. I took the following steps:

• fresh install of 8.5.7
• installed a number of free add-ons, some marked as version 9 compatible (such as Open Graph Tags Lite) but many which I know for a fact have not been updated in quite a while and are marked as not compatible with version 9 (such as Centry and MrKDilkington - Login Page Background)
• upgraded PHP from 7.2 to 7.4
• upgraded to 8.5.9 through the dashboard
• verified there were no errors with the add-ons
• upgraded to 9.1.2 through the dashboard
• verified that there were no errors with the add-ons and that the breadcrumbs were showing correctly

So I think the only way to move forward with this is to provide a MWE and either post it here or make an bug report on GitHub.

[Doki]

I’m two posts above, having done an upgrade to 9.1.1. I JUUSSTTT completed a different upgrade on a different site from 8.5.7 to 9.1.2 and did not encounter the error, whereas in my previous job the issue was extremely widespread.

Maybe 9.1.2 fixed it?

If anyone encounters this bug when moving to 9.1.2 please post here, and if so I’ll write up something in GitHub.

[andrew]

I think this likely has something to do with Dashboard page controllers that have overridden on_start() and/or on_before_render(). It’s possible in the past that this could be done without the calling the parent::on_start() or parent::on_before_render() methods but now those methods actually do something in DashboardPageController; if they don’t run, you’ll get errors in Dashboard page.

tldr: if your Dashboard page controller has on_start() or on_before_render() within it, call parent::on_start() and/or parent::on_before_render() within it to ensure that the base controller method is also run.

[mnakalay]

I can confirm what @andrew said, that was the first thing that broke when I updated my packages to v9.

I would add, make sure you call the parent methods first before anything else

[jb1]

I experiencing the same issue when testing one of my add-ons for V9 compatibility, and Andrew’s suggested fix worked.