2

An interesting workaround is you can make a profile that includes the membership end date for bulk updating memberships, then edit the membership end date there, and save. It won't throw an error. Not sure what the unintended consequences may be.


2

Welcome to CiviCRM SE. I think you have quite a complicated membership processing structure there (very frequent payments), but the basic requirement seems to be process membership update structure from an external file (I presume you get the paycheck info as a CSV file) is quite common. If you don't need to record the payments at all I think you can do a ...


1

If Members are also WP users then let them log in and have access to either a CiviCRM Profile (https://docs.civicrm.org/user/en/latest/organising-your-data/profiles/) or a Caldera Form and you should be able to set up the fields you want them to have access to via the form If Members are NOT WP users then you can send out a Mailing with a checksum link to a ...


1

Not exactly the same but for a similar way of automating check-in take a look at https://civicrm.org/extensions/qr-code-checkin


1

It turns out that the Webform is not picking the price up from the Price Set at all, but from the 'Minimum Fee' field of the Membership Type record. Even if the Minimum Fee is blank (NULL in the database) the Webform picks up zero rather than going to the Price Set. (I had forgotten that the Minimum Fee was set (or even existed)). In fact, not clear ...


1

I've raised this as issue #1126 in GitLab. From the discussion, it appears that this was implemented as a 'feature' in the past but it is unclear why this was necessary. Hopefully this issue will be resolved at some point in the future but this may take some time as we need to ensure that it won't cause a regression for existing users. As a workaround in ...


Only top voted, non community-wiki answers of a minimum length are eligible