Problem/Motivation

The latest version of the JPCOAR schema that I'm trying to implement has a Metadata Prefix of jpcoar_1.0. Because mapping config is being saved into config using the prefix from the annotation as the config key, attempting to save with jpcoar_1.0 as one of the potential sets, causes the following error:

Drupal\Core\Config\ConfigValueException: jpcoar_1.0 key contains a dot which is not supported. in Drupal\Core\Config\ConfigBase->validateKeys() (line 211 of core/lib/Drupal/Core/Config/ConfigBase.php).

I'm not yet able to propose a solution, but I guess either escaping the mapping key on the way in and unescaping on the way out of config, or changing the data structure so that the key does not have to be the metadata prefix would both work.

CommentFileSizeAuthor
#17 3261015-save-values.patch544 bytesjoecorall
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

ultrabob created an issue. See original summary.

ultrabob’s picture

Issue summary: View changes
joecorall’s picture

Can you please provide a full stack trace, or where in the code you're running into this issue?

ultrabob’s picture

Apologies for not explaining well. I'm trying to implement a new mapping. My plugin annotation is as follows:

/**
 * JPCoar configured using a view.
 *
 * @OaiMetadataMap(
 *   id = "jpcoar",
 *   label=@Translation("JPCoar (View Mapping))"),
 *   metadata_format="jpcoar_1.0",
 *   template = {
"type" = "module",
 *     "name" = "rest_oai_pmh",
 *     "directory" = "templates",
 *     "file" = "jpcoar"
 *   }
 *   )
 */

It appears that rest_oai_pmh uses the metadata_format string as a key when saving config, and since dots are not allowed in config keys, the error mentioned in the issue summary pops up when trying to save the config with that mapping in place. Changing the metadata format to jpcoar_10 gets rid of the error, but that also changes the metadata prefix that the module uses, which obviously is not a good outcome.

ultrabob’s picture

I've been very sporadically been able to work on this issue, and will likely be working on something else again tomorrow, so I want to document where I am on preparing to propose a solution for this issue.

Currently in /src/Form/RestOaiPmhSettingsForm.php, at about line 320 the config is set including mapping being set by $config->set('metadata_map_plugins', $form_state->getValue('mapping'))

I'd like to insert code similar to

$mapping = [];
    foreach ($form_state->getValue('mapping') as $label => $value) {
      $mapping[] = [
        'label' => $label,
        'value' => $value,
      ];
    }

before that code block, and then $config-set(metadata_map_plugins', $mapping)

Pre-change, this is stored:

Array
(
    [jpcoar_1.0] => 
    [mods] => mods
    [oai_dc] => dublin_core_metatag
    [oai_raw] => 
)

Post change it becomes:

Array
(
    [0] => Array
        (
            [label] => jpcoar_1.0
            [value] => 
        )

    [1] => Array
        (
            [label] => mods
            [value] => mods
        )

    [2] => Array
        (
            [label] => oai_dc
            [value] => dublin_core_metatag
        )

    [3] => Array
        (
            [label] => oai_raw
            [value] => 
        )

)

This would mean changing the code for parsing reading and parsing the config in /src/Plugin/rest/resource/OaiPmh.php starting around line 659

and probably also means adding an update into rest_oai_pmh.install to update existing mappings and change the way the default mapping is written.

I'd love some feedback on whether this approach makes sense, and would be a welcome change. Another possible way would be to give each metadata prefix a machine_name as well as the actual prefix identifier.

Then we could store the same data like:

Array
(
    [jpcoar_1_0] => Array
        (
            [key] => jcoar_1.0
            [map] => 
         )
    [mods] => Array
        (
            [key] => [mods]
            [map] => mods
         )
    [oai_dc] => Array
        (
            [key] => [oai_dc]
            [map] => dublin_core_metatag
         )
    [oai_raw] => Array
        (
            [key] => [oai_raw]
            [map] =>
         )
)

I guess similar changes would still need to be made in the same places.

ultrabob’s picture

ultrabob’s picture

Status: Active » Needs review

This is the first time I've used merge requests on D.O. so please let me know if I'm doing something wrong. This MR converts the data structure for metadata prefix mapping to not use the prefix itself as a config key, since a prefix with a dot in it would cause a WSOD on the site.

ultrabob’s picture

Status: Needs review » Needs work

I thought this was ready, but I seem to have missed something. Will come back soon with a fix.

ultrabob’s picture

Status: Needs work » Needs review
ultrabob’s picture

Status: Needs review » Needs work
ultrabob’s picture

Status: Needs work » Needs review

  • joecorall committed 784d827 on 2.0.x authored by ultrabob
    Issue #3261015: Cannot introduce schema with a dot in the name
    
joecorall’s picture

Status: Needs review » Fixed

Thanks, @ultrabob! Tested and merged.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

ultrabob’s picture

@joecorall I think the updated change here is important for allowing the saved values to properly show in the configuration form. I can't reopen this, but I do think as it stands I've introduced a bug.

joecorall’s picture

Status: Closed (fixed) » Needs review
StatusFileSize
new544 bytes

Fixed with 2.0-beta4

joecorall’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.