🇩🇰Denmark @Uv516

I don't have the tools or capacity to do more research when I can see such a simple solution to the problem.
In addition to the comments given to me, it would be nice to have an answer to the question I asked in #22
and it would be nice to know what is wrong with patch #7 that fixes the problem?

The error about deprecated function: Creation of dynamic property is comming because the latest release of at_tools have made "corrections" whit wrong spelling.
Eg. is $layout_library set as "$layoutLibrary". It gives 2 errors (upper/lower case + missing underline).
Today I had to fix them all after updating to v. 6.1.

Uv516 → created an issue.

I had the same problem:
Drupal 10.2.5, Adaptivetheme

My settings:

[x] Collapse all tabs by default
[ ] Keep accordion rows open when opening another one
[x] Animate accordion open / close
[ ] Open tabs with hash using anchor links or on page load

The patch in #3 helped me.

I got the error as descriped in attached file. It handles about the field "tagert_id_string" which doesn't have a default value.
After a lot of searching I found the error and the solution:
In MySQL under entity_usage I inspected the table.
The field "target_id_string" is created with no NULL-value and no default value.
The field can not have at NULL-value, but it MUST have at default value.
I set (in) 0 as the default value and that solved my problem.

From the patch:

+  $database->update('entity_usage')
+    ->fields(['target_id_string' => ''])
+    ->condition('target_id_string', NULL, 'IS NULL')
+    ->execute();

I think that line 3 ('->condition('target_id_string', NULL, 'IS NULL')') should be different?

On Drupal 10.2.5, PHP 8.2.17, MySQL db 8.0.36-28:

I have a similar problem, but it's not because I imported the database.
When searching on Google, I have seen that the error can occur when the site is a subsite of another site. That is exactly the case for me.
I have tested two sites that are subsites and two other sites that are main sites.
On my subsites the problem occurs, but on my main sites there is no problem. (The provider is the same: Simply.com).
I have attached a file with error examples similar to the above.

Uv516 → created an issue.

I've just updated to Drupal version 7.100.
To my dismay, I find that the same error that has now existed for 5 years still exists despite the fact that the fix is so simple.

I am not able to enable stable9. I am using stabel (D8). How can I enable stable9?
at_core is in themes\contrib\adaptivetheme\

Just as told in #2

Uv516 → created an issue.

In both Adaptivetheme (5.2) ( https://www.drupal.org/project/adaptivetheme → ) and in AT Tool 2.0 ( https://www.drupal.org/project/at_tool → ) there is confusion about reference to "at_tool" and "at_tools" .
In my Rapid PHP 2022 I chose to search for ALL occurrences of "at_tools" to replace them with "at_tool". (YES, a very ugly method, but it worked!)
After first running "Flush all caches" and then update.php, it now seems that the problems are solved for this time.

The bug is not completely fixed in version 3.0.1.
The call "paragraphs_sets_paragraphs_set_load" must be corrected everywhere and thus also in line 589:

/**
 * Helper function to load a paragraphs set.
 *
 * @param string $name
 *   Name (ID) of paragraphs set.
 *
 * @return \Drupal\paragraphs_sets\Entity\ParagraphsSet
 *   The loaded set or NULL if no set with the given name exists.
 */
function paragraphs_sets_load_paragraphs_set($name) {
  return ParagraphsSet::load($name);
}

// @codingStandardsIgnoreStart
/**
 * Helper function to load a paragraphs set.
 *
 * @param string $name
 *   Name (ID) of paragraphs set.
 *
 * @return \Drupal\paragraphs_sets\Entity\ParagraphsSet
 *   The loaded set or NULL if no set with the given name exists.
 * @deprecated in version 3.0.0 and will be removed in future versions.
 */
function paragraphs_set_load($name) { /* Line 588 */
-  return paragraphs_sets_paragraphs_set_load($name);
+  return paragraphs_sets_load_paragraphs_set($name);
}

Uv516 → created an issue.

I have updated AdaptiveTheme to v. 8.x-5.2 and today I updated Drupal to v. 10.2.2 (PHP v. 8.2.15).
I got similar errors as above:
Deprecated: Creation of dynamic property Drupal\at_core\Layout\Layout::$layout_path is deprecated in /var/www/[my_site]/themes/contrib/adaptivetheme/at_core/src/Layout/Layout.php on line 27

The same error for $layout_cid.
I added line 17 and 18:

  protected $layout_path; // <- new 2024-01-21
  protected $layout_cid; // <- new 2024-01-21

All variables in a class should be forwarded.

renatog: You asked me 2 questions and I gave an answer for the both:
2) No: No bootstrap (I don't use bootstrap, so I can't give you the version.

As I told from the beginning:
When I install Modal, the module list gets distorted. Look at the pictures.
After installing Modal, I can't use the module list and the Module filter.

Do you think that it is "normal".

Which info do you wish?

1) Not "Modal filter", but "Module filter" (look at the pictures)
2) No: No bootstrap
I am using Adaptive Theme / ThemeKey

I cannot use Modal for now.

Uv516 → created an issue.

I wonder how it must be so difficult to solve a problem that seems so small.

What is the difference between and what significance do these two options have:
$widget[#file] == FALSE
or
empty($widget[#file])

Using $widget[#file] == FALSE requires $widget[#file] to exist to avoid a warning.

If you use empty($widget[#file]), the result will apparently be the same, even if $widget[#file] does not actually exist.

See attached documentation: "Uv516 #22 documentation for error.pdf"

Here we are again.
Just updateted to Drupal 7.99 and the error comes again.

Is it a problem to follow #13 in next update?

When I disable "Aggregate JavaScript files",the problem persists.
When I disable "Aggregate CSS files", the problem is gone!

The "Aggregate JavaScript files" can be disabled or enabled: No effect on the problem.

isn't that a pretty significant problem?

Uv516 → created an issue.

Both points are "feature requests".

I guess User Import checks the columns one by one and reads the first line (the header) of each column.
In any case, User Import lists the individual column headers and can be linked to the actual field names.
If there was no header in each column, you could choose to combine column number NN with field db_NN, etc.
When a csv file contains headings in the first line, it will be the headings and not the column numbers that appear as column NN(heading)
I don't know if User Import has a lot of weird code for that, but it should be doable.

(I can suggest installing User Import in the D7 and as a general user check out the good facilities that are there.)

In my organization, overwriting user data can be fatal. I wouldn't say "Nice to have" but "Practical to have" as it has also been a time saver.

I have just tested User CSV Import. There is no doubt that it is useful, but…

Field names in the db are required and cannot be changed. Field names (headers) in csv file can be very different, not necessarily field names, but simply "Name", "Address", "Phone", etc.
I often receive csv files with many names that are either new to the db or just updated. The csv files come from different companies that (believe me) have very different attitudes about column header names.
In User CSV Import, I have to teach my staff raw field names in advance instead of asking them to concatenate column headers with the db's field names.
It is inappropriate and time-consuming to have to go through that process. This is what was better in User Import and what is desired in User CSV Import.
I expect "name" to be unique as well. It will be difficult for the office staff to see through it.
In User Import, username (name) could be formed from the user's name. (Also wish for feature).

In User Import there was a test of whether users who are already in the db were imported. If that were the case, one could e.g. manage to exclude (or accept) these users.

See 3397444 ✨ Two extra features Active

See 3397444 ✨ Two extra features Active

Uv516 → created an issue.

I think gisle 💬 Offering to maintain User Import Active should be allowed to comment more on that. He has obviously been waiting for an answer from me.
Please do not close the topic again immediately.

The wish was to get a D10 version of User Import. We have not reached that, so I don't think you can close the debate while there is someone who wants to do something about it. I started the debate in 3260353 🌱 Version for Drupal 9/10 Active , but I'm not a developer. I've done some research but need others to do the work for it to be useful.

Sorry! I am in a long process of creating several new pages based on D10. I have not seen gisle's comment on this page.
gisle 💬 Offering to maintain User Import Active : You are very welcome to use the things I have suggested. I myself do not have enough knowledge to be the owner or maintainer of the project.

User Import has, among other things, these advantages, which none of the proposed modules have shown:

• The field names in the csv files do not have to be exact, but can be plain text as headers. In User Import, the names will be compared with existing field names, and you can designate which fields (columns) you want to import.
• User Import can check existing users against the information being imported to avoid problems with data for existing users.

Alternative patch. I think it's more safe.

Mohd Sahzad 🐛 Attempt to read property uid [nid] on bool Needs review : I think your patch doesn't ensure that "$submission->uid", "$submission->sid" and "$node->uid" exist?
How is your patch better than the two suggestions I gave?:
$access_own_submission = !empty($submission) && !empty($submission->uid) && !empty($submission->sid) && user_access('access own webform submissions', $account) && (($account->uid && $account->uid == $submission->uid) || isset($_SESSION['webform_submission'][$submission->sid]));
and
$access_node_submissions = !empty($node->uid) && user_access('access own webform results', $account) && $account->uid == $node->uid;

Uv516 → created an issue.

Uv516 → created an issue.

Uv516 → created an issue.

Uv516 → created an issue.

I have problems too. I haven't got any error, but the sub themes can not see at_core, and the sub themes "are not" combatible with Drupal 10.
Solution:
1) Install theme Stable [composer require 'drupal/stable:^2.0']
2) Don't activate Stable
3) Create sub theme with AT Theme Generator
4) The sub theme has core_version_requirement: '^8 || ^9'. Edit the line to core_version_requirement: '^8 || ^9 || ^10'
That's how far I've come to solve the problem.

See https://www.drupal.org/project/adaptivetheme/issues/3331762 💬 Not able to install a subtheme in Drupal 10 Active

I can not run update.php with version 3.3.1 because of error:

1. Update via composer
2. Run update.php
Result: Error!

I don't use Drush but Composer with -W

Uv516 → created an issue.

Uv516 → created an issue.

Same problem here...

I have other modules where I have used the same changes as #13.

If you check $variable['test'] == FALSE, the $variable['test'] must exists, but
if you check !empty($variable['test']), the $variable['test'] may og may not exists.

In my case I have tested

foreach ($widgets as $key => &$widget) {
    if (empty($widget['#file'])) {

I get two $key: [0] and [1].
The [0]-key is the node itself. The $widgets['#file'] IS there.
The [1]-key is about one field in the node. The field is a file field and the $widgets['#file'] is NOT there.
See the screendump code ("file-error.txt")
I wonder if no other fields is mentioned in this - or why the only one field "field_ny_bilag" is mentioned in this.
When I yse "!empty" there is no error.

Just updated to version 7.97.
The issue is still there. - Why?
The patch from #13 🐛 Notice: Undefined index: #file in theme_file_widget_multiple() (line 838 of /public_html/modules/file/file.field.inc Needs work works fine.
Why could it not be implemented in core?

EXACTLY!
I did as descriped as referenced in #4 🐛 Field reference do not use order (asc,desc) that done in views reference Fixed !
Now it works again.

I think that the team should look at the code again. It is fine to save performance, but not at the expense of sorting.

Ok. If I (in the fields UI) use Entity selection -> Mode -> Simple (with optional filter by bundle) and set it to the bundle, the list is sorted correctly.
But if I use Entity selection -> Mode -> Views: Filter by an entity reference view, the list is unsorted. As mentioned the admin views list is sortet correctly.
The problem is the same in alle entity reference fields on the site.
I have other sites without the probelm (as far as I know).
Could it be a core stuff or could it be a code errors in my code? What could smash the sort?

Uv516 → created an issue.

I have tried to show the CF i Views without luck.

I have run dpm($entity) from hook_entity_presave.
In the test node I have one CF and one text field (long formatted).
The CF is named "computed_cf_lang_tekst"
The text field is named "field_langt_tekstfelt"
Note that the field "field_langt_tekstfelt" does NOT appear under #values. Is this an issue?
In the field field_langt_tekstfelt->x-default->list[0] there is some data (see below). In the field computed_cf_lang_tekst->x-default->list this is empty. Is this an issue?

#entityTypeId: "node"
#enforceIsNew: null
#typedData: Drupal\Core\Entity\Plugin\DataType\EntityAdapter {#1906 ▶}
#cacheContexts: []
#cacheTags: []
#cacheMaxAge: -1
#_serviceIds: []
#_entityStorages: []

  #values: array:22 [▼
    "nid" => array:1 [▶]
    "vid" => array:1 [▶]
    "type" => array:1 [▶]
    "uuid" => array:1 [▶]
    "langcode" => array:1 [▶]
    "revision_uid" => array:1 [▶]
    "revision_timestamp" => array:1 [▶]
    "revision_log" => array:1 [▶]
    "revision_default" => array:1 [▶]
    "isDefaultRevision" => array:1 [▶]
    "status" => array:1 [▶]
    "uid" => array:1 [▶]
    "title" => array:1 [▶]
    "created" => array:1 [▶]
    "changed" => array:1 [▶]
    "promote" => array:1 [▶]
    "sticky" => array:1 [▶]
    "default_langcode" => array:1 [▶]
    "revision_translation_affected" => array:1 [▶]
    "body" => array:1 [▶]
    "field_langt_tekstfelt" => array:1 [▶]
    "original" => Drupal\node\Entity\Node {#2160 ▶}

#fields: array:22 [▼
    "revision_log" => array:1 [▶]
    "changed" => array:1 [▶]
    "body" => array:1 [▶]
    "created" => array:1 [▶]
    "field_langt_tekstfelt" => array:1 [▶]
    "langcode" => array:1 [▶]
    "path" => array:1 [▶]
    "promote" => array:1 [▶]
    "status" => array:1 [▶]
    "sticky" => array:1 [▶]
    "title" => array:1 [▶]
    "uid" => array:1 [▶]
    "vid" => array:1 [▶]
    "type" => array:1 [▶]
    "nid" => array:1 [▶]
    "uuid" => array:1 [▶]
    "revision_timestamp" => array:1 [▶]
    "revision_uid" => array:1 [▶]
    "default_langcode" => array:1 [▶]
    "revision_default" => array:1 [▶]
    "revision_translation_affected" => array:1 [▶]
    "computed_cf_lang_tekst" => array:1 [▶]

#fieldDefinitions: array:22 [▼
    "nid" => Drupal\Core\Field\BaseFieldDefinition {#1145 ▶}
    "uuid" => Drupal\Core\Field\BaseFieldDefinition {#1167 ▶}
    "vid" => Drupal\Core\Field\BaseFieldDefinition {#1170 ▶}
    "langcode" => Drupal\Core\Field\BaseFieldDefinition {#1173 ▶}
    "type" => Drupal\Core\Field\BaseFieldDefinition {#1176 ▶}
    "revision_timestamp" => Drupal\Core\Field\BaseFieldDefinition {#1178 ▶}
    "revision_uid" => Drupal\Core\Field\BaseFieldDefinition {#1182 ▶}
    "revision_log" => Drupal\Core\Field\BaseFieldDefinition {#1186 ▶}
    "status" => Drupal\Core\Field\BaseFieldDefinition {#1190 ▶}
    "uid" => Drupal\Core\Field\BaseFieldDefinition {#1195 ▶}
    "title" => Drupal\Core\Field\BaseFieldDefinition {#1199 ▶}
    "created" => Drupal\Core\Field\BaseFieldDefinition {#1202 ▶}
    "changed" => Drupal\Core\Field\BaseFieldDefinition {#1206 ▶}
    "promote" => Drupal\Core\Field\Entity\BaseFieldOverride {#1241 ▶}
    "sticky" => Drupal\Core\Field\BaseFieldDefinition {#1215 ▶}
    "default_langcode" => Drupal\Core\Field\BaseFieldDefinition {#1220 ▶}
    "revision_default" => Drupal\Core\Field\BaseFieldDefinition {#1226 ▶}
    "revision_translation_affected" => Drupal\Core\Field\BaseFieldDefinition {#1232 ▶}
    "path" => Drupal\Core\Field\BaseFieldDefinition {#1238 ▶}
    "computed_cf_lang_tekst" => Drupal\computed_field\Entity\ComputedField {#1242 ▶}
    "body" => Drupal\field\Entity\FieldConfig {#1243 ▶}
    "field_langt_tekstfelt" => Drupal\field\Entity\FieldConfig {#1244 ▶}

-------------

 "field_langt_tekstfelt" => array:1 [▼
      "x-default" => Drupal\Core\Field\FieldItemList {#2102 ▼
        #definition: Drupal\field\Entity\FieldConfig {#1244 ▶}
        #name: "field_langt_tekstfelt"
        #parent: Drupal\Core\Entity\Plugin\DataType\EntityAdapter {#1906 ▶}
        #_serviceIds: []
        #_entityStorages: []
        #stringTranslation: null
        #typedDataManager: Drupal\Core\TypedData\TypedDataManager {#218 ▶}
        #list: array:1 [▼
          0 => Drupal\text\Plugin\Field\FieldType\TextLongItem {#2107 ▼
            #definition: Drupal\Core\Field\TypedData\FieldItemDataDefinition {#1426 ▼
              #definition: array:2 [▶]
              #typedDataManager: Drupal\Core\TypedData\TypedDataManager {#218 ▶}
              #fieldDefinition: Drupal\field\Entity\FieldConfig {#1244}
            }
            #name: 0
            #parent: Drupal\Core\Field\FieldItemList {#2102}
            #_serviceIds: []
            #_entityStorages: []
            #stringTranslation: null
            #typedDataManager: Drupal\Core\TypedData\TypedDataManager {#218 ▶}
            #values: array:2 [ …2]
            #properties: array:2 [ …2]
          }
        ]

computed_cf_lang_tekst" => array:1 [▼
      "x-default" => Drupal\computed_field\Field\ComputedFieldClass {#2152 ▼
        #definition: Drupal\computed_field\Entity\ComputedField {#1242 ▶}
        #name: "computed_cf_lang_tekst"
        #parent: Drupal\Core\Entity\Plugin\DataType\EntityAdapter {#1906 ▶}
        #_serviceIds: []
        #_entityStorages: []
        #stringTranslation: null
        #typedDataManager: Drupal\Core\TypedData\TypedDataManager {#218 ▶}
        #list: []
        #langcode: "da"
        #valueComputed: false
      }

return [$value] (as array)
instead of return $value.
See #40

@joachim: Thank you for your very quick response.

I think I have reached the goal of plugins for CF. After all, there are some things to do after the plugin is created with MB. It is not all that is described (well enough) in the Readme.
I need several different Computed Fields and thus also several different plugins. Furthermore, it is very rare that I reuse a computed field and therefore it will probably also be rare that I reuse a plugin.
On one of my sites I have more than 200 unique computed fields, so there will be something to upgrade from version 3.x to 4.x.
I have tried to make a session of CF with multiple fields. It looks like with one session/module I can have all the CF plugins I want.
Isn't it correct?

For a simple series of plugins for CF, I'd like to make a tutorial that's a bit more educational than the Readme. What do you say to that, @joachim?

Is it correct that CF never stores values in the database but calculates them for each call?
What is possibly the setting for CF to store values in the database?

My first success (with modifications).
I have made my plugin with MB and compared with @joachim's "TestString.php".

"TestString.php" has:

/**
 * Computed field which outputs a simple string.
 *
 * @ComputedField(
 *   id = "test_string",
 *   label = @Translation("Test string"),
 *   field_type = "string",
 * )
 */

My plugin has:

/**
 * TODO: class docs.
 *
 * @ComputedField(
 *   id = "cbm_cf3_cf3a",
 *   label = @Translation("Cf3a"),
 *   field_type = "long_text", // Try something else
 *   no_ui = "TODO: replace this with a value", // I change this value to FALSE to show up in node.
 *   attach = {
 *     "TODO" = "array values", // What is this for? Which values could I set?
 *   },
 * )
 */

"TestString.php" has:
use Drupal\computed_field\Plugin\ComputedField\SingleValueTrait;
and
use SingleValueTrait;
I don't have this... - What is it for? - Should I need it?

"TestString.php" has:

  public function singleComputeValue(EntityInterface $host_entity, ComputedFieldDefinitionWithValuePluginInterface $computed_field_definition): mixed {
    return 'cake!';
  }

My plugin has:

  public function computeValue(EntityInterface $host_entity, ComputedFieldDefinitionWithValuePluginInterface $computed_field_definition): array {
    // Returns the value for a computed field.
    return ['cake']; // Need to be an array (of long_text). @joachim's function is "mixed" and return a string; - HOW is this made in MB?
  }

Notice that my plugin has "computeValue" and not "singleComputeValue" and my type is array instead of mixed. How to control it in MB?

My CF is working!
But I still have many questions about both CF and MB...

@wxman: It is similar to "test_computed_field_plugins" (from CF), but you also have a module-file. It is not needed.
Is your plugin made with MB or just a copy of "test_computed_field_plugins"?

Now I have added a plugin (computed_field).
Se the files.
Create a new CF in my testnode: My new plugin is not shown!

@joachim: Could you make a small, educational manual that we can follow. I think it would make a big difference.
I think it can be done in minutes, instead of us spending days trying to find a solution (while consuming your time).

I have listed what I have done in Module Builder before I tried to create a Computed Field, see "Computed Field.pdf"
The result is shown in the file "cbm_cf.zip".
@joachim: Will you try a look and tell os, what I/we is missing.

I have exactly the same problem.

I have tried to make a module/plugin to CF with MB.
My module and CF is installed/enabled.
When I append a CF, I only see 'Reverse ...' as wxman.
Should I do something more before I can see the plugin in CF?

Uv516 → created an issue.

I have used patch #4, but I still have this message:

User warning: The following theme is missing from the file system: ckeditor in Drupal\Core\Extension\ExtensionPathResolver->getPathname() (line 63 of core/lib/Drupal/Core/Extension/ExtensionPathResolver.php).
Drupal\Core\Extension\ExtensionPathResolver->getPathname('theme', 'ckeditor') (Line: 85)
Drupal\Core\Extension\ExtensionPathResolver->getPath('theme', 'ckeditor') (Line: 123)
Drupal\Core\Asset\LibraryDiscoveryParser->buildByExtension('ckeditor') (Line: 87)
Drupal\Core\Asset\LibraryDiscoveryCollector->getLibraryDefinitions('ckeditor') (Line: 66)
Drupal\Core\Asset\LibraryDiscoveryCollector->resolveCacheMiss('ckeditor') (Line: 149)
Drupal\Core\Cache\CacheCollector->get('ckeditor') (Line: 44)
Drupal\Core\Asset\LibraryDiscovery->getLibrariesByExtension('ckeditor') (Line: 58)
Drupal\Core\Asset\LibraryDiscovery->getLibraryByName('ckeditor', 'drupal.ckeditor') (Line: 68)
Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies(Array, Array) (Line: 70)
Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies(Array) (Line: 41)
Drupal\Core\Asset\LibraryDependencyResolver->getLibrariesWithDependencies(Array) (Line: 104)
Drupal\Core\Asset\AssetResolver->getLibrariesToLoad(Object) (Line: 116)
Drupal\Core\Asset\AssetResolver->getCssAssets(Object, 1) (Line: 312)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object, Array) (Line: 158)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object) (Line: 94)
Drupal\big_pipe\Render\BigPipeResponseAttachmentsProcessor->processAttachments(Object) (Line: 45)
Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object, 'kernel.response', Object)
call_user_func(Array, Object, 'kernel.response', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.response') (Line: 202)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1) (Line: 190)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 713)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Uv516 → created an issue.

I have installed v 2.0.x-dev, but the configuration is still not persistent.
(I have emptied cache and run update.php before this post.)

Uv516 → created an issue.