USAGOV-432: state directory import

[akf]

Jira Task

https://cm-jira.usa.gov/browse/USAGOV-432

Description

This PR adds a script for massaging exports from mothership into a CSV format for import into beta, and a feed configuration for importing that CSV data. There are also some incidental corrections (like the list of "state" abbreviations in the state_directory_record content type) and a bit of documentation.

I'm recommending that PR review consist of making sure the instructions work for someone besides me, and that you wind up with a batch of imported State Directory Records after going through the process. The Content team will look at the actual results of the import once this gets into the dev environment.

This PR includes configuration, so you'll need to "drush cim" before doing the import.

Sample files have already been exported from mothership and can be downloaded from https://drive.google.com/drive/folders/1MRUgvLkfZgNeCh_xL5hgpdG-ues9ij4W (the exports_from_mothership folder).

Refer to the instructions in https://github.com/usagov/usagov-2021/blob/USAGOV-432-state-directory-import/web/modules/custom/usagov_directories/docs/Importing_State_Records.md

1. Skip the export instructions (use the files from Drive instead) and start with "Preparing the files for import." This should produce a CSV file like the one in the "processed_files" folder in the same Drive location. (It will create a couple of other files as well; please ignore them.)
2. Assuming that goes well, follow the instructions under "Importing the data to beta (first time)" to import the data to your local dev site.

The expected result is that you will have a bunch of records (118, since the import data set is known), about half in English and half Spanish:

• http://localhost/admin/content?title=&type=state_directory_record&status=All&langcode=es
• http://localhost/admin/content?title=&type=state_directory_record&status=All&langcode=en

Checklist for the Developer

• A link to the JIRA ticket has been added above.
• The JIRA ticket identifies the desired result of this change.
• The JIRA ticket contains clear acceptance criteria.
• The JIRA ticket contains clear testing steps.
• The JIRA ticket contains a description of "Done".
• Any preparation/installation/update steps required for this code to work properly (drush commands, scripts, configuration updates) are documented in the ticket.

Checklist for the Peer Reviewers

• The branch name of this PR matches the project standards.
• QA steps are followed and any changes to process are updated in the ticket.
• Code Standards are followed, there are no bad practices in use.
• Config changes (if any) include only necessary changes.
• No errors in Drupal or Client Browser.
• Code has been tested locally (if possible).
• Following AC and Testing Steps verify changes work as expected.
• There are no known side-effects outside of expected behavior.

[akf]

Well, this was a rabbit hole. It turns out "iconv" doesn't work the same way on all platforms. It's not the php function, but rather libiconv. musl-libc does not support the //TRANSLIT suffix.

Mentioned here: codecasts/php-alpine#39 , which links to this explanation: https://wiki.musl-libc.org/functional-differences-from-glibc.html#iconv (they do it differently on purpose).

I've removed //TRANSLIT from my iconv target encoding; at least for this data set, it turned out not to be needed. I've also added "error_reporting(-1);" to the script so that iconv errors are reported -- since we call this once per record, this makes it pretty obvious when there's a problem.

[IsabelLaurenceau]

Success!