Problem/Motivation

We need an upgrade path from 7.x for the core Search module.

Remaining Tasks

There doesn't seem to be much of a point in migrating search index data, since that's easily rebuilt. But any variables maintained by Search need to be moved in configuration. We need a migration, with a test, for this.

We also need to migrate configured search pages to SearchPage entities.

Comments

quietone’s picture

Found more search related variables, which I've separated into three groups.

1) node_rank_comments
node_rank_promote
node_rank_recent
node_rank_relevancy
node_rank_sticky
node_rank_views

2) search_active_module
search_default_module
search_embedded_form_submitted

3) search_node_tags_test_query_tag
search_node_tags_test_query_tag_hook

Group 1 is similar to the migration, d6_search_page, and that seems like a separate issue.

Anyone know about the others? I've only done some grepping and comparing to the D6 migration.

phenaproxima’s picture

Issue tags: +Barcelona2015, +Novice
phenaproxima’s picture

Issue tags: -Novice

Well...maybe not novice.

phenaproxima’s picture

Issue summary: View changes
jhodgdon’s picture

Let me do a bit of explaining... hopefully this is the right level of detail; feel free to ask more questions if not and/or skip the parts you know!

In Drupal 7, modules could provide the ability to search via hook_search_info() and configuration for this via hook_search_admin(). In core, there were two implementations: user and node; user had no config and node had config for rankings.

And then on the Search config page itself (provided by the search module), you could turn individual provided search modules on or off, and designate one as the default page that is used for the search block and when you go to /search.

In Drupal 8, this same functionality is provided by search plugins, and Core has NodeSearch and UserSearch from the node/user modules respectively. To make things a bit more complicated, for each provided plugin, users can define one or more *pages*, so you can have multiple node and multiple user search pages (in principle anyway). Search pages are config entities. The Standard install makes page configs for NodeSearch and UserSearch plugins, and makes the NodeSearch page be the default page, so it ends up working just like D7 by default.

So. Migrating, looking at comment #1:

- Your group (1) node_rank* settings - those are rankings settings for the NodeSearch plugin -- see search.plugin.node_search in core/modules/node/config/schema/node.schema.yml -- and I think D6 migrate was also migrating these settings (but I haven't really looked at how it was done, hopefully correct). So they need to be migrated to the node search page config item.

- Your group (2)
== search_active_modules [note the s at the end, missing from #1] - this is the list of all the active search modules from the Search settings page
== search_default_module - this is the default module, from that list of active modules

This needs to be translated into the list of active search pages and the default page, and you'll also need to set up the default node and user pages (get the config from the Standard install profile probably? This was presumably also done in D6). There's a default_page settings on search.settings in search.schema.yml. The list of 'active' pages is not stored in a setting per se, but instead it's the collection of all search.page.* config items.

- In group (2) search_embedded_form_submitted and all of group (3) are just for tests, so you do not need to migrate them.

Hope that is clear...

quietone’s picture

@jhodgdon, thx that really helps. Though, still don't know how to handle search_active_modules.

group 1) node_rank* settings - Saved to search.page.node_search, using entity:search_page destination plugin. This is the same as the D6 migration.

group 2) - Only search_active_modules and search_default_module to be migrated.
search_default_module: This just needs to be added to the D7 search setting migration.

search_active_modules: Do you mean that for each active module a new configuration, "search.page.'active_module_name'_search" needs to be created? If so, then, since search_active_modules is an array, not a simple list, is the key or value used?
The current testing data is:

Array
(
    [node] => node
    [user] => user
)

Also, both search.page.node_search and search.page.user_search are created on D8 install, so there doesn't seem to be a need to migrate those. How do I add other modules to search_active_modules? My D7 test sites only have node and user as options.

I didn't find any reference to search_active_modules or search_default_module in D6. Am I missing something here?

.you'll also need to set up the default node and user pages (get the config from the Standard install profile probably?

I don't know what this means. What is the outcome, the default node, what happens to user pages?

jhodgdon’s picture

So... In D7, the search_active_modules variable is a subset of the modules that implement hook_search_info() (it lists the module names from the list of implementers that the user has chosen to be active search modules). The values you have in your test config say "Node and User search modules are active". In some sites, there may be contrib modules that are active as well.

In D8, the equivalent (in words) is "The default pages for Node and User search are active". In configuration terms, this means that config that comes from core/modules/node/config/optional/search.page.node_search.yml and core/modules/user/config/optional/search.page.user_search.yml config should be made part of the active config. And then the ranking settings from variables like node_rank* should be put into search.page.node_search config.

If someone had just 'node' in search_active_modules, then you would only put search.page.node_search.yml into active config. If they had just 'user', you would only want search.page.user_search.yml. If they have neither, then neither config should be made part of active config.

Does that make sense?

In Drupal 6, there was no way to turn off any search modules -- node and user search were *always* active if Search module was enabled. So there was no equivalent to search_active_modules ==> effectively it was always equal to array('node', 'user') because those two modules were always active (and possibly with the addition of additional contrib modules that implemented hook_search() in D6).

Also in D6 the default search page was always Node search, and there was no way to change this.

quietone’s picture

Yes, what you wrote makes sense. Thanks.

Summarizing, all the remains to do is to add search_default_module to the D7 search settings migration. Search_active_modules doesn't need to be migrated because the node and user search pages are already created on D8 install (or when search is enabled) and migrate isn't responsible for migrating contrib.

jhodgdon’s picture

Umm... Not quite. So if search_active_modules is NOT array('node', 'user'), then it will need to be dealt with. For instance, if only 'node' is in there, that means they have turned off the User search page, so correspondingly you should disable the User search page in D8.

You can disable a search page plugin by setting status:false in the config. So looking at the search.page.user_search.yml file in the user/config/optional directory, it says:

langcode: en
status: true
dependencies:
  module:
    - user
id: user_search
label: Users
path: user
weight: 0
plugin: user_search
configuration: {  }

and in that second line you'd want status:false.

quietone’s picture

@jhodgdon, got it, thanks a lot.

There are two new issues for the follow up work, #2587043: Variable to config: search_default_module [d7] and #2587063: Variable to config: search_active_modules [d7].

chx’s picture

Issue tags: +SprintWeekend2016
quietone’s picture

Issue tags: +migrate-d7-d8

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

damienmckenna’s picture

Adding the main D7-D8 issue as the parent issue.

mikeryan’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update

So, what exactly needs to be done in this issue that isn't covered by #2587063: Variable to config: search_active_modules [d7]?

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

heddn’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

If this is still an issue, please document steps to reproduce and re-open.

heddn’s picture

Status: Closed (cannot reproduce) » Closed (duplicate)

Seems this should actually be closed duplicate to #2456259: [META] Drupal 7 to Drupal 8 Migration path