I am not sure if Civirules does allow to create CMS user when membership is created. But you could right a small extension that implements hook to over-rides the membership id as username and dob as password or implement hook(post on membership) to create user when membership is purchased(created),
So I feel rather silly, all that was needed was to go into the report and edit the filters so that it was no longer looking at the group that no longer existed rather than going to the report via the shortcut we have which ran the report and hence brought up the error.
With regard to the second part of your question - yes, there is my Field Lookup extension which allows you to "chain select" - much like picking a country will limit the choice of available states, you can make one select list dependent on another.
However, it's still in an early (i.e. unfinished) state; I actually have some funding to flesh it out a bit ...
Yes, its a bug in civicrm webform module as it doesn't record line item correctly. The price field value and price field id are missing. I have a patch(for 7.x-5.0) that works for contribution amount field but not for line item field in webform. If you are using contribution amount than you can give it a try.
diff --git a/includes/wf_crm_webform_postprocess....
After testing on Tim's suggestion.
It does not work.
Have not tried yet.
It works after calling Civi::service('settings_manager') on the last tasks before install_finished task is called during Drupal installation.
Haven't done that, but if the focus is on manipulating the content of the settings, then one of these might help:
Try adding calls to Civi::reset() and/or CRM_Core_Config::singleton(TRUE,TRUE) to clear out any statics/singletons/thread-local caches.
Civi's headless unit-tests do this (via CiviTestListener). Note that one should only do it while Civi logic ...
It seems your main reason for rebuilding from scratch is a problem with event fees. As Pradeep says, trying to import all your history is a lot of effort. You are probably better debugging the events problem, or getting someone else to debug it for you.
Importing contact and its details involves more efforts unless you don't want historical data of the contact like contribution, event registration, activity etc. Would suggest to use the same database for your wordpress and clear CiviCRM cache.
The menu items position may differ based on how old is your CiviCRM compared to newly fresh installed CiviCRM but ...
I don't think Backdrop was available when this question was asked, but for the sake of making this complete:
Very similar to Drupal 7 integration, including drush, Views and Webform CiviCRM (Note that the Drupal 7 CiviCRM Entity module has not been ported yet)
Some visual improvements have been added (e.g. CiviCRM menu icon to match Backdrop menu ...
Check out I3Val Input Validation (https://github.com/systopia/be.aivl.i3val/blob/master/docs/index.md) as this allows backend validation before changes go into Civi. It may save people having to complete information again that hasn't changed and from an admin perspective unlikely more work than having to check and then dedupe.
Solution is to either patch the ../web/libraries/civicrm/bower_components/select2/select2.js and select2.min.js files
WARNING: select2 4.0.12 is not compatible with CiviCRM 5.21. The admin toolbar will disappear if you do the following. Use the patches. Do not bower install select2! ;-):
Move the select2 folder out of bower_components and run: