Published
2014-05-01 11:18
Team Coleman, which includes Sarah Gladstone (Pogstone), Coleman Watts (core CiviCRM team), Eileen McNaughton (Fuzion), Michael Daryabeygi (Ginko Labs), Dana Stallman (Tadpole Collective) has been working hard fixing bugs and finishing new features for the upcoming version 4.5. Some highlights: this version includes a new UI framework using a new version of JQuery. Virtually every screen and task benefits from this UI framework. A few screenprints have been attached below. Also the process for configuring profiles forms and custom data for a specific contribution page or specific event is now a lot easier. When configuring the event or contribution page, all editing to profiles/custom data can be done WITHOUT leaving the screen, plus there is a great drag/drop and preview features baked in.
The issue in WordPress that causes CiviCRM front-end pages to take over the website has been fixed.
We have also updated the action "Create PDF Letter" to use a newer PDF library (TCPDF) that allows for the use of stationery in a resource-sparing approach. (The newer library is already used when creating mailing labels and event name badges) Don't worry if you configured CiviCRM to use wkhtmltopdf, this setting is still honored by "Create PDF Letter". PDF Letters can also now be used as an action from within a case.
We have also closed/fixed many bugs that are impacting version 4.5. We have all learned a lot from Eileen and Coleman about proper CiviCRM development techniques, proper use of github, and other technical best practices.
We are also learning from the other participants at the sprint. Adam Wight gave a great presentation after dinner on how WikiMedia is approaching duplicates, merging, and related deduping issues. The basic idea is let the computer handle the easy cases, but allow for human intervention and oversight on what the computer is doing, plus flag the ones that need direct human intervention.
There has also been discussion about best approaches for running CiviCRM as a service (such as some CiviCRM partners do) and for CiviHR. Some people think its best to run CiviCRM stand-alone with no CMS to maintain, others prefer to use CiviCRM in combination with Drupal/Wordpress. Like many things, there are pros and cons to each approach. In any case everyone seems to be in agreement that it should be easier to use "front-end" CiviCRM pages in remote CMS systems. Many people have faced issues when an organization is using a remote installation of WordPress/Drupal/Joomla/Weebly/Wix/Concrete5/etc but still want to show upcoming events, contribution pages, membership directories, etc. on their remote website CMS.
Filed under
