New answers tagged

2

If you have a modern (e.g. Debian 10+) server installed fresh, you should be OK. If not, I believe these are the settings you want in your server config (e.g. /etc/mysql/mariadb.conf.d/50-server.cnf if you're using MariaDB on Debian) innodb_large_prefix = 1 #https://mariadb.com/kb/en/library/innodb-system-variables/#innodb_file_format innodb_file_format = ...


1

It's a good question. I haven't come across any problems like this. I see one varchar(512) custom field in utf8mb4 and the longest value it has at the moment is 383 and both the field and index seem fine, but it wasn't converted it's always been utf8mb4. I do have innodb_default_row_format=dynamic which I remember seeing somewhere that's what tables need. ...


2

I had this experience with a Drupal 8 site and fixed it by enabling the permission "access custom fields" for anonymous visitors. In our case, the issue was that anonymous visitors couldn't access the custom fields, so if the cache was cleared, it would get populated via the anonymous access rules and that same cache was used for everyone. Clearly ...


1

The only way we could solve this was turning off php opcache in fpm/apache/nginx and cli


0

You can use the Views CiviCRM Expose Tables module to join to CiviCRM tables and columns that aren't otherwise exposed.


2

Shoreditch is officially designed to work with 5.24.2 so expect issues when running it with the latest CiviCRM security release. You may just want to disable it!


3

If you have CiviCRM shoreditch extension enabled on your site than try adding below line in your theme css file .crm-container span.btn-slide { display: unset !important; } Thanks Pradeep


Top 50 recent answers are included