CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2019-08-06T20:35:08Zhttps://lab.civicrm.org/dev/core/-/issues/949Export table field size is inadequate for State/Province data values2019-08-06T20:35:08ZorigamiusaExport table field size is inadequate for State/Province data valuesExporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary ...Exporting a custom data field of type State/Province crashes with a db error "Data too long for column" if the State/Province has a long name (example: no crash with "Massachusetts", but crash with "District of Columbia"). The temporary table is created with a column size of varchar(16), presumably because the State/Province key is stored as a LONG; but the exported quantity is the value, which could be of arbitrary length (and certainly includes examples longer than 16 characters in normal usage).
This appears to be a similar issue to https://lab.civicrm.org/dev/core/issues/181 and https://lab.civicrm.org/dev/core/issues/877.5.17.0https://lab.civicrm.org/dev/core/-/issues/1073Performance : Expose some important smarty configuration variables outside th...2021-03-29T14:14:27ZVangelisPPerformance : Expose some important smarty configuration variables outside the smarty classWhile working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the...While working with multiple "complex" civicrm sites on dedicated server instances, I've noticed that even though the database was highly optimized, all sites were having some sort of overhead of nearly 1.5-2 seconds before rendering the results. That is on the contact display page, on search, advanced search and so on.
Added Redis caching to CiviCRM, helped with a bit of small improvement but again, the delay was there.
Digging deeper with XHProf, I've found out that for every page that was loading, Smarty was checking if the templates needed recompiling.
Long story short, inside the /packages/Smarty/Smarty.class.php there's a variable that is `true` by default:
`var $compile_check = true;`
Description is the following:
> This tells Smarty whether to check for recompiling or not. Recompiling does not need to happen unless a template or config file is changed. Typically you enable this during development, and disable for production.
Disabling this in production, i did see a big improvement in terms of speed, as Smarty is now being instructed not scan every time if it needs to recompile the templates.
My suggestion would be to expose that variable (along with `$caching`) as a constant so that for example we can add it to `settings.php` as 'false' in production environments.
I could provide a patch (if needed) that does that.
PS. "complex" = a CiviCRM instance with many extensions and many tpl injections through custom extensions.5.17.0https://lab.civicrm.org/dev/core/-/issues/1120Export help info does not match code2019-07-16T20:03:55ZeileenExport help info does not match codeIn the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04...In the export screen we see that the postal greeting or addressee greeting can change if more than 2 contacts are merged
![Screen_Shot_2019-07-16_at_9.32.04_AM](/uploads/871c946c283258e8e4c6e68bae72e1d7/Screen_Shot_2019-07-16_at_9.32.04_AM.png)
In the code the rules are that 2 or more contacts being merged use the rules (ie if contacts are merged then use the rules). (There is some mickey mouse separate handling where it seems the code attempts to only use the 'other' logic for 2 or more
I can't see why you wouldn't use the merge string for any merges - which would simplify the code a lot too
@lcdweb @colemanw thoughts - can we tweak the above to '(when merging contacts to one row)' & clean up the code to just do that (without extra code that with more or less success attempts to do ? something ? when there are only 2 & use the merge string where there is more than 2
I *think* the intent might have been that you could choose different behaviour for many vs just 2 but in practice you can't actually select that in the UI5.17.0https://lab.civicrm.org/dev/core/-/issues/1226Smart groups: Relative date filters saved incorrectly2019-09-03T06:50:14ZPradeep Nayakpradpnayak@gmail.comSmart groups: Relative date filters saved incorrectly(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not sa...(*Original title: "Regression: Smart group with Change log criteria is not saved."*)
If you create a smart group which uses a relative date filter (e.g. "Last 60 days" or "This calendar current year"), the relative date filter is not saved correctly.
This issue entails two aspects:
1. (*Code update in 5.16.4*) Fix the code so that smart groups are properly saved
2. (*Data cleanup; case-by-case*) Identify any smart-groups which were created or edited in the past month (5.16.x). Determine if they should be updated to use a relative date filter.
The following fields are believed to affected:
* `log_date_relative`
* `pledge_payment_date_relative`
* `pledge_start_date_relative`
* `pledge_end_date_relative`
* `pledge_create_date_relative`
* `member_join_date_relative`
* `member_start_date_relative`
* `member_end_date_relative`
* `birth_date_relative`
* `deceased_date_relative`
* `mailing_date_relative`
* `relation_date_relative`
* `relation_start_date_relative`
* `relation_end_date_relative`
* `relation_action_date_relative`
* `contribution_recur_start_date_relative`
* `contribution_recur_next_sched_contribution_date_relative`
* `contribution_recur_cancel_date_relative`
* `contribution_recur_end_date_relative`
* `contribution_recur_create_date_relative`
* `contribution_recur_modified_date_relative`
* `contribution_recur_failure_retry_date_relative`5.17.0Pradeep Nayakpradpnayak@gmail.comPradeep Nayakpradpnayak@gmail.com