Tag Info

I am not even going to try and answer it all in one go :-) But I am happy to share the configuration that my customers with remote CiviCRM's use. They all basically have a public website (Drupal 7 or 8 in most cases, Wordpress in some but in theory any CMS would do) on a server and a separate CiviCRM in a "dummy" Drupal 7 on another server. I use the word "...

Relationships Can be used to give permissions between contacts Have a start & end date Can attach notes & additional custom data Can be displayed as advanced search results Custom contact reference fields Can be added to a profile form Can be displayed in its own tab or section of the contact summary page Customizable autocomplete filters for ...

In my experience, I default toward relationships, but might use a custom reference field in these situations: I need to export multiple people with the same relationship. For instance, if Andy and Beth both have a "Mentor of" relationship to Johnny, you can't export Johnny's record showing both mentors. So I'll make two contact reference fields. You need ...

According to the developer docs on namespaces, the two standards represent two eras of trend in programming standards: CRM (e.g.: CRM_Core_Invoke) classes use PEAR-style class-naming conventions that were common up until PHP 5.2. Class names include underscores and MUST NOT use the PHP "namespace" directive. Use CRM style when creating classes that plug ...

this is still mostly valid, with the addition of the api folder that contains, you guessed it, the api goodness. You might have several folders missing depending on how you install it. eg all the test and xml folders are only there if you install a full/development environment, not if you download the pre-packaged production version What is missing or ...

CiviCRM uses the registered_by_id to link multiple participants together. Since the CiviEvent registration page doesn't allow you to register others without also registering yourself for an event, an fk to participan_id makes sense. However, some use cases (e.g. summer camps) have different requirements, where a parent registers 1 or more children (but not ...

I think there is some of the code related to payment processing that assumes the registered_by_id is the participant under whom payment has been made. Any changes to the schema would need to account for that. Thats probably the primary reason the FK is to civicrm_participant