Following #2042807: Convert search plugins to use a ConfigEntity and a PluginBag each type of search is configured as one or more SearchPage config entities. Core has two types of search and creates an entity for each of them, with the config stored at search.page.user_search and search.page.node_search.

User search doesn't have any config to migrate.

Node search needs to migrate the hook_rankings configuration. In D7 (and D6?) this is stored as variables named node_rank_* which are set to an integer 0 to 10.

In D8 these are stored an array at configuration.rankings, so variable_get('node_rank_comments', '5') becomes configuration.rankings.comments: 5.

Ideally the array key will NOT be set if the value is 0, but it's not that important if removing those is tricky. There are 6 known variables, so I would expect

node_rank_comments = '5'
node_rank_promote = '0'
node_rank_recent = '0'
node_rank_relevance = '2'
node_rank_sticky = '8'
node_rank_views = '1'

to be converted to:

configuration.rankings:
  comments: 5
  relevance: 2
  sticky: 8
  views: 1

Also, #2123073: Move index.cron_limit setting to NodeSearch proposes moving search.settings.index.cron_limit to search.page.node_search.cron_limit, so whichever of these gets in second should also do the migration for that variable.

Comments

chx’s picture

chx CreditAttribution: chx commented

For anyone writing this: the source is variable, the destination is entity, the entity_type is SearchPage and the process for configuration.rankings needs to be a custom plugin, the id is going to be default_value, default_value: node_search . The custom plugin is roughly this:

$return = array();
foreach ($row->getSource() as $name => $rank) {
  if (substr($name, 0, 10) == 'node_rank_' && $rank) {
    $return[substr($name, 10)] = $rank;
  }
}
return $return;

If the other patch goes in then we to add search_cron_limit to the source and cron_limit: search_cron_limit to the process.

chx’s picture

chx CreditAttribution: chx commented
Assigned: Unassigned » chx

I am almost done with this done.

chx’s picture

chx CreditAttribution: chx commented
Status: Active » Fixed

This was very very hard; needed its own destination to be able to set the configuration.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

Is there any way for someone to see the commit/patch that you used and review it? Because when I look at this project I do not see any commits since November and there is not a link on the project page to any other repo where the work is being done.

ianthomas_uk’s picture

ianthomas_uk
he/him
Primary language English
Location Brighton, UK
CreditAttribution: ianthomas_uk commented

See http://drupalcode.org/sandbox/chx/2105305.git/commitdiff/0f8b39859db1c50...

ianthomas_uk’s picture

ianthomas_uk
he/him
Primary language English
Location Brighton, UK
CreditAttribution: ianthomas_uk commented

It looks like you ran into #2125405: Not all commits showing up

Personally I prefer the layout of the repository viewer, so I hadn't even noticed.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented

Yeah, normally I use the repository viewer too but this time I just went to "all commits" and ran into that issue. Thanks! I'll give that commit a review.

jhodgdon’s picture

jhodgdon
she/her
Primary language English
CreditAttribution: jhodgdon commented
Status: Fixed » Needs work

I looked over what was done in that commit and it doesn't seem complete to me. I think there is more to do, unless you have a separate issue for the rest:

a) In D7, you could turn individual search modules (user, node, or contrib modules) on or off. This configuration needs to be migrated to in D8 as pages being enabled or disabled.

Specifically, in D7 there was a variable 'search_active_modules':

 variable_get('search_active_modules', array('node', 'user'));

If either 'node' or 'user' is not in that variable in D7, in D8 the corresponding search page that is set up for Node or User needs to have its 'status' config key value set to true/false in the page entity config.

b) In D7, you could choose which search module was the default search page. This needs to be migrated to in D8 setting one of the search pages to be the default page.

Specifically, in D7 we had:

variable_get('search_default_module', 'node');

And in D8 this needs to be migrated to the setting 'default_page' (set to a search page entity ID string); this is in search.settings.yml.

This is further complicated by the fact that the default could be a contrib module in 7. So I think what needs to happen in the core migrate code is that if the default module is either 'node' or 'user', the corresponding page node_search or user_search should be set to the default in D8. And if neither of them was set to be the default module in D7, we can assume that the contrib search plugin module's migrate will take care of setting it to be the default in its migrate code (presumably using the core migrate code here as an example).