Cms: Field edit pages are really slow

[TimvanDijkhuizen]

Description

We've recently updated a project to Craft 3.4.9 but now field edit pages have become really slow. I'm on a local installation using a local database and everything else is really fast. I have this problem with all my field edit pages but the page I tested it on is a plain text field.

Debug bar:

Debug timings:

I'm not sure what is causing it so I can't provide a lot of info. If you need any extra information please let me know!

Steps to reproduce

1. Open any field edit page.
2. It loads really slow.

Additional info

• Craft version: 3.4.9
• PHP version: 7.2.18
• Database driver & version: MySQL 5.0.12
• Plugins & versions: If needed please ask me.

[TimvanDijkhuizen]

Turns out this is a Super Table bug. It only took 2,5 seconds after disabling that plugin. Closing this issue.
https://github.com/verbb/super-table/issues/346

[brandonkelly]

2.5 seconds is still pretty terrible, and I suspect we could solve this centrally in a way that could help Super Table as well, to a degree.

[nettum]

Can confirm that _something_ is slower in later versions. I just created a new matrix with 4 blocks. 3 of them have super-table with typed link field inside. This seem to result in a lot of data going through the wire (5.3MB in this case) when opening the matrix field. Saving it is fast.
Opening a plain text field (no matrix or super-table attached to it) takes about 2.4 seconds and the size of the request is about 2.3MB of data. See attached screenshot from the matrix field.

Craft CMS 3.4.20
Super Table 2.4.9
Typed link field 1.0.21

[brandonkelly]

This is now resolved for the next release 🎉

We ran an ill-performing Edit Field page through Blackfire in both Craft 3.3 and 3.4, and found the culprit to be the new JS/CSS minification we added in 3.4 (#5183). So that’s disabled by default now, instantly bringing Craft 3.4 back on par with 3.3 (ignoring any other factors like plugins).

Additionally, I went ahead and implemented something I was planning on doing for 3.5, but decided it’s worth getting out sooner than later: field type settings are now lazy-loaded as needed. So now when you request an Edit Field page, only the selected field type (and if Matrix, any nested selected field types) will need to render their settings up front. All other field types will be rendered over Ajax if/when the Field Type selection changes.

(Super Table will need to be updated to take advantage of field setting lazy loading for its own sub-fields.)

This was a little involved, so I’d appreciate a couple extra pairs of eyes before we release 3.4.22. If you want to help test, change your craftcms/cms requirement in composer.json to:

"require": {
  "craftcms/cms": "dev-develop as 3.4.21",
  "...": "..."
}

Then run composer update.

[brandonkelly]

Got a couple people to test, fixed a bug, and went ahead and released these changes as Craft 3.4.22 because YOLO!

[engram-design]

@brandonkelly Yeah, just do it 🎉

[Mosnar]

@brandonkelly Just tried this out and it feels buttery-smooth! It works perfectly for all fields I tested! ...except for one plugin: SEOmatic (@khalwat) field settings throw a server error. Here's the request stacktrace:

yii\base\ErrorException: Trying to get property 'manifest' of non-object in /home/forge/mysite.com/vendor/nystudio107/craft-seomatic/src/fields/SeoSettings.php:510
Stack trace:
#0 /home/forge/mysite.com/vendor/craftcms/cms/src/web/ErrorHandler.php(74): yii\base\ErrorHandler->handleError(8, 'Trying to get p...', '/home/forge/mys...', 510)
#1 /home/forge/mysite.com/vendor/nystudio107/craft-seomatic/src/fields/SeoSettings.php(510): craft\web\ErrorHandler->handleError(8, 'Trying to get p...', '/home/forge/mys...', 510, Array)
#2 /home/forge/mysite.com/vendor/nystudio107/craft-seomatic/src/fields/SeoSettings.php(300): nystudio107\seomatic\fields\SeoSettings->registerCssModules(Array)
#3 /home/forge/mysite.com/vendor/craftcms/cms/src/controllers/FieldsController.php(274): nystudio107\seomatic\fields\SeoSettings->getSettingsHtml()
#4 [internal function]: craft\controllers\FieldsController->actionRenderSettings()
#5 /home/forge/mysite.com/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#6 /home/forge/mysite.com/vendor/yiisoft/yii2/base/Controller.php(157): yii\base\InlineAction->runWithParams(Array)
#7 /home/forge/mysite.com/vendor/craftcms/cms/src/web/Controller.php(178): yii\base\Controller->runAction('render-settings', Array)
#8 /home/forge/mysite.com/vendor/yiisoft/yii2/base/Module.php(528): craft\web\Controller->runAction('render-settings', Array)
#9 /home/forge/mysite.com/vendor/craftcms/cms/src/web/Application.php(291): yii\base\Module->runAction('fields/render-s...', Array)
#10 /home/forge/mysite.com/vendor/craftcms/cms/src/web/Application.php(559): craft\web\Application->runAction('fields/render-s...', Array)
#11 /home/forge/mysite.com/vendor/craftcms/cms/src/web/Application.php(270): craft\web\Application->_processActionRequest(Object(craft\web\Request))
#12 /home/forge/mysite.com/vendor/yiisoft/yii2/base/Application.php(386): craft\web\Application->handleRequest(Object(craft\web\Request))
#13 /home/forge/mysite.com/web/index.php(17): yii\base\Application->run()
#14 {main}

[khalwat]

Looks like the error is likely being thrown here:

https://github.com/nystudio107/craft-seomatic/blob/v3/src/fields/SeoSettings.php#L510

No idea what the changes @brandonkelly made were, or how that could result in Seomatic::$seomaticVariable being (presumably) null or uninitialized here.

[brandonkelly]

Just released 3.4.22.1 with a fix for that SEOmatic error. Issue was that Seomatic::$seomaticVariable is defined by the Twig extension’s getGlobals() method, which will only get called before rendering the first Twig template for the request. But in 3.4.22, getFieldSettings() was getting called directly from the controller, not through a Twig template, so getGlobals() hadn’t been called yet by the time SeoSettings::registerCssModules() was called.

Fixed by tweaking the new field settings controller to render a template that calls the field’s getSettingsHtml() method, to simulate how it used to work.

[khalwat]

Thanks @brandonkelly -- I was just sitting down to look at it, and my thought was have the Field just call the ManifestHelper class directly, rather than through the variable (which didn't exist in this context).

But looks like I don't have to! Many thanks!