1

Update 11-11-2019 See my answer below.


When dumping a Drupal CiviCRM database to move and convert to a new WordPress install, I've found that the membership data appears to have been encrypted; these random character strings appear in WordPress in Memberships>Dashboard, i.e. bs00fgcb for name, hgaibbsf@example.org for email, etc. But the two letter state abbreviation isn't a random string.

The garbage data appears in the database dump when viewed with a text editor, before I import into the new database.

No other database data seems to be affected, and CiviCRM appears to run fine in WordPress, other than the data display above.

Does this appear to be encryption? There are no encryption modules in Drupal (no Drupal Encrypt) that I can see., nor CiviCRM extensions Where would I find the functions that do the encryption and decrypting? In Drupal [cms.root]/sites/default/files/civicrm/custom/? Or could encryption be done at the MySQL level?

CiviCRM is the same version between Drupal and WordPress; same MySQL database and encoding (both sites are on the same server). Database collations are exactly the same between the two: latin1_swedish_ci. No other data is corrupted. I've tried importing multiple times.

3

There is no encryption in CiviCRM. This sound something that your database dump got corrupted. Or that you imported in a database with another collation (character set) than the source database.

  • Database collations are exactly the same between the two: latin1_swedish_ci. Same database server. No other data is corrupted. I've tried importing multiple times. – BlueDogRanch Nov 8 at 16:16
  • Ehm that is strange. I don't know what migh cause this or how to solve this. – Jaap Jansma - CiviCooP Nov 11 at 8:41
  • 1
    Thanks, it was a strange issue; I added my own answer. – BlueDogRanch Nov 11 at 17:42
3

In the end, I'm not sure what the problem was: either Adminer when either exporting and/or importing; or, the table collations being latin1_swedish_ci, even though both databases used the same collation; or even a conflict between the very old linux version and newer MySQL versions on the server.

But I exported using mysqldump via SSH while forcing UTF, and then changed the table collation to utf8_unicode_ci on the import database, and that worked.

So, export directly from MySQL using mysqldump while forcing utf8:

mysqldump -u root -p --default-character-set=utf8 my_database > backup.sql

Or use gzip, if needed:

mysqldump -u root -p --default-character-set=utf8 my_database | gzip > backup.gz

Then I set the table collation on the database I was importing into at utf8_unicode_ci, and imported the database with Adminer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.