When doing a find or an export, the 'source' fields for memberships is blank for some records. For the records where it displays, its obviously been populated automatically when the membership is set up offline. For the records where it is blank, if I view the record, the value is there and is the same automatically created values as the ones that did display. If I edit and then save without making any changes, then that membership behaves as it should.

I'm using CiviCRM 4.7.24 but can't see anything in subsequent release notes that relates. It would be difficult to try on the demo system because most of the registrations come through correctly.

1 Answer 1


The fact that the record displays correctly on save suggests that there's a difference between how correct and incorrect values are recorded in the MySQL database. I've seen this happen on multi-select custom fields when you import values with a comma rather than a value separator. The field LOOKS ok, but it's not stored correctly - but on save, the form corrects the data.

If you view the underlying MySQL table in a tool that supports showing hidden characters, I'm guessing you'll find one missing (or present) in the incorrect records.

UPDATE: To see if you can view hidden characters, try inserting one into the database. E.g.: INSERT INTO civicrm_worldregion (name) SELECT CONCAT('a', UNHEX(01), 'b');

If I view that in the MySQL CLI client, I can't see it: mysql> SELECT name FROM civicrm_worldregion ORDER BY id DESC LIMIT 1; +------+ | name | +------+ | ab | +------+ 1 row in set (0.00 sec)

I also can't see it from my command line:

~/ » mysql temp -e 'SELECT name FROM civicrm_worldregion ORDER BY id DESC LIMIT 1' +------+ | name | +------+ | ab | +------+

However, if I pipe to vim then it appears as: name c^Ab

That ^A is in blue, which indicates it's not actually "caret then A" but rather "control character 0x01".

  • Jon G - I can see how this might produce the behaviour I have seen, but I think the particular field is f
    – Mick Kahn
    Nov 5, 2018 at 18:47
  • hit return too early and couldn't edit... Jon G - I can see how this might produce the behaviour I have seen, but I think the particular field is filled in by the code and not by the user. around line 1302 in membership.php looks right to me. So I can't see how that would sometimes be right but sometimes wrong. I'm not expert in viewing MySQL - will phpMyAdmin show the hidden characters? But I realise I can't test this at present because I have corrected all the ones that were not showing. I will have to wait until they appear again.
    – Mick Kahn
    Nov 5, 2018 at 18:53
  • I agree that my scenario is different than yours because the code is producing the value for you - and that suggests a bug if you can nail this down. Can you restore a backup to a temporary database? I don't think PhpMyAdmin can view hidden characters - the best way to find out is to insert a hidden character into a record and see if it looks different! I'll update my answer to explain the technique. Nov 6, 2018 at 22:39
  • Thanks - I'm not sure I can restore the backup as I'd need to do some testing be able to not overwrite the live site and don't know if I have time before the backup expires (its a hosted service so can't just save it for later). I should not have corrected all the errors and left one for testing.
    – Mick Kahn
    Nov 7, 2018 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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