In the course of the recent NYC Developer camp, I had the opportunity to discuss the state of CiviCRM's templating system with members of the core team . In the course of our work with CiviCRM we have done extensive theming and have discovered a number of opportunities for improvement over the current system.
Blog posts by Anónimo
Keep up-to-date with blogs from the core team, working groups, developers, users and champions worldwide. Subscribe to our newsletter to receive regular updates by email. We also have an RSS feed.
We've recently upgraded a copy of a 100,000+ contact install running 2.2.8 to 3.0 b3 for testing purposes. Functionality is fine and things look absolutely great in the new interface.
The upgrade was painless and quite quick. There was a foreign key drop constraint in the installer that needs tweaking, but the core team is on it and apart from that it took only about 20 minutes start to finish to upgrade the fairly good sized database.
Minutes for 09-02-2009 meeting - CRM - CiviCRM Wiki
Web redesign project
About 8 weeks ago we began looking into a CiviCRM / QuickBooks integration framework. Our goal is to write a module that allows CiviCRM contributions and contact information to be written to QuickBooks. Our target version is QuickBooks 2009 Premier Non-Profit edition, since that's what we use.
At the very least, the module should be able to:
A problem with using Civi for a members’ website based on Joomla is the need to be able to control access for different types of user – for example you might want ordinary members to be able to edit their own details but not see the details of other members for privacy reasons. But perhaps some groups of members might want to see each others details.
- Here's a report back from Sacha Stanton
The New York Meetup was a great success last night, as 33 people got a glimpse into upcoming releases, several case studies, and great open floor discussions. Dave Greenberg, core contributor, joined in via Skype video to provide insight into upcoming features and answering questions.
This post started out as a reply to Eileen's "Banking Screen?" comment on my previous post on this topic, but by the time I was done, I thought that this warranted its own post.
I think that the core "Accounts" or "Banking" functionality that could be helpful to Civi users without getting too out of control, is:
We are finding that CiviCRM/accounts issues are becoming increasingly important for our clients, and Eileen's recent blogs and the discussion they are generating are a fantastic step towards helping find the best way for Civi to deal with financial transactions.
For example, I think it could be useful for Civi to ultimately develop functionality for maintaining simple bank accounts within CiviCRM, so that small organisations can maintain basic accounts without the headaches of integration with an external package.
Some recent discussions and debates about Active Record and Data Mapper have popped up in the context of new architectural proposals for CiviCRM from Dharmatech and raSANTIAGO. We think it is important that the differences between each is known and to clarify what are some erroneous perceptions. This is not to claim that either design pattern is above criticism. It is to say, that there are some misperceptions that prevent a more intelligent discussion of the trade-offs between these two design patterns. Our hope is to bring some clarity to this discussion.
Current CiviCRM architecture pitfalls
rasantiago has proposed a new CiviCRM architecture with details of the ORM layer. Torenware commented on the latter and mentioned some particular scalability issues. Our own experience with the Active Record design pattern proposed by rasantiago is that it works well for small projects but doesn't scale well. We believe that CiviCRM is now facing serious scaling problems in several areas, to wit:
