dblog_update_8600() breaks views.view.watchdog config entity, leading to PHP warning on admin/reports/dblog and configuration import errors

I'm seeing the same error in my logs. It occurs when browsing to the watchdog page.

Same error, when browsing to the watchdog page.

I'm getting similar error when I go to the reports page.
Not to mention the other major error I reported elsewhere. D 8.6.0 update seems to be a nightmare !

Each time I visit the log page this error is added on the log since 8.6.0

We'll need to draft some instructions to reproduce this problem. Does it happen when installing 8.5 locally and upgrading it to 8.6 immediately?

@Xano

Does it happen when installing 8.5 locally and upgrading it to 8.6 immediately?

In my case, I noticed it after updating locally from 8.5.5 > 8.5.7 > 8.6.0 via composer

I also have a more serious error I reported elsewhere.

Same error in my logs. It occurs when browsing to the watchdog page.

I can see this error too when visiting the watchdog page.
$this->options['content'] in Drupal\views\Plugin\views\area\Text->preQuery() is a string containing the "Watchdog is empty" text, while the code expects it to be an array with a 'value' key that contains the text.

Hi all. Sorry I wasn't aware of this issue until @cilefen moved to the right queue. Thanks!

For some context, this issue #2916898: Do not use basic_html text format for 'No log messages available.' message was created to update the filter used by the empty area plugin in the watchdog view.

I assume most of the people that reports this already ran the database updates, right? Also, if someone can attach the views.view.watchdog config entity as a txt in this issue, it will help me to understand what is going on here.

Definitely the "empty" setting in the view causes the errors.
Removing or replacing it manually solves the problem.

Here the relevant settings part to compare:

causes errors---

      empty:
        area:
          id: area
          table: views
          field: area
          relationship: none
          group_type: group
          admin_label: 'Keine Protokollnachrichten verfügbar.'
          empty: true
          tokenize: false
          content: 'Keine Protokollnachrichten verfügbar.'
          plugin_id: text


works---

      empty:
        area_text_custom:
          id: area_text_custom
          table: views
          field: area_text_custom
          relationship: none
          group_type: group
          admin_label: ''
          empty: true
          tokenize: false
          content: 'Keine Protokollnachrichten verfügbar.'
          plugin_id: text_custom

The problem addressed here seems to exist independently from any distribution (thunder was mentioned above). It even occurs on regular D8 installs without extra modules.

UPDATE: the above config parts are from an export over "/admin/config/development/configuration/single/export".
The first part after the core update before the manual change of the view (over views ui), the second part after the manual change of the view.

@indigoxela . I confirm your observation. Replacing the watchdog config yml file with the code from core d 8.6.x watchdog view .yml code fixed it for me.

Replacing the watchdog config yml file ...

It should be noted, that it's not necessary to touch any yml files on live sites.
The config parts are for dagmar, who asked for it for clarification.

For a fast fix on live sites it is easier and safer to edit the view.
On /admin/structure/views search for "watchdog" and edit the view as you would normally.

The dblog_update_8600 that may be causing that problem.

Could someone please:

1. Confirm that the database update ran (using update.php or drush updb)
2. Provide a full export of the view that you get after running the updates

Thanks!

At least I can confirm that the update ran (drush updb).

On the status page there was no nagging about db updates, everything looked fine.

I didn't change anything on the watchdog views before the errors occurred. But now all are fixed. Would need to set up a new Drupal for a test.

@dagmar, I did the core update via composer (over two stages. It first updated from 8.5.5 to 8.5.7 and I had to edit the composer.json to make it update to d 8.6.0). I then did db update via drush updatedb

If any more info may be of use, here's more details in another issue I created for another error.

@indigoxela, thanks for the hint

I tried to replicate this issue with a fresh install of drupal 8.5.5 and then update it to 8.6.1 without luck.
I wonder if the translation of the site is involved somehow on this. @indigoxela @cestmoi have you seen this issue in plain english sites?

@dagmar the site I experienced it on is multilingual actually and the default language is not En.

@dagmar interesting point - the language...

Do you think the problem is caused by "... $empty_text['area']['content']['value'] == 'No log messages available.'..." in the if clause of dblog_update_8600?

In none of my D8 installs the default language is en.

Just tested on german as default language with a fresh vanilla install of drupal-8.5.7, then updated to 8.6.0, then updated to 8.6.1 (not in one step).

Find attached the export of the watchdog config after updating to 8.6.1.
No errors occurred when updating db via "drush updb", no warnings on the status page afterwards.

Very likely it wasn't dblog_update_8600, as that one simply did nothing because of the language-bound if clause.

It seems to be something with tokens and non-ascii characters in the area (but not on unfiltered text).
To reproduce: Edit the empty setting, simply add an "Ü" (german umlaut) to the area and try to save it.

Anyone else experiencing this, any other findings?

@quixxel if you are still searching for a fix on production sites: first delete the "empty" setting of watchdog view completely. If the view refuses to save, click on the "page" button on the top left of the view ui interface to reload the current page. Saving the view should be possible then.

If you would like to have an empty message, add a new "unfiltered text" (NOT text area) after that.

Confirming I'm having the same issue on a site, after updating to 8.6.1, multi-lingual setup.
Confirming, I'm seeing the same behavior described in #25.
Confirming #29 fixes the warning.

Not completely satisfied : Is this problem going to happen again for the next update ?
Ideally, I assume the problem should be fixed in the configuration files of the watchdog view ==> Problem will mostly likely happen again if the watchdog view configuration is reverted.

FYI. screenshot of the diff of the source and db configurations after carrying the changes from #29:

Hope this feedback will help a bit others and perhaps on the resolution of this issue.
Thanks everyone!

Thanks #29!

Thanks,
I removed the empty text from the watchdog view (admin/structure/views/view/watchdog)

Thanks #29 !

There is no patch to review here yet. Assigning the right status.

I also had this error on a site where the default language is German. (We had to change from English.)
I removed only the German configuration of empty and everything worked okay.

Another site with English as default language (also English / German) didn't have the issue at all.

I'm trying to collect the actual strings for languages, that seem to be affected.
There must be a reason, why some are affected, while others aren't.

So far I have:

• de: Keine Protokollnachrichten verfügbar.
• fr: Aucune entrée du journal n'est disponible.

We see non-ascii characters in both translations, maybe this is causing the problem, maybe not.

There seems to be no central point to search for each and every available translation for an original string, at least I didn't find any.

This was my best guess:
https://localize.drupal.org/translate/languages

I searched for translations in several languages - some have only ascii (es/it/nb..) some have non-ascii chars included (sv/fi/cs...)
If one of you can confirm or refute my thesis, please post here.

Since it was mentioned in this issue the error may be related to non-ascii characters, I actually tried to replace the text with

* Keine Protokollnachrichten vorhanden.

but that didn't work either.

Thanks #29 fixed it.
I have also a multilingual site + the empty views field was set to a custom text format (not the standard basic html)

@yazzybe I suppose, the default language is dutch. Is that right?

Let's skip the idea with non-ascii chars breaking stuff. The dutch translation is "Geen logberichten beschikbaar.".

What we have so far: As reported here by several people, the problem seems to occur on sites, where the default language is not english.
Single language or multilingual - both seem affected.

Very likely the initial installs were made with Drupal versions below 8.6.
At least this is the case with my own installs.

It IS possible to reproduce the InvalidArgumentException: described in #25 on sites for which the above is true (default language not en, installed before 8.6.).

Add an empty message text area to watchdog view with any text, format "basic_html", only ascii chars at first, save the view. No problem.
Edit the view again, add one "Ü".
No problem in the preview, but as soon as you try to save the view, the exception occurs.
To fix the exception, it is necessary to completely delete the empty message as described in #29. Just removing the umlaut won't help - you can't save the view.

Of course, as the view can't get saved, the actual error on the watchdog page "Illegal string offset 'value'..." is not reproducible.

Correct. The message in Dutch “Geen logberichten beschikbaar” has no special ascii characters.

I run 2 nearly identical drupal8 sites.
One had the watchdog problem, the other one didn’t. see attachments.

Both installed around the same time (initial version 8.4 I think > then 8.5), now 8.6.2
Both have the same languages set up:
- Dutch (default)
- English

But both have different text format settings. The breaking site had a “custom” text format above the default basic_html. I don’t know if that caused the issue.

What also could be different is the language choice on initial setup. Both have the same languages setup, but I think I installed one site initially in English and added Dutch later … and the opposite approach on the other site; Dutch on initial install (making English available by default).

Ps: another observation is that the views field labels and title on the watchdog views are not always translated in all my bilingual sites, but all the rest is. However the website with the untranslated stuff did not have the breaking issue.

Just like to pinpoint that this issue is present on Drupal 8.6.2 when user access DBlog admin page /admin/reports/dblog

Consequence : the "Clear log" button is not displayed anymore.

Therefore, it seems quite critical to me. Users can not clear dblog logs.

@yazzybe many thanks for your investigation

But both have different text format settings. The breaking site had a “custom” text format above the default basic_html. I don’t know if that caused the issue.

I suppose, this is because for the site with default language "en" the update dblog_update_8600 worked as expected, so the text format was changed.
As stated before, dblog_update_8600 didn't work for sites with default languages other than "en".

Note that once I add a "No results text" under "No Results Behavior" in the "Watchdog" view I can no longer save it.

The weird thing is that I can save it in a clone of the watchdog view:

diff views.view.watchdog.yml views.view.duplicaat_van_watchdog.yml

1c1
< uuid: 01690db6-c884-4a39-a48a-a977e46aac43
---
> uuid: fe6185af-9f24-445c-9375-e6c2af0b647d
10,11c10,11
< id: watchdog
< label: Watchdog
---
> id: duplicaat_van_watchdog
> label: 'Duplicaat van Watchdog'

This should be major per the issue priority guidelines, since it appears on the dblog page itself:

https://www.drupal.org/core/issue-priority

Trigger a PHP error through the user interface, but only under rare circumstances or affecting only a small percentage of all users, even if there is a workaround.

Are there steps to reproduce this with a new Drupal 8.6 install, or does it only happen with upgraded sites where English is not the default language?

I've tried to update the issue title but this could also use an issue summary update.

Hi @catch,

Are there steps to reproduce this with a new Drupal 8.6 install, or does it only happen with upgraded sites where English is not the default language?

This only happens on upgraded sites.

OK trying another re-title.

Same problem here, upgraded 8.6.x, single-language (FR, not EN) site.

Also, AFAIC no one mentioned it, but the issue ins preQuery() happens because $this->options['content'] is a plain PHP string in that case, while it is expected to be an array, which is visible when comparing the config entity to a snapshot:

diff config/sync_12L28/views.view.watchdog.yml config/sync/views.view.watchdog.yml
663c663
<           admin_label: ''
---
>           admin_label: 'Aucune entrée du journal n''est disponible.'
666,668c666
<           content:
<             value: 'Aucune entrée du journal n''est disponible.'
<             format: basic_html
---
>           content: 'Aucune entrée du journal n''est disponible.'

One of the versions of display.default.display_options.empty.area.content is an array with value and format keys, while the other is a string

I have D8.6.14 (RU lang) version where the same problem appeared. Thanks #29!

The problem is in a multilingual or non-en site, the config key 'content' does not contain 'No log messages available' when it checks to see if the view was altered or not.

This fails:

if ($empty_text['area']['id'] == 'area' &&
      $empty_text['area']['plugin_id'] == 'text' &&
      $empty_text['area']['field'] == 'area' &&
      $empty_text['area']['content']['value'] == 'No log messages available.') {

So the update hook doesn't alter the config and thus becomes incorrect.

The views.view.watchdog.yml file states:

   area:
          id: area_text_custom
          table: views
          field: area_text_custom
          relationship: none
          group_type: group
          admin_label: 'No log messages available.'
          empty: true
          tokenize: false
          content: 'No log messages available.'
          plugin_id: text_custom  

However, what is in config is this:

  area:
          id: area
          table: views
          field: area
          relationship: none
          group_type: group
          admin_label: 'No log messages available.'
          empty: true
          tokenize: false
          content: 'No log messages available.'
          plugin_id: text

So either for this to work you need to change the config into:

  area:
          id: area
          table: views
          field: area
          relationship: none
          group_type: group
          admin_label: 'No log messages available.'
          empty: true
          tokenize: false
          content:
            value: 'No log messages available.'
            format: basic_html
          plugin_id: text

OR

  area:
          id: area
          table: views
          field: area
          relationship: none
          group_type: group
          admin_label: 'No log messages available.'
          empty: true
          tokenize: false
          content: 'No log messages available.'
          plugin_id: text

Also not that when you change this, 'No log messages available.' will need to be translated into your language.

I get this issue too on French website, drupal 8.6.
Thought was a viewreference issue so I posted: https://www.drupal.org/project/viewsreference/issues/3049137
#29 allow to re-save the watchdog view but not to fix my issue on the illegal choice...

Hello,
I've run into this issue, I've added a comment on https://www.drupal.org/project/drupal/issues/2916898#comment-13236983.
For me changing docroot/core/modules/dblog/config/optional/views.view.watchdog.yml from:

empty:
        area:
          id: area_text_custom
          table: views
          field: area_text_custom
          relationship: none
          group_type: group
          admin_label: 'No log messages available.'
          empty: true
          tokenize: false
          content: 'No log messages available.'
          plugin_id: text_custom

TO

empty:
        area_text_custom: // <---------------------- @NOTE the change
          id: area_text_custom
          table: views
          field: area_text_custom
          relationship: none
          group_type: group
          admin_label: 'No log messages available.'
          empty: true
          tokenize: false
          content: 'No log messages available.'
          plugin_id: text_custom

fixed the issue.

Next step maybe get it patched if you confirm this solves the issue?

Adding summary update. Needs some review since this is what I think it happened, but not sure 100%.

Fixing wrong link in the issue summary.

#29 solved it.

Thank you!!

While #29 can be a workaround, is not a fix for this problem. We should fix the root cause so nobody needs to apply that workaround.

Hello,
Adding a test-only patch with the functionality that I think should validate.
Still pending a complete patch.
Any review will be very welcome.

Hello,
Adding the first patch which includes tests and update hook.
It should:

1. Provides an update hook that changes the area plugin (handler) from area to area_text_custom, trying to follow the same approach as in dblog_update_6000. @NOTE we need to watch out for overrides, specially in installations from configuration profiles, configuration splits and so on.
2. Removes DblogNoLogsAvailableUpgradeTest and creates a "similar" one DblogNoLogsAvailablePluginTypeUpgradeTest.
3. Changes (and adds) some code to DbLogViewsTest for validating proper data.

Hello,
I need some help here, DbLogViewsTest is failing with the new changes, but I don't know how to run this test after the update, otherwise it won't pass.
If I make, instead, an update test out of it, what should I do with the "old" DbLogViewsTest which won't validates then?

Hello,
New patch, in this one we also update "/core/modules/dblog/config/optional/views.view.watchdog" view to have proper config. It might make DbLogViewsTest validates.

Changing title and summary to add the root cause of the errors, which is the missconfigured views.view.watchdog config entity after dblog_update_6000 (if watchdog view has not been customized).
Depending on your site configuration this could lead to:

- PHP warnings on admin/reports/dblog.
- Config import not working properly.
- Errors when saving views.view.watchdog config entity, which might happen in sites installed with a non english language when locale hooks into hook_modules_installed or hook_themes_istalled.
- Some other errors not exposed here and difficult to trace because of dependencies, customizations or overrides in configuration.

Typo dblog_update_6000 should be dblog_update_8600

Hello. The patch seems to have moved the problem one line further:

Warning : Illegal string offset 'value' dans Drupal\views\Plugin\views\area\Text->preQuery() (/var/www/projet/www/core/modules/views/src/Plugin/views/area/Text.php ligne 50)
#0 /var/www/projet/www/core/includes/bootstrap.inc(587): _drupal_error_handler_real(2, 'Illegal string ...', '/var/www/proj...', 50, Array)
#1 /var/www/projet/www/core/modules/views/src/Plugin/views/area/Text.php(50): _drupal_error_handler(2, 'Illegal string ...', '/var/www/proj...', 50, Array)
#2 /var/www/projet/www/core/modules/views/src/ViewExecutable.php(1011): Drupal\views\Plugin\views\area\Text->preQuery()
#3 /var/www/projet/www/core/modules/views/src/ViewExecutable.php(1233): Drupal\views\ViewExecutable->_preQuery()
#4 /var/www/projet/www/core/modules/views/src/Plugin/views/display/PathPluginBase.php(390): Drupal\views\ViewExecutable->build()
#5 /var/www/projet/www/core/modules/views/src/Plugin/views/display/Page.php(180): Drupal\views\Plugin\views\display\PathPluginBase->execute()
#6 /var/www/projet/www/core/modules/views/src/ViewExecutable.php(1630): Drupal\views\Plugin\views\display\Page->execute()
#7 /var/www/projet/www/core/modules/views/src/Element/View.php(77): Drupal\views\ViewExecutable->executeDisplay('page', Array)
#8 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array)
#9 /var/www/projet/www/core/lib/Drupal/Core/Render/Renderer.php(378): call_user_func(Array, Array)
#10 /var/www/projet/www/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
#11 /var/www/projet/www/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(226): Drupal\Core\Render\Renderer->render(Array, false)
#12 /var/www/projet/www/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#13 /var/www/projet/www/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(227): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#14 /var/www/projet/www/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(117): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#15 /var/www/projet/www/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#16 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#17 /var/www/projet/www/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#18 /var/www/projet/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent))
#19 /var/www/projet/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#20 /var/www/projet/www/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/www/projet/www/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/projet/www/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/projet/www/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/projet/vendor/asm89/stack-cors/src/Asm89/Stack/Cors.php(49): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/projet/www/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Asm89\Stack\Cors->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/projet/www/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/projet/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/projet/www/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/projet/www/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#30 {main}.

Applied on a drupal core 8.7.5. (paths in the log have been searched & replaced.) Database has been succesfully updated & caches rebuild.

I don't feel legitimate to change status to Needs work. Thanks for investigating.

this solved the issue :D
https://www.drupal.org/project/drupal/issues/3026229#comment-13272349

@netronicus
Editor still not display in my case on D8.7.8 after disabling/enabling the dblog module. :(

Bumping priority.

Patch #69 worked for me. Thanks!

1. +++ b/core/modules/dblog/dblog.install
   @@ -195,3 +195,34 @@ function dblog_update_8600() {
   +
   +/**
   + * Fixes the wrong plugin type introduced in dblog_update_8600().
   + */
   +function dblog_update_8701() {
   +
   +  $view = \Drupal::configFactory()->getEditable('views.view.watchdog');
   +  if (empty($view)) {
   +    return;
   +  }
   +
   +  $empty_text = $view->get('display.default.display_options.empty');
   

   This is a config rather than schema change, so it can be done in a hook_post_update_N().

   Also is there a reason it needs to act on the raw config rather than the views configuration entity?

2. +++ b/core/modules/dblog/tests/src/Functional/Update/DblogNoLogsAvailablePluginTypeUpgradeTest.php
   @@ -8,12 +8,12 @@
     * Test the upgrade path of changing the empty text area for watchdog view.
     *
   - * @see dblog_update_8600()
   + * @see dblog_update_8701()
     *
     * @group Update
     * @group legacy
     */
   -class DblogNoLogsAvailableUpgradeTest extends UpdatePathTestBase {
   +class DblogNoLogsAvailablePluginTypeUpgradeTest extends UpdatePathTestBase {
    
      /**
   

   Drupal 9 is going to remove updates up until 88** soon. I think it would be good for this test to run against one of the more up-to-date database dumps, updated to 8.8.0-alpha1, then re-dumped - then we know that database has the incorrect views config introduced in dblog_update_8600().

   Another way to approach this would be a fresh database dump but with the incorrect configuration.

Tagging as a requirement for Drupal 9.0-beta1.

Working on this one.

This moves the update into hook_post_update_NAME(), adds return messages to explain what happened and updates the @see line in DblogNoLogsAvailableUpgradeTest.php.

Still to do, per #78:

• Consider rewriting the update script to modify a view object instead of a config object; I'm not overly fussed about this as the original update script (8600) used a config object too.
• Rework DblogNoLogsAvailablePluginTypeUpgradeTest to test a db dump with a broken view to confirm it updated correctly.

I left in a 'use' statement while I was considering rewriting the update script, the only change in this patch over #83 is that it removes that one line.

Another minuscule change just to change quotes on a few return statements, so I'm not re-running the tests.

Still working on this.

The weird thing is that the drupal-8.8.0.bare.standard.php.gz fixture file includes the broken view already - the "empty" key in the display options has a single entry named "area" and not "area_text_custom".

So let's change the test to use the 8.8.0 bare standard file and add some more assertions on the view definition before & after the updates are run.

Leaving it back for someone to review.

1. +++ b/core/modules/dblog/config/optional/views.view.watchdog.yml
   @@ -654,7 +654,7 @@ display:
          footer: {  }
          empty:
   -        area:
   +        area_text_custom:
              id: area_text_custom
   

   Huh so the exported config is broken too?

2. +++ b/core/modules/dblog/dblog.post_update.php
   @@ -33,3 +33,35 @@ function dblog_post_update_convert_recent_messages_to_view() {
   +  // Only update the empty text if is untouched from dblog_update_8600 update.
   

   Nit: could use parentheses.

3. +++ b/core/modules/dblog/tests/src/Functional/Update/DblogNoLogsAvailableUpgradeTest.php
   @@ -8,33 +8,50 @@
   +    // Before the updates run, confirm that ¶
   

   Missing the end of this sentence.

4. +++ b/core/modules/dblog/tests/src/Functional/Update/DblogNoLogsAvailableUpgradeTest.php
   @@ -8,33 +8,50 @@
   +
   +    // Confirm the display's definition is correct.
   +    $area = $data['display']['default']['display_options']['empty']['area_text_custom'];
   

   Could we add deleting all the dblog entries and visiting admin/reports/dblog? Then the test only patch would show the PHP error.

1. Huh so the exported config is broken too?

   Yes, and the fixture is too, so should we include fixing that here too?

2. Nit: could use parentheses

   Missed this, will add it next time.

3. Missing the end of this sentence

   *whistles innocently*
   This updated patch fixes the comments, but I'm not going to run the tests or change the status as that's the only change.

4. Could we add deleting all the dblog entries and visiting admin/reports/dblog? Then the test only patch would show the PHP error.

   In theory the test-only patch would fail as-is, but that'd be another scenario to consider. Do we need to test both?

The fixture being broken is OK I think - that represents real 8.x data that we're upgrading to be fixed here. If we do a later dump (say a 9.0.0 dump), then it'll be with this update having been run and correct again.

#4 the test changes that the structure of the view has changed, but it looks similar to the original test coverage in that if our expectations were still wrong it could still pass I think? Whereas visiting the dblog page itself the view either loads or it doesn't.

Working on this.

So, something like this?

Whoops sorry about the typo.

I also moved the new test method to the DbLogViewsTest file, it seemed like the better option?

Could you upload a test-only patch too?

Tests-only.

Working on fixing the tests.

This fixes the tests locally. I also discovered that the class in DblogNoLogsAvailableUpgradeTest.php was named incorrectly.

+++ b/core/modules/dblog/tests/src/Functional/DbLogViewsTest.php
@@ -54,11 +54,41 @@ protected function filterLogsEntries($type = NULL, $severity = NULL) {
+
+    // Confirm the 'empty' message is displayed correctly.
+    $this->assertText('No log messages available.');
+  }
+

This test seems to be passing with the test-only patch, but it ought to be failing?

Also general note we decided at least for now that while critical, this bug shouldn't block the 9.0.x beta - because we're able to repair the data broken in the update (unlike other upgrade path bugs that leave the database unrecoverable). #3110367: [META] Beta blocking upgrade path bugs. So untagging but of course it'd be great to get this fixed asap regardless.

Ok, the weird thing is that if I add another text area plugin to the no results behavior portion the new plugin is given the machine name "area_1", indicating that the default name in 8.9.x for a text area plugin is "area", not "area_text_custom". Which suggests that this might be entirely wrong, and possibly superfluous.

If I add a "Text area" plugin to the no results section its machine name is "area", if I add an "Unfiltered text" plugin its machine name is "area_text_custom". So the problem might be made more confusing because of a bug/feature elsewhere in the Views system that loads Drupal\views\Plugin\views\area\Text for the area plugin named "area", even though that plugin's ID should be "text". Maybe?

I tested the patch and this resolved the issue for me. Not sure about the few latest comments though so might needs to go back to needs work.

@DamienMcKenna Thanks for working on this again!

If I add a "Text area" plugin to the no results section its machine name is "area", if I add an "Unfiltered text" plugin its machine name is "area_text_custom". So the problem might be made more confusing because of a bug/feature elsewhere in the Views system that loads Drupal\views\Plugin\views\area\Text for the area plugin named "area", even though that plugin's ID should be "text". Maybe?

In #2916898: Do not use basic_html text format for 'No log messages available.' message we changed from Text to Text Custom because the minimal profile doesn't creates the Filtered HTML text format. So I think area_text_custom is ok.

I've been following this problem since a long time, in the past week I tried to replicate it installing 8.5.15 and running the upgrade installing the site in Spanish without success. The only result I managed to get was a non translated string.

But reading again the entire thread I managed to get a clean replicate path:

git checkout 8.5.5
drush si standard --account-pass=admin --locale=es
git checkout 8.6.0
composer install
drush updb
// Login and save the watchdog views as is, this will trigger a fatal error and dblog 

I'm afraid none of the tests try this scenario, and this is why https://www.drupal.org/project/drupal/issues/2998103#comment-13455097 passes.

Then the rest is testing:

git checkout 8.9.x
curl https://www.drupal.org/files/issues/2020-02-06/drupal-n2998103-103.patch | git apply -
drush updb

Fixes the problem, so at least we can be sure that user testing was done.

But interestingly there is another way to replicate this:

git checkout 8.9.x
drush si standard --account-pass=admin --locale=es
// Login, edit the watchdog view, remove the empty text area filter, and add a Filtered HTML text instead. 
// Save the view, and you get exactly the same result.

This is the trace-back:

InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() (line 738 of core/lib/Drupal/Core/Database/Connection.php).

Drupal\Core\Database\Connection->query('UPDATE {locales_target} SET translation=:db_update_placeholder_0, customized=:db_update_placeholder_1
WHERE (lid = :db_condition_placeholder_0) AND (language = :db_condition_placeholder_1)', Array, Array) (Line: 357)
Drupal\Core\Database\Driver\mysql\Connection->query('UPDATE {locales_target} SET translation=:db_update_placeholder_0, customized=:db_update_placeholder_1
WHERE (lid = :db_condition_placeholder_0) AND (language = :db_condition_placeholder_1)', Array, Array) (Line: 148)
Drupal\Core\Database\Query\Update->execute() (Line: 395)
Drupal\Core\Database\Query\Merge->execute() (Line: 508)
Drupal\locale\StringDatabaseStorage->dbStringUpdate(Object) (Line: 125)
Drupal\locale\StringDatabaseStorage->save(Object) (Line: 185)
Drupal\locale\StringBase->save() (Line: 109)
Drupal\locale\TranslationString->save() (Line: 224)
Drupal\locale\LocaleConfigSubscriber->saveCustomizedTranslation('views.view.watchdog', 'No log messages available.', '', Array, 'es') (Line: 156)
Drupal\locale\LocaleConfigSubscriber->processTranslatableData('views.view.watchdog', Array, Array, 'es', Array) (Line: 153)
Drupal\locale\LocaleConfigSubscriber->processTranslatableData('views.view.watchdog', Array, Array, 'es', Array) (Line: 153)
Drupal\locale\LocaleConfigSubscriber->processTranslatableData('views.view.watchdog', Array, Array, 'es', Array) (Line: 153)
Drupal\locale\LocaleConfigSubscriber->processTranslatableData('views.view.watchdog', Array, Array, 'es', Array) (Line: 153)
Drupal\locale\LocaleConfigSubscriber->processTranslatableData('views.view.watchdog', Array, Array, 'es', Array) (Line: 153)
Drupal\locale\LocaleConfigSubscriber->processTranslatableData('views.view.watchdog', Array, Array, 'es', Array) (Line: 122)
Drupal\locale\LocaleConfigSubscriber->updateLocaleStorage(Object, 'es') (Line: 85)
Drupal\locale\LocaleConfigSubscriber->onConfigSave(Object, 'config.save', Object)

My guess is because the configuration provided by the yaml incontent: is a string but the basic filter html is provides an array, the LocaleConfigSubscriber confuses everything.

So it seems there is another bug around the locale module that may not be related to views or dblog after all. I'm pretty sure this can affect any configuration that changes from a string of the form content: to something like:

content:
  value:
  format:

I did the following...

• Installed 8.5.16-dev site with "standard" profile and English language.
• Enabled French and German.
• Loaded /fr/admin/reports/dblog, confirmed it loaded correctly.
• Cleared the dblog, loaded /fr/admin/reports/dblog again, confirmed it still worked.
• Exported the site's database.
• Imported the database into a codebase that had 8.6.19-dev.
• Ran the database updates, including dblog_update_8600.
• Logged into the 8.6 site.
• Loaded /fr/admin/reports/dblog, confirmed it loaded correctly.
• Cleared the dblog, loaded /fr/admin/reports/dblog again, it loaded correctly.

Is there a step I missed in order to trigger the problem?

@DamienMcKenna you need to save the watchdog view to trigger the translation process.

I just did that, but it didn't trigger the error?

@DamienMcKenna ah, sorry, you need to install the site in a different language than English. When installing the site choose some other language.

@dagmar: Doesn't that just change what the default language is? Or is there more to it than that?

@dagmar: Doesn't that just change what the default language is? Or is there more to it than that?

@DamienMcKenna I'm not 100% sure about the internals of the two options. I know that installing the site in another language also install a few extra translation modules out of the box.

l just tried your approach and indeed the bug cannot be reproduced if you install the site in English. It seems the trick is to install the site in a different language than English. It doesn't even need to be multilingual.

1. So re #113 it seems like the test coverage we need is to do an UpdateTest with the install being in different language.
2. I don't think we have a fixture that provides this yet. Does anyone know if we do or if an example of an update test where Core was originally installed in different language?
3. If we need to make a new fixture what would recommend core version to make this from?

I trying to reproduce the problem but I can't

I am following the instructions that @dagmar wrote in #108

See his instructions directly after

But reading again the entire thread I managed to get a clean replicate path:

1. I have tried using both sqlite and mysql.
2. I have tried not going to admin/reports/dblog first before I saved the view
3. I have tried not using drush but instead doing everything through the UI.
4. Right now I am using PHP Version 7.2.23. I thought about switching to 5.6 but I assume @dagmar would have mentioned that since commented just a month ago and php 5.6 is already deprecated.

The only way I can get a fatal error is to try to save the view without running database updates.

We need an issue summary update with instructions to reproduce this problem. If it is the instructions from #108 will still need the issue summary update and try to get someone else to reproduce the problem on test site not a real so we can narrow down what the problem is.

Update to #118

I am now able to now reproduce the error installing drupal in another language.

Here are my steps similar to @dagmar's steps in #108

1. git checkout 8.5.5
2. drush sql-drop
3. rm -rf vendor && composer install
4. drush si standard --account-pass=admin --locale=es
5. sign-in in the web
6. git checkout 8.6.0
7. rm -rf vendor && composer install
8. run update.php via web
9. goto admin/reports/dblog
10. edit and save the view

The last step will get the error

El sitio web encontró un error inesperado. Vuelva a intentarlo más tarde.InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() (line 729 of core/lib/Drupal/Core/Database/Connection.php).

Drupal\Core\Database\Connection->query('UPDATE {locales_target} SET translation=:db_update_placeholder_0, customized=:db_update_placeholder_1
WHERE (lid = :db_condition_placeholder_0) AND (language = :db_condition_placeholder_1)', Array, Array) (Line: 148)

  // Only update the empty text if is untouched from the original version.
  if ($empty_text['area']['id'] == 'area' &&
      $empty_text['area']['plugin_id'] == 'text' &&
      $empty_text['area']['field'] == 'area' &&
      $empty_text['area']['content']['value'] == 'No log messages available.') {

The last condition does not pass when installing in Spanish $empty_text['area']['content']['value'] == 'No log messages available.' will not true because this actually has the Spanish translation.

So there might another problem going on here

follow up to #119.

I am now able to reproduce the error saving the Watchdog view with an English install. It involves switching the language and updating the view after install.

Rather than listed the steps I am attaching the script I am using to reproduce. It is mostly an automated script but has points that needs user action.

I am working on writing update test for this but have not succeed yet.

If I use this script but instead of
git checkout 8.9.x
to run the updates I switch branch patched with the file in #102 it does not get the error. So at least for manual testing this proves it fixes the problem, though it would be great if others could confirm.

I am not assigning this to myself because I don't want to stop anyone else from working on tests for this.

This issue was covering 2 problems that appear to happen in the update 8.6.0 and possibly involving dblog_update_8600() and a site was installed with a language beside English

1. The user simply went to admin/reports/dblog and encountered an error
2. The user tries to edit the watchdog View at admin/reports/dblog and encountered an error

the issue summary for this describes 1). 2) is probably related but is different view but I guessing affects less people because it would only affect users that were actually editing the view.

So split off 2) into #3125425: Error saving watchdog view after dblog_update_8600()

I think we should handle 1) in this issue.

When the "Recent Log Messages" page was converted to a view, it used the "Text area" handler.
id: area
As seen in views.views.inc (currently lines 59-65), that handler definition corresponds to \Drupal\views\Plugin\views\area\Text
That plugin expects there to be a content array containing the value key.
See https://github.com/drupal/drupal/blob/8.8.x/core/modules/views/src/Plugi...

That is also what shipped in 8.5: https://github.com/drupal/drupal/blob/8.5.x/core/modules/dblog/config/op...

After #2916898: Do not use basic_html text format for 'No log messages available.' message, this view was changed to no longer use the Basic HTML format, and by doing so, switched the handler to "Unfiltered text".
id: area_text_custom
As seen in views.views.inc (currently lines 67-73), that handler definition corresponds to \Drupal\views\Plugin\views\area\TextCustom
That plugin expects there to be a content string.
See https://github.com/drupal/drupal/blob/8.8.x/core/modules/views/src/Plugi...

And this is what shipped afterward: https://github.com/drupal/drupal/blob/8.8.x/core/modules/dblog/config/op...

The config presented in #15 (and confirmed by others) could never have existed without some developer interaction. dblog_update_8600() correctly performed the updates. And here's the key point: even if that update never ran, nothing would be broken.

The only way for things to be broken is if the content key were changed and the id/plugin_id didn't, or vice versa.
In either the old or new set of config, nothing would be broken.

My theory is that the broken config resulted from an incorrectly resolved merge conflict when exporting config.

The reproducible bug that @tedbow describes in #121 is unrelated to the bug as originally described, so +1 to splitting that off.
Based on all of the above, I am downgrading this to a normal bug.

Oh, one other thought. The fact that key is still area even though the handler ID is area_text_custom is not a problem. Those key names are not used literally. If you add multiple "Text area" plugins you will get keys like area, area_1, area_2 etc.

Hello,

On a D8 migrated to D9 latest I have the same bug.

Sorry for my beginner question, but by uninstalling Database logging, wouldn't it also remove the faulty view, and when reactivating the module, the view would be rebuilt with the right criteria, or am I wrong?

Regards

On a D9 latest I have the same bug.

UP. Fix by edit views

Is this still an issue? Those 8.6 updates are long removed now

It's still an issue, the update can corrupt the view if English isn't the default language, resaving the view repairs it.

There are two groups of sites potentially affected:

1. Sites where English isn't the default language that have already updated from Drupal < 8.6, but then have never resaved the view. There is no way to know how many of those sites exist.

2. Sites where English isn't the default language that are still on Drupal < 8.6 (less than 10-15,000 sites with any language configuration) that haven't run the update yet, and will need to update to Drupal 8.9, then from there to Drupal 9.

If we wanted to fix it for either group, the only way now would be to add a new update to Drupal 9 that repairs the view from the broken state that can be introduced in dblog_update_8600() but leaves it untouched for sites where it's correct.

It's definitely true that it's a 'normal' bug compared to almost any other upgrade path bug, only affects the one page, fixable by resaving the view. It's also the case that the number of sites affected is small and diminishing. All these are why it hasn't been fixed yet, but to close the issue I think we'd need to either fix it, or explicitly decide that we're never going to.

IS update.

#121 states two cases, and that this issue is for case 1 and the other issue is for case 2. But the Issue Summary here is for case 2 as are many of the comments. Case 2 (the Placeholder error) is in #3125425: Error saving watchdog view after dblog_update_8600(). This issue concerns the "Warning: Illegal string offset 'value' in Drupal\views\…".

Using #122 I found a way to reproduce this error and then did some testing.

1. Alter the config to force the error
2. A re-save of the view did not fix the problem.
3. I edited the empty text area and on save get the Placeholder error message for Case 2. I
4. I removed the empty text area, saved, and no errors.
5. I edited the view again and re-added the text area, without entering any data, on save I got the error for Case 2.
6. I applied the patch from #103
7. I reloaded the view edit page and saved, this time no errors.

Maybe we should be treating these two issues the same and work with the patch from #103?

More testing and I have discovered that there is still a problem with the 'text area' plugin in the 'No Results behavior' section on Drupal 9.4.x, Italian standard install. If the plugin is deleted and then re-added a Notice is logged. A bit of improvement from an Error or a Warning ;-)

Messaggio Notice: Array to string conversion in Drupal\Core\Database\StatementWrapper->execute() (line 145 of /var/www/html/core/lib/Drupal/Core/Database/StatementWrapper.php)

I have given it some thought and I am going to close #3125425: Error saving watchdog view after dblog_update_8600() as a duplicate. I found that I could fix the Case 2 error but then I would get the error in Case 1 (this issue). But more importantly the fix is the same.

Added a workaround to the IS.

Added a change record that includes the steps to repair this problem.

Discussed with xjm and catch in Slack. It was pointed out that the update, dblog_update_8600(), is no longer in a supported version of Drupal. And if a site can't update because of this problem there are steps that can be done from the UI to repair it. The steps are in this issue summary and the change record. Therefor since there is a path forward and no one is actually prevented from updating this can be closed.

Thanks!

#29 worked for me. Thx.

Why not overwrite the views.view.watchdog.yml with the default one from D10 by example and import it :
https://api.drupal.org/api/drupal/core%21modules%21dblog%21config%21opti...

Indeed, #140 is a very simple solution.

Thank you for the solution!