3

You can create custom fields under Administer --> Customize Data and Screens --> Custom Fields. You first create a custom group for the event. You could even limit this group to a certain type of event. You then add a field in this group with type Text and HTML type Select.


2

No that is not possible. The tokens in CiviCRM are used in letters/emails. So they are used for communication with the contacts in your database. Also note that a token in CiviCRM is always related to a contact.


2

If you have a report that doesn't show the custom fields on an entity, it might be because those fields are not configured as searchable (yes, a very non-obvious thing). If that's the issue, then it's the same as this question/answer: Custom fields in the Report Templates Alternatively, if it's a problem with the report itself, you can generally hack it ...


2

I do not think it is because you have too many custom fields but it might well be that something is not totally right in your data? Ideally you should compare the values in the civicrm_custom_group and civicrm_custom_field tables with the actual data holding tables (in your example civicrm_value_care_init_69) and check if that is all correct. The error also ...


1

You haven't said what field type you were using, but I think you should probably be using a note field rather than an alphanumeric. My understanding is that the note field isn't stored as fixed length.


1

That table is defined in templates/CRM/Event/Form/Selector.tpl and changing that would require some level of coding (your profile suggests you have this skill). Changing the Selector.tpl template directly would solve your problem but is discouraged because it causes headaches when upgrading to new versions. Creating an extension is the preferred way to make ...


1

Moe's answer is technically workable - but oof ouch my performance! Instead, something like this: function getElementNameFromFieldName($fieldName, $elementIndex) { // This function could be further optimized so it's only called once, but meh. $elementNames = array_keys($elementIndex); foreach ($fieldNames as $fieldName) { if (strpos($elementName, ...


1

With the help of JaapJansma-CiviCooP I was able to make this work using the below code: function dfi_civicrm_buildForm($formName, &$form) { if ( $formName == 'CRM_Contact_Form_CustomData' ) { for ($i = 1; $i < 10000; $i++) { $form->updateElementAttr('custom_198_'. $i,array('readonly')); $form->...


1

It appears to be a bug, but temporary workaround fixes the issue (split the fields into two custom field groups). Bug report can be found here: https://lab.civicrm.org/dev/core/issues/1330


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