For the past few weeks I have been sending a dev digest to the dev-civicrm mailing list at the end of each week (subscribe here). The dev digest is a mix of what's being worked on, what proposals people are looking for input on, what we need review or help with, or just whatever bubbles to the top.
I have pasted a copy of the digest that just went out below - if you wish to subscribe the dev-list is just an old-fashioned mailing list. There is some technical discussion - but we do try to move discussion to gitlab where we can. We might switch to a more formal system at some point - but at this stage it is what it is.
If you are a dev - one thing covered in previous weeks is that 5.31 alters the html on CiviCRM buttons - you should check if you have css or javascript or similar that interacts with them - preferably by testing the 5.31 rc against your code from next Thurs on.
Here's this week's digest
Dev digest 3 Oct 2020 (or 2 Oct for those still living yesterday)
So we reach the end of September - release 5.30 is due out next week and release 5.31 goes into rc.
The 2 themes of 5.31 have been addressing our theming contract and micro-performance improvements. I’ve covered off theming a bit in previous dev-digests - I’ve written a longer version on the micro performance improvements at the end of this digest (I’m calling them micro performance improvements as each one makes only a very small difference but hopefully the effect is cumulative).
Help wanted - drupal 7
- Still looking for drupal expert help on this session related paypal bug in chrome
Review wanted
- Drupal 8 error handling
- Fix merge code so that deleted contacts are not left without a primary address
Making progress
- Mosaico Introduce A/B testing for subject lines (CiviDesk currently testing)
- Work by Compucorp on adding options for inbound email processing - this will help avoid creating spam contacts & contact who might not wish to be in your DB when processing inbound emails.
- Work to make use of recently added public fields for CiviCRM Groups (Agileware have indicated they are going to test)
- Rationalise BAO create vs add functions - for anyone who has ever wondered why it’s sometimes add & sometimes create - the goal is that it would always be create
Coming up
- Sometime in Oct we are going to try to put our heads together & do a better plan for group contacts …..
Shout out
One of the challenges of acknowledging people when so many people do so much is that as soon as you start mentioning anyone who deserves credit you wind up with a whole long list & there is no good place to stop. However, I’d like to make a practice of at least pointing out one person each digest who deserves recognition - and hopefully in time we’ll get well down that long list! Anyway this week I want to draw attention to Pradeep Nayak from Circle Interactive. Lately it feels like whatever medium I’m looking at from stackexchange to chat to gitlab to github I see evidence of Pradeep helping people with their questions, bugs and review.
Micro-performance improvements
As mentioned in previous digests I’ve been doing a lot of work this month around tiny improvements that (hopefully) add up on long running jobs. As each of these is very small it takes a lot to make a dent! I’ve learnt a few things and made some progress and hope to have most of these merged into 5.31
- Learnt: - for unit test speed it’s worth unsetting the properties of test classes in tear down. It turns out phpunit keeps a full copy of every test class until the end - so unsetting properties during tear down can reduce the memory hogging
- Learnt: - our legacy $daoObject->query() method has a memory leak - we’ve been removing these anyway but a few are hanging around so fixed like this help a bit (MailingJob still has some & couple of other places)
- Investigating - could this memory leak affect us “When you require a file declaring a closure in a loop, the memory usage increases continuously, so it definitely hit hard on Symfony container loading!”
- Fixed: - a cache bypass
- Working on - removing uncached, unused queries that run whenever you retrieve custom fields using the v3 Contact.get
- Working on (some fixed, some in review) - My original project of trying to eliminate about 50% of the queries in a Contact.create+contribution.create call (once caches are already warm.). The image below is from here and colour codes the query for one Contact.create+contribution.create in terms of green = needed & the other shades are various progress on reducing /removing
Comments
Thank you Eileen for this post, it gives even more confidence in using Civi and helping it to grow in France!