Problem/Motivation

Provide Drupal Migrate support for updating from Drupal 7.

Proposed resolution

Adds migration template and migrate source and destination plugins necessary to migrate variables matching honeypot_% as configuration.

Each variable merges into the existing honeypot configuration object.
Form ids are statically-mapped to their equivalents supported by honeypot in 2.1.x.

Remaining tasks

- Figure out core contact module migration mess.
- Review expected values for form ids to make sure they are what they should be.

Release notes snippet

Issue fork honeypot-2401647

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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

heddn’s picture

geerlingguy’s picture

@heddn - thanks!

Wim Leers’s picture

Issue tags: +migrate-d7-d8

@geerlingguy If you can give some guidance on the changes in configuration between D7 and D8, I'm willing to write the migration.

geerlingguy’s picture

@Wim - Thanks for the offer!

So, Honeypot has a variety of settings (stored in variables table) that are more or less hardcoded in D7 (and D6 I think), like:

  • honeypot_element_name (string, varchar, example "url")
  • honeypot_log (integer, 0 or 1)
  • honeypot_protect_all_forms (integer, 0 or 1)
  • honeypot_time_limit (string, varchar, example "8" for 8 seconds)

Then there are honeypot_form_* settings which are dynamic—these are basically a list of all the forms Honeypot is configured to protect. As an example, here's the list of these settings on my personal site:

  • honeypot_form_blog_post_node_form (all are integer, 0 or 1)
  • honeypot_form_comment_node_blog_post_form
  • honeypot_form_comment_node_page_form
  • honeypot_form_comment_node_project_form
  • honeypot_form_page_node_form
  • honeypot_form_project_node_form
  • honeypot_form_user_pass
  • honeypot_form_user_register_form

And for Drupal 8, the config schema should be up to date: https://git.drupalcode.org/project/honeypot/blob/8.x-1.x/config/schema/h...

I believe the honeypot_form_* settings all go into honeypot.settings.form_settings; see how they're structured in the Config form here: https://git.drupalcode.org/project/honeypot/blob/8.x-1.x/src%2FControlle...

TR’s picture

Version: 8.x-1.x-dev » 2.0.x-dev

New features should go into the most-current version of this module first, then be backported if there is community interest.

TR’s picture

Version: 2.0.x-dev » 2.1.x-dev

mradcliffe made their first commit to this issue’s fork.

mradcliffe’s picture

Status: Active » Needs work

This a work-in-progress to start migrating variables into the honeypot configuration object. It probably needs a lot of work.

It needs a test case + fixture for when all forms isn't selected and further assertions for the fixture.

Setting to Needs work.

drumm’s picture

(updating to resolve Drupal.org indexing issue, please disregard)

mradcliffe’s picture

Status: Needs work » Needs review

Probably ready for some sanity check review and manual testing.

mradcliffe’s picture

Issue summary: View changes
Status: Needs review » Needs work

Removing old issue summary and adding up-to-date issue summary.